SIPPING Working Group M. Garcia-Martin Internet-Draft M. Matuszewski Intended status: Standards Track Nokia Expires: June 23, 2007 N. Beijar J. Lehtinen Helsinki University of Technology December 20, 2006 A Framework for Sharing Resources with the Session Initiation Protocol (SIP) draft-garcia-sipping-resource-sharing-framework-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 memo proposes a SIP framework used for advertising and searching for shared resources, such as services or files, within a given community. The memo defines the signaling used by users to signal the availability of resources stored in their User Agents (UA). It Garcia-Martin, et al. Expires June 23, 2007 [Page 1] Internet-Draft SIP Resource Sharing Framework December 2006 also provides the signaling for users to perform searches of available resources and monitor changes in existing resources. Additionally, we provide the signaling used to access a resource. These methods can be used in (but are not limited to) SIP peer-to- peer systems based on centralized, semi-centralized or fully distributed architectures. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Document Conventions . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. File Publication . . . . . . . . . . . . . . . . . . . . . 5 3.2. File Search . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. File Directory Through Presence Information . . . . . . . 6 3.4. File Download . . . . . . . . . . . . . . . . . . . . . . 7 4. Resource Publication . . . . . . . . . . . . . . . . . . . . . 7 4.1. Resource Publication in Support of Search Operations . . . 7 4.1.1. Initial Resource Metadata Publication . . . . . . . . 7 4.1.2. Publication of Modified Resource Metadata . . . . . . 9 4.1.3. Actions Performed by the ESC . . . . . . . . . . . . . 9 4.2. Resource Publication in Support of Directory Operations . 10 5. Search Operation . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Sending a Search Request . . . . . . . . . . . . . . . . . 12 5.2. Reporting Search Results . . . . . . . . . . . . . . . . . 12 5.3. Propagating Searches . . . . . . . . . . . . . . . . . . . 13 5.3.1. Searching Based on Flooding . . . . . . . . . . . . . 13 5.3.2. Searching Based on Distributed Hash Tables (DHT) . . . 14 5.4. Terminating a Search Request . . . . . . . . . . . . . . . 14 5.5. Example of a Search Filter . . . . . . . . . . . . . . . . 14 6. Directory Operations Through Presence Information . . . . . . 16 7. Accessing a Resource . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Garcia-Martin, et al. Expires June 23, 2007 [Page 2] Internet-Draft SIP Resource Sharing Framework December 2006 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events framework [RFC3265] to provide a mechanism whereby a user can subscribe to state changes of resources and get notifications when the state of the resource changes. SIP also provides a publication mechanism [RFC3903] that allows a user to supply resource metadata related to the state and changes in the state of such resource. A 'resource' event package [I-D.garcia-sipping-resource-event-package] is used to allow SIP User Agents to publish, subscribe, and get notifications of the availability of generic resources, where a resource can be, for example, a file (e.g., images, video files, audio files), a chat room, streaming content, a printer, a printer job, etc. All these building blocks can easily be combined to provide a generic mechanism whereby users can provide the availability at their user agents of resources of any kind. The mechanism can also provide a directory search within a publishing community, so that members of the community can search for the availability of resources that have been made available by other members of the same community, and then further access those resources (e.g., join a chat room or download a file, etc.). Think for example of a user, Alice, who wants to make a set of image files available to members of her family. She sets up a SIP peer-to- peer network with her family, and publishes the resouce metadata describing her available files. The resource metadata is stored in the peer nodes, in the user agents of Alice's family members. Then, Bob, a member of the same SIP peer-to-peer network, wants to acquire those pictures, tagged with a keyword 'vacation'. He defines the search criteria; his SIP UA creates an appropriate filter and sets up a short subscription by sending it to the SIP peer-to-peer network. Then he receives notifications from the different peer nodes, containing a metadata describing the searched files. In another scenario, a centralized server can be used to aggregate all the state resource metadata. This might be useful in cases where several instances of the same resource are available at different SIP user agents. The server will act as a state agent (defined in RFC 3265 [RFC3265]) and Event State Compositor (ESC) (defined in RFC 3903 [RFC3903]). The aggregation that the server relieves the endpoints from doing the aggregation itself, so this is an interesting scenario in deployments that involve endpoints with limited processing capability and network bandwidth. A hybrid scenario is also possible, where, for example, User Agents act as secondary nodes (ordinary peers) in a SIP peer-to-peer Garcia-Martin, et al. Expires June 23, 2007 [Page 3] Internet-Draft SIP Resource Sharing Framework December 2006 network. ESCs are primary nodes (super peers). In this scenario, publication of resource metadata and search operations takes place between the secondary and the primary nodes. The primary nodes keep the state consistent among themselves proactively according to a well-defined algorithm (e.g. Chord), or alternatively, distribute the search request among themselves reactively as a resource is needed. This memo describes a framework where SIP is used for advertising and searching for shared resources, such as services or files. The framework defines the signaling used for users to signal the availability of resources stored in their User Agents (UA). It also provides the signaling used for users to perform searches of available resources and monitor changes in existing resources. Additionally, signaling used to access a resource from a remote UA is provided. These methods can be used in (but are not limited to) SIP peer-to-peer systems based on centralized, semi-centralized or fully distributed architectures. While other protocols and mechanisms can be used to achieve similar purposes, it is a beneficial to provide the means to use SIP in order to minimize the protocol implementation support, especially in endpoints with limited resources. 2. Definitions and Document Conventions In addition to the definitions of RFC 3265 [RFC3265], and RFC 3903 [RFC3903], this document introduces the following new terms: Community: A collection of loosely coupled SIP user agents that agree to share resources among members of the community. A community can be composed of, e.g., an enterprise, a group of friends, family members, or members of a club. Resource: An abstraction of a shared object, which can be a service or information, e.g., in the form of an audio/video stream or a static file. Resource metadata: A set of properties describing the resource. The resource metadata can include the hash (if resource is hashable), name, creation date, Uniform Resource Name (URN), Uniform Resource Identifier (URI), and other relevant information. Resource descriptor: A subset of the resource metadata that uniquely identifies one resource. Resource directory: A device storing the resource descriptors of a set of resources; also called ESC in this document. Search operation: Signalling issued by a user to get information of the available resources and its associated metadata. Typically search operations are delimited with search filters. Garcia-Martin, et al. Expires June 23, 2007 [Page 4] Internet-Draft SIP Resource Sharing Framework December 2006 Search filter: A set of properties used in search operations to set the limits of the search, based on user's input. A search filter can consist of, e.g., a file name, file type, a resource description, etc. File transfer operation: An operation whereby a User Agent gets a file resource from a remote UA. In this document, 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. Indented passages such as this one are used in this document to provide additional information and clarifying text. They do not contain descriptions of normative protocol behavior. 3. Use Cases This section describes a number of use cases that are addressed later in this document. The use cases are just examples, and do not intend to limit the applicability of the resource sharing framework. 3.1. File Publication Alice is on holiday in Monaco. While visiting the Casino, she sees a famous painting which she takes a picture of with her camera phone. After taking the photo, she tags it with the following tags: Alice, Holiday, Monaco, Painting, Casino. These tags are there to help her and her friends to locate the picture later. Alice knows that her friends are also interested in art, so she wants to make this picture available for anyone to download. Alice selects the picture of the painting, along with some other pictures she took later that day, in the picture browser application and selects the publish option to make the picture available for others to see. Once the selection of shared resources is done, the SIP UA publishes the availability of those resources towards an Event State Compositor (ESC). The actual files are not transmitted until someone requests them. Resource publication is further discussed in Section 4.1.1. 3.2. File Search While talking with Charlie on the phone, Bob learns that Alice is currently on vacation in Monaco. Bob knows that Alice likes to take Garcia-Martin, et al. Expires June 23, 2007 [Page 5] Internet-Draft SIP Resource Sharing Framework December 2006 photos and share them with her friends, so he opens up his search application and types in keywords: Alice and Monaco. Once Bob hits the search button, his SIP UA sends the search message to the ESC. After a while, the ESC sends the search results back to Bob's SIP UA in a series of notifications. Now Bob can see the names of all pictures Alice has taken when she was in Monaco. Bob's application may also download and display thumbnails of the pictures. Bob also finds a couple of pictures taken by Alice's friend, Eve, which have been tagged with tag: Alice, Monaco. Dave is a student of art. On the bus he meets his friend Eve. While chatting, Eve tells about the painting she has seen on her recent visit in Monaco. Dave wonders if there are some pictures of it, and enters the keywords Monaco, Painting into the application on his mobile phone. Dave hits the search button, and his SIP UA sends the search message to the ESC. After a while, the ESC sends the search results back to his SIP UA in a series of notifications. The application displays a list of files matching the keywords, including the pictures Alice and other visitors have taken. To his surprise, Dave also finds a video stream presenting the art museums of Monaco. Search operations are further discussed in Section 5. 3.3. File Directory Through Presence Information Charlie is a good friend of Alice. Therefore he is interested to know about new pictures that Alice publishes. In this case he can just subscribe to the presence information of Alice and his other friends. Attached with conventional the presence information, he receives the information about the files these people are hosting on their SIP UAs. Instead of periodical searching for files tagged with Alice's name, Charlie can just subscribe to Alice's presence information, and get notification every time Alice adds new pictures to her shared files. The same file browsing functionality can be used also in multi-user chat between Alice, Charlie, Eve, and Bob. In the chat application, Bob sees names of every participant in the user list displayed on his screen. When clicking anyone's name, he gets list of files that the selected participant is hosting attached with the conventional presence information of this person. This document does not specify implementation of the file browsing via presence information. A solution is described in the Internet- Draft 'Resource Descriptions Extension to the PIDF' [I-D.garcia-sipping-resource-desc-pidf]. Garcia-Martin, et al. Expires June 23, 2007 [Page 6] Internet-Draft SIP Resource Sharing Framework December 2006 Resource directory through presence information is further discussed in Section 6. 3.4. File Download Once a Bob has found an interesting file called 'Alice and Eve at the Casino', e.g., by using the search functionality or by browsing Alice's presence information for files, he wants to display that picture on his device. To initiate the download, Bob selects the picture and hits the download button. Bob's SIP UA sends a download request to Alice's SIP UA. Alice's terminal will automatically approve the request and their UAs will establish a file transfer session. After the file transfer, Bob is presented with a dialog of file transfer completion, and asked if he wants to open the file immediately in the picture viewer. Section Section 7 provides further discussion on accessing resources. 4. Resource Publication Resource publication is based on the PUBLISH method specified in RFC 3903 [RFC3903]. We proposed two variants of publication, depending on whether the publication supports search operations or directory operations. To support the former, publication is done together with the 'resource' event package [I-D.garcia-sipping-resource-event-package]. To support the later, the Presence Information Data Format (PIDF) [RFC3863] is extended to provide a description of available resources together with the presence information of the presentity. 4.1. Resource Publication in Support of Search Operations 4.1.1. Initial Resource Metadata Publication Initial resource metadata publication is perfomed to publish metadata about the availability of one or more resources to the ESC. Figure 1 presents the signaling flow required for an Event Publishing Agent (EPA) to publish the availability of one or more resources towards the Event State Compositor (ESC). Garcia-Martin, et al. Expires June 23, 2007 [Page 7] Internet-Draft SIP Resource Sharing Framework December 2006 EPA ESC | | | SIP/2.0 PUBLISH | | Event: resource | | (resource metadata in body) | | ------------------------------------> | | | | 200 OK SIP/2.0 | | SIP-ETag: x | | <------------------------------------ | | | Figure 1: Signaling flow for publication of resource metadata The EPA performs the initial resource metadata publication by sending a PUBLISH [RFC3903] request to the ESC. The PUBLISH request contains a full 'resource' document that contains metadata about one or more resources available at the EPA. The 'resource' document is defined in the 'resource' event package [I-D.garcia-sipping-resource-event-package]. Each resource is described using a set of invariant metadata and a set of metadata specific to each instance of the resource, given in the and child elements of the element. In case of publishing availability of a file, the invariant metadata contains the following attributes: the Uniform Resource Name (URN), the MIME type (e.g., image/jpeg), the size and the SHA1 hash of the file. For each identical copy of the file, the instance-specific metadata contains any of: the SIP URI of the file, the file name, a short description, a set of keywords describing the file, the file creation date, the file modification date, the file read date, a link to an icon, and other resource metadata that is associated to the file. Additionally the instance-specific metadata contains the SIP AOR (e.g. URI) and GRUU of the user's endpoint where the file is stored. In case of publishing availablility of some other type of resource, the attributes are used as applicable. The PUBLISH request is routed to the ESC. The ESC sends a 200 OK response that, according to RFC 3903 [RFC3903], includes a SIP-ETag header that contains the entity-tag allocated to the resource. The EPA stores this entity-tag for future references to the publication. Note that the actual file is not transmitted at any point to the ESC: only the metadata associated with the file is transmitted. Garcia-Martin, et al. Expires June 23, 2007 [Page 8] Internet-Draft SIP Resource Sharing Framework December 2006 4.1.2. Publication of Modified Resource Metadata Whenever a resource is modified or new resources are added or deleted from the endpoint, the EPA refreshes the previous publication by sending a new PUBLISH request, as shown in Figure 2. This publication carries a partial 'resource' document that contains a number of XML patch operations that add, remove, or replace XML elements towards the last published 'resource' document. A resource modification occurs, e.g., when an image file is edited to suppress red eyes, an audio file is edited to suppress silence or apply some noise filter, or when some audio/music stream provided by the UE changes its bitrate. Any kind of modification to the resource owned by the UE implies a change in the metadata. RFC 3903 [RFC3903] contains provisions to allow the ESC to distinguish an initial publication from a refreshment-based one with the aid of the entity tags and the SIP-ETag and SIP-If-Match header fields. The SIP-Etags in conjunction with the 'version' attribute of the root element of the 'resource' document provide the means to synchronize versions. EPA ESC | | | SIP/2.0 PUBLISH | | SIP-If-Match: x | | Event: resource | | (resource description in body) | | ------------------------------------> | | | | 200 OK SIP/2.0 | | SIP-ETag: y | | <------------------------------------ | | | Figure 2: Signaling flow for publication of modified resource metadata If a resouce becomes unavailable at the EPA, e.g., as a result of a file deletion, the resource publication contains a partial 'resource' document that describes the resource to be removed. 4.1.3. Actions Performed by the ESC As the ESC receives initial or updated publications, the ESC will typically locally store the published metadata, but in some cases, depending on the usage scenario, storage of metadata will take place in other nodes, for example, in other primary nodes which are members Garcia-Martin, et al. Expires June 23, 2007 [Page 9] Internet-Draft SIP Resource Sharing Framework December 2006 of the DHT. The ESC may act as a primary node in an overlay SIP P2P network. Thus, upon reception of a publication from one of its secondary nodes, the primary node may need to publish or update the metadata in the overlay SIP P2P network. This step heavily depends on the chosen peer-to-peer algorithm. For example, if the SIP P2P distribution algorithm is based on flooding, the primary node may not need to contact any other primary node, but just wait for search queries from them. However, if the overlay is based on a Distributed Hash Table (DHT) based algorithm, then the primary node may need to update resource metadata and store it in the appropriate node. The actual mechanism to update resource metadata is dependent on the specific algorithm and out of scope of this memo. 4.2. Resource Publication in Support of Directory Operations Publication of resources in support of directory operations is done by extending the presence information that a presentity supplies with resource metadata. The publisher composes a PIDF [RFC3863] document according to the Presence Data Model [RFC4479]. The element of the data model contains the resource metadata. This is further described in a the Internet-Draft 'Resource Descriptions Extension to the PIDF' [I-D.garcia-sipping-resource-desc-pidf]. All the presence methods are available in publication of presence information with available resources. For example, partial publication, presence authorization rules, etc., are always at the presentity's disposal. EPA ESC | | | SIP/2.0 PUBLISH | | Event: presence | | (PIDF + data model + | | resource metadata in body) | | ------------------------------------> | | | | 200 OK SIP/2.0 | | SIP-ETag: x | | <------------------------------------ | | | Figure 3: Signaling flow for publication of presence information that includes resource metadata Publication of modified resource data in the PIDF is done similarly to the publication of modified resource data (see Section 4.1.2), but Garcia-Martin, et al. Expires June 23, 2007 [Page 10] Internet-Draft SIP Resource Sharing Framework December 2006 the event package is set to presence. 5. Search Operation The search of shared resources is implemented with the SIP event framework defined in RFC 3265 [RFC3265] in conjunction with the 'resource' event package [I-D.garcia-sipping-resource-event-package] and a filter document [RFC4661]. The signaling flow for a search operation is shown in Figure 4. Subscriber Notifier | | | SIP/2.0 SUBSCRIBE | | Event: resource | | (search filter in body) | | ------------------------------------> | | | | 200 OK SIP/2.0 | | <------------------------------------ | | | | SIP/2.0 NOTIFY | | Event: resource | | <------------------------------------ | | | | 200 OK SIP/2.0 | | ------------------------------------> | | | | SIP/2.0 NOTIFY | | Event: resource | | (resource descriptor in body) | | <------------------------------------ | | | | 200 OK SIP/2.0 | | ------------------------------------> | | | | SIP/2.0 NOTIFY | | Event: resource | | Subscription-State: terminated | | (resource descriptor in body) | | <------------------------------------ | | | | 200 OK SIP/2.0 | | ------------------------------------> | | | Figure 4: Signaling flow of a search operation Garcia-Martin, et al. Expires June 23, 2007 [Page 11] Internet-Draft SIP Resource Sharing Framework December 2006 5.1. Sending a Search Request To search for a resource, the subscriber first builds a filter containing the data of the searched resource. The filter can contain, for example, keywords, file names, types of files, etc. The filter conforms to the XML format for filters [RFC4661]. Then it attaches the filter to a SUBSCRIBE request for the resource event package. The subscription duration will be short, typically on the order of a few minutes. This subscription time provides enough time for a primary node in a SIP peer-to-peer network to propagate the search within the overlay network and get responses before the subscription expires. Eventually, the SUBSCRIBE request is sent to a notifier (either a peer or an ESC) that will provide one or more NOTIFY requests including a 'resource' document according to the filtered content. 5.2. Reporting Search Results After receiving the SUBSCRIBE message, and acknowledging it with a 200 OK, the Notifier sends a NOTIFY request to the Subscriber. This request may contain a first collection of metadata about the searched resources, if such information is already available in the ESC, in a full 'resource' document. Information may be available immediately in case there is matching metadata stored in the ESC, due to push operations according to the peer-to-peer algorithm, or due to cached information from previous searches. In many cases, however, this NOTIFY request does not contain metadata about the searched resources, and it is sent just because the protocol (RFC 3265 [RFC3265]) requires an immediate NOTIFY after each successful SUBSCRIBE request. The NOTIFY request is acknowledged with a 200 OK response. The ESC may, depending on algorithm, invoke a search for additional resources, whose metadata is stored in other ESCs (see section 4.3). Due to this propagated search, additional matching resource descriptors may become known. New matching resource descriptors may also become known as a result of PUBLISH requests received by the ESC within the duration of the subscription. To report matching resources, the ESC sends NOTIFY requests to the Subscriber. The body of the initial NOTIFY contains a full 'resource' document that is formatted according to the 'resource' event package [I-D.garcia-sipping-resource-event-package] and it can contain metadata about several resources that matched the search criteria. The 'resource' event package defines all the metadata associated to each resource, including the file name, size, type, icon, hash, SIP URI and UE (GRUU) of the users where the file is available, etc. In some cases, the metadata that describes a given Garcia-Martin, et al. Expires June 23, 2007 [Page 12] Internet-Draft SIP Resource Sharing Framework December 2006 resource will provide more than one location of the resource. This will typically be the case when a popular resource (e.g., a file) is available in several endpoints. Then the 'resource' XML document supplied in the NOTIFY request will contain more than one child element in a given element. It may also be necessary to divide a NOTIFY request into several smaller due to the user's preferences (rate of notifications, bandwidth consumption, and event throttling). The NOTIFY requests are acknowledged with a 200 OK response. The initial NOTIFY request contains a full 'resource' XML document. Once the notifier acquires more metadata, it sends partial 'resource' XML documents with additions, replacement, or removals. Upon reception of a new partial 'resource' document, the subscriber composes a full 'resource' XML document, based on the existing previous version plus the partial notification. Then, the subscriber UA has the new full 'resource' XML document at his disposal, so it can, e.g., display the metadata sequentially to the user, as soon as new results are received. 5.3. Propagating Searches In many cases, such as in P2P systems, the metadata is distributed in several ESCs. We consider two special cases: 1. In a flooding based architecture, several or all ESCs need to be queried in order to find the matching resources. A given ESC is only aware of resources that have been published into its local database. 2. In a DHT based architecture, such as Chord, a specific ESC is responsible for a specific set of metadata. In both cases, the ESC/ESCs containing the required metadata may be another ESC than the one receiving the Subscribe request. 5.3.1. Searching Based on Flooding In a flooding based search, the SUBSCRIBE request is first processed by the local ESC itself, and then distributed to all ESCs in the system. The distribution is, however, limited by the value of the Max-Forwards header field. An ESC receiving the SUBSCRIBE consults its local database to find matching resources and it replies with a NOTIFY request that may contain a 'resource' document if matching resources are found locally. The ESC also acts as an URI-list server [I-D.ietf-simple-event-list] where the URI-list is locally stored. It then forwards a SUBSCRIBE request with the same filter document to each of the ESCs stored in its neighbor table, providing that the Max-Forwards header is still positive and provided that the ESC Garcia-Martin, et al. Expires June 23, 2007 [Page 13] Internet-Draft SIP Resource Sharing Framework December 2006 hasn't already processed the same request. The generation and maintenance of the neighbor table is out of scope of this memo. The ESC will receive NOTIFY requests from other neighbor nodes, each of the requests containing a different 'resource' document. The ESC will aggregates and composes a single 'resource' document, and sends partial notifications to the subscriber, according to the rate of notifications. The subscriber is getting periodic partial notifications, each one adding new resources or new instances of existing resources. 5.3.2. Searching Based on Distributed Hash Tables (DHT) In a DHT based system, a single node (a notifier) is responsible for the metadata related to a given search key (the resource). For file resources the search key is the hash. An ESC receiving a SUBSCRIBE request consults its routing table (finger table in Chord) to locate the notifier whose key is the closest one to the search key, and forwards the SUBSCRIBE to that ESC. Finally the SUBSCRIBE will reach the node responsible for the given search key. The definition of 'closest' is depending on the actual DHT used. 5.4. Terminating a Search Request When the last results are made available, or when the search operation expires, the server sends a last NOTIFY request to the user, containing the latest available results (if any), and setting the Subscription-State header field to "terminated" to indicate the end of the search operation, as per procedures of RFC 3265 [RFC3265]. The user can also cancel the search operation by sending a re- SUBSCRIBE request that contains a Expires header field set to zero, according also to the procedures of RFC 3265 [RFC3265]. 5.5. Example of a Search Filter Figure 4 provides the signaling flow for a search operation. The SUBSCRIBE request contains a filter body, formatted according to the filter data format [RFC4661]. Figure 5 shows an example of the SUBSCRIBE request carrying a filter. The filter selects a few XML elements of a resource that contains the string "vacation" in a element. SUBSCRIBE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP alice.example.net;branch=z9hG4bKnashds7 Max-Forwards: 70 From: ;tag=31415 Garcia-Martin, et al. Expires June 23, 2007 [Page 14] Internet-Draft SIP Resource Sharing Framework December 2006 To: Call-ID: b89rjhnedlrfjflslj40a222 CSeq: 61 SUBSCRIBE Event: resource Expires: 180 Accept: application/resource+xml;q=0.3 Contact: Content-Type: application/simple-filter+xml Content-Length: [length] /rs:resource-set/rs:resource /rs:resource-set/rs:resource/rs:identity/rs:urn /rs:resource-set/rs:resource/rs:identity/rs:mime-type /rs:resource-set/rs:resource/rs:identity/rs:size /rs:resource-set/rs:resource/rs:identity/rs:sha-1 /rs:resource-set/rs:resource/rs:instance/rs:uri /rs:resource-set/rs:resource/rs:instance/rs:user-aor /rs:resource-set/rs:resource/rs:instance/rs:user-gruu /rs:resource-set/rs:resource/rs:instance/rs:description /rs:resource-set/rs:resource/rs:instance[rs:keyword="vacation"] Garcia-Martin, et al. Expires June 23, 2007 [Page 15] Internet-Draft SIP Resource Sharing Framework December 2006 Figure 5: Example of a search filter 6. Directory Operations Through Presence Information Directory operations through presence information allows an authorized watcher of presence information to be updated on the list available resources at a presentity device. In Figure 6, the watcher does a regular subscription to the presentity's presence information, either directly between the two endpoints, or with the support of a Presence Agent (PA). Once the subscription is duly authorized, the subscriber receives updated presence information in NOTIFY requests. The request contains a PIDF document structured according to the presence data model. The 'device' part of the data model contains a list of available resources that the presentity provides for the subscriber's disposal. All the presence methods are available also in directory operations. For example, partial notifications, presence authorization rules, filters, etc., are applicable. Garcia-Martin, et al. Expires June 23, 2007 [Page 16] Internet-Draft SIP Resource Sharing Framework December 2006 Subscriber PA | | | SIP/2.0 SUBSCRIBE | | Event: presence | | (search filter in body) | | ------------------------------------> | | | | 200 OK SIP/2.0 | | <------------------------------------ | | | | SIP/2.0 NOTIFY | | Event: presence | | <------------------------------------ | | | | 200 OK SIP/2.0 | | ------------------------------------> | | | | SIP/2.0 NOTIFY | | Event: presence | | (PIDF + data model + | | resource descriptor in body) | | <------------------------------------ | | | | 200 OK SIP/2.0 | | ------------------------------------> | | | Figure 6: Signaling flow of a directory operation through presence 7. Accessing a Resource Once the search operation is complete, the user can select whether to do any further operation on a given resource, and if so, on which instance to operate. This heavily depends on the type of resource that has been shared. File resources can be downloaded, for example, by setting up an MSRP session towards the user's SIP URI, and providing a file description in the SDP. This mechanism is described in [I-D.ietf-mmusic-file-transfer-mech]. In this case, the SIP INVITE request is addressed (Request-URI) to the URI contained in a (preferred option) or elements of the chosen for that . The file requester creates an SDP description of an MSRP session that contains the SDP file description extensions to describe the file. If the hash of the file is available, it is RECOMMENDED to include it, as it uniquely identifies the file. In other cases, there can be a URN or URI that describes the resource Garcia-Martin, et al. Expires June 23, 2007 [Page 17] Internet-Draft SIP Resource Sharing Framework December 2006 in the or elements of that . The mechanism to retrieve or receive service from the resource is dependent on it. For example, an HTTP URI requires an HTTP GET request to retrieve the resource. Similarly FTP URIs require the establishment of an FTP session. 8. Security Considerations TBD 9. IANA Considerations This document contains no actions to IANA. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [I-D.garcia-sipping-resource-event-package] Garcia-Martin, M. and M. Matuszewski, "A Session Initiation Protocol (SIP) Event Package and Data Format for Publication and Searching Generic Resources", draft-garcia-sipping-resource-event-package-01 (work in progress), December 2006. Garcia-Martin, et al. Expires June 23, 2007 [Page 18] Internet-Draft SIP Resource Sharing Framework December 2006 [I-D.garcia-sipping-resource-desc-pidf] Garcia-Martin, M. and M. Matuszewski, "Resource Descriptions Extension to the Presence Information Data Format(PIDF)", draft-garcia-sipping-resource-desc-pidf-00 (work in progress), December 2006. 10.2. Informative References [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. [I-D.ietf-simple-event-list] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-07 (work in progress), January 2005. [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. 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, et al. Expires June 23, 2007 [Page 19] Internet-Draft SIP Resource Sharing Framework December 2006 Nicklas Beijar Helsinki University of Technology P.O.Box 3000 TKK, FIN 02015 Finland Phone: +358 9 451 5303 Email: nbeijar@netlab.tkk.fi URI: http://www.netlab.tkk.fi/ Juuso Lehtinen Helsinki University of Technology P.O.Box 3000 TKK, FIN 02015 Finland Phone: +358 9 451 2472 Email: juuso@netlab.tkk.fi URI: http://www.netlab.tkk.fi/ Garcia-Martin, et al. Expires June 23, 2007 [Page 20] Internet-Draft SIP Resource Sharing Framework 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, et al. Expires June 23, 2007 [Page 21]