SIPPING Working Group M. Garcia-Martin Internet-Draft Nokia Siemens Networks Intended status: Standards Track M. Matuszewski Expires: December 10, 2007 Nokia June 8, 2007 A Session Initiation Protocol (SIP) Event Package and Data Format for Describing Files draft-garcia-sipping-file-event-package-00 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 December 10, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies the format and semantics associated to a 'file' event package that allows SIP endpoints to publish the availability of files. A file can be, for example, images, video files, audio files, etc. File descriptors are provided in an eXtended Mark-up Language (XML) 'file-metadata' document. This event package also allows SIP endpoints to subscribe to changes in the Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 1] Internet-Draft File Event Package in SIP June 2007 availability of files, or perform searches for the availability and location of a given file. 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 'file' Event Package . . . . . . . . . . . . . . . . . . . 5 3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . 7 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9 3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10 3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 10 3.14. PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . 10 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. The 'file-metadata' Document . . . . . . . . . . . . . . . . . 12 4.1. Full 'file-metadata' document . . . . . . . . . . . . . . 12 4.2. Partial 'file-metadata' document: patch operations . . . . 15 4.3. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4.1. Example of a full 'file-document' document in a publication . . . . . . . . . . . . . . . . . . . . . 19 4.4.2. Example of a partial 'file-metadata' document used in a publication . . . . . . . . . . . . . . . . . . . 21 4.4.3. Example of a full 'file-metadata' document used in a notification . . . . . . . . . . . . . . . . . . . . 22 4.4.4. Example of a partial 'file-metadata' document used in a notification . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7.1. Registration of the 'file' Event Package . . . . . . . . . 25 7.2. Registration of the "application/file+xml" MIME type . . . 25 Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 2] Internet-Draft File Event Package in SIP June 2007 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 December 10, 2007 [Page 3] Internet-Draft File Event Package in SIP June 2007 1. Introduction There are scenarios where a SIP endpoint has a number of available files that can be offered for public disposal or for a limited number of authorized users. 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 describe the files she wants to share. In another scenario, Alice might be interested in finding out the availability of a given file, 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 files. The user who performs the search identifies one or more aspects of the file she is searching, but probably she is not able to provide a full description of the file. SIP [RFC3261] provides an extensible event mechanism [RFC3265] that is suitable for our needs. We enable the above scenarios by defining a SIP event package for file metadata publication and search. We define a 'file-metadata' document that allows an Event Publication Agent (EPA) to provide a description of locally available files in a PUBLISH request [RFC3903]. In a community, there can be an Event State Compositor that aggregates shared files available at different endpoints. The Event State Compositor (ESC) that receives the PUBLISH request processes 'file-metadata' 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 files issues a SUBSCRIBE request (either a subscription or a fetch of state, see RFC 3265 [RFC3265]) to the 'file' event package. Because a subscription to all of the files published in the community is likely to contain a large amount of data, the subscriber will typically attach a filter [RFC4661] that describes the files under search. This will result in the generation of one or more NOTIFY requests that contains the searched items. Once the information on files 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 file descriptor, smetimes the URI points to the file itself itself (such as an HTTP URI that points to an image file). In other Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 4] Internet-Draft File Event Package in SIP June 2007 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 'file' 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 'file' event package. Event Publication Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in the 'file' event package. The ESC, acting as a notifier, notifies subscribers to the 'file' event package when changes occur. 3.1. Package Name The name of this package is 'file'. 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. 3.2. Event Package Parameters RFC 3265 [RFC3265] allows event packages to define additional parameters carried in the Event header field. This event package, 'file', does not define additional parameters. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 5] Internet-Draft File Event Package in SIP June 2007 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 'file' 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 'file' even package. In one, the user may want to either perform a single search operation on the existing files. In the other, the user may want to monitor the changes in the state information of files. These functionalities can be controlled by the duration of the subscription. A search on existing files 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 file 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 'file- metadata' document (see Section 4), expressed as either a full 'file- metadata' document or a partial 'file-metadata' document. The ESC can receive 'file-metadata' documents from different EPAs or other sources. The ESC applies a composition policy, and composes a 'file- metadata' document that contains all the available known files to the EPA. If the ESC is not able to resolve a conflict, due to Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 6] Internet-Draft File Event Package in SIP June 2007 contradictory information provided by two different EPAs, the ESC provides a comprehensive information for that file, so that the subscriber can resolve the conflict. All subscribers and notifiers of 'file' event package MUST support the "application/file+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/ file+xml" (assuming that the Event header field contains a value of 'file'). If the Accept header field is present, it MUST include "application/file+xml", and MAY include any other types capable of representing 'file-metadata' documents. 3.6. Notifier processing of SUBSCRIBE requests The contents of a 'file-metadata' document can contain sensitive information that can reveal some privacy information. For example, it can contain a list of valuable files and the address (SIP URI) 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, 'file-metadata' 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 Common Policy Framework [RFC4745]. 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 request, how to compute the state of the resource, how to generate neutral or fake state Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 7] Internet-Draft File Event Package in SIP June 2007 information, and whether state information is complete or partial. This section describes those details for the 'file' event package. A notifier MAY send a NOTIFY at any time. The NOTIFY request MAY contain a body containing a 'file-metadata' 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 files for which a change has occurred. Since 'file-metadata' documents can contain full or partial state, the first 'file-metadata' document that a notifier sends to subscriber MUST contain be a full 'file-metadata' document. Subsequent documents sent to the same subscriber MAY contain full 'file-metadata' documents or partial 'file-metadata' documents (Section 4 provides further discussion about full and partial 'file- metadata' 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 'file-metadata' document with the current state of the files 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 files described in a 'file-metadata' document. For the duration of the subscription, the notifier can be running searches for the availability of the searched files. 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 'file-metadata' 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/file+xml" if no Accept header field was present. Notifiers will typically act as Event State Compositors (ESC) and thus, will learn the 'file' event state via PUBLISH requests sent from the user's Event Publication Agent (EPA) when the user makes one or more files available or via subscriptions passed further to other ESCs. For reasons of privacy, it will frequently be necessary to encrypt Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 8] Internet-Draft File Event Package in SIP June 2007 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 'file- metadata' document, a full 'file-metadata' document representing files which are available at one or more SIP User Agents, or a partial 'file-metadata' document that represent changes with respect a previously notified 'file-metadata' document. Within a dialog, when a 'file-metadata' 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 'file-metadata' document that updates a previously received 'file-metadata' 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 'file-metadata' documents received in NOTIFY requests. It might be possible that new elements are received in forked 'file-metadata' 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. 3.10. Rate of Notifications RFC 3265 [RFC3265] requires each package to specify the maximum rate at which notifications can be sent. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 9] Internet-Draft File Event Package in SIP June 2007 Notifiers of 'file-metadata' 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 file 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 file. In this case, it is expected that, because the same file is available in different endpoints, there might be different URIs for a given available file. 3.12. Examples Examples of 'file-metadata' 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 'file-metadata' 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 'file-metadata' documents. 3.14. PUBLISH bodies RFC 3903 [RFC3903] requires event packages to define the content types expected in PUBLISH requests. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 10] Internet-Draft File Event Package in SIP June 2007 In this event package, the body of a PUBLISH request contains a 'file-metadata' document (see Section 4). This 'file-metadata' document describes the availability of one or more files (typically, but not necessarily, stored at the EPA). EPAs SHOULD only publish the description of locally available files, i.e., the URI of the file SHOULD resolve to the EPA itself. All EPAs and ESCs MUST support the "application/file+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 file. For the same file, each EPA publishes data that is invariant with the instance of the file, and data that is specific with each instance. The ESC SHOULD merge the data pertaining to the same file according to a composition policy. This policy can, e.g., list all the difference instances where each file 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 'file' 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 'file' publication. It is expected that new files 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. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 11] Internet-Draft File Event Package in SIP June 2007 4. The 'file-metadata' Document A 'file-metadata' document is an XML document [W3C.REC-xml-20001006] that MUST be well-formed and SHOULD be valid. A 'file-metadata' 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 'file-metadata' 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:file The 'file-metadata' documents are identified with the MIME type "application/file+xml" and are instances of the XML schema defined in Section 4.3. The XML schema that defines the constrains of the 'file-metadata' document provides support for full and partial 'file-metadata' 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 'file-metadata' document. The element is used to describe a full 'file- metadata' document, i.e., one containing a full state of the available files. A full 'file-metadata' document MUST be used in any initial publication or initial notification. On the contrary, the element is used to describe a partial 'file-metadata' document. The element contains a number of patch operations that, once applied to a previous version of a full 'file-metadata' 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 'file-metadata' 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 'file-metadata' document, depending on whether it contains a full or a partial 'file-metadata' document, we describe separately each of them in Section 4.1 and Section 4.2, respectively. 4.1. Full 'file-metadata' document A full 'file-metadata' document begins with the root element tag that describes a collection of files. The element contains a mandatory 'version' attribute. The first publication or notification selects an initial value for the Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 12] Internet-Draft File Event Package in SIP June 2007 '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 'file' document). As a consequence, the counter 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 description data of a file. It includes an 'id' attribute that contains a unique identifier. The value of the 'id' attribute MUST be unique within the 'file-metadata' 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 file, i.e., file metadata that is common across different instances of the file. 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 file (such as the user's address-of-record who hosts the file, 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 contains zero or one , , , and 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 contains a persistent, location-independent, resource identifier expressed as a Uniform Resource Name (URN) [RFC2141] that is allocated to the file and uniquely identifies it. If present, the value of the element MUST be formatted according to the URN syntax specified in RFC 2141 [RFC2141]. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 13] Internet-Draft File Event Package in SIP June 2007 The element contains the Multipurpose Internet Mail Extensions (MIME) type of the file. If present, the value of the element SHOULD contain an IANA registered MIME media type expressed as type/subtype format. The element contains the file size in octets. The element contains the results of a hashing operation on the file. The hashing operation MUST be computed using the US Secure Hash Algorithm 1 (SHA1) [RFC3174] and MUST be expressed in hexadecimal format. One or more elements can be included in the element. Each element provides information that is related to a particular instance of the file, rather than the file itself. In publications, EPAs SHOULD include only one element per element, and the data SHOULD include only the local description of the file. 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 files 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. The element contains a location-dependent, typically protocol- specific file identifier expressed 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 file, e.g., if the file 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 file is available. This might be useful when it is not possible to provide a URI (in the element) that resolves to the file Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 14] Internet-Draft File Event Package in SIP June 2007 itself, but instead, there is a URI that resolves to the user that hosts the file. EPAs MUST NOT include containing addresses-of-record that point to other users than the one whose file 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 file is available. This element completes the by providing an pointer to the SIP instance that is hosting the file. The element contains the filename. The element contains a human readable text describing the file. The element contains a URI that points to an icon that represents the file. This is typically applicable to image or video files. The element indicates the date and time at which the file was created. The element indicates the date and time at which the file was last modified. The element indicates the date and time at which the file was last read. The element is a container of keywords associated to the file. Its main purpose is to assist indexing and search engines. 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 file. 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 'file-metadata' document: patch operations A partial 'file-metadata' 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 Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 15] Internet-Draft File Event Package in SIP June 2007 version of a full 'file-metadata' document. The element contains a mandatory 'version' attribute whose counter is shared with the 'version' attribute of the element. Each new partial 'file-metadata' 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 'file-metadata' 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 'file- metadata' 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 'file- metadata' 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 full 'file-metadata' document, a new full 'file-metadata' document is created with the same 'version' attribute value, letting a subsequent partial 'file-metadata' 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 'file- metadata' document: XML Schema Definition to provide information about available files at a host. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 17] Internet-Draft File Event Package in SIP June 2007 Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 18] Internet-Draft File Event Package in SIP June 2007 Figure 1: 'file-metadata' document XML schema 4.4. Examples 4.4.1. Example of a full 'file-document' document in a publication Figure 2 is an example of a 'file-metadata' document that can be present in a PUBLISH request: Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 19] Internet-Draft File Event Package in SIP June 2007 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 'file-metadtaa' document used in a publication The example in Figure 2 shows a full 'file-metadata' document that an EPA provides to the ESC. The example contains the description of a single file: an image file. The EPA provides description of the file (an element) that contains the static data of the file included in the element and the variable data (that depends on the actual instance of the file) in the element. The element contains a number of characteristics of the file that would not change across different instances, such as the MIME type, the size, and the hash of the file. On the contrary, Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 20] Internet-Draft File Event Package in SIP June 2007 the element contains the data related to the particular instance of the file, such as the name assigned by the user to the file, a human readable description, the GRUU that points to the SIP User Agent where the file is stored, the creation, modification, and read dates, etc. 4.4.2. Example of a partial 'file-metadata' document used in a publication Figure 3 is an example of a partial 'file-metadata' document that can be present in a PUBLISH request: message/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 'file-metadata' document used in a publication The example in Figure 3 shows an example of a partial 'file-metadata' document that a EPA is sending to an ESC. The document contains the patch operations that adds one more new files 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 'file-metadata' document in Figure 2. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 21] Internet-Draft File Event Package in SIP June 2007 4.4.3. Example of a full 'file-metadata' document used in a notification Figure 4 is an example of a full 'file-metadata' 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 Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 22] Internet-Draft File Event Package in SIP June 2007 2006-05-01T01:30:47+03:00 2006-05-02T02:24:34+03:00 2006-05-24T05:12:07+02:00 Bob nanotechnology Figure 4: Example of a full 'file-metadata' document used in notifications The example in Figure 4 shows an example of a full 'file-metadata' document that a ESC is sending to a subscriber. The document describes a single audio file, which is available at two difference hosts, thus, the 'file-metadata' document starts with a element that contains the description of the file in the element. The element contains an element and two elements. The element contains descriptive invariant data of the file. Each of the elements contains data related to the particular instance where the file is available. 4.4.4. Example of a partial 'file-metadata' document used in a notification Figure 5 is an example of a partial 'file-metadata' document that can be present in a NOTIFY request: Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 23] Internet-Draft File Event Package in SIP June 2007 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 'file-metadata' document used in a notification Figure 5 contains a number of XML patch operations to be applied to the full 'file-metadata' document included in Figure 4. The document in Figure 5 starts with a root element, indicating that it is a partial 'file-metadata' document. The 'version' attribute is incremented by one with respect the 'version' attribute of the element of the full 'file-metadata' 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 file 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 December 10, 2007 [Page 24] Internet-Draft File Event Package in SIP June 2007 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 'file' 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: file 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.garcia@nsn.com 7.2. Registration of the "application/file+xml" MIME type To: ietf-types@iana.org Subject: Registration of MIME media type application/file+xml MIME media type name: application MIME subtype name: file+xml Required parameters: (none) Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 25] Internet-Draft File Event Package in SIP June 2007 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 file availability. Additional information: none Person & email address to contact for further information: Miguel A. Garcia-Martin, miguel.garcia@nsn.com Intended usage: Limited use, file 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/file+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 December 10, 2007 [Page 26] Internet-Draft File Event Package in SIP June 2007 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., Maler, E., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium 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-13 (work in progress), April 2007. [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-03 (work in progress), June 2007. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 27] Internet-Draft File Event Package in SIP June 2007 [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. [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. Authors' Addresses Miguel A. Garcia-Martin Nokia Siemens Networks P.O.Box 6 Nokia Siemens Networks, FIN 02022 Finland Email: miguel.garcia@nsn.com Marcin Matuszewski Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland Email: marcin.matuszewski@nokia.com Garcia-Martin & Matuszewski Expires December 10, 2007 [Page 28] Internet-Draft File Event Package in SIP June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 December 10, 2007 [Page 29]