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 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 elements are received in forked 'resource' documents, or it might be possible that existing elements are updated with new information (e.g., a new 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 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 and , of which only one MUST be present in a valid 'resource' document. The 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 element is used to describe a partial 'resource' document. The 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 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 root element or a 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 that describes a collection of resources. The element contains a mandatory 'version' attribute. The first publication or notification selects an initial value for the 'version' attribute of the 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 or 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 elements. The element consists of one or more child elements. The 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 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 element consists of one element and one or more elements. The 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 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 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 element. The element contains an 'id' attribute whose value MUST be unique within the XML document. The 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 element contains zero or one , , , and elements. The 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 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 element MUST be formatted according to the URN syntax specified in RFC 2141 [RFC2141]. The element contains the Multipurpose Internet Mail Extensions (MIME) type of the resource. If present, the value of the element SHOULD contain an IANA registered MIME media type expressed as type/subtype format. The element contains the resource size in octets. This is typically applicable to file resources. The 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 elements can be included in the element. Each 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 element per element, and the data SHOULD include only the local description of the resource. In notifications, ESCs MAY include several elements per 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 element contains an 'id' attribute whose value MUST be unique within the XML document. The element also contains one or more elements, and zero or one , , , , , , and elements. Additionally, the 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 element contains a location-dependent, typically protocol- specific resource identifier express as a Uniform Resource Identifier (URI) [RFC3986]. If present, the value of the element MUST be formatted according to the URN syntax specified in RFC 3986 [RFC3986]. EPAs MUST NOT publish non-local URIs in the element, although they MAY publish several URIs for a single resource, e.g., if the resource is available through several protocols and URIs. The 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 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 containing addresses-of-record that point to other users than the one whose resources EPA is publishing. ESCs MUST verify that a received in a PUBLISH request belongs to the same user who published the request; this requires the ESC to first authenticate the publisher. The 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 by providing an pointer to the SIP instance that is hosting the resource. The element contains the name of the resource. If the resource is a file, the element is the resource filename. The element contains a human readable text describing the resource. The element contains a URI that points to an icon that represents the resource. This is typically applicable to image resources. The element indicates the date and time at which the resource was created. The element indicates the date and time at which the resource was last modified. The element indicates the date and time at which the resource was last read. The 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 element contains one or more elements (notice the singular form of the child elements). The element MAY contain other attributes from different namespaces for the purposes of extensibility; attributes from unknown namespaces MUST be ignored. Each element contains one word that represents a keyword associated to the resource. A element SHOULD NOT contain any white spaces. If several keywords are to be included, each one should be included in a separate element. 4.2. Partial 'resource' document: patch operations A partial 'resource' document begins with the root element tag 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 element contains a mandatory 'version' attribute whose address space is shared with the 'version' attribute of the 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 element consists of one or more child , , or 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 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 element is used to add new content to the 'resource' document. The details of the element are discussed in the XML Patch Operations [I-D.ietf-simple-xml-patch-ops]. The element is used to update content in the 'resource' document. The details of the element are discussed in the XML Patch Operations [I-D.ietf-simple-xml-patch-ops]. The element is used to remove content from the 'resource' document. The details of the 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 Schema Definition to provide information about available resources at a host. Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 17] Internet-Draft Generic Resource Event Package December 2006 Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 18] Internet-Draft Generic Resource Event Package December 2006 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 image/jpeg 230432 72245FE8653DDAF371362F86D471913EE4A2CE2E coolpic.jpg This is my latest cool picture from my summer vacation sip:miguel.an.garcia@example.com; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 sip:miguel.an.garcia@example.com 2006-05-09T09:30:47+03:00 2006-05-09T10:24:34+03:00 2006-05-10T14:24:32+03:00 http://www.example.com/coolpic-icon.jpg summer vacation 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 element) that contains the static data of the resource included in the element and the variable data (that depends on the actual instance of the resource) in the element. The 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 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: meessage/msrp IETFers chat room Dedicated chat room for IETF discussions sip:miguel.an.garcia@example.com; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 sip:miguel.an.garcia@example.com 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 element is incremented by one with respect the 'version' attribute of the 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: audio/3gpp 34987 E05DA01A590E31F6E3100AD7BEC39C63464A1CD0 recording-1.3gp Bob's speech at a conference sip:miguel.an.garcia@example.com; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 sip:miguel.an.garcia@example.com 2006-05-01T01:30:47+03:00 2006-05-02T02:24:34+03:00 2006-05-03T03:24:32+03:00 Bob speech bob-speech.3gp Bob talking about nanotechnology sip:alice@example.com; gr=urn:uuid:f81d4fae-7dec-11d0-4de9-00a2ac4e398a sip:alice@example.com 2006-05-01T01:30:47+03:00 Garcia-Martin & Matuszewski Expires June 23, 2007 [Page 22] Internet-Draft Generic Resource Event Package December 2006 2006-05-02T02:24:34+03:00 2006-05-24T05:12:07+02:00 Bob nanotechnology 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 element that contains the description of the resource in the element. The element contains an element and two elements. The element contains descriptive invariant data of the resource. Each of the 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 nanotalk.3gp Nanotechnology speech sip:bob@example.com; gr=urn:uuid:f81d4fae-7dec-11d0-5d3a-bbc333431122 sip:bob@example.com 2006-06-07T17:26:04+03:00 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 root element, indicating that it is a partial 'resource' document. The 'version' attribute is incremented by one with respect the 'version' attribute of the element of the full 'resource' document of Figure 4. The document contains an element that first selects the element whose 'id' attribute is set to "nkcdn0". Then it appends, at then of the existing child elements, a new element that describes the availability of the same resource at a different endpoint. The element selects the element of the whose 'id' attribute is set to "idea1dof" and replaces the value with a new date and time. Note: the 'sel' attribute of the 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]