SIPPING Working Group M. Garcia-Martin
Internet-Draft M. Matuszewski
Intended status: Standards Track Nokia
Expires: June 23, 2007 December 20, 2006
A Session Initiation Protocol (SIP) Event Package and Data Format for
Describing Generic Resources
draft-garcia-sipping-resource-event-package-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
This document specifies the format and semantics associated to a
'resource' event package that allows SIP endpoints to publish the
availability of generic resources. A resource can be, for example,
files (e.g., images, video files, audio files), chat rooms, streaming
content, printers, printer jobs, etc. This event package also allows
SIP endpoints to subscribe to changes in the availability of
resources, or perform searches for the availability and location of a
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 1]
Internet-Draft Generic Resource Event Package December 2006
given resource. Support for partial notifications and publications
is also accomplished by using XML patch operations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The 'resource' Event Package . . . . . . . . . . . . . . . . . 5
3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6
3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
3.4. Subscription duration . . . . . . . . . . . . . . . . . . 6
3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6
3.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 7
3.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 7
3.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 7
3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9
3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9
3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 10
3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10
3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 10
3.14. PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . 11
3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 11
3.16. Multiple Sources for Event State . . . . . . . . . . . . . 11
3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 11
3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 11
4. Resource Document . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Full 'resource' document . . . . . . . . . . . . . . . . . 13
4.2. Partial 'resource' document: patch operations . . . . . . 16
4.3. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1. Example of a full 'resource' document in a
publication . . . . . . . . . . . . . . . . . . . . . 19
4.4.2. Example of a partial 'resource' document used in a
publication . . . . . . . . . . . . . . . . . . . . . 21
4.4.3. Example of a full 'resource' document used in a
notification . . . . . . . . . . . . . . . . . . . . . 22
4.4.4. Example of a partial 'resource' document used in a
notification . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Registration of the 'resource' Event Package . . . . . . . 25
7.2. Registration of the "application/resource+xml" MIME
type . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 2]
Internet-Draft Generic Resource Event Package December 2006
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 3]
Internet-Draft Generic Resource Event Package December 2006
1. Introduction
There are scenarios where a SIP endpoint has a number of available
resources that can be offered for public disposal, for example,
sharing files. One of these cases is, for example, when Alice takes
some pictures with her camera phone and she wants to share them
within a community. This requires a mechanism that allows Alice to
spread the information of the resources that she wants is able to
share.
In another scenario, Alice might be interested in finding out the
availability of a given resource, defined by a set of parameters.
Think, for example, of Alice trying to find pictures of the bowling
tournament that took place recently in her home town. This implies a
mechanism whereby Alice can perform searches of available resources.
The user who performs the search identifies one or more aspects of
the resource she is searching, but probably she is not able to
provide a full description of the resource.
SIP [RFC3261] provides an extensible event mechanism [RFC3265] that
is suitable for our needs. We enabled the above scenarios by
defining a SIP event package for generic resource publication and
search. We define a 'resource' document that allows an Event
Publication Agent (EPA) to provide a description of the locally
available resources in a PUBLISH request [RFC3903]. In a community,
there can be an Event State Compositor that aggregates shared
resources available at different endpoints. The Event State
Compositor (ESC) that receives the PUBLISH request processes
'resource' documents according to a well defined strategy (which is
outside the scope of this document). For example, the ESC can be a
centralized intermediary facilitator for a given community, or it can
be a super-node of a SIP Peer-to-Peer (P2P) network.
A user that searches for one or more resources issues a SUBSCRIBE
request (either a subscription or a fetch of state, see RFC 3265
[RFC3265]) to the 'resource' event package. Because a subscription
to all of the resources published in the community is likely to
contain a large amount of data, the subscriber will typically attach
a filter [RFC4661] that describes the resources under search. This
will result in the generation of one or more NOTIFY requests that
contains the searched items. Once the information on resources is
retrieved, the subscriber can use any suitable mechanism (such as the
one defined in "Session Description Protocol (SDP) Offer/Answer
Mechanism to Enable File Transfer"
[I-D.ietf-mmusic-file-transfer-mech]) to actually download the file.
Such file transfer mechanisms are outside the scope of this memo.
In the context of this document, a resource is anything that can be
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 4]
Internet-Draft Generic Resource Event Package December 2006
addressed by a URI. Sometimes the URI points to the resource itself
(such as the SIP URI of a chat room or an HTTP URI that points to an
image file). In other cases the URI merely resolves to a host where
the content is available (for example, the SIP URI of a camera phone
that stores images).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
3. The 'resource' Event Package
RFC 3265 [RFC3265] defines a SIP extension for subscribing to, and
receiving notifications of changes (events) in the state of remote
nodes. It leaves the definition of many aspects of these events to
concrete extensions, known as event packages. This document
qualifies as an event package. This section fills in the information
required for all event packages by RFC 3265 [RFC3265].
Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP
User Agents to publish event state. According to RFC 3903 [RFC3903]
any event package intended to be used in conjunction with the SIP
PUBLISH method has to include a considerations section. This section
also fills the information for all event packages to be used with
PUBLISH requests.
We define a new 'resource' event package. Event Publication Agents
(EPA) use PUBLISH requests to inform an Event State Compositor (ESC)
of changes in the 'resource' event package. The ESC, acting as a
notifier, notifies subscribers to the 'resource' event package when
changes occur.
3.1. Package Name
The name of this package is 'resource'. As specified in RFC 3265
[RFC3265], this value appears in the Event header field present in
SUBSCRIBE and NOTIFY requests. As specified in the RFC 3903
[RFC3903], this value appears as well in the Event header field
present in PUBLISH requests.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 5]
Internet-Draft Generic Resource Event Package December 2006
3.2. Event Package Parameters
RFC 3265 [RFC3265] allows event packages to define additional
parameters carried in the Event header field. This event package,
'resource', does not define additional parameters.
3.3. SUBSCRIBE Bodies
According to RFC 3265 [RFC3265], a SUBSCRIBE request can contain a
body. The purpose of the body depends on its type. Subscriptions to
the 'resource' event package MAY contain a filter body according to
the format specified in [RFC4661]. Filters are used to reduce the
number of results during searches.
3.4. Subscription duration
From the functional point of view, there are two kinds of
subscriptions to the 'resource' even package. In one, the user may
want to either perform a single search operation on the existing
resources. In the other, the user may want to monitor the changes in
the state information. These functionalities can be controlled by
the duration of the subscription.
A search on existing resources can be implemented with a single fetch
operation (where the Expires header field is set to zero) or by a
subscription of a short duration (typically on the order of a few
minutes). The other functionality, where a user wants to monitor the
changes of a state, is typically implemented as a lengthy
subscription, on the order of hours, as the user needs to be notified
whenever a change in the resource has occurred.
Due to the lack of congruence in the two types of subscriptions, it
is hard to select a default expiration value. We have decided to
select a mean default value that accommodate both types of
subscriptions: 1800 seconds. As per RFC 3265 [RFC3265], the
subscriber MAY specify an alternate expiration in the Expires header
field. It is RECOMMENDED that UACs always include an explicit
Expires header field with the desired subscription value.
3.5. NOTIFY Bodies
As described in RFC 3265 [RFC3265], the NOTIFY message can contain a
body describing the state of the subscribed resources. This body is
either in a format listed in the Accept header field of the SUBSCRIBE
request, or in a package-specific default format, if the Accept
header field was omitted from the SUBSCRIBE request.
In this event package, the body of the notification contains a
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 6]
Internet-Draft Generic Resource Event Package December 2006
'resource' document (see Section 4), expressed as either a full
'resource' document or a partial 'resource' document. The ESC can
receive 'resource' documents from different EPAs or other sources.
The ESC applies a composition policy, and composes a 'resource'
document that contains all the available known resources to the EPA.
If the ESC is not able to resolve a conflict, due to contradictory
information provided by two different EPAs, the ESC provides a
comprehensive information for that resource, so that the subscriber
can resolve the conflict.
All subscribers and notifiers of the 'resource' event package MUST
support the "application/resource+xml" data format described in
Section 4. The SUBSCRIBE request MAY contain an Accept header field.
If no such header field is present, it has a default value of
"application/resource+xml" (assuming that the Event header field
contains a value of 'resource'). If the Accept header field is
present, it MUST include "application/resource+xml", and MAY include
any other types capable of representing 'resource' documents.
3.6. Notifier processing of SUBSCRIBE requests
The contents of a 'resource' document can contain sensitive
information that can reveal some privacy information. For example,
it can contain a list of valuable files and the address of the SIP
User Agent where those are stored. While this information itself is
not very useful, it can be used by malicious agents, e.g., to mount
an attack to avoid other users to retrieve such a file. Therefore,
'resource' documents MUST only be sent to authorized subscribers. In
order to determine if a subscription originates in an authorized
user, the user MUST be authenticated as described in Section 3.6.1
and then he MUST be authorized to be a subscriber as described in
Section 3.6.2.
3.6.1. Authentication
Notifiers SHOULD authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined in RFC
3261 [RFC3261] and other authentication extensions.
3.6.2. Authorization
Once authenticated, the notifier makes an authorization decision. A
notifier MUST NOT accept a subscription unless authorization has been
provided by the user. The means by which authorization are provided
are outside the scope of this document. Authorization may have been
provided ahead of time through access lists, perhaps specified in a
web page, or provided with the Document Format for Expressing Privacy
Preferences [I-D.ietf-geopriv-common-policy].
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 7]
Internet-Draft Generic Resource Event Package December 2006
3.7. Notifier Generation of NOTIFY Requests
RFC 3265 [RFC3265] details the formatting and structure of NOTIFY
messages. However, packages are mandated to provide detailed
information on when to send a NOTIFY, how to compute the state of the
resource, how to generate neutral or fake state information, and
whether state information is complete or partial. This section
describes those details for the 'resource' event package.
A notifier MAY send a NOTIFY at any time. The NOTIFY request MAY
contain a body containing a 'resource' document. The times at which
the NOTIFY is sent to a particular subscriber, and the contents of
the body within that notification, are subject to any rules specified
by the authorization policy that governs the subscription, but
typically will contain an indication of those known resources for
which a change has occurred.
Since 'resource' documents can contain full or partial state, the
first 'resource' document that a notifier sends to subscriber MUST
contain be a full 'resource' documents. Subsequent documents sent to
the same subscriber MAY be full 'resource' documents or partial
'resource' documents (Section 4 provides further discussion about
full and partial 'resource' documents).
In the case of a pending subscription, when final authorization is
determined, a NOTIFY request can be sent. If the result of the
authorization decision was success, a NOTIFY SHOULD be sent and
SHOULD contain a full 'resource' document with the current state of
the resources known by the notifier at that moment. If the
subscription is rejected, a NOTIFY MAY be sent. As described in RFC
3265 [RFC3265], the Subscription-State header field indicates the
state of the subscription.
Frequently, the notifier will have a incomplete view of the available
resources of the document. For the duration of the subscription, the
notifier can be running searches for the availability of the searched
resources. When new state information is made available to the
notifier, the notifier SHOULD provide this information to the
subscribers, typically as notifications that contain a partial
'resource' document.
The body of the NOTIFY MUST be sent using one of the types listed in
the Accept header field in the most recent SUBSCRIBE request, or
using the type "application/resource+xml" if no Accept header field
was present.
Notifiers will typically act as Event State Compositors (ESC) and
thus, will learn the 'resource' event state via PUBLISH requests sent
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 8]
Internet-Draft Generic Resource Event Package December 2006
from the user's Event Publication Agent (EPA) when the user makes a
resource available or via subscriptions passed further to other ESCs.
For reasons of privacy, it will frequently be necessary to encrypt
the contents of the notifications. This can be accomplished using
S/MIME [RFC3851]. The encryption can be performed using the key of
the subscriber as identified in the From field of the SUBSCRIBE
request. Similarly, integrity of the notifications is important to
subscribers. As such, the contents of the notifications MAY provide
authentication and message integrity using S/MIME [RFC3851]. This
will require the notifier to sign the content of the notification
with the notifier's private key.
3.8. Subscriber Processing of NOTIFY Requests
RFC 3265 [RFC3265] leaves it to event packages to describe the
process followed by the subscriber upon receipt of a NOTIFY request,
including any logic required to form a coherent resource state.
In this specification, each NOTIFY request contains either no
'resource' document, a full 'resource' document representing
resources available at one or more SIP User Agents, or a partial
'resource' document that represent changes with respect a previously
notified 'resource' document. Within a dialog, when a 'resource'
document is received in a NOTIFY request with a higher CSeq header
field value than a previously received NOTIFY, and when the 'version'
attribute value of the <patch> element is increased by one (see
Section 4 for more details) it contains a partial 'resource' document
that updates a previously received 'resource' document.
3.9. Handling of Forked Requests
RFC 3265 [RFC3265] requires each package to describe handling of
forked SUBSCRIBE requests.
This specification allows several dialogs to be constructed as a
result of emitting an initial SUBSCRIBE request, i.e., in cases where
the SUBSCRIBE request forked to several notifiers. In this case, the
subscriber will keep several simultaneous dialogs. The subscriber
SHOULD merge the several 'resource' documents received in NOTIFY
requests. It might be possible that new <resource> elements are
received in forked 'resource' documents, or it might be possible that
existing <resource> elements are updated with new information (e.g.,
a new <gruu> element). In both cases the merge should provide a
logical OR operation of all the available information such as new
entries and added information to existing entries.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 9]
Internet-Draft Generic Resource Event Package December 2006
3.10. Rate of Notifications
RFC 3265 [RFC3265] requires each package to specify the maximum rate
at which notifications can be sent.
Notifiers of 'resource' documents SHOULD NOT generate notifications
for a single user at a higher rate than once every second.
3.11. State Agents
RFC 3265 [RFC3265] requires each package to consider the role of
state agents in the package, and if they are used, to specify how
authentication and authorization are done.
This specification allows state agents to be located in the network.
A given resource might be available at different SIP User Agents in
the network. ESCs can act as state agents by compiling and
aggregating state towards, e.g., subscribers, other networks or
communities. State agents MUST use any of the mechanism specified in
RFC 3261 [RFC3261] or any other SIP extension to authenticate and
authorize users prior to accepting publications.
If the state agent acts as an aggregator, the state agent SHOULD
aggregate all the information related to the same available resource.
In this case, it is expected that, because the same resource is
available in different endpoints, there might be different URIs for a
given available resource.
3.12. Examples
Examples of 'resource' documents are provided in Section 4.4.
3.13. Use of URIs to Retrieve State
RFC 3265 [RFC3265] allows packages to use URIs to retrieve large
state documents.
A 'resource' document can be of any arbitrary length, and can also
become too large to be reasonably sent in a SIP request. To avoid
the burden of transmitting large documents through SIP proxies and to
avoid potential congestion scenarios, it is possible that the
notifier instead includes a URI that points to the contents, rather
than the actual contents. For example, the notifier can include an
HTTP [RFC2616] URI that points to the notifier itself. Since HTTP
requests are transferred via a congestion controlled protocol (such
as TCP [RFC0793]), the inclusion of a URI to retrieve state mitigates
the problem of large 'resource' documents.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 10]
Internet-Draft Generic Resource Event Package December 2006
3.14. PUBLISH bodies
RFC 3903 [RFC3903] requires event packages to define the content
types expected in PUBLISH requests.
In this event package, the body of a PUBLISH request contains a
'resource' document (see Section 4). This 'resource' document
describes the availability of one or more resources (typically, but
not necessarily, stored at the EPA). EPAs SHOULD only publish
resources available at its own EPA, i.e., the URI of the resource
SHOULD resolve to the EPA itself.
All EPAs and ESCs MUST support the "application/resource+xml" data
format described in Section 4 and MAY support other formats.
3.15. PUBLISH Response Bodies
This specification does not associate semantics to a body in a
PUBLISH response.
3.16. Multiple Sources for Event State
RFC 3903 [RFC3903] requires event packages to specify whether
multiple sources can contribute to the event state view at the ESC.
This event package allows different EPAs to publish the availability
of the same resource. For the same resource, each EPA will publish
data that is invariant with the instance of the resource, and data
that is specific with each instance. The ESC SHOULD merge the data
pertaining to the same resource according to a composition policy.
This policy can, e.g., list all the difference instances where each
resource is available.
3.17. Event State Segmentation
RFC 3903 [RFC3903] defines segments within a state document. Each
segment is defined as one of potentially many identifiable sections
in the published event state.
In this 'resource' event package, each <resource> element composes a
segment.
3.18. Rate of Publication
RFC 3903 [RFC3903] allows event packages to define their own rate of
publication.
There are no rate limiting recommendations for 'resource'
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 11]
Internet-Draft Generic Resource Event Package December 2006
publication. It is expected that new resources are added at the time
of creation (e.g., a new image is taken with a camera phone), and
that they are not changed often. Thus, a typical rate of publication
does not exist and there is no foreseen need to limit the rate of
publications.
4. Resource Document
A 'resource' document is an XML document [W3C.REC-xml-20001006] that
MUST be well-formed and SHOULD be valid. A 'resource' document MUST
be based on XML 1.0 and MUST be encoded using UTF-8 [RFC3629]. This
specification makes use of XML namespaces for identifying 'resource'
documents. The namespace URI for elements defined by this
specification is a URN [RFC2141], using the namespace identifier
'ietf'. This URN is:
urn:ietf:params:xml:ns:resource
The 'resource' documents are identified with the MIME type
"application/resource+xml" and are instances of the XML schema
defined in Section 4.3.
The XML schema that defines the constrains of the 'resource' document
provides support for full and partial 'resource' documents in both
publications and notifications. The XML schema contains provisions
for two root elements, namely <resource-set> and <patch>, of which
only one MUST be present in a valid 'resource' document. The
<resource-set> element is used to describe a full 'resource'
document, i.e., one containing a full state of the available
resources. A full 'resource' document MUST be used in any initial
publication or initial notification. On the contrary, the <patch>
element is used to describe a partial 'resource' document. The
<patch> element contains a number of patch operations that, once
applied to a previous version of a full 'resource' document, create
an updated full document. Non-initial publications and non-initial
notifications MAY use the partial publication and partial
notification mechanism provided with the <patch> element.
The XML schema rules require that only one root element is present
in an XML document. Therefore, a 'resource' document compliant
with the XML schema definition contains either a <resource-set>
root element or a <patch> root element, but not both.
Due to the duality of a 'resource' document, depending on whether it
contains a full or a partial 'resource' document, we describe
separately each of them in Section 4.1 and Section 4.2, respectively.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 12]
Internet-Draft Generic Resource Event Package December 2006
4.1. Full 'resource' document
A full 'resource' document begins with the root element tag
<resource-set> that describes a collection of resources. The
<resource-set> element contains a mandatory 'version' attribute. The
first publication or notification selects an initial value for the
'version' attribute of the <resource-set> element. Subsequent
publications or notifications, no matter whether they are full or
partial, MUST increment the value of the 'version' attribute by one,
and add it either to the <resource-set> or <patch> element, as
appropriate (depending on whether the SIP request contains a full of
partial 'resource' document). As a consequence, the address space of
the 'version' attribute is shared between <resource-set< and <patch>
elements.
The <resource-set> element consists of one or more child <resource>
elements. The <resource-set> element MAY contain other elements and
attributes from different namespaces for the purposes of
extensibility; elements or attributes from unknown namespaces MUST be
ignored.
Each <resource> element represents the descriptive data of a
resource. It includes an 'id' attribute that contains a unique
identifier. The value of the 'id' attribute MUST be unique within
the 'resource' document.
The <resource> element consists of one <identity> element and one or
more <instance> elements. The <resource> element MAY also contain
other elements and attributes from different namespaces for the
purposes of extensibility; elements or attributes from unknown
namespaces MUST be ignored.
The <identity> element groups a number of elements that represent the
invariant data of the resource, i.e., resource metadata that is
common across different instances of the resource. For example, the
<identity> element provides a description for the hash or size of a
file. On the contrary, data that is specific to the location of the
resource (such as the user's address-of-record, or a human readable
description) are grouped in the <instance> element.
The <identity> element contains an 'id' attribute whose value MUST be
unique within the XML document. The <identity> element can also
contain an 'isfile' attribute, whose default value is set to "true".
The 'isfile' attribute provides an indication of whether the
described resource is a file.
The <identity> element contains zero or one <urn>, <mime-type>,
<size>, and <sha1> elements. The <identity> element MAY also contain
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 13]
Internet-Draft Generic Resource Event Package December 2006
other elements and attributes from different namespaces for the
purposes of extensibility; elements or attributes from unknown
namespaces MUST be ignored.
The <urn> element contains a persistent, location-independent,
resource identifier expressed as a Uniform Resource Name (URN)
[RFC2141] that is allocated to the resource and uniquely identifies
it. If present, the value of the <urn> element MUST be formatted
according to the URN syntax specified in RFC 2141 [RFC2141].
The <mime-type> element contains the Multipurpose Internet Mail
Extensions (MIME) type of the resource. If present, the value of the
<mime-type> element SHOULD contain an IANA registered MIME media type
expressed as type/subtype format.
The <size> element contains the resource size in octets. This is
typically applicable to file resources.
The <sha1> element contains the results of a hashing operation on the
resource. The hashing operation MUST be computed using the US Secure
Hash Algorithm 1 (SHA1) [RFC3174] and MUST be expressed in
hexadecimal format. This is typically applicable to file resources.
One or more <instance> elements can be included in the <resource>
element. Each <instance> element provides information that is
related to a particular instance of the resource, rather than the
resource itself. In publications, EPAs SHOULD include only one
<instance> element per <resource> element, and the data SHOULD
include only the local description of the resource. In
notifications, ESCs MAY include several <instance> elements per
<resource> element. This would be the case when the ESC has acquired
such information, for example, through publications from different
EPAs.
Allowing EPAs to provide a description of non-locally stored
resources could be maliciously used for creating, e.g., denial of
service attacks.
Each <instance> element contains an 'id' attribute whose value MUST
be unique within the XML document. The <instance> element also
contains one or more <uri> elements, and zero or one <user-aor>,
<user-gruu>, <name>, <description> <iconptr>, <creation-date>,
<modification-date>, <read-date> and <keywords> elements.
Additionally, the <instance> element MAY contain other elements and
attributes from different namespaces for the purposes of
extensibility; elements or attributes from unknown namespaces MUST be
ignored.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 14]
Internet-Draft Generic Resource Event Package December 2006
The <uri> element contains a location-dependent, typically protocol-
specific resource identifier express as a Uniform Resource Identifier
(URI) [RFC3986]. If present, the value of the <uri> element MUST be
formatted according to the URN syntax specified in RFC 3986
[RFC3986]. EPAs MUST NOT publish non-local URIs in the <uri>
element, although they MAY publish several URIs for a single
resource, e.g., if the resource is available through several
protocols and URIs.
The <user-aor> provides a container for a SIP, SIPS or similar type
of URI that resolves to the address-of-record of the user where the
resource is available. This might be useful when it is not possible
to provide a URI (in the <uri> element) that resolves to the resource
itself, but instead, there is a URI that resolves to the user that
hosts the resource. EPAs MUST NOT include <user-aor> containing
addresses-of-record that point to other users than the one whose
resources EPA is publishing. ESCs MUST verify that a <user-aor>
received in a PUBLISH request belongs to the same user who published
the request; this requires the ESC to first authenticate the
publisher.
The <user-gruu> provides a Globally Routable User Agent URI (GRUU)
[I-D.ietf-sip-gruu] that points to the SIP instance in the User Agent
where the resource is available. This element completes the <user-
aor> by providing an pointer to the SIP instance that is hosting the
resource.
The <name> element contains the name of the resource. If the
resource is a file, the <name> element is the resource filename.
The <description> element contains a human readable text describing
the resource.
The <iconptr> element contains a URI that points to an icon that
represents the resource. This is typically applicable to image
resources.
The <creation-date> element indicates the date and time at which the
resource was created.
The <modification-date> element indicates the date and time at which
the resource was last modified.
The <read-date> element indicates the date and time at which the
resource was last read.
The <keywords> element is a container of keywords associated to the
resource. Its main purpose is to assist indexing and search engines.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 15]
Internet-Draft Generic Resource Event Package December 2006
The <keywords> element contains one or more <keyword> elements
(notice the singular form of the child elements). The <keywords>
element MAY contain other attributes from different namespaces for
the purposes of extensibility; attributes from unknown namespaces
MUST be ignored.
Each <keyword> element contains one word that represents a keyword
associated to the resource. A <keyword> element SHOULD NOT contain
any white spaces. If several keywords are to be included, each one
should be included in a separate <keyword> element.
4.2. Partial 'resource' document: patch operations
A partial 'resource' document begins with the root element tag
<patch> that describes a collection of XML patch operations
[I-D.ietf-simple-xml-patch-ops] that are to be applied to a previous
version of the document. The <patch> element contains a mandatory
'version' attribute whose address space is shared with the 'version'
attribute of the <resource-set> element. Each new partial 'resource'
document MUST increment the 'version' attribute value by one, with
respect the previously sent version. The value of the 'version'
attribute can be used to ensure consistent updates as the recipient
of the document can use the 'version' number to properly order
received documents and to ensure that updates have not been lost.
The <patch> element consists of one or more child <add>, <replace>,
or <remove> elements whose type definitions are included from the XML
Patch Operations [I-D.ietf-simple-xml-patch-ops] identified with the
namespace "urn:ietf:params:xml:schema:xml-patch-ops".
The <patch> element MAY contain other elements and attributes from
different namespaces for the purposes of extensibility; elements or
attributes from unknown namespaces MUST be ignored.
The <add> element is used to add new content to the 'resource'
document. The details of the <add> element are discussed in the XML
Patch Operations [I-D.ietf-simple-xml-patch-ops].
The <replace> element is used to update content in the 'resource'
document. The details of the <replace> element are discussed in the
XML Patch Operations [I-D.ietf-simple-xml-patch-ops].
The <remove> element is used to remove content from the 'resource'
document. The details of the <remove> element are discussed in the
XML Patch Operations [I-D.ietf-simple-xml-patch-ops].
Once all the patch operations have been applied to the previous
'resource' document, a new full 'resource' document is created with
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 16]
Internet-Draft Generic Resource Event Package December 2006
the same 'version' attribute value, letting a subsequent partial
'resource' document operate on the last full document.
4.3. XML Schema
Implementations according to this specification MUST comply to the
following XML schema that defines the constraints of the 'resource'
document:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:resource"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:resource"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition to provide information about
available resources at a host.
</xs:documentation>
</xs:annotation>
<!-- include xml-patch-ops type definitions -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:xml-patch-ops"/>
<xs:element name="resource-set" type="resource-setType"/>
<xs:element name="patch" type="patchType"/>
<xs:complexType name="resource-setType">
<xs:sequence>
<xs:element name="resource" type="resourceType"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:unsignedInt"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="resourceType">
<xs:sequence>
<xs:element name="identity" type="identityType" />
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 17]
Internet-Draft Generic Resource Event Package December 2006
<xs:element name="instance" type="instanceType"
maxOccurs="unbounded" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="identityType">
<xs:sequence>
<xs:element name="urn" type="xs:anyURI" minOccurs="0"/>
<xs:element name="mime-type" type="xs:string" minOccurs="0"/>
<xs:element name="size" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="sha1" type="xs:hexBinary" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="isfile" type="xs:boolean" default="true"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="instanceType">
<xs:sequence>
<xs:element name="uri" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="user-aor" type="xs:anyURI" minOccurs="0"/>
<xs:element name="user-gruu" type="xs:anyURI" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:element name="iconptr" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="creation-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="modification-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="read-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="keywords" type="keywordsType"
minOccurs="0"/>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 18]
Internet-Draft Generic Resource Event Package December 2006
</xs:complexType>
<xs:complexType name="keywordsType">
<xs:sequence>
<xs:element name="keyword" type="xs:token"
maxOccurs="unbounded" />
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="patchType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="add" type="add"/>
<xs:element name="replace" type="replace"/>
<xs:element name="remove" type="remove"/>
</xs:choice>
<xs:attribute name="version" type="xs:unsignedInt"/>
</xs:complexType>
</xs:schema>
Figure 1: 'resource' document XML schema
4.4. Examples
4.4.1. Example of a full 'resource' document in a publication
Figure 2 is an example of a 'resource' document that can be present
in a PUBLISH request:
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 19]
Internet-Draft Generic Resource Event Package December 2006
<?xml version="1.0" encoding="UTF-8"?>
<resource-set xmlns="urn:ietf:params:xml:ns:resource"
version="123">
<resource id="id38sh12jd">
<identity id="id9d8c9" isfile="true">
<mime-type>image/jpeg</mime-type>
<size>230432</size>
<sha1>72245FE8653DDAF371362F86D471913EE4A2CE2E</sha1>
<identity>
<instance id="idc989c00">
<name>coolpic.jpg</name>
<description>
This is my latest cool picture from my summer vacation
</description>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<user-aor>sip:miguel.an.garcia@example.com</user-aor>
<creation-date>2006-05-09T09:30:47+03:00</creation-date>
<modification-date>
2006-05-09T10:24:34+03:00
</modification-date>
<read-date>2006-05-10T14:24:32+03:00</read-date>
<icon-ptr>http://www.example.com/coolpic-icon.jpg</icon-ptr>
<keywords>
<keyword>summer</keyword>
<keyword>vacation</keyword>
</keywords>
</instance>
</resource>
</resource-set>
Figure 2: Example of a full 'resource' document used in a publication
The example in Figure 2 shows a full 'resource' document that an EPA
provides to the ESC. The example contains the description of a
single resource: an image file. The EPA provides description of the
resource (an <resource> element) that contains the static data of the
resource included in the <identity> element and the variable data
(that depends on the actual instance of the resource) in the
<instance> element. The <identity> element contains a number of
characteristics of the resource that wouldn't change across different
instances, such as the MIME type, the size, and the hash of the
resource. On the contrary, the <instance> element contains the data
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 20]
Internet-Draft Generic Resource Event Package December 2006
related to the particular instance of the resource, such as the name
assigned by the user to the resource, a human readable description,
the GRUU that points to the SIP User Agent where the resource is
stored, the creation, modification, and read dates, etc.
4.4.2. Example of a partial 'resource' document used in a publication
Figure 3 is an example of a partial 'resource' document that can be
present in a PUBLISH request:
<?xml version="1.0" encoding="UTF-8"?>
<patch xmlns="urn:ietf:params:xml:ns:resource"
version="124">
<add sel="resource-set">
<resource id="b390d92">
<identity id="mm8b8d" isfile="false">
<mime-type>meessage/msrp</mime-type>
</identity>
<instance id="hhdu23">
<name>IETFers chat room</name>
<description>
Dedicated chat room for IETF discussions
</description>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<user-aor>sip:miguel.an.garcia@example.com</user-aor>
</instance>
</resource>
</add>
</patch>
Figure 3: Example of a partial 'resource' document used in a
publication
The example in Figure 3 shows an example of a partial 'resource'
document that a EPA is sending to an ESC. The document contains the
patch operations that adds one more new resource to the existing
list. The 'version' attribute of the <patch> element is incremented
by one with respect the 'version' attribute of the <resource-set>
element of the full 'resource' document in Figure 2.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 21]
Internet-Draft Generic Resource Event Package December 2006
4.4.3. Example of a full 'resource' document used in a notification
Figure 4 is an example of a full 'resource' document that can be
present in a NOTIFY request:
<?xml version="1.0" encoding="UTF-8"?>
<resource-set xmlns="urn:ietf:params:xml:ns:resource"
version="312">
<resource id="nkcdn0">
<identity id="aa77d7">
<mime-type>audio/3gpp</mime-type>
<size>34987</size>
<sha1>E05DA01A590E31F6E3100AD7BEC39C63464A1CD0</sha1>
<identity>
<instance id="idea1dof">
<name>recording-1.3gp</name>
<description>
Bob's speech at a conference
</description>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<user-aor>sip:miguel.an.garcia@example.com</user-aor>
<creation-date>2006-05-01T01:30:47+03:00</creation-date>
<modification-date>
2006-05-02T02:24:34+03:00
</modification-date>
<read-date>2006-05-03T03:24:32+03:00</read-date>
<keywords>
<keyword>Bob</keyword>
<keyword>speech</keyword>
</keywords>
</instance>
<instance id="kxf-312">
<name>bob-speech.3gp</name>
<description>
Bob talking about nanotechnology
</description>
<user-gruu>
sip:alice@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-4de9-00a2ac4e398a
</user-gruu>
<user-aor>sip:alice@example.com</user-aor>
<creation-date>2006-05-01T01:30:47+03:00</creation-date>
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 22]
Internet-Draft Generic Resource Event Package December 2006
<modification-date>
2006-05-02T02:24:34+03:00
</modification-date>
<read-date>2006-05-24T05:12:07+02:00</read-date>
<keywords>
<keyword>Bob</keyword>
<keyword>nanotechnology</keyword>
</keywords>
</instance>
</resource>
</resource-set>
Figure 4: Example of a full 'resource' document used in notifications
The example in Figure 4 shows an example of a full 'resource'
document that a ESC is sending to a subscriber. The document
describes a single resource, an audio file, which is available at two
difference hosts, thus, the 'resource' document starts with a
<resource-set> element that contains the description of the resource
in the <resource> element. The <resource> element contains an
<identity> element and two <instance> elements. The <identity>
element contains descriptive invariant data of the resource. Each of
the <instance> elements contains data related to the particular
instance where the resource is available.
4.4.4. Example of a partial 'resource' document used in a notification
Figure 5 is an example of a partial 'resource' document that can be
present in a NOTIFY request:
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 23]
Internet-Draft Generic Resource Event Package December 2006
<?xml version="1.0" encoding="UTF-8"?>
<patch xmlns="urn:ietf:params:xml:ns:resource"
version="313">
<add sel="resource-set/resource[@id='nkcdn0']">
<instance id="ak6v3d">
<name>nanotalk.3gp</name>
<description>
Nanotechnology speech
</description>
<user-gruu>
sip:bob@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-5d3a-bbc333431122
</user-gruu>
<user-aor>sip:bob@example.com</user-aor>
</instance>
</add>
<replace sel="id=('idea1dof')/read-date/text()"
>2006-06-07T17:26:04+03:00</replace>
</patch>
Figure 5: Example of a partial 'resource' document used in a
notification
Figure 5 contains a number of XML patch operations to be applied to
the full 'resource' document included in Figure 4. The document in
Figure 5 starts with a <patch> root element, indicating that it is a
partial 'resource' document. The 'version' attribute is incremented
by one with respect the 'version' attribute of the <resource-set>
element of the full 'resource' document of Figure 4.
The document contains an <add> element that first selects the
<resource> element whose 'id' attribute is set to "nkcdn0". Then it
appends, at then of the existing child elements, a new <instance>
element that describes the availability of the same resource at a
different endpoint.
The <replace> element selects the <read-date> element of the
<instance> whose 'id' attribute is set to "idea1dof" and replaces the
value with a new date and time.
Note: the 'sel' attribute of the <replace> element in Figure 5 is
split in two lines due to formatting restrictions. It will appear
as a single line in XML documents.
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 24]
Internet-Draft Generic Resource Event Package December 2006
5. Security Considerations
TBD
6. Acknowledgements
The authors want to thank Jari Urpalainen for providing extensive
guidance with the XML schema definition and support for partial
publication and notification. Nicklas Beijar and Juuso Lehtinen held
fruitful discussions with the authors that lead to the design of this
event package. Pekka Kuure and Arto Leppisaari provided helpful
comments during the initial review.
7. IANA Considerations
7.1. Registration of the 'resource' Event Package
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [RFC3265]. The following
is the information required for such a registration:
Package Name: resource
Package or Template-Package: This is a package.
Published Document: RFC XXX [Replace by the RFC number of this
specification].
Person to Contact: Miguel A. Garcia-Martin,
miguel.an.garcia@nokia.com
7.2. Registration of the "application/resource+xml" MIME type
To: ietf-types@iana.org
Subject: Registration of MIME media type application/resource+xml
MIME media type name: application
MIME subtype name: resource+xml
Required parameters: (none)
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 25]
Internet-Draft Generic Resource Event Package December 2006
Optional parameters: charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 [RFC3629].
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], Section 3.2.
Security considerations: TBD
Interoperability considerations: none
Published specification: RFC XXXX (this document).
Applications which use this media type: publication and share of
resource availability.
Additional information: none
Person & email address to contact for further information: Miguel
A. Garcia-Martin, miguel.an.garcia@nokia.com
Intended usage: Limited use, resource sharing for SIP user agents.
Author/Change controller: IETF, SIPPING Worknig Group.
Other information: This media type is a specialization of
application/xml RFC 3023 [RFC3023], and many of the considerations
described there also apply to application/resource+xml.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 26]
Internet-Draft Generic Resource Event Package December 2006
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[W3C.REC-xml-20001006]
Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)",
W3C FirstEdition REC-xml-20001006, October 2000.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-11 (work in progress),
October 2006.
[I-D.ietf-simple-xml-patch-ops]
Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-02 (work in
progress), March 2006.
8.2. Informative References
[I-D.ietf-mmusic-file-transfer-mech]
Garcia-Martin, M., "A Session Description Protocol (SDP)
Offer/Answer Mechanism to Enable File Transfer",
draft-ietf-mmusic-file-transfer-mech-00 (work in
progress), December 2006.
[I-D.ietf-geopriv-common-policy]
Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 27]
Internet-Draft Generic Resource Event Package December 2006
August 2006.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format
for Event Notification Filtering", RFC 4661,
September 2006.
Authors' Addresses
Miguel A. Garcia-Martin
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: miguel.an.garcia@nokia.com
Marcin Matuszewski
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: marcin.matuszewski@nokia.com
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 28]
Internet-Draft Generic Resource Event Package December 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 29]