Network Working Group A. B. Roach Internet-Draft J. Rosenberg Expires: February 8, 2005 B. Campbell dynamicsoft August 10, 2004 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists draft-ietf-simple-event-list-05 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 February 8, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. Roach, et al. Expires February 8, 2005 [Page 1] Internet-Draft SIP Event Lists August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 4. Operation of List Subscriptions . . . . . . . . . . . . . . 6 4.1 Negotiation of Support for Resource Lists . . . . . . . . . 6 4.2 Subscription Duration . . . . . . . . . . . . . . . . . . . 7 4.3 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 RLS Processing of SUBSCRIBE Requests . . . . . . . . . . . . 7 4.5 RLS Generation of NOTIFY requests . . . . . . . . . . . . . 8 4.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 9 4.7 Handling of Forked Requests . . . . . . . . . . . . . . . . 10 4.8 Rate of Notifications . . . . . . . . . . . . . . . . . . . 10 5. Using multipart/related to Convey Aggregate State . . . . . 11 5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 12 5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 13 5.4 Instance Attributes . . . . . . . . . . . . . . . . . . . . 13 5.5 Constructing Coherent Resource State . . . . . . . . . . . . 15 5.5.1 Processing Full State Notifications . . . . . . . . . . . . 16 5.5.2 Processing Partial State Notifications . . . . . . . . . . . 16 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 30 7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 30 7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 31 7.4 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 32 8.2 New MIME type for Resource List Meta-Information . . . . . . 32 8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 Normative References . . . . . . . . . . . . . . . . . . . . 36 Non-Normative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.1 Changes since -04 . . . . . . . . . . . . . . . . . . . . . 39 A.2 Changes since -03 . . . . . . . . . . . . . . . . . . . . . 39 A.3 Changes since -02 . . . . . . . . . . . . . . . . . . . . . 39 A.4 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 39 A.5 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 40 B. Intellectual Property Statement . . . . . . . . . . . . . . 41 Full Copyright Statement . . . . . . . . . . . . . . . . . . 42 Roach, et al. Expires February 8, 2005 [Page 2] Internet-Draft SIP Event Lists August 2004 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 list of resources they are interested in. Without some aggregating mechanism, this will require the subscriber generate a SUBSCRIBE request for each resource about which they want information. For environments in which bandwidth is limited, such as wireless networks, subscribing to each resource individually is problematic. Some 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 SUBSCRIBE refreshes 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. To solve these problems, this specification defines an extension to RFC 3265 [2] that allows for requesting and conveying notifications for lists 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: [9]) is also foreseen. The notifier for the list 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 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 constrained to be in the domain of the resource list server. Roach, et al. Expires February 8, 2005 [Page 3] Internet-Draft SIP Event Lists August 2004 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. The following terms are used throughout the remainder of this document. Back-End Subscription: Any subscription (SIP or otherwise) that an RLS creates to learn of the state of a resource. An RLS will create back-end subscriptions to learn of the state of a resource about which the RLS is not an authority. For back-end subscriptions, RLSes act as a subscriber. List Subscription: A subscription to a resource list. In list subscriptions, RLSes act a the notifier. Resource: A resource is any logical entity that has a state or states that can be subscribed to. Resources are identified by URIs. Resource List: A list of zero or more resources that can have their individual states subscribed to with a single subscription. RLMI: Resource List Meta-Information. RLMI is a document that describes the state of the virtual subscriptions associated with a list subscription. RLS: Resource List Server. RLSes accept subscriptions to resource lists and send notifications to update subscribers of the state of the resources in a resource list. Virtual Subscription: Virtual Subscriptions are a logical construct within an RLS that represent subscriptions to the resources in a resource list. For each list subscription it services, an RLS creates at least one virtual subscription for every resource in the resource list being subscribed to. In some cases, such as when the RLS is not the authority for the state of the resource, this virtual subscription will be associated with a back-end subscription. In other cases, such as when the RLS is the authority for the state of the resource, the virtual subscription will not have a corresponding back-end subscription. Roach, et al. Expires February 8, 2005 [Page 4] Internet-Draft SIP Event Lists August 2004 3. Overview of Operation This section provides an overview of the typical mode of operation of this extension. It is not normative. When users wish to subscribe to the resource of a list of resources, they can use the mechanisms described in this specification. The first step is creation of 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. 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 subscriptions to non-local resources may or may not be SIP subscriptions; any mechanism for determining such information may be employed. This document uses the term "back-end subscription" to refer to such a subscription, regardless of whether SIP is used to establish and service it. As the state of resources in the list change, the RLS generates notifications to the list subscribers. The RLS can, at its discretion, buffer notifications of resource changes, 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. The remaining sections contain the actual state information for each resource. Roach, et al. Expires February 8, 2005 [Page 5] Internet-Draft SIP Event Lists August 2004 4. Operation of List Subscriptions The event list extension acts, in many ways, like an event template package. In particular, any single list subscription must be homogeneous with respect to the underlying event package. In other words, a single list subscription can apply only one event package to all of the resources in the resource list. It is worth noting that it is perfectly valid, for an RLS to allow multiple subscriptions to the same list to use differing 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 a several virtual subscriptions to a tree of resources. The leaf nodes of this tree are virtual subscriptions of the event type given in the "Event" header field; 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 these virtual subscriptions are not literal SIP subscriptions (although they may result in SIP subscriptions, depending on the RLS implementation). 4.1 Negotiation of Support for Resource Lists This specification uses the SIP option tag mechanism for negotiating support for the extension defined herein. Refer to RFC3261 [1] for the normative description of processing of the "Supported" and "Require" header fields and the 421 (Extension Required) response code. A non-normative description of the implications of the use of option tags follows. Any client that supports the event list extension will include an option tag of "eventlist" in a "Supported" header field 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 field of the response to the SUBSCRIBE, and in all NOTIFY messages within that subscription. Roach, et al. Expires February 8, 2005 [Page 6] Internet-Draft SIP Event Lists August 2004 Use of "Require: eventlist" in NOTIFY messages is applied by the notifier to satisfy the RFC3261 requirement that a UAC MUST insert a Require header field into a request if the UAC wishes to insist that a UAS understand an extension in order to process the request. Because the NOTIFY would not be usable without applying the eventlist option, the notifier is obligated to include it. Including "eventlist" in a "Require" header field in a SUBSCRIBE request serves no purpose, and is consequently NOT RECOMMENDED. There is nothing in a SIP URI which indicates whether it represents a list of resources or a single resource. Therefore, if a subscriber sends a request to a URI that represents a list resource, but does not include a Supported header field listing the "eventlist" token, the notifier will typically return a 421 (Extension Required) response code. RFC 3261 [1] advises servers to avoid returning a 421, and instead, attempt to process the request without the extension. However, in this case, the URI fundamentally represents a list resource, and therefore, the subscription cannot proceed without this extension. 4.2 Subscription Duration Since the primary benefit of the resource list server is to reduce the overall messaging volume to a subscriber, it is RECOMMENDED that the subscription duration to a list be reasonably long. The default, when no duration is specified, is taken from the underlying event package. Of course, the standard techniques [2] can be used to increase or reduce this amount. 4.3 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 (including any types required by the event package being used). 4.4 RLS Processing of SUBSCRIBE Requests 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 an RLS can use any authorization policy it chooses. Roach, et al. Expires February 8, 2005 [Page 7] Internet-Draft SIP Event Lists August 2004 4.5 RLS 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. As a baseline behavior, the RLS MAY generate a NOTIFY to the RLS subscriber whenever the state of any resource on the list changes. See Section 5 for a detailed definition of the syntax used to convey the state of resource lists. For the purposes of the following discussion, it is important to know that the overall list contains zero or more resources, and that the resources contains zero or more instances. Each instance has a state associated with it (pending, active, or terminating), representing the state of the virtual subscription. Notifications contain a multipart document, the first part of which always contains meta-information about the list (e.g. membership, state of the virtual subscription to the resource). Remaining parts are used to convey the actual state of the resources listed in the meta-information. The "state" attribute of each instance of a resource in the meta- information is set according to the state of the virtual subscription. The meanings of the "state" attribute are described in RFC 3265 [2]. If an instance of a resource was previously reported to the subscriber but is no longer available (i.e. the virtual subscription to that instance has been terminated), the resource list server SHOULD include that resource instance in the meta-information in the first NOTIFY message sent to the subscriber following the instance's unavailability. The RLS MAY continue to do so for future notifications. When sending information for a terminated resource instance, the RLS indicates a state of "terminated" and an appropriate reason value. Valid reason values and their meanings are described in RFC 3265 [2]. If the RLS will attempt to recover the resource state again at some point in the future (e.g. when the reason in the meta-information is "probation"), then the instance of the resource SHOULD remain in the meta-information until the instance state is available, or until the RLS gives up on making such state available. When the first SUBSCRIBE message for a particular subscription is received by a RLS, the RLS will often not know state information for Roach, et al. Expires February 8, 2005 [Page 8] Internet-Draft SIP Event Lists August 2004 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 RLS 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 co-located 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 include an RLMI document with full state indicated. The RLS SHOULD also include state information for all resources in the list for which the RLS has state, subject to policy restrictions. This allows the subscriber to refresh their state, and to recover from lost notifications. 4.6 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 some or all of the resources 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 indicated 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 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 messages. See Section 5.5 for more information. When full state is indicated, note that it applies only to the RLMI document in which it occurs. In particular, one of the elements in the document may in turn refer to another list of resources. Any such sub-lists will be detailed in their own RLMI documents, which may or may not have full state indicated. Further note that underlying event package may have its own rules for compositing partial state notification. When processing data Roach, et al. Expires February 8, 2005 [Page 9] Internet-Draft SIP Event Lists August 2004 related to those packages, their rules apply (i.e. the fact that they were reported as part of a list does not change their partial notification semantics). Finally, note that a consequence of the way in which resource list subscriptions work is that polling of resource state may not be particularly useful. While such polls will retrieve the resource list, they will not necessarily contain state for some or all of the resources on the list. 4.7 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 to a list MUST NOT install multiple subscriptions when the initial request is forked. If multiple responses are received, they are handled using the techniques described in section 4.4.9 of RFC 3265[2]. 4.8 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. Roach, et al. Expires February 8, 2005 [Page 10] Internet-Draft SIP Event Lists August 2004 5. Using multipart/related to Convey Aggregate State In order to convey the state of multiple resources, the list extension uses the "multipart/related" mime type. The syntax for multipart/related is defined in "The MIME Multipart/Related Content- type" [4]. 5.1 XML Syntax The root document of the multipart/related body MUST be a Resource List Meta-Information (RLMI) document. It is of type "application/ rlmi+xml". This document contains the meta-information for the resources contained in the notification. The schema for this XML document is given below. Roach, et al. Expires February 8, 2005 [Page 11] Internet-Draft SIP Event Lists August 2004 An example of a document formatted using this schema follows. 5.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. Roach, et al. Expires February 8, 2005 [Page 12] Internet-Draft SIP Event Lists August 2004 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, 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 list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). 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 contains 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. Finally, elements MAY contain a "cid" attribute. If present, the "cid" attribute identifies a section within the multipart/related body that contains aggregate state information for the resources contained in the list. The definition of such aggregate information is outside the scope of this document, and will be defined on a per- package basis as needed. The cid attribute is the Content-ID for the corresponding section in the multipart body. The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root. See Section 5.4 for an example. 5.3 Resource Attributes The resource list contains one element for each resource being reported in the notification. These resource elements contain attributes that identify meta-data associated 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. 5.4 Instance Attributes Each resource element contains zero or more instance elements. These instance elements are used to represent a single notifier for the Roach, et al. Expires February 8, 2005 [Page 13] Internet-Draft SIP Event Lists August 2004 resource. For event packages that allow forking, multiple virtual subscriptions may exist for a given resource. Multiple virtual subscriptions are represented as multiple instance elements in the corresponding resource element. For subscriptions in which forking does not occur, at most one instance will be present for a given 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. Construction of this string is an implementation decision. Any mechanism for generating this string is 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 field in RFC 3265 [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 field in RFC 3265 [2]. Note that the "reason" attribute 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 conveying state. The cid attribute is the Content-ID for the corresponding section in the multipart body. The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root. For example, consider a multipart/related document containing three parts; we'll label these parts A, B, and C. Part A is type application/rlmi+xml, part B is type multipart/related, and part C is type application/cpim-pidf+xml. Part B is in turn a document containing three parts: D, E, and F. Part D is of type application/rlmi+xml, and parts E and F are of type application/ cpim-pidf+xml. Roach, et al. Expires February 8, 2005 [Page 14] Internet-Draft SIP Event Lists August 2004 +-------------------------------------------+ | Top Level Document: multipart/related | | | | +---------------------------------------+ | | | Part A: application/rlmi+xml | | | +---------------------------------------+ | | | Part B: multipart/related | | | | | | | | +-----------------------------------+ | | | | | Part D: application/rlmi+xml | | | | | +-----------------------------------+ | | | | | Part E: application/cpim-pidf+xml | | | | | +-----------------------------------+ | | | | | Part F: application/cpim-pidf+xml | | | | | +-----------------------------------+ | | | | | | | +---------------------------------------+ | | | Part C: application/cpim-pidf+xml | | | +---------------------------------------+ | | | +-------------------------------------------+ Any "cid" attributes in document A must refer only to parts B or C. Referring to parts D, E, or F would be illegal. Similarly, Any "cid" attributes in document D must refer only to parts E or F. Referring to any other parts would be illegal. Also note that the subscription durations of any back-end subscriptions are not propagated into the meta-information state in any way. 5.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 corresponding event package. This value is used when comparing versions of partial notifications for a resource. Roach, et al. Expires February 8, 2005 [Page 15] Internet-Draft SIP Event Lists August 2004 The processing of the resource list notification depends on whether it contains full or partial state. 5.5.1 Processing Full State Notifications If a notification contains full state, indicated by the attribute "fullState" set to "true", the notification is used to update the table. A check is first made to ensure that the "version" attribute of the attribute in the received message is greater than the local version number. If not, the received document is discarded without any further processing. Otherwise, the contents of the resource-list table are flushed, and repopulated from the contents of the document. A new row in the table is created for each "resource" element. 5.5.2 Processing Partial State Notifications If a notification contains partial state, indicated by the attribute "fullState" set to "false", 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. The list subscriber SHOULD also 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. 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 February 8, 2005 [Page 16] Internet-Draft SIP Event Lists August 2004 6. Example This section gives an example call flow. It is not normative. If a conflict arises between this call flow 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 [6]. In this example, the RLS has information to service some of the resources on the list, but must consult other servers to retrieve information for others. The implementation of the RLS in this example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such information. Terminal pres.example.com pres.example.org | | pres.example.net | 1 |---SUBSCRIBE--->| | | 2 |<-----200-------| | | 3 |<----NOTIFY-----| | | 4 |------200------>| | | 5 | |---SUBSCRIBE--->| | 6 | |<-----200-------| | 7 | |<----NOTIFY-----| | 8 | |------200------>| | 9 | |------------SUBSCRIBE----------->| 10| |<--------------200---------------| 11| |<-------------NOTIFY-------------| 12| |---------------200-------------->| 13|<----NOTIFY-----| | | 14|------200------>| | | 1. We initiate 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 presence. Roach, et al. Expires February 8, 2005 [Page 17] Internet-Draft SIP Event Lists August 2004 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 call flow. Those steps are omitted for brevity. 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 RFC 3265 [2], the RLS sends a NOTIFY immediately upon accepting the subscription. In this example, we are assuming 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 Roach, et al. Expires February 8, 2005 [Page 18] Internet-Draft SIP Event Lists August 2004 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: binary Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" Roach, et al. Expires February 8, 2005 [Page 19] Internet-Draft SIP Event Lists August 2004 open sip:bob@example.com --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" closed --50UBfW7LSCVLtggUPe5z-- 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 Roach, et al. Expires February 8, 2005 [Page 20] Internet-Draft SIP Event Lists August 2004 "sip:ed@example.net". Since the local RLS knows how to receive notifications for list subscriptions, it includes the "Supported: eventlist" header field 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" header fields 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. 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 would normally take place at this point in the call flow. Those steps are omitted for brevity. Roach, et al. Expires February 8, 2005 [Page 21] Internet-Draft SIP Event Lists August 2004 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: 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 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.net;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. Roach, et al. Expires February 8, 2005 [Page 22] Internet-Draft SIP Event Lists August 2004 Local RLS -> Presence Server in example.net SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW From: ;tag=e45TmHTh To: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.example.com CSeq: 1002640632 NOTIFY Contact: Content-Length: 0 9. The Local RLS subscribes to the state of the other non-local resource. 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 call flow. Those steps are omitted for brevity. Roach, et al. Expires February 8, 2005 [Page 23] Internet-Draft SIP Event Lists August 2004 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: Expires: 3600 Content-Length: 0 11. In this example, we are assuming 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 sign [12] the body of the NOTIFY message. As described in RFC 2633, signing is performed by creating a multipart/signed document which has two parts. The first part is the document to be signed (in this example, the multipart/related document that describes the list resource states), while the second part is the actual signature. RLS in example.org -> Local RLS NOTIFY sip:pres.example.com SIP/2.0 Via: SIP/2.0/TCP pres.example.org;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: active;expires=3600 Require: eventlist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" Content-Length: 2038 --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: multipart/related;type="application/rlmi+xml"; Roach, et al. Expires February 8, 2005 [Page 24] Internet-Draft SIP Event Lists August 2004 start="";boundary="tuLLl3lDyPZX0GMr2YOo" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" open sip:joe@example.org --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" closed Roach, et al. Expires February 8, 2005 [Page 25] Internet-Draft SIP Event Lists August 2004 --tuLLl3lDyPZX0GMr2YOo-- --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pkcs7-signature [PKCS #7 signature here] --l3WMZaaL8NpQWGnQ4mlU-- 12. The Local RLS completes the NOTIFY transaction. Local RLS -> RLS in example.org SIP/2.0 200 OK Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI From: ;tag=JenZ40P3 To: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.example.com CSeq: 294444656 NOTIFY Contact: 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". To avoid corrupting the S/MIME signature on the data received from the RLS in example.org, the local RLS copies the entire application/signed body as-is into the notification that it sends. 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 Roach, et al. Expires February 8, 2005 [Page 26] Internet-Draft SIP Event Lists August 2004 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: binary Content-ID: <2BEI83@pres.example.com> Content-Type: application/rlmi+xml;charset="UTF-8" --TfZxoxgAvLqgj4wRWPDL Content-Transfer-Encoding: binary Content-ID: <1KQhyE@pres.example.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: multipart/related;type="application/rlmi+xml"; start="";boundary="tuLLl3lDyPZX0GMr2YOo" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" Roach, et al. Expires February 8, 2005 [Page 27] Internet-Draft SIP Event Lists August 2004 --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" open sip:joe@example.org --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/cpim-pidf+xml;charset="UTF-8" closed --tuLLl3lDyPZX0GMr2YOo-- --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pkcs7-signature Roach, et al. Expires February 8, 2005 [Page 28] Internet-Draft SIP Event Lists August 2004 [PKCS #7 signature here] --l3WMZaaL8NpQWGnQ4mlU-- --TfZxoxgAvLqgj4wRWPDL-- 14. The terminal completes the NOTIFY transaction. 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 February 8, 2005 [Page 29] Internet-Draft SIP Event Lists August 2004 7. Security Considerations Note that the mechanisms for obtaining state information for resources in a list are generally left to the RLS implementor. Some of the security issues below are specific to the the circumstance that a SIP back-end subscription is used for such a purpose. Non-SIP mechanisms for obtaining state information of resources in a list will typically have their own security issues associated with doing so; however, exhaustively enumerating such access methods is not possible in this document. Implementors using such mechanisms must analyze their chosen access methods for relevant security issues. 7.1 Authentication If back-end subscriptions are required to retrieve resource state information, 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 [14] 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 and back-end subscriptions. The RLS would authenticate the subscriber, and then MAY use the SIP extensions for authenticated identity assertion [7] to provide an authenticated identity to the notifiers for the resource. 7.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 back-end 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 notifier for 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, Roach, et al. Expires February 8, 2005 [Page 30] Internet-Draft SIP Event Lists August 2004 depending on the identity of the subscribing user. Implementations MUST NOT attempt to perform this type of optimization unless adequate access to complete authorization policy can be guaranteed. Note that this is a very difficult problem to solve correctly. Even in the cases that such access is believed possible, this mode of operation is NOT RECOMMENDED. 7.3 Signing and Sealing Implementors should keep in mind that any section of the MIME body may be signed and/or encrypted as necessary. Resource List Servers should take care not to modify any MIME bodies they receive from any back-end subscriptions, 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 to any SIP back-end subscriptions, if the subscriber includes them in the initial SUBSCRIBE message. Not doing so may actually result in resources refusing 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 implementation of encryption and signing by the RLS is not necessary to be able to pass through signed and/or encrypted bodies. 7.4 Infinite Loops One risk introduced by the ability to nest resource lists is the possibility of creating lists which ultimately contain themselves as a sub-list. Detection and handling of such a case is trivial when the RLS services all of the virtual subscriptions internally. When back-end subscriptions are created to service virtual subscriptions, however, detection of such situations becomes a more difficult problem. Implementors of RLSes that create back-end subscriptions MUST implement safeguards to prevent such nestings from creating an infinite loop of subscriptions. Typically, such mechanisms will require support in the back-end subscription protocol. In particular, applying filters to the back-end subscriptions can be an effective way to preclude such problems. Roach, et al. Expires February 8, 2005 [Page 31] Internet-Draft SIP Event Lists August 2004 8. IANA Considerations 8.1 New SIP Option Tag: eventlist This section defines a new option tag for the registry established by section 27.1 of RFC 3261[1]. Option Tag Name: eventlist Description: Extension to allow subscriptions to lists of resources Published specification: RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]] 8.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 [11] 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 [10] and RFC 3023 [11] 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 meta-information for the state of lists of resources within a Session Initiation Protocol (SIP) subscription. Roach, et al. Expires February 8, 2005 [Page 32] Internet-Draft SIP Event Lists August 2004 Additional information: 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. 8.3 URN Sub-Namespace URI: urn:ietf:params:xml:ns:rlmi Description: This is the XML namespace URI for XML elements defined by [RFCXXXX] to describe information about subscriptions when such subscriptions are aggregated within a single SIP subscription. It is used in the application/rlmi+xml body type. Registrant Contact: 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. XML: Roach, et al. Expires February 8, 2005 [Page 33] Internet-Draft SIP Event Lists August 2004 BEGIN Namespace for SIP Event Resource List Meta-Information

Namespace for SIP Event Resource List Meta-Information

application/rlmi+xml

See RFCXXXX.

END Roach, et al. Expires February 8, 2005 [Page 34] Internet-Draft SIP Event Lists August 2004 9. Acknowledgements Thanks to Sean Olson for a review of and corrections to the usage of XML in this protocol. Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage and Robert Sparks for their careful reviews of and comments on this document. Roach, et al. Expires February 8, 2005 [Page 35] Internet-Draft SIP Event Lists August 2004 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. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Roach, et al. Expires February 8, 2005 [Page 36] Internet-Draft SIP Event Lists August 2004 Non-Normative References [6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. [7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft- ietf-sip-identity-02 (work in progress), May 2004. [8] Olson, S., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content- indirect-mech-02 (work in progress), February 2003. [9] Crocker, D. and J. Peterson, "Common Profile for Presence (CPP)", draft-ietf-impp-pres-02 (work in progress), February 2003. [10] Levinson, E., "SGML Media Types", RFC 1874, December 1995. [11] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [12] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [13] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Authors' Addresses Adam Roach dynamicsoft 5100 Tennyson Pkwy Suite 1200 Plano, TX 75024 US EMail: adam@dynamicsoft.com Roach, et al. Expires February 8, 2005 [Page 37] Internet-Draft SIP Event Lists August 2004 Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054-2711 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 February 8, 2005 [Page 38] Internet-Draft SIP Event Lists August 2004 Appendix A. Changes Note that this section will be removed before publication as an RFC. A.1 Changes since -04 Removed references to P-Asserted-Identity mechanism. Removed some leftover cruft from the section on constructing coherent resource state. A.2 Changes since -03 o Changed Content-Encoding in examples from 8bit to binary. o Adjusted formatting to comply with RFC 2223. A.3 Changes since -02 o Added discussion in security section about infinite loops. o Fixed several places where the document said "one or more" instead of "zero or more", when referring to the number of resources that can appear in a list and the number of instances that can appear in a resource. o Tiny editorial cleanup (mostly spelling gaffes). A.4 Changes since -01 o Several editorial updates. Change "collection" to "list" everywhere. o Added terminology section. o Added restriction that cid attributes can only point to documents at the same level as the RLMI document in which they appear. o Clarified description of how to construct resource state by splitting discussion of full state notifications apart from discussion of partial-state notifications. Roach, et al. Expires February 8, 2005 [Page 39] Internet-Draft SIP Event Lists August 2004 A.5 Changes since -00 o Removed text in several places which went into detail about specific implementations which used SIP SUB/NOT for back-end subscriptions. Some of this text will probably be published later as part of an implementors' guide. o Removed specific semantics for "Event" header field parameters and SUBSCRIBE bodies. These will be defined on a per-package basis, probably by the filtering work. o Added "cid" attribute to elements. o Reworked XML schema definition for meta-information. o Added IANA registration for XML namespace. o Minor editorial fixes Roach, et al. Expires February 8, 2005 [Page 40] Internet-Draft SIP Event Lists August 2004 Appendix B. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Roach, et al. Expires February 8, 2005 [Page 41] Internet-Draft SIP Event Lists August 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Roach, et al. Expires February 8, 2005 [Page 42]