Internet Engineering Task Force                                SIMPLE WG
Internet Draft                                              J. Rosenberg
                                                             dynamicsoft
draft-ietf-simple-presence-10.txt
January 31, 2003
Expires: July 2003


   A Presence Event Package for the Session Initiation Protocol (SIP)

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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   This document describes the usage of the Session Initiation Protocol
   (SIP) for subscriptions and notifications of presence. Presence is
   defined as the willingness and ability of a user to communicate with
   other users on the network. Historically, presence has been limited
   to "on-line" and "off-line" indicators; the notion of presence here
   is broader. Subscriptions and notifications of presence are supported
   by defining an event package within the general SIP event
   notification framework. This protocol is also compliant with the
   Common Presence Profile (CPP) framework.








J. Rosenberg                                                  [Page 1]


Internet Draft                SIP Presence              January 31, 2003






                           Table of Contents



   1          Introduction ........................................    3
   2          Terminology .........................................    3
   3          Definitions .........................................    3
   4          Overview of Operation ...............................    5
   5          Usage of Presence URIs ..............................    6
   6          Presence Event Package ..............................    8
   6.1        Package Name ........................................    8
   6.2        Event Package Parameters ............................    8
   6.3        SUBSCRIBE Bodies ....................................    8
   6.4        Subscription Duration ...............................    9
   6.5        NOTIFY Bodies .......................................    9
   6.6        Notifier Processing of SUBSCRIBE Requests ...........   10
   6.6.1      Authentication ......................................   10
   6.6.2      Authorization .......................................   11
   6.7        Notifier Generation of NOTIFY Requests ..............   12
   6.8        Subscriber Processing of NOTIFY Requests ............   13
   6.9        Handling of Forked Requests .........................   13
   6.10       Rate of Notifications ...............................   14
   6.11       State Agents ........................................   14
   6.11.1     Aggregation, Authentication, and Authorization ......   14
   6.11.2     Migration ...........................................   15
   7          Learning Presence State .............................   16
   7.1        Co-location .........................................   16
   7.2        REGISTER ............................................   16
   7.3        Uploading Presence Documents ........................   17
   8          Example Message Flow ................................   17
   9          Security Considerations .............................   20
   9.1        Confidentiality .....................................   20
   9.2        Message Integrity and Authenticity ..................   21
   9.3        Outbound Authentication .............................   22
   9.4        Replay Prevention ...................................   22
   9.5        Denial of Service Attacks Against Third Parties .....   22
   9.6        Denial Of Service Attacks Against Servers ...........   23
   10         IANA Considerations .................................   23
   11         Contributors ........................................   23
   12         Acknowledgements ....................................   25
   13         Authors Addresses ...................................   25
   14         Normative References ................................   25
   15         Informative References ..............................   26





J. Rosenberg                                                  [Page 2]


Internet Draft                SIP Presence              January 31, 2003


1 Introduction

   Presence, also known as presence information, conveys the ability and
   willingness of a user to communicate across a set of devices. RFC
   2778 [10] defines a model and terminology for describing systems that
   provide presence information. In that model, a presence service is a
   system that accepts, stores, and distributes presence information to
   interested parties, called watchers. A presence protocol is a
   protocol for providing a presence service over the Internet or any IP
   network.

   This document proposes the usage of the Session Initiation Protocol
   (SIP) [1] as a presence protocol. This is accomplished through a
   concrete instantiation of the general event notification framework
   defined for SIP [2], and as such, makes use of the SUBSCRIBE and
   NOTIFY methods defined there. Specifically, this document defines an
   event package, as described in RFC 3265 [2]. SIP is particularly well
   suited as a presence protocol. SIP location services already contain
   presence information, in the form of registrations. Furthermore, SIP
   networks are capable of routing requests from any user on the network
   to the server that holds the registration state for a user. As this
   state is a key component of user presence, those SIP networks can
   allow SUBSCRIBE requests to be routed to the same server. This means
   that SIP networks can be reused to establish global connectivity for
   presence subscriptions and notifications.

   This event package is based on the concept of a presence agent, which
   is a new logical entity that is capable of accepting subscriptions,
   storing subscription state, and generating notifications when there
   are changes in presence. The entity is defined as a logical one,
   since it is generally co-resident with another entity.

   This event package is also compliant with the Common Presence Profile
   (CPP) framework that has been defined in [3]. This allows SIP for
   presence to easily interwork with other presence systems compliant to
   CPP.

2 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
   indicate requirement levels for compliant implementations.

3 Definitions

   This document uses the terms as defined in RFC 2778 [10].
   Additionally, the following terms are defined and/or additionally



J. Rosenberg                                                  [Page 3]


Internet Draft                SIP Presence              January 31, 2003


   clarified:

        Presence User Agent (PUA): A Presence User Agent manipulates
             presence information for a presentity. This manipulation
             can be the side effect of some other action (such as
             sending a SIP REGISTER request to add a new Contact) or can
             be done explicitly through the publication of presence
             documents. We explicitly allow multiple PUAs per
             presentity. This means that a user can have many devices
             (such as a cell phone and Personal Digital Assistant
             (PDA)), each of which is independently generating a
             component of the overall presence information for a
             presentity. PUAs push data into the presence system, but
             are outside of it, in that they do not receive SUBSCRIBE
             messages, or send NOTIFY messages.

        Presence Agent (PA): A presence agent is a SIP user agent which
             is capable of receiving SUBSCRIBE requests, responding to
             them, and generating notifications of changes in presence
             state. A presence agent must have knowledge of the presence
             state of a presentity. This means that it must have access
             to presence data manipulated by PUAs for the presentity.
             One way to do this is by co-locating the PA with the
             proxy/registrar. Another way is to co-locate it with the
             presence user agent of the presentity. However, these are
             not the only ways, and this specification makes no
             recommendations about where the PA function should be
             located. A PA is always addressable with a SIP URI that
             uniquely identifies the presentity (i.e,
             sip:joe@example.com). There can be multiple PAs for a
             particular presentity, each of which handles some subset of
             the total subscriptions currently active for the
             presentity. A PA is also a notifier (defined in RFC 3265
             [2]) that supports the presence event package.

        Presence Server: A presence server is a physical entity that can
             act as either a presence agent or as a proxy server for
             SUBSCRIBE requests. When acting as a PA, it is aware of the
             presence information of the presentity through some
             protocol means. When acting as a proxy, the SUBSCRIBE
             requests are proxied to another entity that may act as a
             PA.

        Edge Presence Server: An edge presence server is a presence
             agent that is co-located with a PUA. It is aware of the
             presence information of the presentity because it is co-
             located with the entity that manipulates this presence
             information.



J. Rosenberg                                                  [Page 4]


Internet Draft                SIP Presence              January 31, 2003


4 Overview of Operation

   In this section, we present an overview of the operation of this
   event package. The overview describes behavior that is documented in
   part here, in part within the SIP event framework [2], and in part in
   the SIP specification [1], in order to provide clarity on this
   package for readers only casually familiar with those specifications.
   However, the detailed semantics of this package require the reader to
   be familiar with SIP events and the SIP specification itself.

   When an entity, the subscriber, wishes to learn about presence
   information from some user, it creates a SUBSCRIBE request. This
   request identifies the desired presentity in the Request-URI, using a
   SIP URI, SIPS URI [1] or a presence URI [3]. The SUBSCRIBE request is
   carried along SIP proxies as any other SIP request would be. In most
   cases, it eventually arrives at a presence server, which can either
   generate a response to the request (in which case it acts as the
   presence agent for the presentity), or proxy it on to an edge
   presence server. If the edge presence server handles the
   subscription, it is acting as the presence agent for the presentity.
   The decision at a presence server about whether to proxy or terminate
   the SUBSCRIBE is a local matter; however, we describe one way to
   effect such a configuration, using REGISTER.

   The presence agent (whether in the presence server or edge presence
   server) first authenticates the subscription, then authorizes it. The
   means for authorization are outside the scope of this protocol, and
   we expect that many mechanisms will be used. If authorized, a 200 OK
   response is returned. If authorization could not be obtained at this
   time, the subscription is considered "pending", and a 202 response is
   returned. In both cases, the PA sends an immediate NOTIFY message
   containing the state of the presentity and of the subscription. The
   presentity state may be bogus in the case of a pending subscription,
   indicating offline no matter what the actual state of the presentity,
   for example. This is to protect the privacy of the presentity, who
   may not want to reveal that they have not provided authorization for
   the subscriber. As the state of the presentity changes, the PA
   generates NOTIFYs containing those state changes to all subscribers
   with authorized subscriptions. Changes in the state of the
   subscription itself can also trigger NOTIFY requests; that state is
   carried in the Subscription-State header field of the NOTIFY, and
   would typically indicate whether the subscription is active or
   pending.

   The SUBSCRIBE message establishes a "dialog" with the presence agent.
   A dialog is defined in RFC 3261 [1], and it represents the SIP state
   between a pair of entities to facilitate peer-to-peer message
   exchanges. This state includes the sequence numbers for messages in



J. Rosenberg                                                  [Page 5]


Internet Draft                SIP Presence              January 31, 2003


   both directions (SUBSCRIBE from the subscriber, NOTIFY from the
   presence agent), in addition to a route set and remote target URI.
   The route set is a list of SIP (or SIPS) URIs which identify SIP
   proxy servers that are to be visited along the path of SUBSCRIBE
   refreshes or NOTIFY requests. The remote target URI is the SIP or
   SIPS URI that identifies the target of the message - the subscriber,
   in the case of NOTIFY, or the presence agent, in the case of a
   SUBSCRIBE refresh.

   SIP provides a procedure called record-routing that allows for proxy
   servers to request to be on the path of NOTIFY messages and SUBSCRIBE
   refreshes. This is accomplished by inserting a URI into the Record-
   Route header field in the initial SUBSCRIBE request.

   The subscription persists for a duration that is negotiated as part
   of the initial SUBSCRIBE. The subscriber will need to refresh the
   subscription before its expiration, if they wish to retain the
   subscription. This is accomplished by sending a SUBSCRIBE refresh
   within the same dialog established by the initial SUBSCRIBE. This
   SUBSCRIBE is nearly identical to the initial one, but contains a tag
   in the To header field, a higher CSeq header field value, and
   possibly a set of Route header field values that identify the path of
   proxies the request is to take.

   The subscriber can terminate the subscription by sending a SUBSCRIBE,
   within the dialog, with an Expires header field (which indicates
   duration of the subscription) value of zero. This causes an immediate
   termination of the subscription. A NOTIFY request is then generated
   by the presence agent with the most recent state. In fact, behavior
   of the presence agent for handling a SUBSCRIBE request with Expires
   of zero is no different than for any other expiration value; pending
   or authorized SUBSCRIBE requests result in a triggered NOTIFY with
   the current presentity and subscription state.

   The presence agent can terminate the subscription at any time. To do
   so, it sends a NOTIFY request with a Subscription-State header field
   indicating that the subscription has been terminated. A reason
   parameter can be supplied which provides the reason.

   It is also possible to fetch the current presence state, resulting in
   a one-time notification containing the current state. This is
   accomplished by sending a SUBSCRIBE request with an immediate
   expiration.

5 Usage of Presence URIs

   A presentity is identified in the most general way through a presence
   URI [3], which is of the form pres:user@domain. These URIs are



J. Rosenberg                                                  [Page 6]


Internet Draft                SIP Presence              January 31, 2003


   protocol independent. They are resolved to protocol specific URIs,
   such as a SIP or SIPS URI, through domain-specific mapping policies.

   It is very possible that a user will have both a SIP (and/or SIPS)
   URI and a pres URI to identify both themself and other users. This
   leads to questions about how these URI relate and which are to be
   used.

   In some instances, a user starts with one URI format, such as the
   pres URI, and learns a URI in a different format through some
   protocol means. As an example, a SUBSCRIBE request sent to a pres URI
   will result in learning a SIP or SIPS URI for the presentity from the
   Contact header field of the 200 OK to the SUBSCRIBE request. As
   another example, a DNS mechanism might be defined that would allow
   lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one
   URI is learned from another through protocol means, those means will
   often provide some kind of scoping that limit the lifetime of the
   learned URI. DNS, for example, provides a TTL which would limit the
   scope of the URI. These scopes are very useful to avoid stale or
   conflicting URIs for identifying the same resource. To ensure that a
   user can always determine whether a learned URI is still valid, it is
   RECOMMENDED that systems which provide lookup services for presence
   URIs have some kind of scoping mechanism.

   If a subscriber is only aware of the protocol-independent pres URI
   for a presentity, it follows the procedures defined in [5]. These
   procedures will result in the placement of the pres URI in the
   Request-URI of the SIP request, followed by the usage of the DNS
   procedures defined in [5] to determine the host to send the SIP
   request to. Of course, a local outbound proxy may alternatively be
   used, as specified in RFC 3261 [1]. If the subscriber is aware of
   both the protocol-independent pres URI and the SIP or SIPS URI for
   the same presentity, and both are valid (as discussed above) it
   SHOULD use the pres URI format. Of course, if the subscriber only
   knows the SIP URI for the presentity, that URI is used, and standard
   RFC 3261 processing will occur.

   SUBSCRIBE messages also contain logical identifiers that define the
   originator and recipient of the subscription (the To and From header
   fields). These headers can take either a pres or SIP URI. When the
   subscriber is aware of both a pres and SIP URI for its own identity,
   it SHOULD use the pres URI in the From header field. Similarly, when
   the subscriber is aware of both a pres and a SIP URI for the desired
   presentity, it SHOULD use the pres URI in the To header field.

   The usage of the pres URI instead of the SIP URI within the SIP
   message supports interoperability through gateways to other CPP-
   compliant systems. It provides a protocol-independent form of



J. Rosenberg                                                  [Page 7]


Internet Draft                SIP Presence              January 31, 2003


   identification which can be passed between systems. Without such an
   identity, gateways would be forced to map SIP URIs into the
   addressing format of other protocols. Generally, this is done by
   converting the SIP URI to the form <foreign-protocol-scheme>:<encoded
   SIP URI>@<gateway>. This is commonly done in email systems, and has
   many known problems. The usage of the pres URI is a SHOULD, and not a
   MUST, to allow for cases where it is known that there are no gateways
   present, or where the usage of the pres URI will cause
   interoperability problems with SIP components that do not support the
   pres URI.

   The Contact, Record-Route and Route fields do not identify logical
   entities, but rather concrete ones used for SIP messaging. SIP [1]
   specifies rules for their construction.

6 Presence Event Package

   The SIP event framework [2] defines a SIP extension for subscribing
   to, and receiving notifications of, events. It leaves the definition
   of many aspects of these events to concrete extensions, known as
   event packages. This document qualifies as an event package. This
   section fills in the information required for all event packages by
   RFC 3265 [2].

6.1 Package Name

   The name of this package is "presence". As specified in RFC 3265 [2],
   this value appears in the Event header field present in SUBSCRIBE and
   NOTIFY requests.

   Example:



   Event: presence



6.2 Event Package Parameters

   The SIP event framework allows event packages to define additional
   parameters carried in the Event header field. This package, presence,
   does not define any additional parameters.

6.3 SUBSCRIBE Bodies

   A SUBSCRIBE request MAY contain a body. The purpose of the body
   depends on its type. Subscriptions will normally not contain bodies.



J. Rosenberg                                                  [Page 8]


Internet Draft                SIP Presence              January 31, 2003


   The Request-URI, which identifies the presentity, combined with the
   event package name, is sufficient for presence.

   One type of body that can be included in a SUBSCRIBE request is a
   filter document. These filters request that only certain presence
   events generate notifications, or would ask for a restriction on the
   set of data returned in NOTIFY requests. For example, a presence
   filter might specify that the notifications should only be generated
   when the status of the user's instant inbox [10] changes. It might
   also say that the content of these notifications should only contain
   the status of the instant inbox. Filter documents are not specified
   in this document, and at the time of writing, are expected to be the
   subject of future standardization activity.

   Honoring of these filters is at the policy discretion of the PA.

   If the SUBSCRIBE request does not contain a filter, this tells the PA
   that no filter is to be applied. The PA SHOULD send NOTIFY requests
   at the discretion of its own policy.

6.4 Subscription Duration

   User presence changes as a result of many events. Some examples are:

        o Turning on and off of a cell phone

        o Modifying the registration from a softphone

        o Changing the status on an instant messaging tool

   These events are usually triggered by human intervention, and occur
   with a frequency on the order of seconds to hours. As such,
   subscriptions should have an expiration in the middle of this range,
   which is roughly one hour. Therefore, the default expiration time for
   subscriptions within this package is 3600 seconds. As per RFC 3265
   [2], the subscriber MAY specify an alternate expiration in the
   Expires header field.

6.5 NOTIFY Bodies

   As described in RFC 3265 [2], the NOTIFY message will contain bodies
   that describe the state of the subscribed resource. This body is in a
   format listed in the Accept header field of the SUBSCRIBE, or a
   package-specific default if the Accept header field was omitted from
   the SUBSCRIBE.

   In this event package, the body of the notification contains a
   presence document. This document describes the presence of the



J. Rosenberg                                                  [Page 9]


Internet Draft                SIP Presence              January 31, 2003


   presentity that was subscribed to. All subscribers and notifiers MUST
   support the "application/cpim-pidf+xml" presence data format
   described in [6]. The subscribe request MAY contain an Accept header
   field. If no such header field is present, it has a default value of
   "application/cpim-pidf+xml". If the header field is present, it MUST
   include "application/cpim-pidf+xml", and MAY include any other types
   capable of representing user presence.

6.6 Notifier Processing of SUBSCRIBE Requests

   Based on the proxy routing procedures defined in the SIP
   specification, the SUBSCRIBE request will arrive at a presence agent
   (PA). This subsection defines package-specific processing at the PA
   of a SUBSCRIBE request. General processing rules for requests are
   covered in Section 8.2 of RFC 3261 [1], in addition to general
   SUBSCRIBE processing in RFC 3265 [2].

   User presence is highly sensitive information. Because the
   implications of divulging presence information can be severe, strong
   requirements are imposed on the PA regarding subscription processing,
   especially related to authentication and authorization.

6.6.1 Authentication

   A presence agent MUST authenticate all subscription requests. This
   authentication can be done using any of the mechanisms defined in RFC
   3261 [1]. Note that digest is mandatory to implement, as specified in
   RFC 3261.

   In single-domain systems, where the subscribers all have shared
   secrets with the PA, the combination of digest authentication over
   Transport Layer Security (TLS) [7] provides a secure and workable
   solution for authentication. This use case is described in Section
   26.3.2.1 of RFC 3261 [1].

   In inter-domain scenarios, establishing an authenticated identity of
   the subscriber is harder. It is anticipated that authentication will
   often be established through transitive trust. SIP mechanisms for
   network asserted identity can be applied to establish the identity of
   the subscriber [11].

   A presentity MAY choose to represent itself with a SIPS URI. By
   "represent itself", it means that the user represented by the
   presentity hands out, on business cards, web pages, and so on, a SIPS
   URI for their presentity. The semantics associated with this URI, as
   described in RFC 3261 [1], require TLS usage on each hop between the
   subscriber and the server in the domain of the URI. This provides
   additional assurances (but no absolute guarantees) that identity has



J. Rosenberg                                                 [Page 10]


Internet Draft                SIP Presence              January 31, 2003


   been verified at each hop.

   Another mechanism for authentication is S/MIME. Its usage with SIP is
   described fully in RFC 3261 [1]. It provides an end-to-end
   authentication mechanism that can be used for a PA to establish the
   identity of the subscriber.

6.6.2 Authorization

   Once authenticated, the PA makes an authorization decision. A PA MUST
   NOT accept a subscription unless authorization has been provided by
   the presentity. The means by which authorization are provided are
   outside the scope of this document. Authorization may have been
   provided ahead of time through access lists, perhaps specified in a
   web page. Authorization may have been provided by means of uploading
   of some kind of standardized access control list document. Back end
   authorization servers, such as a DIAMETER [12] server, can also be
   used. It is also useful to be able to query the user for
   authorization following the receipt of a subscription request for
   which no authorization information has been provided. The
   "watcherinfo" event template package for SIP [8] defines a means by
   which a presentity can become aware that a user has attempted to
   subscribe to it, so that it can then provide an authorization
   decision.

   Authorization decisions can be very complex. Ultimately, all
   authorization decisions can be mapped into one of three states:
   rejected, successful, and pending. Any subscription for which the
   client is authorized to receive information about some subset of
   presence state at some points in time is a successful subscription.
   Any subscription for which the client will never receive any
   information about any subset of the presence state is a rejected
   subscription. Any subscription for which it is not yet known whether
   it is successful or rejected is pending. Generally, a pending
   subscription occurs when the server cannot obtain authorization at
   the time of the subscription, but may be able to do so at a later
   time, perhaps when the presentity becomes available.

   The appropriate response codes for conveying a successful, rejected,
   or pending subscription (200, 403 or 603, and 202, respectively) are
   described in RFC 3265 [2].

   If the resource is not in a meaningful state, RFC 3265 [2] allows the
   body of the initial NOTIFY to be empty. In the case of presence, that
   NOTIFY MAY contain a presence document. This document would indicate
   whatever presence state the subscriber has been authorized to see; it
   is interpreted by the subscriber as the current presence state of the
   presentity. For pending subscriptions, the state of the presentity



J. Rosenberg                                                 [Page 11]


Internet Draft                SIP Presence              January 31, 2003


   SHOULD include some kind of textual note that indicates a pending
   status.

   Polite blocking, as described in [13], is possible by generating a
   200 OK to the subscription even though it has been rejected (or
   marked pending). Of course, an immediate NOTIFY will still be sent.
   The contents of the presence document in such a NOTIFY are at the
   discretion of the implementor, but SHOULD be constructed in such a
   way as to not reveal to the subscriber that their request has
   actually been blocked. Typically, this is done by indicating
   "offline" or equivalent status for a single contact address.

6.7 Notifier Generation of NOTIFY Requests

   RFC 3265 details the formatting and structure of NOTIFY messages.
   However, packages are mandated to provide detailed information on
   when to send a NOTIFY, how to compute the state of the resource, how
   to generate neutral or fake state information, and whether state
   information is complete or partial. This section describes those
   details for the presence event package.

   A PA MAY send a NOTIFY at any time. Typically, it will send one when
   the state of the presentity changes. The NOTIFY request MAY contain a
   body indicating the state of the presentity. The times at which the
   NOTIFY is sent for a particular subscriber, and the contents of the
   body within that notification, are subject to any rules specified by
   the authorization policy that governs the subscription. This protocol
   in no way limits the scope of such policies. As a baseline, a
   reasonable policy is to generate notifications when the state of any
   of the presence tuples changes. These notifications would contain the
   complete and current presence state of the presentity as known to the
   presence agent. Future extensions can be defined that allow a
   subscriber to request that the notifications contain changes in
   presence information only, rather than complete state.

   In the case of a pending subscription, when final authorization is
   determined, a NOTIFY can be sent. If the result of the authorization
   decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
   presence document with the current state of the presentity. If the
   subscription is rejected, a NOTIFY MAY be sent. As described in RFC
   3265 [2], the Subscription-State header field indicates the state of
   the subscription.

   The body of the NOTIFY MUST be sent using one of the types listed in
   the Accept header field in the most recent SUBSCRIBE request, or
   using the type "application/cpim-pidf+xml" if no Accept header field
   was present.




J. Rosenberg                                                 [Page 12]


Internet Draft                SIP Presence              January 31, 2003


   The means by which the PA learns the state of the presentity are also
   outside the scope of this recommendation. Registrations can provide a
   component of the presentity state. However, the means by which a PA
   uses registrations to construct a presence document are an
   implementation choice. If a PUA wishes to explicitly inform the
   presence agent of its presence state, it should explicitly publish
   the presence document (or its piece of it) rather than attempting to
   manipulate their registrations to achieve the desired result.

   For reasons of privacy, it will frequently be necessary to encrypt
   the contents of the notifications. This can be accomplished using
   S/MIME. The encryption can be performed using the key of the
   subscriber as identified in the From field of the SUBSCRIBE request.
   Similarly, integrity of the notifications is important to
   subscribers. As such, the contents of the notifications MAY provide
   authentication and message integrity using S/MIME. Since the NOTIFY
   is generated by the presence server, which may not have access to the
   key of the user represented by the presentity, it will frequently be
   the case that the NOTIFY is signed by a third party. It is
   RECOMMENDED that the signature be by an authority over the domain of
   the presentity. In other words, for a user pres:user@example.com, the
   signator of the NOTIFY SHOULD be the authority for example.com.

6.8 Subscriber Processing of NOTIFY Requests

   RFC 3265 [2] leaves it to event packages to describe the process
   followed by the subscriber upon receipt of a NOTIFY request,
   including any logic required to form a coherent resource state.

   In this specification, each NOTIFY contains either no presence
   document, or a document representing the complete and coherent state
   of the presentity. Within a dialog, the presence document in the
   NOTIFY request with the highest CSeq header field value is the
   current one. When no document is present in that NOTIFY, the presence
   document present in the NOTIFY with the next highest CSeq value is
   used. Extensions which specify the use of partial state for
   presentities will need to dictate how coherent state is achieved.

6.9 Handling of Forked Requests

   RFC 3265 [2] requires each package to describe handling of forked
   SUBSCRIBE requests.

   This specification only allows a single dialog to be constructed as a
   result of emitting an initial SUBSCRIBE request. This guarantees that
   only a single PA is generating notifications for a particular
   subscription to a particular presentity. The result of this is that a
   presentity can have multiple PAs active, but these should be



J. Rosenberg                                                 [Page 13]


Internet Draft                SIP Presence              January 31, 2003


   homogeneous, so that each can generate the same set of notifications
   for the presentity. Supporting heterogeneous PAs, each of which
   generates notifications for a subset of the presence data, is complex
   and difficult to manage. Doing so would require the subscriber to act
   as the aggregator for presence data. This aggregation function can
   only reasonably be performed by agents representing the presentity.
   Therefore, if aggregation is needed, it MUST be done in a PA
   representing the presentity.

   Section 4.4.9 of RFC 3265 [2] describes the processing that is
   required to guarantee the creation of a single dialog in response to
   a SUBSCRIBE request.

6.10 Rate of Notifications

   RFC 3265 [2] requires each package to specify the maximum rate at
   which notifications can be sent.

   A PA SHOULD NOT generate notifications for a single presentity at a
   rate of more than once every five seconds.

6.11 State Agents

   RFC 3265 [2] requires each package to consider the role of state
   agents in the package, and if they are used, to specify how
   authentication and authorization are done.

   State agents are core to this package. Whenever the PA is not co-
   located with the PUA for the presentity, the PA is acting as a state
   agent. It collects presence state from the PUA, and aggregates it
   into a presence document. Because there can be multiple PUA, a
   centralized state agent is needed to perform this aggregation. That
   is why state agents are fundamental to presence. Indeed, they have a
   specific term that describes them - a presence server.

6.11.1 Aggregation, Authentication, and Authorization

   The means by which aggregation is done in the state agent is purely a
   matter of policy. The policy will typically combine the desires of
   the presentity along with the desires of the provider. This draft in
   no way restricts the set of policies which may be applied.

   However, there is clearly a need for the state agent to have access
   to the state of the presentity. This state is manipulated by the PUA.
   One way in which the state agent can obtain this state is to
   subscribe to it. As a result, if there were 5 PUA manipulating
   presence state for a single presentity, the state agent would
   generate 5 subscriptions, one to each PUA. For this mechanism to be



J. Rosenberg                                                 [Page 14]


Internet Draft                SIP Presence              January 31, 2003


   effective, all PUA SHOULD be capable of acting as a PA for the state
   that they manipulate, and that they authorize subscriptions that can
   be authenticated as coming from the domain of the presentity.

   The usage of state agents does not significantly alter the way in
   which authentication is done by the PA. Any of the SIP authentication
   mechanisms can be used by a state agent. However, digest
   authentication will require the state agent to be aware of the shared
   secret between the presentity and the subscriber. This will require
   some means to securely transfer the shared secrets from the
   presentity to the state agent.

   The usage of state agents does, however, have a signficiant impact on
   authorization. As stated in Section 6.6, a PA is required to
   authorize all subscriptions. If no explicit authorization policy has
   been defined, the PA will need to query the user for authorization.
   In a presence edge server (where the PUA is co-located with the PUA),
   this is trivially accomplished. However, when state agents are used
   (i.e., a presence server), a means is needed to alert the user that
   an authorization decision is required. This is the reason for the
   watcherinfo event package [8]. All state agents SHOULD support this
   event package.

6.11.2 Migration

   On occasion, it makes sense for the PA function to migrate from one
   server to another. For example, for reasons of scale, the PA function
   may reside in the presence server when the PUA is not running, but
   when the PUA connects to the network, the PA migrates subscriptions
   to it in order to reduce state in the network. The mechanism for
   accomplishing the migration is described in Section 3.3.5 of RFC 3265
   [2]. However, packages need to define under what conditions such a
   migration would take place.

   A PA MAY choose to migrate subscriptions at any time, through
   configuration, or through dynamic means. The REGISTER request
   provides one dynamic means for a presence server to discover that the
   function can migrate to a PUA. Specifically, if a PUA wishes to
   indicate support for the PA function, it SHOULD use the caller
   preferences specification [9] to indicate that it supports the
   SUBSCRIBE request method and the presence event package. The
   combination of these two define a PA. Of course, a presence server
   can always attempt a migration without these explicit hints. If it
   fails with either a 405 or 489 response code, the server knows that
   the PUA does not support the PA function. In this case, the server
   itself will need to act as a PA for that subscription request. Once
   such a failure has occurred, the server SHOULD NOT attempt further
   migrations to that PUA for the duration of its registration. However,



J. Rosenberg                                                 [Page 15]


Internet Draft                SIP Presence              January 31, 2003


   to avoid the extra traffic generated by these failed requests, a
   presence server SHOULD support the caller preferences extension.

   Furthermore, indication of support for the SUBSCRIBE request and the
   presence event package is not sufficient for migration of
   subscriptions. A PA SHOULD NOT migrate the subscription if it is
   composing aggregated presence documents received from multiple PUA.

7 Learning Presence State

   Presence information can be obtained by the PA in many ways. No
   specific mechanism is mandated by this specification. This section
   overviews some of the options, for informational purposes only.

7.1 Co-location

   When the PA function is co-located with the PUA, presence is known
   directly by the PA.

7.2 REGISTER

   A UA uses the SIP REGISTER method to inform the SIP network of its
   current communications addresses (i.e., Contact addresses). Multiple
   UA can independently register Contact addresses for the same
   address-of-record. This registration state represents an important
   piece of the overall presence information for a presentity. It is an
   indication of basic reachability for communications.

   Usage of REGISTER information to construct presence is only possible
   if the PA has access to the registration database, and can be
   informed of changes to that database. One way to accomplish that is
   to co-locate the PA with the registrar.

   The means by which registration state is converted into presence
   state is a matter of local policy, and beyond the scope of this
   specification. However, some general guidelines can be provided. The
   address-of-record in the registration (the To header field)
   identifies the presentity. Each registered Contact header field
   identifies a point of communications for that presentity, which can
   be modeled using a tuple. Note that the contact address in the tuple
   need not be the same as the registered contact address. Using an
   address-of-record instead allows subsequent communications from a
   watcher to pass through proxies. This is useful for policy processing
   on behalf of the presentity and the provider.

   A PUA that uses registrations to manipulate presence state SHOULD
   make use of the SIP caller preferences extension [9]. This allows the
   PUA to provide the PA with richer information about itself. For



J. Rosenberg                                                 [Page 16]


Internet Draft                SIP Presence              January 31, 2003


   example, the presence of the methods parameter listing the method
   "MESSAGE" indicates support for instant messaging.

   The q values from the Contact header field [1] can be used to
   establish relative priorities amongst the various communications
   addresses in the Contact header fields.

   The usage of registrations to obtain presence information increases
   the requirements for authenticity and integrity of registrations.
   Therefore, REGISTER requests used by presence user agents MUST be
   authenticated.

7.3 Uploading Presence Documents

   If a means exists to upload presence documents from PUA to the PA,
   the PA can act as an aggregator and redistributor of those documents.
   The PA, in this case, would take the presence documents received from
   each PUA for the same presentity, and merge the tuples across all of
   those PUA into a single presence document. Typically, this
   aggregation would be accomplished through administrator or user
   defined policies about how the aggregation should be done.

   The specific means by which a presence document are uploaded to a
   presence agent are outside the scope of this specification. When a
   PUA wishes to have direct manipulation of the presence that is
   distributed to subscribers, direct uploading of presence documents is
   RECOMMENDED.

8 Example Message Flow

   This message flow illustrates how the presence server can be the
   responsible for sending notifications for a presentity. This flow
   assumes that the watcher has previously been authorized to subscribe
   to this resource at the server.

   In this flow, the PUA informs the server about the updated presence
   information through some non-SIP means.

   When the value of the Content-Length header field is "..." this means
   that the value should be whatever the computed length of the body is.




   Watcher             Server                 PUA
      | F1 SUBSCRIBE      |                    |
      |------------------>|                    |
      | F2 200 OK         |                    |



J. Rosenberg                                                 [Page 17]


Internet Draft                SIP Presence              January 31, 2003


      |<------------------|                    |
      | F3 NOTIFY         |                    |
      |<------------------|                    |
      | F4 200 OK         |                    |
      |------------------>|                    |
      |                   |                    |
      |                   |   Update presence  |
      |                   |<------------------ |
      |                   |                    |
      | F5 NOTIFY         |                    |
      |<------------------|                    |
      | F6 200 OK         |                    |
      |------------------>|                    |



   Message Details



   F1 SUBSCRIBE   watcher->example.com server

      SUBSCRIBE sip:resource@example.com SIP/2.0
      Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
      To: <sip:resource@example.com>
      From: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 17766 SUBSCRIBE
      Max-Forwards: 70
      Event: presence
      Accept: application/cpim-pidf+xml
      Contact: <sip:user@watcherhost.example.com>
      Expires: 600
      Content-Length: 0





   F2 200 OK   example.com server->watcher

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
        ;received=192.0.2.1
      To: <sip:resource@example.com>;tag=ffd2
      From: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 17766 SUBSCRIBE



J. Rosenberg                                                 [Page 18]


Internet Draft                SIP Presence              January 31, 2003


      Event: presence
      Expires: 600
      Contact: sip:server.example.com
      Content-Length: 0





   F3 NOTIFY  example.com server-> watcher

      NOTIFY sip:user@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      Event: presence
      Subscription-State: active;expires=599
      Max-Forwards: 70
      CSeq: 8775 NOTIFY
      Contact: sip:server.example.com
      Content-Type: application/cpim-pidf+xml
      Content-Length: ..

      [PIDF Document]






   F4 200 OK watcher-> example.com server

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
        ;received=192.0.2.2
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 8775 NOTIFY
      Content-Length: 0





   F5 NOTIFY example.com server -> watcher




J. Rosenberg                                                 [Page 19]


Internet Draft                SIP Presence              January 31, 2003


      NOTIFY sip:user@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 8776 NOTIFY
      Event: presence
      Subscription-State: active;expires=543
      Max-Forwards: 70
      Contact: sip:server.example.com
      Content-Type: application/cpim-pidf+xml
      Content-Length: ...

      [New PIDF Document]







   F6 200 OK

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
       ;received=192.0.2.2
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      CSeq: 8776 NOTIFY
      Content-Length: 0




9 Security Considerations

   There are numerous security considerations for presence. RFC 2779
   [13] outlines many of them, and they are discussed above. This
   section considers them issue by issue.

9.1 Confidentiality

   Confidentiality encompasses many aspects of a presence system:

        o Subscribers may not want to reveal the fact that they have
          subscribed to certain users




J. Rosenberg                                                 [Page 20]


Internet Draft                SIP Presence              January 31, 2003


        o Users may not want to reveal that they have accepted
          subscriptions from certain users

        o Notifications (and fetch results) may contain sensitive data
          which should not be revealed to anyone but the subscriber

   Confidentiality is provided through a combination of hop-by-hop
   encryption and end-to-end encryption. The hop-by-hop mechanisms
   provide scalable confidentiality services, disable attacks involving
   traffic analysis, and hide all aspects of presence messages. However,
   they operate based on transitivity of trust, and they cause message
   content to be revealed to proxies. The end-to-end mechanisms do not
   require transitivity of trust, and reveal information only to the
   desired recipient. However, end-to-end encryption cannot hide all
   information, and is susceptible to traffic analysis. Strong end-to-
   end authentication and encryption can be done using public keys, and
   end-to-end encryption can be done using private keys [14]. Both hop-
   by-hop and end-to-end mechanisms will likely be needed for complete
   privacy services.

   SIP allows any hop by hop encryption scheme, but TLS is mandatory to
   implement for servers. Therefore, it is RECOMMENDED that TLS [7] be
   used between elements to provide this function.  The details for
   usage of TLS for server-to-server and client-to-server security are
   detailed in Section 26.3.2 of RFC 3261 [1].

   SIP encryption, using S/MIME, MAY be used end-to-end for the
   transmission of both SUBSCRIBE and NOTIFY requests.

9.2 Message Integrity and Authenticity

   It is important for the message recipient to ensure that the message
   contents are actually what was sent by the originator, and that the
   recipient of the message be able to determine who the originator
   really is. This applies to both requests and responses of SUBSCRIBE
   and NOTIFY. NOTIFY requests are particularly important. Without
   authentication and integrity, presence documents could be forged or
   modified, fooling the watcher into believing incorrect presence
   information.

   RFC 3261 provides many mechanisms to provide these features. In order
   for the PA to authenticate the watcher, it MAY use HTTP Digest
   (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP
   Digest. This is a redundant requirement, however, since all SIP user
   agents are mandated to support it by RFC 3261. To provide
   authenticity and integrity services, a watcher MAY use the SIPS
   scheme when subscribing to the presentity. To support this, all PA
   MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1



J. Rosenberg                                                 [Page 21]


Internet Draft                SIP Presence              January 31, 2003


   of RFC 3261).

   Furthermore, SMIME MAY be used for integrity and authenticity of
   SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC
   3261.

9.3 Outbound Authentication

   When local proxies are used for transmission of outbound messages,
   proxy authentication is RECOMMENDED. This is useful to verify the
   identity of the originator, and prevent spoofing and spamming at the
   originating network.

9.4 Replay Prevention

   Replay attacks can be used by an attacker to fool a watcher into
   believing an outdated presence state for a presentity. For example, a
   document describing a presentity as being "offline" can be replayed,
   fooling watchers into thinking that the user is never online. This
   may effectively block communications with the presentity.

   SIP S/MIME can provide message integrity and authentication over SIP
   request bodies. Watchers and PAs MAY implement S/MIME signatures to
   prevent these replay attacks. When it is used for that purpose, the
   presence document carried in the NOTIFY request MUST contain a
   timestamp. In the case of PIDF, this is accomplished using the
   timestamp element, as described in Section 6 of [6]. Tuples whose
   timestamp is older than the timestamp of the most recently received
   presence document SHOULD be considered stale, and discarded.

   Finally, HTTP digest authentication (which MUST be implemented by
   watchers and PAs) MAY be used to prevent replay attacks, when there
   is a shared secret between the PA and the watcher. In such a case,
   the watcher can challenge the NOTIFY requests with the auth-int
   quality of protection.

9.5 Denial of Service Attacks Against Third Parties

   Denial of Service (DOS) attacks are a critical problem for an open,
   inter-domain, presence protocol. Unfortunately, presence is a good
   candidate for Distributed DoS (DDOS) attacks because of its
   amplification properties. A single SUBSCRIBE message could generate a
   nearly unending stream of notifications, so long as a suitably
   dynamic source of presence data can be found. Thus, a simple way to
   launch an attack against a target is to send subscriptions to a large
   number of users, and in the Contact header field (which is where
   notifications are sent), place the address of the target.




J. Rosenberg                                                 [Page 22]


Internet Draft                SIP Presence              January 31, 2003


   RFC 3265 provides some mechanisms to mitigate these attacks [2]. If a
   NOTIFY is not acknowledged or was not wanted, the subscription that
   generated it is removed. This eliminates the amplification properties
   of providing false Contact addresses.

   Authentication and authorization at the PA can also prevent these
   attacks. Typically, authorization policy will not allow subscriptions
   from unknown watchers. If the attacks are launched from watchers
   unknown to the presentity (a common case), the attacks are mitigated.

9.6 Denial Of Service Attacks Against Servers

   Denial of service attacks can also be launched against a presence
   agent itself, in order to disrupt service to a community of users.
   SIP itself, along with RFC 3265 [2], describes several mechanisms to
   mitigate these attacks.

   A server can prevent SYN-attack style attacks through a four-way
   handshake using digest authentication [1]. Even if the server does
   not have a shared secret with the client, it can verify the source IP
   address of the request using the "anonymous" user mechanism described
   in Section 22.1 of RFC 3261 [1]. SIP also allows a server to instruct
   a client to back-off from sending it requests, using the 503 response
   code (Section 21.5.4 of RFC 3261 [1]). This can be used to fend off
   floods of SUBSCRIBE requests launched as a result of a distributed
   denial of service attack.

10 IANA Considerations

   This specification registers an event package, based on the
   registration procedures defined in RFC 3265 [2]. The following is the
   information required for such a registration:

        Package Name: presence

        Package or Template-Package: This is a package.

        Published Document: RFC XXXX (Note to RFC Editor: Please fill in
             XXXX with the RFC number of this specification).

        Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.

11 Contributors

   The following individuals were part of the initial team that worked
   through the technical design of this specification:





J. Rosenberg                                                 [Page 23]


Internet Draft                SIP Presence              January 31, 2003


   Jonathan Lennox
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: lennox@cs.columbia.edu

   Robert Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   email: rsparks@dynamicsoft.com

   Ben Campbell
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   email: bcampbell@dynamicsoft.com

   Dean Willis
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   email: dwillis@dynamicsoft.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   email: huitema@microsoft.com

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   email: bernarda@microsoft.com

   David Gurle
   Microsoft Corporation



J. Rosenberg                                                 [Page 24]


Internet Draft                SIP Presence              January 31, 2003


   One Microsoft Way
   Redmond, WA 98052-6399
   email: dgurle@microsoft.com

   David Oran
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA 95134
   email: oran@cisco.com



12 Acknowledgements

   We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy
   Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen
   Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan,
   Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their
   comments and support of this specification.

13 Authors Addresses



   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com




14 Normative References

   [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
   Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
   initiation protocol," RFC 3261, Internet Engineering Task Force, June
   2002.

   [2] A. B. Roach, "Session initiation protocol (sip)-specific event
   notification," RFC 3265, Internet Engineering Task Force, June 2002.

   [3] D. H. Crocker and J. Peterson, "Common profile: Presence,"
   internet draft, Internet Engineering Task Force, Dec. 2002.  Work in
   progress.




J. Rosenberg                                                 [Page 25]


Internet Draft                SIP Presence              January 31, 2003


   [4] S. Bradner, "Key words for use in rfcs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [5] D. H. Crocker and J. Peterson, "Address resolution for instant
   messaging and presence," internet draft, Internet Engineering Task
   Force, Dec. 2002.  Work in progress.

   [6] H. Sugano, S. Fujimoto, et al.  , "Common presence and instant
   messaging (cpim)presence information data format," internet draft,
   Internet Engineering Task Force, Jan. 2003.  Work in progress.

   [7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246,
   Internet Engineering Task Force, Jan. 1999.

   [8] J. Rosenberg, "A watcher information event template-package for
   the session initiation protocol (SIP)," internet draft, Internet
   Engineering Task Force, Dec. 2002.  Work in progress.

   [9] H. Schulzrinne and J. Rosenberg, "Session initiation protocol
   (SIP) caller preferences and callee capabilities," internet draft,
   Internet Engineering Task Force, Nov. 2002.  Work in progress.

15 Informative References

   [10] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
   instant messaging," RFC 2778, Internet Engineering Task Force, Feb.
   2000.

   [11] J. Peterson, "Enhancements for authenticated identity management
   in the session initiation protocol (SIP)," internet draft, Internet
   Engineering Task Force, Oct. 2002.  Work in progress.

   [12] P. Calhoun et al.  , "Diameter base protocol," internet draft,
   Internet Engineering Task Force, Jan. 2003.  Work in progress.

   [13] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
   / presence protocol requirements," RFC 2779, Internet Engineering
   Task Force, Feb.  2000.

   [14] P. Gutmann, "Password-based encryption for CMS," RFC 3211,
   Internet Engineering Task Force, Dec. 2001.


   Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in



J. Rosenberg                                                 [Page 26]


Internet Draft                SIP Presence              January 31, 2003


   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


   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.






J. Rosenberg                                                 [Page 27]