Network Working Group A. B. Roach Internet-Draft J. Rosenberg Expires: August 18, 2003 B. Campbell dynamicsoft February 17, 2003 A Session Initiation Protocol (SIP) Event Notification Extension for Collections draft-ietf-simple-event-list-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 August 18, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogenous collection of event packages. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire collection, and then receive notifications when the state of any of the resources in the collection changes. Roach, et al. Expires August 18, 2003 [Page 1] Internet-Draft SIP Event Lists February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 3. Operation of List Subscriptions . . . . . . . . . . . . . . 6 3.1 Negotiation of Support for Resource Lists . . . . . . . . . 6 3.2 Event Header Parameters . . . . . . . . . . . . . . . . . . 7 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 7 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 7 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 7 3.7 Notifier Generation of NOTIFY requests . . . . . . . . . . . 8 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 9 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 10 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 10 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Using multipart/related to Convey Aggregate State . . . . . 12 4.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 13 4.4 Instance Attributes . . . . . . . . . . . . . . . . . . . . 14 4.5 Constructing Coherent Resource State . . . . . . . . . . . . 15 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . 30 6.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 30 6.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 30 6.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 7.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 32 7.2 New MIME type for Resource List Meta-Information . . . . . . 32 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 34 Normative References . . . . . . . . . . . . . . . . . . . . 35 Non-Normative References . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 Full Copyright Statement . . . . . . . . . . . . . . . . . . 38 Roach, et al. Expires August 18, 2003 [Page 2] Internet-Draft SIP Event Lists February 2003 1. Introduction The SIP-specific event notification mechanism [2] allows a user (the subscriber) to request to be notified of changes in the state of a particular resource. This is accomplished by having the subscriber generate a SUBSCRIBE request for the resource, which is processed by a notifier that represents the resource. In many cases, a subscriber has a collection of resources they are interested in. For environments in which bandwidth is limited, such as wireless networks, subscribing to each resource individually is problematic. The specific problems are: o Doing so generates substantial message traffic, in the form of the initial SUBSCRIBE requests for each resource, and the refreshes of each individual subscription. o The notifier may insist on low refresh intervals, in order to avoid long lived subscription state. This means that the subscriber may need to generate subscriptions faster than it would like to, or has the capacity to. o The notifier may generate NOTIFY requests more rapidly than the subscriber desires, causing NOTIFY traffic at a greater volume than is desired by the subscriber. o If a subscriber has only intermittent connectivity, and generally polls for state rather than simply subscribing, the latency to obtain the state of the entire resource can be large. The messaging required for each poll can also be substantial. To solve these problems, this specification defines an extension that allows for requesting and conveying notifications for collections of resources. A resource list is identified by a URI and it represents a list of zero or more URIs. Each of these URIs is an identifier for an individual resource for which the subscriber wants to receive information. In many cases, the URI will be a SIP URI [1]; however, the use of other schemes (such as pres:) is also forseen. The notifier for the collection is called a "resource list server", or RLS. In order to determine the state of the entire list, the RLS will act as if it has typically generated a subscription to each resource in the list. The resource list is not restricted to be inside the domain of the subscriber. Similarly, the resources in the list are not contstrained to be in the domain of the resource list server. Roach, et al. Expires August 18, 2003 [Page 3] Internet-Draft SIP Event Lists February 2003 2. Overview of Operation This section provides an overview of the typical mode of operation of this extension. It is not normative. When a user wishes to subscribe to the resource of a list of resources, they create a resource list. This resource list is represented by a SIP URI. The list contains a set of URIs, each of which represents a resource for which the subscriber wants to receive information. The resource list can exist in any domain. Typically, the user who creates the list (and subsequently subscribes to it) will have a trust relationship with the domain that hosts the list. The list could be manipulated through a web page, through a voice response system, or through some other protocol. The specific means by which the list is created and maintained is outside of the scope of this specification. To learn the resource state of the set of elements on the list, the user sends a single SUBSCRIBE request targeted to the URI of the list. This will be routed to an RLS for that URI. The RLS acts as a notifier, authenticates the subscriber, and accepts the subscription. The RLS may have direct information about some or all of the resources specified by the list. If it does not, it could subscribe to any non-local resources specified by the list resource. (Note that such a subscription will typically be SIP subscription; however, any mechanism for determining such information may be employed). Since the RLS is acting on behalf of the user, it will need a mechanism for authenticating the user so that appropriate policy can be applied. In the simplest case, the user can provide credentials to the RLS ahead of time; this requires a trust relationship between the user and RLS. Additional approaches can be formulated using the mechanisms defined in "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks" [6] and "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [7]. As notifications arrive from individual resources, the RLS accepts them, extracts the resource information, and generates a notification to the subscriber. The RLS can, at its discretion, buffer notifications that it receives, and send the resource information to the subscriber in batches, rather than individually. This allows the RLS to provide rate limiting for the subscriber. The list notifications contain a body of type multipart/related. The root section of the multipart/related content is an XML document that provides meta-information about each resource present in the list. Roach, et al. Expires August 18, 2003 [Page 4] Internet-Draft SIP Event Lists February 2003 The remaining sections contain the actual state information for each resource. Joe RLS User A User B | | | | |(1) SUBSCRIBE | | | |---------------->| | | |(2) 200 OK | | | |<----------------| | | |(3) NOTIFY | | | |<----------------| | | |(4) 200 OK | | | |---------------->| | | | |(5) SUBSCRIBE a | | | |---------------->| | | |(6) SUBSCRIBE b | | | |---------------------------------->| | |(7) 200 OK | | | |<----------------| | | |(8) 200 OK | | | |<----------------------------------| | |(9) NOTIFY | | | |<----------------| | | |(10) 200 OK | | | |---------------->| | |(11) NOTIFY | | | | a's state | | | |<----------------| | | |(12) 200 OK | | | |---------------->| | | | |(13) NOTIFY | | | |<----------------------------------| | |(14) 200 OK | | | |---------------------------------->| |(15) NOTIFY | | | | b's state | | | |<----------------| | | |(16) 200 OK | | | |---------------->| | | As an example, consider a resource list with two resources, sip:userA@a.com and sip:userB@b.com. A typical flow for a subscription to this resource list is shown above. Roach, et al. Expires August 18, 2003 [Page 5] Internet-Draft SIP Event Lists February 2003 3. Operation of List Subscriptions A list subscription acts, in many ways, like an event template package. In particular, any single list subscription MUST be homogenous with respect to the underlying event package. In other words, a single list subscription cannot contain subscriptions to different kinds of event packages. The key difference between a list subscription and templates in general is that support for list subscriptions indicates support for arbitrary nesting of list subscriptions. In other words, elements within the list may be atomic elements, or they may be lists themselves. The consequence of this is that subscription to a URI that represents a list actually results in subscription to a tree of resources. The leaf nodes of this tree are subscriptions of the event type given in the "Event" header; all other nodes in the tree are list subscriptions that are serviced as described in this section and its subsections. It is important to keep in mind that, although the overall system is specified in terms that imply that such subscriptions are literal SIP subscriptions on separate servers, servers are free to implement in any way that provides equivalent functionality as viewed from the interface towards the subscriber. In particular, it is expected that notifiers for list subscriptions will often have direct information about some of the resources in the list; they will presumably not send SUBSCRIBE requests to themselves in order to service such list subscriptions. 3.1 Negotiation of Support for Resource Lists This specification uses the SIP option tag mechanism for negotiating support of the extension defined herein. Refer to RFC3261 [1] for the normative description of processing of the "Supported" and "Require" headers and the 421 (Extension Required) response code. Any client that supports the event list extension will include an option tag of "eventlist" in a "Supported" header of every SUBSCRIBE message for a subscription for which it is willing to process a list. If the subscription is made to a URI that represents a list, the RLS will include "eventlist" in a "Require" header of the response to the SUBSCRIBE, and in all NOTIFY messages within that subscription. Note that including "eventlist" in a "Require" header in a SUBSCRIBE request serves no purpose, and is consequently NOT RECOMMENDED. As described in RFC3265 [2], a subscription to a particular state of Roach, et al. Expires August 18, 2003 [Page 6] Internet-Draft SIP Event Lists February 2003 a resource is identified by the Request-URI and the event package used. Because it is quite reasonable for an RLS to contain a resource that is inherantly a list (e.g. "sip:buddylist@example.com"), it is perfectly reasonable to expect that RLSes will return a 421 (Extension Required) response code if the "eventlist" option tag is not indicated in a request to subscribe to that resource. Because of the forgoing situation, this specification relaxes the "NOT RECOMMENED" provision described in RFC3261 [1], section 8.2.4. 3.2 Event Header Parameters This specification does not define any parameters on the Event header. Any parameters that are present on the Event header, however, are applied to the underlying leaf subscriptions. If a new subscription is generated to learn about this resource state, this generally means that such parameters are propagated to any SUBSCRIBE messages generated for the resources in the list. 3.3 SUBSCRIBE Bodies The SUBSCRIBE message MAY contain a body whose purpose is to define filters on the individual leaf subscriptions. If a new subscription is generated to learn about this resource state, this means that such bodies are propagated to any SUBSCRIBE messages generated for the resources in the list. 3.4 Subscription Duration Since the primary benefit of the resource list server is to reduce the overall messaging volume to a handset, it is RECOMMENDED that the subscription duration to a list be reasonably long. The default, when no duration is specified, is two hours, which reduces the need to refresh too frequently. Of course, the standard techniques [2] can be used to increase or reduce this amount. 3.5 NOTIFY Bodies An implementation compliant to this specification MUST support the multipart/related and application/rlmi+xml MIME types. These types MUST be included in an Accept header sent in SUBSCRIBE message, in addition to any other types supported by the client. 3.6 Notifier Processing of SUBSCRIBE Requests All subscriptions for resource lists SHOULD be authenticated. The use of the SIP HTTP Digest mechanism [1] over TLS is RECOMMENDED. Roach, et al. Expires August 18, 2003 [Page 7] Internet-Draft SIP Event Lists February 2003 Once the subscriber is authenticated, the RLS performs authorization per its local policy. In many cases, each resource list is associated with a particular user (the one who created it and manages the set of elements in it), and only that user will be allowed to subscribe. Of course, this mode of operation is not inherent in the use of resource lists, and a notifier can use any authorization policy it chooses. 3.7 Notifier Generation of NOTIFY requests This specification leaves the choice about how and when to generate NOTIFY requests at the discretion of the implementor. One of the value propositions of the RLS is the means by which it aggregates, rate limits, or optimizes the way in which notifications are generated. See Section 4 for a definition of the syntax used to convey resource lists. For the purposes of the following discussion, it is important to know that the overall list contains one or more resources, and that the resources contains one or more instances of the resource. Each instance of the resource has a state associated with it (pending, active, or terminating), representing the state of the subscription. As a baseline behavior, if the RLS acts as a subscriber to determine the state of the resources on the resource list, it MAY generate a NOTIFY to the RLS subscriber whenever it receives a NOTIFY about a state change in one or more resources. If a subscription to a resource is terminated by the notifier and the RLS is unable to re-establish the subscription by the recovery mechanisms described in SIP Events [2], that resource is still present in resource list NOTIFY messages as appropriate. The "state" attribute is set to "terminated", and the "reason" attribute is copied from the "reason" parameter from the "Subscription-State" in the NOTIFY received from the resource. If a SUBSCRIBE to a resource is refused with a response code that cannot be recovered from, that resource is still present in resource list NOTIFY messages as appropriate. The resource will be reported with a a "state" of "terminated," and a "reason" parmeter of "rejected". Note that the forgoing explanation is given in term of a back-end subscription to resources in the list. In practice, such subscriptions may not actually exist. In these cases, the RLS sets the "state" and "reason" attributes in such as was as would be consistent with such back-end subscriptions. Roach, et al. Expires August 18, 2003 [Page 8] Internet-Draft SIP Event Lists February 2003 When the first SUBSCRIBE message for a particular subscription is received by a resource list notifier, the notifier will often not know state information for all of the resources specified by the resource list. For any resource for which state information is not known, the corresponding "uri" attribute will be set appropriately, and no elements will be present for the resource. For an initial notification, sections corresponding to resources for which the resource list notifier does have state will be populated with appropriate data (subject, of course, to local policy decisions). This will often occur if the resource list server is colocated with the server for one or more of the resources specified on the list. Immediate notifications triggered as a result of subsequent SUBSCRIBE messages should result in full meta-information about the list of resources. The RLS will also include state information for all resources in the list for which the RLS has state. This allows the subscriber to refresh their state, and to recover from lost notifications. Note that a consequence of the way in which resource list subscriptions work, polling of resource state will often not be particularly useful. While such polls will retrieve the resource list (and potentially even some of the states if a resource on the list is colocated with the resource list server), they will often not contain state for some or all of the resources on the list. Because the notifications delivered by this mechanism have a tendency to be large, implementors are directed towards "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages" [8]. 3.8 Subscriber Processing of NOTIFY Requests Notifications for a resource list can convey information about a subset of the list elements. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state. The XML document present in the root of the multipart/related document contains a element for each resource in the list. Each element contains a URI which uniquely identifies the resource to which that section corresponds. When a NOTIFY arrives, it can contain full or partial state (as indicate by the "fullState" attribute of the top-level element). If full state is indicated, then the recipient replaces all state associated with the list with the entities in the NOTIFY body. If full state is not Roach, et al. Expires August 18, 2003 [Page 9] Internet-Draft SIP Event Lists February 2003 indicated, the recipient of the NOTIFY updates information for each identified resource. Information for any resources that are not identified in the NOTIFY are not changed, even if they were indicated in previous NOTIFY mesages. See section Section 4.5 for more information. Note that the underlying event package may have its own rules for compositing partial state notification. When processing data related to those packages, their rules apply (i.e. the fact that they were reported as part of a collection does not change their partial notification semantics). 3.9 Handling of Forked Requests Forking makes little sense with subscriptions to event lists, since the whole idea is a centralization of the source of notifications. Therefore, a subscriber MUST create just a single dialog as a result of a single subscription request, using the techniques described in RFC 3265[2]. If the resource list server generates subscriptions to packages that allow forking, and multiple subscriptions are established as the result of sending a single SUBSCRIBE message, the RLS maintains both subscriptions (as described in [2]), and includes the resource state information for all the subscriptions. This will result in having multiple elements in the corresponding element in the root part of the multipart/related body. See section Section 4 and its subsections for details. 3.10 Rate of Notifications One potential role of the RLS is to perform rate limitations on behalf of the subscriber. As such, this specification does not mandate any particular rate limitation, and rather leaves that to the discretion of the implementation. 3.11 State Agents Effectively, a resource list server is nothing more than a state agent for the resource event type. The usage of an RLS does introduce some security considerations. The end user is no longer the direct subscriber to the state of the resource. If the notifier for the resource demands end-to-end authentication, the RLS will need to be provided appropriate credentials to access those resources (e.g. shared secrets for Digest authentication). This requires a certain level of trust between the user and their RLS. This specification does not describe Roach, et al. Expires August 18, 2003 [Page 10] Internet-Draft SIP Event Lists February 2003 any particular means of providing such credentials to the RLS (such as uploading a shared secret). However, any such upload mechanism MUST ensure privacy of the key data; using HTTPS to fill out a form is a reasonable method. If the notifier for the resource is using a transitive trust model to validate the subscriber, then this works well with the RLS concept. The RLS would authenticate the subscriber, and then MAY use the SIP extensions for network asserted identity (see [6] and [7]) to provide an authenticated identity to any downstream servers. It is even conceivable that the subscriber may provide an authenticated ID in its original subscribe request for use by the RLS for the dual purpose of local authentication and use in any generated SUBSCRIBE messages. Roach, et al. Expires August 18, 2003 [Page 11] Internet-Draft SIP Event Lists February 2003 4. Using multipart/related to Convey Aggregate State In order to convey the state of multiple resources, the list template package uses the "multipart/related" mime type. The syntax for multipart/related is defined in "The MIME Multipart/Related Content- type" [4]. 4.1 XML Syntax The root document of the multipart/related body is always a Resource List Meta-Information (RLMI) document. It is of type "application/ rlmi+xml". This document containes the metadata for the resources contained in the notification. The schema for this XML document is given below. An example of a document formatted using this schema follows. Roach, et al. Expires August 18, 2003 [Page 12] Internet-Draft SIP Event Lists February 2003 4.2 List Attributes The element present in a list notification MUST contain three attributes. The first mandatory attribute is "uri", which contains the uri that corresponds to the list. Typically, this is the URI to which the SUBSCRIBE request was sent. The second mandatory attribute is "version", which contains a number from 0 to 2^32-1. This version number MUST be 0 for the first NOTIFY message sent within a subscription (typically in response to a SUBSCRIBE request), and MUST increase by exactly one for each subsequent NOTIFY sent within a subscription. The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the collection. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). Note that the first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription. The optional "name" attribute can contain a human readable description or name for the resource list. This attribute is somewhat analogous to the "Display Name" present in the SIP name-addr element. 4.3 Resource Attributes The resource list contains one element for each resource Roach, et al. Expires August 18, 2003 [Page 13] Internet-Draft SIP Event Lists February 2003 being reported in the notification. These resource elements contain attributes that identify meta-data assocated with each resource. The "uri" attribute identifies the resource to which the element corresponds. Typically, this will be a SIP URI which, if subscribed to, would return the state of the resource. This attribute must be present. The optional "name" attribute can contain a human readable description or name for the resource. This attribute is somewhat analogous to the "Display Name" present in the SIP name-addr element. 4.4 Instance Attributes Each resource element contains one or more instance elements. These instance elements are used to represent a single notifier for the resource. For event packages that allow forking, multiple subscriptions corresponding to a single resource are represented by including multiple instance elements in the corresponding resource element. For subscriptions in which forking does not occur, only one instance will be present in the resource. The "id" attribute contains an opaque string used to uniquely identify the instance of the resource. The "id" attribute is unique only within the context of a resource. Composition of this string is an implementation decision. One viable method for constructing the instance id would be copying the "From:" header "tag" parameter from the NOTIFY message received from the instance of the resource. Any other mechanism for generating this string is equally valid, as long as uniqueness within the resource is assured. The "state" attribute contains the subscription state for the identified instance of the resource. This attribute contains one of the values "active", "pending", or "terminated". The meanings for these values are as defined for the "Subscription-State" header in SIP Events [2]. If the "state" attribute indicates "terminated", then a "reason" attribute MUST also be present. This "reason" attribute has the same values and meanings as given for the "reason" parameter on the "Subscription-State" header in SIP Events [2]. Note that the reason is included for informational purposes; the list subscriber is not expected to take any automated actions based on the reason value. Finally, the "cid" attribute, which must be present if the "state" attribute is "active", identifies the section within the multipart/ related body that contains the actual resource state. This state is expressed in the content type defined by the event package for Roach, et al. Expires August 18, 2003 [Page 14] Internet-Draft SIP Event Lists February 2003 conveying state. This cid is Content-ID the corresponding section. Note that the expiration durations of the underlying subscriptions (if any) are not propagated into the aggregated state in any way. 4.5 Constructing Coherent Resource State The resource list subscriber maintains a table for each resource list. The table contains a row for each resource in the resource list. Each row is indexed by the URI for that resource. That URI is obtained from the "uri" attribute on each element. The contents of each row contain the state of that resource as conveyed in the resource document. For resources that provide versioning information (which is mandated by [2] for any formats that allow partial notification), each row also contains a resource state version number. The version number of the row is initialized with the version specified in the first document received, as defined by the corrsponding event package. This value is used when comparing versions of partial notifications for a resource. The processing of the resource list notification depends on whether it contains full or partial state. If it contains full state, indicated by the value of the attribute "fullState", the contents of the resource-list table are flushed. They are repopulated from the document. A new row in the table is created for each "resource" element. First, a check is made to ensure that no list notifications have been lost. The value of the local version number (the "version" attribute of the element) is compared to the version number of the new document. o If the value in the new document is exactly one higher than the local version number, the local version number is increased by one, and the document is processed, as described below. o If the version in the document is more than one higher than the local version number, the local version number is set to the value in the new document, and the document is processed as described below. Further, if the notification does not contain full state (as indicated by the "fullState" attribute of the element), the list subscriber SHOULD generate a refresh request to trigger a full state notification. o If the version in the document is less than or equal to the local version, the document is discarded without any further processing. Roach, et al. Expires August 18, 2003 [Page 15] Internet-Draft SIP Event Lists February 2003 If the resource list document contains partial state, the notification is used to update the table. For each resource listed in the document, the subscriber checks to see whether a row exists for that resource. This check is done by comparing the Resource-URI value with the URI associated with the row. If the resource doesn't exist in the table, a row is added, and its state is set to the information from that "resource" element. If the resource does exist, its state is updated to be the information from that "resource" element, as described in the definition of the event package. If a row is updated or created such that its state is now "terminated," that entry MAY be removed from the table at any time. Roach, et al. Expires August 18, 2003 [Page 16] Internet-Draft SIP Event Lists February 2003 5. Example This section gives an example callflow. It is not normative. If a conflict arises between this callflow and the normative behavior described in this or any other document, the normative descriptions are to be followed. In this particular example, we request a subscription to a nested presence list. The subscriber's address-of-record is "sip:adam@example.com", and the name of the nested list resource that we are subscribing to is called "sip:adam-buddies@pres.example.com". The underlying event package is "presence", described by [5]. 1. We initate the subscription by sending a SUBSCRIBE message to our local RLS. (There is no reason that the RLS we contact has to be in our domain, of course). Note that we must advertise support for application/rlmi+xml and multipart/related because we support the eventlist extension, and we must advertise application/cpim-pidf+xml because we are requesting a subscription to a list. Terminal -> Local RLS SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL Max-Forwards: 70 To: From: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 322723822 SUBSCRIBE Contact: Event: presence Expires: 7200 Supported: eventlist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: multipart/encrypted Content-Length: 0 2. The Local RLS completes the SUBSCRIBE transaction. Note that authentication and authorization would normally take place at this point in the callflow. Those steps are omitted for brevity. Roach, et al. Expires August 18, 2003 [Page 17] Internet-Draft SIP Event Lists February 2003 Local RLS -> Terminal SIP/2.0 200 OK Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL To: ;tag=zpNctbZq From: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 322723822 SUBSCRIBE Contact: Expires: 7200 Require: eventlist Content-Length: 0 3. As is required by SIP Events [2], the RLS sends a NOTIFY immediately upon accepting the subscription. In this example, we are asserting that the local RLS is also an authority for presence information for the users in the "example.com" domain. The NOTIFY contains an RLMI document describing the entire buddy list (initial notifies require full state), as well as presence information for the users about which it already knows. Note that, since the RLS has not yet retrieved information for some of the entries on the list, those elements contain no elements. Local RLS -> Terminal NOTIFY sip:terminal.example.com SIP/2.0 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm Max-Forwards: 70 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 997935768 NOTIFY Contact: Event: presence Subscription-State: active;expires=7200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml"; start="";boundary="50UBfW7LSCVLtggUPe5z" Content-Length: 1560 --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" Roach, et al. Expires August 18, 2003 [Page 18] Internet-Draft SIP Event Lists February 2003 --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" open sip:bob@example.com --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" closed --50UBfW7LSCVLtggUPe5z-- Roach, et al. Expires August 18, 2003 [Page 19] Internet-Draft SIP Event Lists February 2003 4. The terminal completes the transaction. Terminal -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 997935768 NOTIFY Contact: Content-Length: 0 5. In order to service the subscription, the local RLS subscribes to the state of the resources. In this step, the RLS attempts to subscribe to the presence state of the resource "sip:ed@example.com". Since the local RLS knows how to receive notifications for list subscriptions, it includes the "Supported: eventlist" header in its request. Although the linkage between this subscription and the one sent by the terminal is left up to the application, this message demonstrates some reasonable behavior by including "Accept" headers for all of the body types it knows the subscriber (Terminal) supports. This is safe to do, since the local RLS will only pass these formats through to the subscriber, and does not need to actually understand them. Roach, et al. Expires August 18, 2003 [Page 20] Internet-Draft SIP Event Lists February 2003 Local RLS -> Presence Server in example.net SUBSCRIBE sip:ed@example.net SIP/2.0 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH Max-Forwards: 70 To: From: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.example.com CSeq: 870936068 SUBSCRIBE Contact: Event: presence Expires: 3600 Supported: eventlist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: multipart/encrypted Content-Length: 0 6. The Presence Server in example.net completes the SUBSCRIBE transaction. Note that authentication and would normally take place at this point in the callflow. Those steps are omitted for brevity. Presence Server in example.net -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH To: ;tag=e45TmHTh From: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.example.com CSeq: 870936068 SUBSCRIBE Contact: Event: presence Expires: 3600 Content-Length: 0 7. In this example, we assume that the server at example.net doesn't have enough authorization information to reject or accept our subscription. The initial notify, therefore, contains a "Subscription-State" of "pending". Presumably, the party responsible for accepting or denying authorization for the resource is notified of this change; however, those steps are Roach, et al. Expires August 18, 2003 [Page 21] Internet-Draft SIP Event Lists February 2003 not included in this call flow for brevity. Presence Server in example.net -> Local RLS NOTIFY sip:pres.example.com SIP/2.0 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKfwpklPxmrW Max-Forwards: 70 From: ;tag=e45TmHTh To: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.example.com CSeq: 1002640632 NOTIFY Contact: Subscription-State: pending;expires=3600 Event: presence Require: eventlist Content-Length: 0 8. The local RLS completes the NOTIFY transaction. Note that, at this point, the Local RLS has new information to report to the subscriber. Whether it chooses to report the information immediately or spool it up for later delivery is completely up to the application. For this example, we assume that the RLS will wait for a short period of time before doing so, in order to allow the subscriptions it sent out sufficient time to provide useful data. Local RLS -> Presence Server in example.net SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKfwpklPxmrW From: ;tag=e45TmHTh To: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.example.com CSeq: 1002640632 NOTIFY Contact: Event: presence Content-Length: 0 9. The Local RLS subscribes to the state of the other non-local resource. Roach, et al. Expires August 18, 2003 [Page 22] Internet-Draft SIP Event Lists February 2003 Local RLS -> RLS in example.org SUBSCRIBE sip:adam-friends@example.org SIP/2.0 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL Max-Forwards: 70 To: From: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.example.com CSeq: 980774491 SUBSCRIBE Contact: Event: presence Expires: 3600 Supported: eventlist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: multipart/encrypted Content-Length: 0 10. The RLS in example.org completes the SUBSCRIBE transaction. Note that authentication and would normally take place at this point in the callflow. Those steps are omitted for brevity. RLS in example.org -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL To: ;tag=JenZ40P3 From: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.example.com CSeq: 980774491 SUBSCRIBE Contact: Event: presence Expires: 3600 Content-Length: 0 11. In this example, we are asserting that the RLS in example.org is also an authority for presence information for the users in the "example.org" domain. The NOTIFY contains an RLMI document describing the contained buddy list, as well as presence information for those users. In this particular case, the RLS in example.org has chosen to PGP sign [11] the body of the NOTIFY message. Roach, et al. Expires August 18, 2003 [Page 23] Internet-Draft SIP Event Lists February 2003 RLS in example.org -> Local RLS NOTIFY sip:pres.example.com SIP/2.0 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKmGL1nyZfQI Max-Forwards: 70 From: ;tag=JenZ40P3 To: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.example.com CSeq: 294444656 NOTIFY Contact: Event: presence Subscription-State: pending Require: eventlist Content-Type: multipart/signed;protocol="application/pgp-signature"; micalc="pgp-md5";boundary="l3WMZaaL8NpQWGnQ4mlU" Content-Length: 2038 --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: 8bit Content-ID: Content-Type: multipart/related;type="application/rlmi+xml"; start="";boundary="tuLLl3lDyPZX0GMr2YOo" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" Roach, et al. Expires August 18, 2003 [Page 24] Internet-Draft SIP Event Lists February 2003 open sip:joe@example.org --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" closed --tuLLl3lDyPZX0GMr2YOo-- --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= =ndaj -----END PGP MESSAGE----- --l3WMZaaL8NpQWGnQ4mlU-- 12. The Local RLS completes the NOTIFY transaction. Roach, et al. Expires August 18, 2003 [Page 25] Internet-Draft SIP Event Lists February 2003 Local RLS -> RLS in example.org SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKmGL1nyZfQI From: ;tag=JenZ40P3 To: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.example.com CSeq: 294444656 NOTIFY Contact: Event: presence Content-Length: 0 13. At this point, the Local RLS decides it has collected enough additional information to warrant sending a new notification to the user. Although sending a full notification would be perfectly acceptable, the RLS decides to send a partial notification instead. The RLMI document contains only information for the updated resources, as indicated by setting the "fullState" parameter to "false". Local RLS -> Terminal NOTIFY sip:terminal.example.com SIP/2.0 Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 Max-Forwards: 70 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 997935769 NOTIFY Contact: Event: presence Subscription-State: active;expires=7200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml"; start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL" Content-Length: 2862 --TfZxoxgAvLqgj4wRWPDL Content-Transfer-Encoding: 8bit Content-ID: <2BEI83@pres.example.com> Content-Type: application/rlmi+xml;charset="UTF-8" Roach, et al. Expires August 18, 2003 [Page 26] Internet-Draft SIP Event Lists February 2003 --TfZxoxgAvLqgj4wRWPDL Content-Transfer-Encoding: 8bit Content-ID: <1KQhyE@pres.example.com> Content-Type: multipart/signed;protocol="application/pgp-signature"; micalc="pgp-md5";boundary="l3WMZaaL8NpQWGnQ4mlU" --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: 8bit Content-ID: Content-Type: multipart/related;type="application/rlmi+xml"; start="";boundary="tuLLl3lDyPZX0GMr2YOo" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" open sip:joe@example.org Roach, et al. Expires August 18, 2003 [Page 27] Internet-Draft SIP Event Lists February 2003 --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" closed --tuLLl3lDyPZX0GMr2YOo-- --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: 8bit Content-ID: Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= =ndaj -----END PGP MESSAGE----- --l3WMZaaL8NpQWGnQ4mlU-- --TfZxoxgAvLqgj4wRWPDL-- 14. The terminal completes the NOTIFY transaction. Roach, et al. Expires August 18, 2003 [Page 28] Internet-Draft SIP Event Lists February 2003 Terminal -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 997935769 NOTIFY Contact: Content-Length: 0 Roach, et al. Expires August 18, 2003 [Page 29] Internet-Draft SIP Event Lists February 2003 6. Security Considerations 6.1 Authentication The usage of the RLS does introduce some security considerations. The end user is no longer the direct subscriber to the state of the resource. If the notifier for the resource demands end-to-end authentication, the RLS will need to be provided appropriate credentials to access those resources (e.g. shared secrets for Digest authentication). This requires a certain level of trust between the user and their RLS. This specification does not describe any particular means of providing such credentials to the RLS (such as uploading a shared secret). However, any such upload mechanism MUST ensure privacy of the key data; using HTTPS to fill out a form is a reasonable method. If the notifier for the resource is using a transitive trust model to validate the subscriber, then this works well with the RLS concept. The RLS would authenticate the subscriber, and then MAY use the SIP extensions for network asserted identity [6][7] to provide an authenticated identity to the PA. 6.2 Risks of Improper Aggregation A resource list server typically serves information to multiple subscribers at once. In many cases, resources may be present in several lists; additionally, it is quite possible that resource list servers will have two users subscribe to the same list. In these cases, misguided RLS implementations may attempt to minimize network load by maintaining only one subscription to a resource in a list, and presenting the result of such a subscription to more than one user. Of course, doing so circumvents any authorization policy that the resource maintains. It is important to keep in mind that authorization is often much more than a simple binary "allowed/not allowed" decision; resources may render very different -- and even conflicting -- resource states, depending on the identity of the subscribing user. Implementations MUST NOT attempt to perform this type of optimization unless adequate access to complete authorizaton policy can be guaranteed. Note that this is a very difficult problem to solve correctly; even in the cases that such access is beleived possible, this mode of operation is NOT RECOMMENDED. 6.3 Signing and Sealing Implementors should keep in mind that any section of the MIME body Roach, et al. Expires August 18, 2003 [Page 30] Internet-Draft SIP Event Lists February 2003 may be signed and/or encrypted as necessary. Resource List Servers should take care not to modify any MIME bodies they receive from other notifiers, and should not generally rely on being able to read them. In order to facilitate security, resource list servers SHOULD pass along indication for support of "multipart/signed" and "multipart/ encrypted" content types, if the subscriber includes them in the initial SUBSCRIBE message. Not doing so may actually result in resources refusling to divulge state (if notifier policy requires encryption, but the RLS fails to convey support), or subscribers discarding valid state (if subscriber policy requires a signature, but the RLS fails to convey support). Note that actual implemetation of encryption and signing by the RLS is not necessary to be able to pass through signed and/or encrypted bodies. Roach, et al. Expires August 18, 2003 [Page 31] Internet-Draft SIP Event Lists February 2003 7. IANA Considerations 7.1 New SIP Option Tag: eventlist Option Tag Name: eventlist Description: Extension to allow subscriptions to collections of resources Published specification: RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]] 7.2 New MIME type for Resource List Meta-Information MIME Media Type Name: application MIME subtype name: rlmi+xml Required parameters: None Optional parameters: charset See RFC 3023 [10] for a discussion of the charset parameter on XML-derived MIME types. Since this MIME type is used exclusively in SIP, the use of UTF-8 encoding is strongly encouraged. Encoding considerations: 8-bit text Security considerations: Security considerations specific to uses of this this MIME type are discussed in RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]]. RFC 1874 [9] and RFC 3023 [10] discuss security issues common to all uses of XML. Interoperability considerations: The use of this MIME body is intended to be generally interoperable. No unique considerations have been identified. Published specification: RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]] Applications which use this media type: This media type is used to convey metadata for the state of collections of resources within a Session Initiation Protocol (SIP) subscription. Additional information: Roach, et al. Expires August 18, 2003 [Page 32] Internet-Draft SIP Event Lists February 2003 Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None. Object Identifier(s) or OID(s): None. Intended usage: Limited Use Other Information/General Comment: None. Person to contact for further information: Name: Adam Roach E-Mail: adam@dynamicsoft.com Author/Change Controller: The specification of this MIME type is a work product of the SIMPLE working group, and was authored by Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has change control over its specification. Roach, et al. Expires August 18, 2003 [Page 33] Internet-Draft SIP Event Lists February 2003 8. Open Issues o RFC 3265 allows event packages to include bodies in their SUBSCRIBE requests to filter notifications. It would be natural to merely copy the body from the SUBSCRIBE in a list subscription to any SUBSCRIBE messages generated to additional entities, so that they would take the appropriate actions. Would that be correct behavior, or do we need to define some other way to handle this (e.g. including the filter documents as part of the provisioned data that is considered part of the list). Roach, et al. Expires August 18, 2003 [Page 34] Internet-Draft SIP Event Lists February 2003 Normative References [1] 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. [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993. [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. Roach, et al. Expires August 18, 2003 [Page 35] Internet-Draft SIP Event Lists February 2003 Non-Normative References [5] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for Presence", draft-ietf-simple-presence-07 (work in progress), May 2002. [6] Watson, M., Peterson, J. and C. Jennings, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", draft-ietf-sip-asserted-identity-02 (work in progress), August 2002. [7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft- peterson-sip-identity-01 (work in progress), July 2002. [8] Olson, S., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content- indirect-mech-01 (work in progress), November 2002. [9] Levinson, E., "SGML Media Types", RFC 1874, December 1995. [10] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [11] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [12] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. Authors' Addresses Adam Roach dynamicsoft 5100 Tennyson Pkwy Suite 1200 Plano, TX 75024 US EMail: adam@dynamicsoft.com Roach, et al. Expires August 18, 2003 [Page 36] Internet-Draft SIP Event Lists February 2003 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936 US EMail: jdrosen@dynamicsoft.com Ben Campbell dynamicsoft 5100 Tennyson Pkwy Suite 1200 Plano, TX 75024 US EMail: bcampbell@dynamicsoft.com Roach, et al. Expires August 18, 2003 [Page 37] Internet-Draft SIP Event Lists February 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Roach, et al. Expires August 18, 2003 [Page 38]