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

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

Network Working Group                                        A. B. Roach
Request for Comments: 4662                                   B. Campbell
Category: Standards Track                               Estacado Systems
                                                            J. Rosenberg
                                                           Cisco Systems
                                                             August 2006


   A Session Initiation Protocol (SIP) Event Notification Extension
                           for Resource Lists

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document presents an extension to the Session Initiation
   Protocol (SIP)-Specific Event Notification mechanism for subscribing
   to a homogeneous list of resources.  Instead of sending a SUBSCRIBE
   for each resource individually, the subscriber can subscribe to an
   entire list and then receive notifications when the state of any of
   the resources in the list changes.




















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


Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Overview of Operation ...........................................4
   4. Operation of List Subscriptions .................................5
      4.1. Negotiation of Support for Resource Lists ..................6
      4.2. Subscription Duration ......................................7
      4.3. NOTIFY Bodies ..............................................7
      4.4. RLS Processing of SUBSCRIBE Requests .......................7
      4.5. RLS Generation of NOTIFY Requests ..........................7
      4.6. Subscriber Processing of NOTIFY Requests ...................9
      4.7. Handling of Forked Requests ...............................10
      4.8. Rate of Notifications .....................................10
   5. Using multipart/related to Convey Aggregate State ..............10
      5.1. XML Syntax ................................................11
      5.2. List Attributes ...........................................13
      5.3. Resource Attributes .......................................14
      5.4. Name Attributes ...........................................14
      5.5. Instance Attributes .......................................14
      5.6. Constructing Coherent Resource State ......................16
           5.6.1. Processing Full State Notifications ................17
           5.6.2. Processing Partial State Notifications .............17
   6. Example ........................................................18
   7. Security Considerations ........................................31
      7.1. Authentication ............................................31
           7.1.1. RLS and Subscriber in the Same Domain ..............31
           7.1.2. RLS and Subscriber in Different Domains ............32
      7.2. Risks of Improper Aggregation .............................33
      7.3. Signing and Sealing .......................................33
      7.4. Infinite Loops ............................................34
   8. IANA Considerations ............................................34
      8.1. New SIP Option Tag: eventlist .............................34
      8.2. New MIME type for Resource List Meta-Information ..........34
      8.3. URN Sub-Namespace .........................................35
   9. Acknowledgements ...............................................36
   10. References ....................................................36
      10.1. Normative References .....................................36
      10.2. Informative References ...................................37












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


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 the subscriber
   generating a SUBSCRIBE request for the resource, which is processed
   by a notifier that represents the resource.

   In many cases, a subscriber has a list of resources they are
   interested in.  Without some aggregating mechanism, this will require
   the subscriber to generate a SUBSCRIBE request for each resource
   about which they want information.  For environments in which
   bandwidth is limited, such as wireless networks, subscribing to each
   resource individually is problematic.  Some specific problems are:

   o  Doing so generates substantial message traffic, in the form of the
      initial SUBSCRIBE requests for each resource and the refreshes of
      each individual subscription.

   o  The notifier may insist on low refresh intervals, in order to
      avoid a long-lived subscription state.  This means that the
      subscriber may need to generate SUBSCRIBE refreshes faster than it
      would like to or has the capacity to.

   o  The notifier may generate NOTIFY requests more rapidly than the
      subscriber desires, causing NOTIFY traffic at a greater volume
      than is desired by the subscriber.

   To solve these problems, this specification defines an extension to
   RFC 3265 [2] that allows for requesting and conveying notifications
   for lists of resources.  A resource list is identified by a URI, and
   it represents a list of zero or more URIs.  Each of these URIs is an
   identifier for an individual resource for which the subscriber wants
   to receive information.  In many cases, the URI used to identify the
   resource list will be a SIP URI [1]; however, the use of other
   schemes (such as pres: [10]) is also foreseen.

   The notifier for the list is called a "resource list server", or RLS.
   In order to determine the state of the entire list, the RLS will act
   as if it has generated a subscription to each resource in the list.

   The resource list is not restricted to be inside the domain of the
   subscriber.  Similarly, the resources in the list are not constrained
   to be in the domain of the resource list server.







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


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [5].

   The following terms are used throughout the remainder of this
   document.

   Back-End Subscription:  Any subscription (SIP or otherwise) that an
      RLS creates to learn of the state of a resource.  An RLS will
      create back-end subscriptions to learn of the state of a resource
      about which the RLS is not an authority.  For back-end
      subscriptions, RLSes act as a subscriber.

   List Subscription:  A subscription to a resource list.  In list
      subscriptions, RLSes act as the notifier.

   Resource:  A resource is any logical entity that has a state or
      states that can be subscribed to.  Resources are identified by
      URIs.

   Resource List:  A list of zero or more resources that can have their
      individual states subscribed to with a single subscription.

   RLMI:  Resource List Meta-Information.  RLMI is a document that
      describes the state of the virtual subscriptions associated with a
      list subscription.

   RLS:  Resource List Server.  RLSes accept subscriptions to resource
      lists and send notifications to update subscribers of the state of
      the resources in a resource list.

   Virtual Subscription:  A Virtual Subscription is a logical construct
      within an RLS that represents subscriptions to the resources in a
      resource list.  For each list subscription it services, an RLS
      creates at least one virtual subscription for every resource in
      the resource list being subscribed to.  In some cases, such as
      when the RLS is not the authority for the state of the resource,
      this virtual subscription will be associated with a back-end
      subscription.  In other cases, such as when the RLS is the
      authority for the state of the resource, the virtual subscription
      will not have a corresponding back-end subscription.

3.  Overview of Operation

   This section provides an overview of the typical mode of operation of
   this extension.  It is not normative.



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


   When users wish to subscribe to the resource of a list of resources,
   they can use the mechanisms described in this specification.  The
   first step is the creation of a resource list.  This resource list is
   represented by a SIP URI.  The list contains a set of URIs, each of
   which represents a resource for which the subscriber wants to receive
   information.  The resource list can exist in any domain.  The list
   could be manipulated through a web page, through a voice response
   system, or through some other protocol.  The specific means by which
   the list is created and maintained is outside the scope of this
   specification.

   To learn the resource state of the set of elements on the list, the
   user sends a single SUBSCRIBE request targeted to the URI of the
   list.  This will be routed to an RLS for that URI.  The RLS acts as a
   notifier, authenticates the subscriber, and accepts the subscription.

   The RLS may have direct information about some or all of the
   resources specified by the list.  If it does not, it could subscribe
   to any non-local resources specified by the list resource.

   Note that subscriptions to non-local resources may or may not be SIP
   subscriptions; any mechanism for determining such information may be
   employed.  This document uses the term "back-end subscription" to
   refer to such a subscription, regardless of whether SIP is used to
   establish and service it.

   As the state of resources in the list change, the RLS generates
   notifications to the list subscribers.  The RLS can, at its
   discretion, buffer notifications of resource changes and send the
   resource information to the subscriber in batches, rather than
   individually.  This allows the RLS to provide rate limiting for the
   subscriber.

   The list notifications contain a body of type multipart/related.  The
   root section of the multipart/related content is an XML document that
   provides meta-information about each resource present in the list.
   The remaining sections contain the actual state information for each
   resource.

4.  Operation of List Subscriptions

   The event list extension acts, in many ways, like an event template
   package.  In particular, any single list subscription must be
   homogeneous with respect to the underlying event package.  In other
   words, a single list subscription can apply only one event package to
   all the resources in the resource list.





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


   Note that it is perfectly valid for an RLS to allow multiple
   subscriptions to the same list to use differing event packages.

   The key difference between a list subscription and templates in
   general is that support for list subscriptions indicates support for
   arbitrary nesting of list subscriptions.  In other words, elements
   within the list may be atomic elements, or they may be lists
   themselves.

   The consequence of this is that subscription to a URI that represents
   a list actually results in several virtual subscriptions to a tree of
   resources.  The leaf nodes of this tree are virtual subscriptions of
   the event type given in the "Event" header field; all other nodes in
   the tree are list subscriptions that are serviced as described in
   this section and its subsections.

   Keep in mind that these virtual subscriptions are not literal SIP
   subscriptions (although they may result in SIP subscriptions,
   depending on the RLS implementation).

4.1.  Negotiation of Support for Resource Lists

   This specification uses the SIP option tag mechanism for negotiating
   support for the extension defined herein.  Refer to RFC 3261 [1] for
   the normative description of processing of the "Supported" and
   "Require" header fields and the 421 (Extension Required) response
   code.

      A non-normative description of the implications of the use of
      option tags follows.
      Any client that supports the event list extension will include an
      option tag of "eventlist" in a "Supported" header field of every
      SUBSCRIBE message for a subscription for which it is willing to
      process a list.  If the subscription is made to a URI that
      represents a list, the RLS will include "eventlist" in a "Require"
      header field of the response to the SUBSCRIBE, and in all NOTIFY
      messages within that subscription.

      Use of "Require: eventlist" in NOTIFY messages is applied by the
      notifier to satisfy the RFC 3261 requirement that a UAC MUST
      insert a Require header field into a request if the UAC wishes to
      insist that a UAS understand an extension in order to process the
      request.  Because the NOTIFY would not be usable without applying