rfc4662 a session initiation protocol (sip) event notification extension.txt

有关IMS SIP及Presence应用的RFC文档包

      the eventlist option, the notifier is obligated to include it.

   Including "eventlist" in a "Require" header field in a SUBSCRIBE
   request serves no purpose except to break interoperability in certain
   cases, and is consequently NOT RECOMMENDED.



Roach, et al.               Standards Track                     [Page 6]

RFC 4662                    SIP Event Lists                  August 2006


   Sending of "Supported: eventlist" in a NOTIFY message is meaningless
   and silly.  Implementations SHOULD NOT include "Supported: eventlist"
   in any requests except for SUBSCRIBE.

   There is nothing in a SIP URI that 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 that servers 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 a 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.

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
   differentiators between various RLS implementations is the means by
   which they aggregate, rate-limit, or optimize the way in which



Roach, et al.               Standards Track                     [Page 7]

RFC 4662                    SIP Event Lists                  August 2006


   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.

   It is important to understand that any given subscription is a
   subscription either to a single resource or to a list of resources.
   This nature (single resource versus list of resources) cannot change
   during the duration of a single subscription.  In particular, this
   means that RLSes MUST NOT send NOTIFY messages that do not contain
   RLMI for a subscription if they have previously sent NOTIFY messages
   in that subscription containing RLMI.  Similarly, RLSes MUST NOT send
   NOTIFY messages that do contain RLMI for a subscription if they have
   previously sent NOTIFY messages in that subscription which do not.

      List representations necessarily contain RLMI documents for two
      reasons.  Importantly, they identify the resource to which the
      event state corresponds.  Many state syntaxes do not fully
      identify the resource to which the state applies, or they may
      identify the resource in a different way than it is represented in
      the list; for example, PIDF documents may contain resource URIs
      that are not identical to the URI used to retrieve them.  Further,
      RLMI documents serve to disambiguate multiple instances of a
      single resource.

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



Roach, et al.               Standards Track                     [Page 8]

RFC 4662                    SIP Event Lists                  August 2006


   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 an RLS, the RLS will often not know state information for
   all 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 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 in which the full state is
   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 <resource> element for some or all of the
   resources in the list.  Each <resource> element contains a URI that
   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 <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 indicated, the recipient of the NOTIFY



Roach, et al.               Standards Track                     [Page 9]

RFC 4662                    SIP Event Lists                  August 2006


   updates information for each identified resource.  Information for
   any resources that are not identified in the NOTIFY is not changed,
   even if they were indicated in previous NOTIFY messages.  See
   Section 5.6 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
      <resource> 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 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 list does not change their
      partial notification semantics).

      Finally, note that as a consequence of the way in which resource
      list subscriptions work, 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.

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





Roach, et al.               Standards Track                    [Page 10]

RFC 4662                    SIP Event Lists                  August 2006


5.1.  XML Syntax

   The root document of the multipart/related body MUST be a Resource
   List Meta-Information (RLMI) document.  It is of the 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.

   <?xml version="1.0" 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:import namespace="http://www.w3.org/XML/1998/namespace"
              schemaLocation="http://www.w3.org/2001/xml.xsd"/>
     <xs:element name="list">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="name" minOccurs="0"
                       maxOccurs="unbounded" />
           <xs:element ref="resource" minOccurs="0"
                       maxOccurs="unbounded" />
         </xs:sequence>
         <xs:attribute name="uri" type="xs:anyURI" use="required" />
         <xs:attribute name="version" type="xs:unsignedInt"
                       use="required" />
         <xs:attribute name="fullState" type="xs:boolean"
                       use="required" />
         <xs:attribute name="cid" type="xs:string" use="optional" />
         <xs:anyAttribute processContents="lax" />
       </xs:complexType>
     </xs:element>
     <xs:element name="resource">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="name" minOccurs="0"
                       maxOccurs="unbounded" />
           <xs:element ref="instance" minOccurs="0"
                       maxOccurs="unbounded" />
         </xs:sequence>
         <xs:attribute name="uri" type="xs:anyURI" use="required" />
         <xs:anyAttribute processContents="lax" />
       </xs:complexType>
     </xs:element>
     <xs:element name="instance">
       <xs:complexType>
         <xs:sequence>
           <xs:any minOccurs="0" maxOccurs="unbounded"



Roach, et al.               Standards Track                    [Page 11]

RFC 4662                    SIP Event Lists                  August 2006


                   processContents="lax" />
         </xs:sequence>
         <xs:attribute name="id" type="xs:string" use="required" />
         <xs:attribute name="state" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:string">
               <xs:enumeration value="active" />
               <xs:enumeration value="pending" />
               <xs:enumeration value="terminated" />
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="reason" type="xs:string"
                       use="optional" />
         <xs:attribute name="cid" type="xs:string" use="optional" />
         <xs:anyAttribute processContents="lax" />
       </xs:complexType>
     </xs:element>
     <xs:element name="name">
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:string">
             <xs:attribute ref="xml:lang" use="optional"/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>
   </xs:schema>

   An example of a document formatted using this schema follows.

   <?xml version="1.0"?>
   <list xmlns="urn:ietf:params:xml:ns:rlmi"
         uri="sip:[e-mail]"
         version="7" fullState="true">