view Side-By-Side changes

Network Working Group                                        A. B. Roach
Internet-Draft                                              J. Rosenberg
Expires: August 18, September 26, 2003                                  B. Campbell
                                                             dynamicsoft
                                                       February 17,
                                                          March 28, 2003


  A Session Initiation Protocol (SIP) Event Notification Extension for
                              Collections
                    draft-ietf-simple-event-list-00
                    draft-ietf-simple-event-list-01

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, September 26, 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, September 26, 2003               [Page 1]

Internet-Draft              SIP Event Lists                February                   March 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Operation of List Subscriptions  . . . . . . . . . . . . . .   6 .  5
   3.1 Negotiation of Support for Resource Lists  . . . . . . . . .   6
   3.2  Event Header Parameters  . . . . . . . . . . . . . . . . . .   7
   3.3  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . .   7
   3.4  5
   3.2 Subscription Duration  . . . . . . . . . . . . . . . . . . .   7
   3.5 .  6
   3.3 NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . . .   7
   3.6 .  6
   3.4 Notifier Processing of SUBSCRIBE Requests  . . . . . . . . .   7
   3.7 .  6
   3.5 Notifier Generation of NOTIFY requests . . . . . . . . . . .   8
   3.8 .  6
   3.6 Subscriber Processing of NOTIFY Requests . . . . . . . . . .   9
   3.9 .  8
   3.7 Handling of Forked Requests  . . . . . . . . . . . . . . . .  10
   3.10 .  8
   3.8 Rate of Notifications  . . . . . . . . . . . . . . . . . . .  10
   3.11 .  9
   3.9 State Agents . . . . . . . . . . . . . . . . . . . . . . . .  10 .  9
   4.  Using multipart/related to Convey Aggregate State  . . . . .  12 . 10
   4.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . .  12 . 10
   4.2 List Attributes  . . . . . . . . . . . . . . . . . . . . . .  13 . 11
   4.3 Resource Attributes  . . . . . . . . . . . . . . . . . . . .  13 . 12
   4.4 Instance Attributes  . . . . . . . . . . . . . . . . . . . .  14 . 12
   4.5 Constructing Coherent Resource State . . . . . . . . . . . .  15 . 13
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  17 . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . .  30 . 28
   6.1 Authentication . . . . . . . . . . . . . . . . . . . . . . .  30 . 28
   6.2 Risks of Improper Aggregation  . . . . . . . . . . . . . . .  30 . 28
   6.3 Signing and Sealing  . . . . . . . . . . . . . . . . . . . .  30 . 29
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  32 . 30
   7.1 New SIP Option Tag: eventlist  . . . . . . . . . . . . . . .  32 . 30
   7.2 New MIME type for Resource List Meta-Information . . . . . .  32
   8.   Open Issues . 30
   7.3 URN Sub-Namespace  . . . . . . . . . . . . . . . . . . . . . . 31
   8.  Acknowledgements .  34 . . . . . . . . . . . . . . . . . . . . . . 33
       Normative References . . . . . . . . . . . . . . . . . . . .  35 . 34
       Non-Normative References . . . . . . . . . . . . . . . . . .  36 . 35
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  36 . 35
   A.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
   A.1 Changes since -00  . . . . . . . . . . . . . . . . . . . . . . 37
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 38















Roach, et al.          Expires August 18, September 26, 2003               [Page 2]

Internet-Draft              SIP Event Lists                February                   March 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
   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 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, September 26, 2003               [Page 3]

Internet-Draft              SIP Event Lists                February                   March 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

   Note that such a subscription will typically subscriptions to non-local resources may or may not be SIP subscription; however,
   subscriptions; 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,
   employed.  This document uses the user can provide credentials term "back-end subscription" to the RLS ahead of time; this requires
   refer to such a trust relationship between
   the user and RLS.  Additional approaches can be formulated using the
   mechanisms defined in "Private Extensions subscription, regardless of whether SIP is used to the Session Initiation
   Protocol (SIP) for Asserted Identity within Trusted Networks" [6]
   establish and
   "Enhancements for Authenticated Identity Management service them.

   As the state of resources in the Session
   Initiation Protocol (SIP)" [7].

   As notifications arrive from individual resources, list change, the RLS accepts
   them, extracts the resource information, and generates a notification
   notifications to the subscriber. list subscribers.  The RLS can, at its
   discretion, buffer notifications that it receives, 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.



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, September 26, 2003               [Page 5] 4]

Internet-Draft              SIP Event Lists                February                   March 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 a virtual subscription to a tree of
   resources.  The leaf nodes of this tree are virtual 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 these virtual subscriptions are
   not 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; (although they will presumably not
   send SUBSCRIBE requests to themselves may result in order to service such list
   subscriptions. SIP
   subscriptions, depending on the RLS implementation).

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 inherently 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,



Roach, et al.          Expires September 26, 2003               [Page 5]

Internet-Draft              SIP Event Lists                   March 2003


   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 8.2.4 for the
   resources in the list.

3.4 extension described herein.

3.2 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 taken from the need
   to refresh too frequently. underlying event
   package.  Of course, the standard techniques [2] can be used to
   increase or reduce this amount.

3.5

3.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.

3.6

3.4 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

3.5 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.  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 4 for a detailed 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



Roach, et al.          Expires September 26, 2003               [Page 6]

Internet-Draft              SIP Event Lists                   March 2003


   with it (pending, active, or terminating), representing the state of
   the subscription.

   As

   Notifications contain a baseline behavior, if multipart document, the RLS acts as a subscriber to determine first part of which
   always contains meta-information about the list (e.g.  membership,
   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 virtual subscription to a resource is terminated by the notifier and the
   RLS is unable resource).  Remaining parts
   are used to re-establish convey the subscription by actual state of the recovery
   mechanisms described in SIP Events [2], that resource is still
   present resources listed in resource list NOTIFY messages as appropriate. the
   meta-information.

   The "state" attribute of each instance of a resource in the meta-
   information is set according to "terminated", and the "reason" attribute is
   copied from state of the "reason" parameter from virtual
   subscription.  The meanings of the "Subscription-State" "state" attribute are described in
   the NOTIFY received from the resource.
   RFC 3265 [2].

   If a SUBSCRIBE to an instance of a resource was previously reported to the
   subscriber but is refused with a response code no longer available (i.e.  the virtual subscription
   to that
   cannot be recovered from, instance has been terminated), the resource list server
   SHOULD include that resource is still present instance in resource
   list the meta-information in the
   first NOTIFY messages as appropriate. message sent to the subscriber following the instance's
   unavailability.  The resource will be reported
   with RLS MAY continue to do so for future
   notifications.

   When sending information for a terminated resource instance, the RLS
   indicates a "state" state of "terminated," "terminated" and a "reason" parmeter of
   "rejected".

   Note that the forgoing explanation is given an appropriate reason value.
   Valid reason values and their meanings are described in term of a back-end
   subscription RFC 3265 [2].
   If the RLS will attempt to resources recover the resource state again at some
   point in the list.  In practice, such
   subscriptions may not actually exist.  In these cases, future (e.g.  when the RLS sets reason in the "state" and "reason" attributes meta-informaion is
   "probation"), then the instance of the resource SHOULD remain 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 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 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 <instance> 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 SHOULD result in full meta-information about the list of
   resources.  The RLS will SHOULD also include state information for all



Roach, et al.          Expires September 26, 2003               [Page 7]

Internet-Draft              SIP Event Lists                   March 2003


   resources in the list for which the RLS has state. state, subject to policy
   restrictions.  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

3.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 <resource> element for each resource in the list.
   Each <resource> 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 <list> 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

3.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 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 <instance> elements in the corresponding <resource> element
   in the root part of the multipart/related body.  See section Section
   4 and its subsections for details.

3.10






Roach, et al.          Expires September 26, 2003               [Page 8]

Internet-Draft              SIP Event Lists                   March 2003


3.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.

3.11

3.9 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, September 26, 2003               [Page 11] 9]

Internet-Draft              SIP Event Lists                February                   March 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 meta-information for the
   resources contained in the notification.  The schema for this XML
   document is given below.


   <?xml version="1.0" encoding="UTF-8"?> encoding="UTF-8" ?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi"
              elementFormDefault="qualified"
              xmlns="urn:ietf:params:xml:ns:rlmi"
              xmlns:xs="http://www.w3.org/2001/XMLSchema">
     <xs:element name="instance"> name="list">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="resource" minOccurs="0" maxOccurs="unbounded" />
         </xs:sequence>
         <xs:attribute name="id" type="xs:string use="required""/> name="uri" type="xs:anyURI" use="required" />
         <xs:attribute name="state" type="xs:string" use="required"/> name="version" type="xs:unsignedInt" use="required" />
         <xs:attribute name="reason" name="fullState" type="xs:boolean" use="required" />
         <xs:attribute name="name" type="xs:string" use="optional"/> use="optional" />
         <xs:attribute name="cid" type="xs:string use="optional""/> use="optional" />
         <xs:anyAttribute />
       </xs:complexType>
     </xs:element>
     <xs:element name="resource">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="instance" minOccurs="0" maxOccurs="unbounded"/> maxOccurs="unbounded" />
         </xs:sequence>
         <xs:attribute name="uri" type="xs:string" use="required"/> type="xs:anyURI" use="required" />
         <xs:attribute name="name" type="xs:string" use="optional"/> use="optional" />
         <xs:anyAttribute />
       </xs:complexType>
     </xs:element>
     <xs:element name="list"> name="instance">
       <xs:complexType>
         <xs:element ref="resource"
         <xs:sequence>
           <xs:any minOccurs="0" maxOccurs="unbounded"/>
         <xs:attribute name="uri" type="xs:string" use="required"/> maxOccurs="unbounded" />



Roach, et al.          Expires September 26, 2003              [Page 10]

Internet-Draft              SIP Event Lists                   March 2003


         </xs:sequence>
         <xs:attribute name="version" type="xs:unsignedInt" use="required"/> name="id" type="xs:string use="required" />
         <xs:attribute name="fullState" type="xs:boolean" use="required"/> name="state" type="xs:string" use="required" />
         <xs:attribute name="name" name="reason" type="xs:string" use="optional"/> use="optional" />
         <xs:attribute name="cid" type="xs:string use="optional" />
         <xs:anyAttribute />
       </xs:complexType>
     </xs:element>
   </xs:schema>


   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


   <list uri="sip:adam-friends@lists.example.com" version="7"
         name="Buddy List" fullState="true">
     <resource uri="sip:bob@example.com" name="Bob Smith">
       <instance id="juwigmtboe" state="active" cid="12345.aaa@example.com"/>
     </resource>
     <resource uri="sip:dave@example.com" name="Dave Jones">
       <instance id="hqzsuxtfyq" state="active" cid="12345.aab@example.com"/>
     </resource>
     <resource uri="sip:jim@example.com" name="Jim">
       <instance id="oflzxqzuvg" state="terminated" reason="rejected" />
     </resource>
     <resource uri="sip:ed@example.com" name="Ed">
       <instance id="grqhzsppxb" state="pending"/>
     </resource>
   </list>


4.2 List Attributes

   The <list> element present in a list notification MUST contain three
   attributes.

   The first mandatory <list> 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 <list> 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



Roach, et al.          Expires September 26, 2003              [Page 11]

Internet-Draft              SIP Event Lists                   March 2003


   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.

   Finally, <list> 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.

4.3 Resource Attributes

   The resource list contains one <resource> 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 <resource>
   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 virtual
   subscriptions corresponding to may exist for a single resource given resource.  Multiple virtual
   subscriptions are represented by
   including as multiple instance elements in the
   corresponding resource element.  For subscriptions in which forking
   does not occur, only at most one instance will be present in the 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.  Composition of this string is



Roach, et al.          Expires September 26, 2003              [Page 12]

Internet-Draft              SIP Event Lists                   March 2003


   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
   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 in SIP Events RFC 3265 [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  The cid attribute is the Content-ID for the
   corresponding section. section in the multipart body.

   Note that the expiration subscription durations of the underlying any back-end subscriptions
   (if any)
   are not propagated into the aggregated meta-information 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 <resource> 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 <list> 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



Roach, et al.          Expires September 26, 2003              [Page 13]

Internet-Draft              SIP Event Lists                   March 2003


   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 <list> 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 <list> 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, September 26, 2003              [Page 16] 14]

Internet-Draft              SIP Event Lists                February                   March 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].

   In this example, the RLS has information to service some of the
   resources on the list, but must consult other servers to retrive
   information for others.  The implementation of the RLS in this
   example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such
   information.

   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: <sip:adam-buddies@pres.example.com>
   From: <sip:adam@example.com>;tag=ie4hbb8t
   Call-ID: cdB34qLToC@terminal.example.com
   CSeq: 322723822 SUBSCRIBE
   Contact: <sip:terminal.example.com>
   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





Roach, et al.          Expires September 26, 2003              [Page 15]

Internet-Draft              SIP Event Lists                   March 2003


   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: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
   From: <sip:adam@example.com>;tag=ie4hbb8t
   Call-ID: cdB34qLToC@terminal.example.com
   CSeq: 322723822 SUBSCRIBE
   Contact: <sip:pres.example.com>
   Expires: 7200
   Require: eventlist
   Content-Length: 0



   3.   As is required by SIP Events RFC 3265 [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 <resource> elements contain no
        <instance> 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: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
   To: <sip:adam@example.com>;tag=ie4hbb8t
   Call-ID: cdB34qLToC@terminal.example.com
   CSeq: 997935768 NOTIFY
   Contact: <sip:pres.example.com>
   Event: presence
   Subscription-State: active;expires=7200
   Require: eventlist
   Content-Type: multipart/related;type="application/rlmi+xml";
       start="<nXYxAE@pres.example.com>";boundary="50UBfW7LSCVLtggUPe5z"
   Content-Length: 1560

   --50UBfW7LSCVLtggUPe5z
   Content-Transfer-Encoding: 8bit
   Content-ID: <nXYxAE@pres.example.com>
   Content-Type: application/rlmi+xml;charset="UTF-8"




Roach, et al.          Expires August 18, September 26, 2003              [Page 18] 16]

Internet-Draft              SIP Event Lists                February                   March 2003


   --50UBfW7LSCVLtggUPe5z
   Content-Transfer-Encoding: 8bit
   Content-ID: <nXYxAE@pres.example.com>
   Content-Type: application/rlmi+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <list uri="sip:adam-friends@pres.example.com" version="1"
         name="Buddy List at COM" fullState="true">
     <resource uri="sip:bob@example.com" name="Bob Smith">
       <instance id="juwigmtboe" state="active" cid="bUZBsM@pres.example.com"/>
     </resource>
     <resource uri="sip:dave@example.com" name="Dave Jones">
       <instance id="hqzsuxtfyq" state="active" cid="ZvSvkz@pres.example.com"/>
     </resource>
     <resource uri="sip:ed@example.net" name="Ed at NET" />
     <resource uri="sip:adam-friends@example.org" name="My Friends at ORG" />
   </list>

   --50UBfW7LSCVLtggUPe5z
   Content-Transfer-Encoding: 8bit
   Content-ID: <bUZBsM@pres.example.com>
   Content-Type: application/cpim-pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       entity="sip:bob@example.com">
     <tuple id="sg89ae">
       <status>
         <basic>open</basic>
       </status>
       <contact priority="1.0">sip:bob@example.com</contact>
     </tuple>
   </presence>

   --50UBfW7LSCVLtggUPe5z
   Content-Transfer-Encoding: 8bit
   Content-ID: <ZvSvkz@pres.example.com>
   Content-Type: application/cpim-pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       entity="sip:dave@example.com">
     <tuple id="slie74">
       <status>
         <basic>closed</basic>
       </status>
     </tuple>
   </presence>

   --50UBfW7LSCVLtggUPe5z--



Roach, et al.          Expires August 18, September 26, 2003              [Page 19] 17]

Internet-Draft              SIP Event Lists                February                   March 2003


   --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: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
   To: <sip:adam@example.com>;tag=ie4hbb8t
   Call-ID: cdB34qLToC@terminal.example.com
   CSeq: 997935768 NOTIFY
   Contact: <sip:terminal.example.com>
   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, September 26, 2003              [Page 20] 18]

Internet-Draft              SIP Event Lists                February                   March 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: <sip:ed@example.net>
   From: <sip:pres.example.com>;tag=aM5icQu9
   Call-ID: Ugwz5ARxNw@pres.example.com
   CSeq: 870936068 SUBSCRIBE
   Contact: <sip:pres.example.com>
   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: <sip:ed@example.net>;tag=e45TmHTh
   From: <sip:pres.example.com>;tag=aM5icQu9
   Call-ID: Ugwz5ARxNw@pres.example.com
   CSeq: 870936068 SUBSCRIBE
   Contact: <sip:example.net>
   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, September 26, 2003              [Page 21] 19]

Internet-Draft              SIP Event Lists                February                   March 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: <sip:ed@example.net>;tag=e45TmHTh
   To: <sip:pres.example.com>;tag=aM5icQu9
   Call-ID: Ugwz5ARxNw@pres.example.com
   CSeq: 1002640632 NOTIFY
   Contact: <sip:example.net>
   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: <sip:ed@example.net>;tag=e45TmHTh
   To: <sip:pres.example.com>;tag=aM5icQu9
   Call-ID: Ugwz5ARxNw@pres.example.com
   CSeq: 1002640632 NOTIFY
   Contact: <sip:pres.example.com>
   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, September 26, 2003              [Page 22] 20]

Internet-Draft              SIP Event Lists                February                   March 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: <sip:adam-friends@example.org>
   From: <sip:pres.example.com>;tag=a12eztNf
   Call-ID: kBq5XhtZLN@pres.example.com
   CSeq: 980774491 SUBSCRIBE
   Contact: <sip:pres.example.com>
   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: <sip:adam-friends@example.org>;tag=JenZ40P3
   From: <sip:pres.example.com>;tag=a12eztNf
   Call-ID: kBq5XhtZLN@pres.example.com
   CSeq: 980774491 SUBSCRIBE
   Contact: <sip:example.org>
   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, September 26, 2003              [Page 23] 21]

Internet-Draft              SIP Event Lists                February                   March 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: <sip:adam-friends@example.org>;tag=JenZ40P3
   To: <sip:pres.example.com>;tag=a12eztNf
   Call-ID: kBq5XhtZLN@pres.example.com
   CSeq: 294444656 NOTIFY
   Contact: <sip:example.org>
   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: <ZPvJHL@example.org>
   Content-Type: multipart/related;type="application/rlmi+xml";
       start="<Cvjpeo@example.org>";boundary="tuLLl3lDyPZX0GMr2YOo"

   --tuLLl3lDyPZX0GMr2YOo
   Content-Transfer-Encoding: 8bit
   Content-ID: <Cvjpeo@example.org>
   Content-Type: application/rlmi+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <list uri="sip:adam-friends@example.org" version="1"
         name="Buddy List at ORG" fullState="true">
     <resource uri="sip:joe@example.org" name="Joe Thomas">
       <instance id="1" state="active" cid="mrEakg@example.org"/>
     </resource>
     <resource uri="sip:mark@example.org" name="Mark Edwards">
       <instance id="1" state="active" cid="KKMDmv@example.org"/>
     </resource>
   </list>

   --tuLLl3lDyPZX0GMr2YOo
   Content-Transfer-Encoding: 8bit
   Content-ID: <mrEakg@example.org>
   Content-Type: application/cpim-pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       entity="sip:joe@example.org">
     <tuple id="7823a4">



Roach, et al.          Expires August 18, September 26, 2003              [Page 24] 22]

Internet-Draft              SIP Event Lists                February                   March 2003


       <status>
         <basic>open</basic>
       </status>
       <contact priority="1.0">sip:joe@example.org</contact>
     </tuple>
   </presence>

   --tuLLl3lDyPZX0GMr2YOo
   Content-Transfer-Encoding: 8bit
   Content-ID: <KKMDmv@example.org>
   Content-Type: application/cpim-pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       entity="sip:mark@example.org">
     <tuple id="398075">
       <status>
         <basic>closed</basic>
       </status>
     </tuple>
   </presence>

   --tuLLl3lDyPZX0GMr2YOo--

   --l3WMZaaL8NpQWGnQ4mlU
   Content-Transfer-Encoding: 8bit
   Content-ID: <K9LB7k@example.org>
   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, September 26, 2003              [Page 25] 23]

Internet-Draft              SIP Event Lists                February                   March 2003


   Local RLS -> RLS in example.org

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKmGL1nyZfQI
   From: <sip:adam-friends@example.org>;tag=JenZ40P3
   To: <sip:pres.example.com>;tag=a12eztNf
   Call-ID: kBq5XhtZLN@pres.example.com
   CSeq: 294444656 NOTIFY
   Contact: <sip:pres.example.com>
   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: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
   To: <sip:adam@example.com>;tag=ie4hbb8t
   Call-ID: cdB34qLToC@terminal.example.com
   CSeq: 997935769 NOTIFY
   Contact: <sip:pres.example.com>
   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"

   <?xml version="1.0" encoding="UTF-8"?>
   <list uri="sip:adam-friends@pres.example.com" version="2"
         name="Buddy List at COM" fullState="false">
     <resource uri="sip:ed@example.net" name="Ed at NET">



Roach, et al.          Expires August 18, September 26, 2003              [Page 26] 24]

Internet-Draft              SIP Event Lists                February                   March 2003


       <instance id="sdlkmeopdf" state="pending"/>
     </resource>
     <resource uri="sip:adam-friends@example.org" name="My Friends at ORG">
       <instance id="cmpqweitlp" state="active" cid="1KQhyE@pres.example.com"/>
     </resource>
   </list>

   --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: <ZPvJHL@example.org>
   Content-Type: multipart/related;type="application/rlmi+xml";
       start="<Cvjpeo@example.org>";boundary="tuLLl3lDyPZX0GMr2YOo"

   --tuLLl3lDyPZX0GMr2YOo
   Content-Transfer-Encoding: 8bit
   Content-ID: <Cvjpeo@example.org>
   Content-Type: application/rlmi+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <list uri="sip:adam-friends@example.org" version="1"
         name="Buddy List at ORG" fullState="true">
     <resource uri="sip:joe@example.org" name="Joe Thomas">
       <instance id="1" state="active" cid="mrEakg@example.org"/>
     </resource>
     <resource uri="sip:mark@example.org" name="Mark Edwards">
       <instance id="1" state="active" cid="KKMDmv@example.org"/>
     </resource>
   </list>

   --tuLLl3lDyPZX0GMr2YOo
   Content-Transfer-Encoding: 8bit
   Content-ID: <mrEakg@example.org>
   Content-Type: application/cpim-pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       entity="sip:joe@example.org">
     <tuple id="7823a4">
       <status>
         <basic>open</basic>
       </status>
       <contact priority="1.0">sip:joe@example.org</contact>



Roach, et al.          Expires August 18, September 26, 2003              [Page 27] 25]

Internet-Draft              SIP Event Lists                February                   March 2003


     </tuple>
   </presence>

   --tuLLl3lDyPZX0GMr2YOo
   Content-Transfer-Encoding: 8bit
   Content-ID: <KKMDmv@example.org>
   Content-Type: application/cpim-pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       entity="sip:mark@example.org">
     <tuple id="398075">
       <status>
         <basic>closed</basic>
       </status>
     </tuple>
   </presence>

   --tuLLl3lDyPZX0GMr2YOo--

   --l3WMZaaL8NpQWGnQ4mlU
   Content-Transfer-Encoding: 8bit
   Content-ID: <K9LB7k@example.org>
   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, September 26, 2003              [Page 28] 26]

Internet-Draft              SIP Event Lists                February                   March 2003


   Terminal -> Local RLS

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1
   From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
   To: <sip:adam@example.com>;tag=ie4hbb8t
   Call-ID: cdB34qLToC@terminal.example.com
   CSeq: 997935769 NOTIFY
   Contact: <sip:terminal.example.com>
   Content-Length: 0









































Roach, et al.          Expires August 18, September 26, 2003              [Page 29] 27]

Internet-Draft              SIP Event Lists                February                   March 2003


6. 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
   analyse their chosen access methods for relevant security issues.

6.1 Authentication

   The usage of the RLS does introduce some security considerations.
   The  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 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. concept
   and back-end subscriptions.  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. notifiers
   for the resource.

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 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



Roach, et al.          Expires September 26, 2003              [Page 28]

Internet-Draft              SIP Event Lists                   March 2003


   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, 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, 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 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, September 26, 2003              [Page 31] 29]

Internet-Draft              SIP Event Lists                February                   March 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 meta-information for the state of collections of resources
      within a Session Initiation Protocol (SIP) subscription.

   Additional information:




Roach, et al.          Expires August 18, September 26, 2003              [Page 32] 30]

Internet-Draft              SIP Event Lists                February                   March 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: 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.


7.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 August 18, September 26, 2003              [Page 33] 31]

Internet-Draft              SIP Event Lists                   March 2003


         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml">
           <head>
             <meta http-equiv="content-type"
                content="text/html;charset=utf-8"/>
             <title>Namespace for SIP Event Resource List
                    Meta-Information</title>
           </head>
           <body>
             <h1>Namespace for SIP Event Resource List Meta-Information</h1>
             <h2>application/rlmi+xml</h2>
             <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
           </body>
           </html>
         END

































Roach, et al.          Expires September 26, 2003              [Page 32]

Internet-Draft              SIP Event Lists                February                   March 2003


8. Open Issues

   o  RFC 3265 allows event packages to include bodies in their
      SUBSCRIBE requests to filter notifications.  It would be natural Acknowledgements

   Thanks to merely copy the body from the SUBSCRIBE in Sean Olson for 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 review of and corrections to the
      provisioned data that is considered part usage of the list).
   XML in this protocol.















































Roach, et al.          Expires August 18, September 26, 2003              [Page 34] 33]

Internet-Draft              SIP Event Lists                February                   March 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, September 26, 2003              [Page 35] 34]

Internet-Draft              SIP Event Lists                February                   March 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, September 26, 2003              [Page 36] 35]

Internet-Draft              SIP Event Lists                February                   March 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, September 26, 2003              [Page 36]

Internet-Draft              SIP Event Lists                   March 2003


Appendix A. Changes

   Note that this section will be removed before publication as an RFC.

A.1 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 parameters and
      SUBSCRIBE bodies.  These will be defined on a per-package basis,
      probably by the filtering work.

   o  Added "cid" attribute to <list> elements.

   o  Reworked XML schema definition for meta-information.

   o  Added IANA registration for XML namespace.

   o  Minor editorial fixes





























Roach, et al.          Expires September 26, 2003              [Page 37]

Internet-Draft              SIP Event Lists                February                   March 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, September 26, 2003              [Page 38]

----