Internet Engineering Task Force                               Adam Roach
Internet Draft                                             Ericsson Inc.                                               dynamicsoft
Category: Standards Track                                  November 2001                                  February 2002
                                                     Expires May August 2002
                                          <draft-ietf-sip-events-01.txt>
                                          <draft-ietf-sip-events-02.txt>

                    SIP-Specific Event Notification

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 cite them other than as "work in
     progress".

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/lid-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html

     This document is an individual submission to the IETF. Comments
     should be directed to the authors.

Abstract

     This document describes an extension to the Session Initiation
     Protocol (SIP). The purpose of this extension is to provide an
     extensible framework by which SIP nodes can request notification
     from remote nodes indicating that certain events have occurred.

     Concrete uses of the mechanism described in this document may be
     standardized in the future.

     Note that the event notification mechanisms defined herein are
     NOT intended to be a general-purpose infrastructure for all
     classes of event subscription and notification.

1. Table of Contents

    1.       Table of Contents...................................... 1
    2.       Introduction........................................... 3
    2.1.     Overview of Operation.................................. 4
    3.       Syntax.................................................       Definitions............................................ 4
    3.1.     New Methods............................................ 4
    3.1.1.   SUBSCRIBE method....................................... 5
    3.1.2.   NOTIFY method.......................................... 6
    3.2.     New Headers............................................ 6
    3.2.1.   "Event" header......................................... 6
    3.2.2.   "Allow-Events" Header.................................. 7
    3.2.3.   "Subscription-Expires" Header.......................... 7
    3.3.     New Response Codes..................................... 7
    3.3.1.   "202 Accepted" Response Code........................... 8
    3.3.2.   "489 Bad Event" Response Code.......................... 8
    4.       Node Behavior.......................................... 8 5
    4.1.     General................................................ 8
    4.1.1.   Route Handling......................................... 8
    4.1.2.   Detecting support for SUBSCRIBE and NOTIFY............. 9
    4.1.3.   CANCEL requests........................................ 9
    4.1.4.   State Agents and Notifier Migration.................... 9
    4.2.     Description of SUBSCRIBE Behavior...................... 10
    4.2.1.   Correlation to dialogs, calls, and terminals........... 10
    4.2.2. 5
    4.1.1.   Subscription duration.................................. 11
    4.2.3. 5
    4.1.2.   Identification of Subscribed Events and Event Classes.. 11
    4.2.4. 6
    4.1.3.   Additional SUBSCRIBE Header Values..................... 12
    4.2.5. 6
    4.1.4.   Subscriber SUBSCRIBE Behavior.......................... 12
    4.2.6. 7
    4.1.5.   Proxy SUBSCRIBE Behavior............................... 14
    4.2.7. 8
    4.1.6.   Notifier SUBSCRIBE Behavior............................ 14
    4.3. 9
    4.2.     Description of NOTIFY Behavior......................... 17
    4.3.1.   Correlation............................................ 17
    4.3.2. 11
    4.2.1.   Identification of reported events, event classes, and c 18
    4.3.3. 12
    4.2.2.   Notifier NOTIFY Behavior............................... 18
    4.3.4. 12
    4.2.3.   Proxy NOTIFY Behavior.................................. 20
    4.3.5. 14
    4.2.4.   Subscriber NOTIFY Behavior............................. 20
    4.4. 14
    4.3.     General................................................ 16
    4.3.1.   Detecting support for SUBSCRIBE and NOTIFY............. 16
    4.3.2.   CANCEL requests........................................ 16
    4.3.3.   Forking................................................ 16
    4.3.4.   Dialog creation and termination........................ 17
    4.3.5.   State Agents and Notifier Migration.................... 18
    4.3.6.   Polling Resource State................................. 21
    4.5. 18
    4.3.7.   Allow-Events header usage.............................. 21 19
    4.3.8.   PINT Compatibility..................................... 19
    5.       Event Packages......................................... 21 19
    5.1.     Appropriateness of Usage............................... 22 19
    5.2.     Sub-packages........................................... 22     Event Template-packages................................ 20
    5.3.     Amount of State to be Conveyed......................... 23 20
    5.3.1.   Complete State Information............................. 23 21
    5.3.2.   State Deltas........................................... 23 21
    5.4.     Event Package Responsibilities......................... 24 22
    5.4.1.   Event Package Name..................................... 24 22
    5.4.2.   Event Package Parameters............................... 24 22
    5.4.3.   SUBSCRIBE Bodies....................................... 24 22
    5.4.4.   Subscription Duration.................................. 25 22
    5.4.5.   NOTIFY Bodies.......................................... 25 23
    5.4.6.   Notifier processing of SUBSCRIBE requests.............. 25 23
    5.4.7.   Notifier generation of NOTIFY requests................. 25 23
    5.4.8.   Subscriber processing of NOTIFY requests............... 25 23
    5.4.9.   Handling of forked requests............................ 26 23
    5.4.10.  Rate of notifications.................................. 26 24
    5.4.11.  State Agents........................................... 26 24
    5.4.12.  Examples............................................... 26 25
    5.4.13.  URI List handling...................................... 25
    6.       Security Considerations................................ 27 25
    6.1.     Access Control......................................... 27 25
    6.2.     Release of Sensitive Policy Information................ 27 25
    6.3.     Denial-of-Service attacks.............................. 26
    6.4.     Replay Attacks......................................... 26
    6.5.     Man-in-the middle attacks.............................. 26
    6.6.     Confidentiality........................................ 27
    7.       IANA Considerations.................................... 27
    7.1.     Registration Information............................... 28
    7.2.     Registration Template.................................. 28
    8.       Open Issues............................................ 29
    8.1.     CANCEL Handling........................................
    7.3.     Syntax................................................. 29
    8.2.     Version of SIP to reference............................
    7.4.     New Methods............................................ 29
    8.3.     Immediate NOTIFYs...................................... 30
    9.
    7.4.1.   SUBSCRIBE method....................................... 31
    7.4.2.   NOTIFY method.......................................... 31
    7.5.     New Headers............................................ 31
    7.5.1.   "Event" header......................................... 31
    7.5.2.   "Allow-Events" Header.................................. 32
    7.5.3.   "Subscription-State" Header............................ 32
    7.6.     New Response Codes..................................... 33
    7.6.1.   "202 Accepted" Response Code........................... 33
    7.6.2.   "489 Bad Event" Response Code.......................... 33
    8.       Changes................................................ 30
    9.1. 33
    8.1.     Changes from draft-ietf-...-01......................... 33
    8.2.     Changes from draft-ietf-...-00......................... 30
    9.2. 35
    8.3.     Changes from draft-roach-...-03........................ 31
    9.3. 36
    8.4.     Changes from draft-roach-...-02........................ 33
    9.4. 38
    8.5.     Changes from draft-roach-...-01........................ 35
    10. 39
    9.       References............................................. 35
    11. 40
    10.      Acknowledgements....................................... 36
    12. 41
    11.      Author's Address....................................... 36 41

2. Introduction

     The ability to request asynchronous notification of events proves
     useful in many types of services for which cooperation between
     end-nodes is required. Examples of such services include
     automatic callback services (based on terminal state events),
     buddy lists (based on user presence events), message waiting
     indications (based on mailbox state change events), and PINT
     status (based on call state events).

     The methods described in this document allow a framework by which
     notification of these events can be ordered.

     The event notification mechanisms defined herein are NOT intended
     to be a general-purpose infrastructure for all classes of event
     subscription and notification. Meeting requirements for the
     general problem set of subscription and notification is far too
     complex for a single protocol. Our goal is to provide a
     SIP-specific framework for event notification which is not so
     complex as to be unusable for simple features, but which is still
     flexible enough to provide powerful services. Note, however, that
     event packages based on this framework may define arbitrarily
     complex rules which govern the subscription and notification for
     the events or classes of events they describe.

     This draft does not describe an extension which may be used
     directly; it must be extended by other drafts (herein referred to
     as "event packages.") In object-oriented design terminology, it
     may be thought of as an abstract base class which must be derived
     into an instantiatable class by further extensions. Guidelines
     for creating these extensions are described in section 5.

2.1. Overview of Operation

     The general concept is that entities in the network can subscribe
     to resource or call state for various resources or calls in the
     network, and those entities (or entities acting on their behalf)
     can send notifications when those states change.

     A typical flow of messages would be:

     Subscriber          Notifier
         |-----SUBSCRIBE---->|     Request state subscription
         |<-------200--------|     Acknowledge subscription
         |<------NOTIFY----- |     Return current state information
         |--------200------->|
         |<------NOTIFY----- |     Return current state information
         |--------200------->|

     The subscriber and notifier entities need not necessarily be UAs,
     but often will be.

     Subscriptions are expired and must be refreshed in exactly the
     same manner as registrations (see RFC 2543 [1] ). by subsequent
     SUBSCRIBE messages.

3. Syntax

     This section describes the Definitions

     Event Package: An event package is an additional specification
         which defines a set of state information to be reported by a
         notifier to a subscriber. Event packages also define further
         syntax extensions and semantics based on the framework defined by this
         document required for to convey such state information.

     Event Template-Package: An event
     notification template-package is a special
         kind of event package which defines a set of state which may
         be applied to all possible event packages, including itself.

     Notification: Notification is the act of a notifier sending a
         NOTIFY message to a subscriber to inform the subscriber of
         the state of a resource.

     Notifier: A notifier is a user agent which generates NOTIFY
         requests for the purpose of notifying subscribers of the
         state of a resource. Notifiers typically also accept
         SUBSCRIBE requests to create subscriptions.

     State Agent: A state agent is a notifier which publishes state
         information on behalf of a resource; in SIP. Semantics are described order to do so, it
         may need gather such state information from multiple sources.
         State Agents always have complete state information for the
         resource for which it is creating notifications.

     Subscriber: A subscriber is a user agent which receives NOTIFY
         requests from notifiers; these NOTIFY requests contain
         information about the state of a resource in section 4.

3.1. New Methods

     This document describes two new SIP methods: "SUBSCRIBE" and
     "NOTIFY."

     This table expands on tables 4 which the
         subscriber is interested. Subscribers typically also generate
         SUBSCRIBE requests and 5 in RFC 2543 [1] .

     Header                    Where    SUB NOT
     ------                    -----    --- ---
     Accept                      R       o   o
     Accept-Encoding             R       o   o
     Accept-Language             R       o   o
     Allow                      200      -   -
     Allow                      405      o   o
     Authorization               R       o   o
     Call-ID                    gc       m   m
     Contact                     R       m   m
     Contact                    1xx      o   o
     Contact                    2xx      m   o
     Contact                    3xx      m   m
     Contact                    485      o   o
     Content-Encoding            e       o   o
     Content-Length              e       o   o
     Content-Type                e       *   *
     CSeq                       gc       m   m
     Date                        g       o   o
     Encryption                  g       o   o
     Expires                     g       o   -
     From                       gc       m   m
     Hide                        R       o   o
     Max-Forwards                R       o   o
     Organization                g       o   o
     Priority                    R       o   o
     Proxy-Authenticate         407      o   o
     Proxy-Authorization         R       o   o
     Proxy-Require               R       o   o
     Require                     R       o   o
     Retry-After                 R       -   -
     Retry-After            404,480,486  o   o
     Retry-After                503      o   o
     Retry-After              600,603    o   o
     Response-Key                R       o   o
     Record-Route                R       o   o
     Record-Route               2xx      o   o
     Route                       R       o   o
     Server                      r       o   o
     Subject                     R       o   o
     Timestamp                   g       o   o
     To                        gc(1)     m   m
     Unsupported                420      o   o
     User-Agent                  g       o   o
     Via                       gc(2)     m   m
     Warning                     r       o   o
     WWW-Authenticate           401      o   o

3.1.1. SUBSCRIBE method
     "SUBSCRIBE" send them to notifiers to create
         subscriptions.

     Subscription: A subscription is added a set of application state
         associated with a dialog. This application state includes a
         pointer to the definition of associated dialog, the element "Method" event package name, and
         possibly an identification token. Event packages will define
         additional subscription state information. By definition,
         subscriptions exist in both a subscriber and a notifier.

     Subscription Migration: Subscription migration is the SIP message grammar.

     Like all SIP method names, the SUBSCRIBE method name is case
     sensitive. The act of
         moving a subscription from one notifier to another notifier.

4. Node Behavior

4.1. Description of SUBSCRIBE Behavior

     The SUBSCRIBE method is used to request asynchronous
     notification of current state and state
     updates from a remote node.

4.1.1. Subscription duration

     SUBSCRIBE requests SHOULD contain an event or set "Expires" header (defined in
     SIP [1] ). This expires value indicates the duration of events at the
     subscription. In order to keep subscriptions effective beyond the
     duration communicated in the "Expires" header, subscribers need
     to refresh subscriptions on a later time.

3.1.2. NOTIFY method

     "NOTIFY" periodic basis using a new
     SUBSCRIBE message on the same dialog as defined in SIP [1] .

     If no "Expires" header is added to present in a SUBSCRIBE request, the definition
     implied default is defined by the event package being used.

     200-class responses to SUBSCRIBE requests also MUST contain an
     "Expires" header. The period of time in the element "Method" response MAY be
     shorter or longer than specified in the SIP message grammar. request. The NOTIFY method period of
     time in the response is used the one which defines the duration of the
     subscription.

     An "expires" parameter on the "Contact" header has no semantics
     for SUBSCRIBE and is explicitly not equivalent to notify an "Expires"
     header in a SIP node SUBSCRIBE request or response.

     A natural consequence of this scheme is that a SUBSCRIBE with an event
     which has been requested by
     "Expires" of 0 constitutes a request to unsubscribe from an earlier SUBSCRIBE method has
     occurred. It
     event.

     Notifiers may also provide further details about wish to cancel subscriptions to events; this
     is useful, for example, when the event.

3.2. New Headers

     This table expands resource to which a subscription
     refers is no longer available. Further details on tables 4 and 5 in RFC 2543 [1] , as amended
     by the changes described this mechanism
     are discussed in section 3.1.

     Header field         where  proxy ACK BYE CAN INV OPT REG SUB NOT
     -----------------------------------------------------------------
     Allow-Events           g           o   o   o   o   o   o   o   o
     Allow-Events          489          -   -   -   -   -   -   m   m 4.2.2.

4.1.2. Identification of Subscribed Events and Event                  R           -   -   -   -   -   -   m   m
     Subscription-Expires   R           -   -   -   -   -   -   -   o

3.2.1. "Event" header

     The following header Classes

     Identification of events is defined for the purposes provided by three pieces of this
     specification.

     Event             =  ( "Event" | "o" ) ":" event-type
                          *(( ";" parameter-name
                          ["=" ( token | quoted-string ) ] )
     event-type        =  event-package *( "." event-subpackage )
     event-package     =  token-nodot
     event-subpackage  =  token-nodot
     token-nodot       =  1*( alphanum | "-"  | "!" | "%" | "*"
                              | "_" | "+" | "`" | "'" | "~" )
     information: Request URI, Event is added Type, and (optionally) message
     body.

     The Request URI of a SUBSCRIBE request, most importantly,
     contains enough information to route the definition of request to the element "request-header"
     in
     appropriate entity. It also contains enough information to
     identify the SIP message grammar.

     This document does not define values resource for event-types. These
     values will be defined by individual event packages, and MUST be
     registered with the IANA.

     There must be exactly one event type listed per which event header.
     Multiple events per message are disallowed.

     For the curious, the "o" short form notification is chosen desired,
     but not necessarily enough information to represent
     "occurrence."

3.2.2. "Allow-Events" Header

     The following header is defined for uniquely identify the purposes
     nature of this
     specification.

     Allow-Events =  ( "Allow-Events" | "u" ) ":" 1#event-type

     Allow-Events is added to the definition of event (e.g. "sip:adam@dynamicsoft.com" would be an
     appropriate URI to subscribe to for my presence state; it would
     also be an appropriate URI to subscribe to the element
     "general-header" state of my voice
     mailbox).

     Subscribers MUST include exactly one "Event" header in the SIP message grammar.

     For the curious, the "u" short form is chosen SUBSCRIBE
     requests, indicating to represent
     "understands."

3.2.3. "Subscription-Expires" Header which event or class of events they are
     subscribing. The following "Event" header is defined for will contain a token which
     indicates the purposes type of this
     specification.

     Subscription-Expires =  "Subscription-Expires" ":"
                              ( SIP-date | delta-seconds )
                               *( ";" subexp-params )

     subexp-params        =   "reason" "=" reason-code
                            | generic-param

     reason-code          =   "migration"
                            | "maint"
                            | "refused"
                            | "timeout"
                            | reason-extension

     reason-extension      =   token

     Subscription-Expires state for which a subscription is added being
     requested. This token will be registered with the IANA and will
     correspond to an event package which further describes the definition
     semantics of the element
     "request-header" in the SIP message grammar.

3.3. New Response Codes

3.3.1. "202 Accepted" Response Code event or event class. The 202 response is added to the "Success" "Event" header field
     definition:

     Success  = "200"  ;  OK
             |  "202"  ;  Accepted

     "202 Accepted" has the same meaning as that defined in HTTP/1.1
     [5] .

3.3.2. "489 Bad Event" Response Code

     The 489 event response is added to MAY
     also contain an "id" parameter. This "id" parameter, if present,
     contains an opaque token which identifies the "Client-Error" header
     field definition:

     Client-Error = "400"  ; Bad Request
                  ...
                  | "489"  ; Bad Event

     "489 Bad Event" specific
     subscription within a dialog. An "id" parameter is used to indicate that only valid
     within the server did not
     understand scope of a single dialog.

     If the event package specified in a "Event" header field.

4. Node Behavior

4.1. General

     Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow to which the
     same protocol rules governing event token corresponds defines
     behavior associated with the usage body of tags, Route handling,
     Record-Route handling, Via handling, and Contact handling as
     INVITE; retransmission, reliability, CSeq handling and
     provisional responses are the same as its SUBSCRIBE requests,
     those defined semantics apply.

     Event packages may also define parameters for BYE.

     For the purposes of this document, Event header;
     if they do so, they must define the semantics for such
     parameters.

4.1.3. Additional SUBSCRIBE Header Values

     Because SUBSCRIBE requests create a "dialog" is defined dialog as all
     messages sharing defined in SIP [1]
     , they MAY contain an "Accept" header. This header, if present,
     indicates the tuple of "To" (including tag), "From"
     (including tag), and "Call-Id." As body formats allowed in INVITE-initiated dialogs, subsequent NOTIFY requests.

     Event packages MUST define the behavior for SUBSCRIBE requests containg no "To" tag
     without "Accept" headers; usually, this will connote a single,
     default body type.

     Header values not described in this document are also considered to be part of
     the same dialog
     interpreted as messages which contain described in SIP [1] .

4.1.4. Subscriber SUBSCRIBE Behavior

4.1.4.1. Requesting a "To" tag but
     otherwise match.

4.1.1. Route Handling

     Route and Record-Route handling for Subscription

     SUBSCRIBE and NOTIFY dialogs is generally the same a dialog-creating method, as for INVITE and its subsequent responses.
     The exact method for echoing Record-Route headers in responses
     and using them to form Route headers in subsequent requests is described in RFC2543 SIP [1] . For the purposes of the following
     discussion, the "Contact" header is considered part of the
     "Record-Route" set.

     From

     When a subscriber perspective, the "Record-Route" headers
     received in wishes to subscribe to a particular state for a
     resource, it forms a SUBSCRIBE response are stored locally and placed in message. If the "Route" headers for initial SUBSCRIBE refreshes. To support forking
     represents a request outside of SUBSCRIBE requests, "Record-Route" headers received in NOTIFY
     requests MUST be echoed back in the NOTIFY responses; if no route
     for the a dialog has been established, these "Record-Route" headers
     MUST be stored locally and MUST be placed in (as it typically will),
     its construction follows the "Route" headers procedures outlined in SIP [1] for SUBSCRIBE refreshes.

     From
     UAC request generation outside of a notifier perspective, dialog.

     This SUBSCRIBE request "Record-Route"
     headers are echoed back in will be confirmed with a final response.
     200-class responses indicate that the SUBSCRIBE subscription has been
     accepted, and that a NOTIFY will be sent immediately. A 200
     response indicates that the subscription has been accepted and stored
     locally. The locally stored copy of
     that the "Record-Route" headers user is
     placed in authorized to subscribe to the "Route" headers when generating NOTIFY requests.

     The result of requested
     resource. A 202 response merely indicates that the forgoing rules is subscription
     has been understood, and that proxies wishing authorization may or may not have
     been granted.

     The "Expires" header in a 200-class response to
     remain on SUBSCRIBE
     indicates the signalling path actual duration for subsequent requests in which the subscription will
     remain active (unless refreshed).

     Non-200 class final responses indicate that no subscription or
     dialog MUST include themselves in a "Record-Route" for all
     requests, not just the initial SUBSCRIBE.

4.1.2. Detecting support for SUBSCRIBE has been created, and no subsequent NOTIFY

     Neither SUBSCRIBE nor NOTIFY necessitate message will be
     sent. All non-200 class responses (with the use exception of "Require" or
     "Proxy-Require" headers; similarly, there is no token defined for
     "Supported" headers. If necessary, clients may probe for "489,"
     described herein) have the
     support of SUBSCRIBE same meanings and NOTIFY using the OPTIONS request defined handling as
     described in RFC2543 SIP [1] .

     The presence of the "Allow-Events" header

     A SUBSCRIBE request MAY include an "id" parameter in a message is
     sufficient its "Event"
     header to indicate support for SUBSCRIBE and NOTIFY.

     The "methods" parameter for Contact allow differentiation between multiple subscriptions in
     the same dialog.

4.1.4.2. Refreshing of Subscriptions

     At any time before a subscription expires, the subscriber may also be used to
     specifically announce support for
     refresh the timer on such a subscription by sending another
     SUBSCRIBE and NOTIFY messages
     when registering. (See reference [8] for details request on the "methods"
     parameter).

4.1.3. CANCEL requests

     For same dialog as the purposes of generality, both SUBSCRIBE and NOTIFY MAY be
     canceled; however, doing so is not recommended. Successfully
     cancelled SUBSCRIBE existing
     subscription, and NOTIFY requests MUST be completed with a
     "487 Request Cancelled" response; the server acts as if same "Event" header "id" parameter (if
     one was present in the initial subscription). The handling for
     such a request were never received. In general, since neither SUBSCRIBE
     nor NOTIFY are allowed to have protracted transactions, attempts
     to cancel them are expected to fail.

4.1.4. State Agents and Notifier Migration
     When state agents (see section 5.4.11. ) are used, it is often
     useful to allow migration of subscriptions between state agents
     and the nodes same as for which they are providing state aggregation (or
     even among various state agents). Such migration may be effected
     by sending a "NOTIFY" with an "Subscription-Expires" header the initial creation of
     "0," and a reason parameter of "migration." This NOTIFY request
     is otherwise normal, and is formed
     subscription except as described in section 4.3.3.

     Upon receipt of this NOTIFY message, the subscriber SHOULD
     attempt to re-subscribe (as described in below.

         If the following sections).
     The resulting initial SUBSCRIBE message can then be proxied or redirected
     to contained an "id" parameter
         on the node to which notification responsibility is passing.

4.2. Description "Event" header, then refreshes of SUBSCRIBE Behavior

     The SUBSCRIBE method is used to request current state and state
     updates from the subscription
         must also contain an identical "id" parameter; they will
         otherwise be considered new subscriptions in an existing
         dialog.

     If a remote node.

4.2.1. Correlation SUBSCRIBE request to dialogs, calls, and terminals

     A refresh a subscription is uniquely identified by the combination of receives a "481"
     response, this indicates that the
     To, From, subscription has been
     terminated and Call-ID fields in that the SUBSCRIBE request. Refreshes subscriber did not receive notification
     of subscriptions SHOULD reuse this fact. In this case, the same Call-ID if possible, since
     subscriptions are uniquely identified at presence servers using subscriber should consider the Call-ID. Two subscriptions from
     subscription invalid. If the same user, for subscriber wishes to re-subscribe to
     the same
     user, but state, he does so by composing an unrelated initial SUBSCRIBE
     request with different Call-IDs, are considered different
     subscriptions. Note this a freshly-generated Call-ID and a new, unique "From"
     tag (see section 4.1.4.1. )

     If a SUBSCRIBE request to refresh a subscription fails with a
     non-481 response, the original subscription is exactly still considered
     valid for the same as usage duration of Call-ID
     in registrations.

     Initial the most recently known "Expires" value
     as negotiated by SUBSCRIBE requests MUST contain a "tag" parameter (as
     defined and its response, or as communicated
     by NOTIFY in RFC 2543 [1] ) the "Subscription-State" header "expires" parameter.

4.1.4.3. Unsubscribing

     Unsubscribing is handled in the "From" header, and MUST NOT
     contain same way as refreshing of a "tag" parameter in
     subscription, with the "To" header. Responses "Expires" header set to
     SUBSCRIBE requests MUST contain "0." Note that a "tag" parameter in the "To"
     header.
     successful unsubscription will also trigger a final "NOTIFY".

4.1.4.4. Confirmation of Subscription Creation

     The "tag" in the "To" header allows the subscriber can expect to
     differentiate between receive a NOTIFY requests message from different clients in
     the case that the SUBSCRIBE request was forked. SUBSCRIBE
     requests for re-subscription MUST contain "tag" parameters in
     both the "To" and "From" headers (matching those previously
     established for each
     node which has processed a successful subscription or
     subscription refresh. Until the dialog).

     The relationship between subscriptions and (INVITE-initiated)
     sessions sharing first NOTIFY message arrives, the same dialog correlation information is
     undefined. Re-using  dialog correlation information for
     subscriptions is allowed, but sharing of such information does
     not change
     subscriber should consider the semantics state of the INVITE session or the SUBSCRIBE
     dialog.

     Similarly, the relationship between a subscription in one
     direction (e.g. from node A subscribed resource
     to node B) and be in a subscription neutral state. Event packages which define new event
     packages MUST define this "neutral state" in the
     opposite direction (from B such a way that
     makes sense for their application (see section 5.4.7. ).

     Due to A) with the same dialog correlation
     information is undefined. While re-using such information is
     allowed, potential for both out-of-order messages and forking,
     the sharing of such information does not change subscriber MUST be prepared to receive NOTIFY messages before
     the
     semantics of either SUBSCRIBE dialog.

4.2.2. Subscription duration SUBSCRIBE requests SHOULD contain an "Expires" header. This
     expires value indicates the duration of the subscription. The
     formatting transaction has completed.

     Except as noted above, processing of these is described in RFC 2543. In order to keep
     subscriptions effective beyond the duration communicated in the
     "Expires" header, subscribers need to refresh subscriptions on a
     periodic basis. This refreshing this NOTIFY is performed in the same way as
     REGISTER refreshes: the To, From, and Call-ID match those
     in the section 4.2.4.

4.1.5. Proxy SUBSCRIBE being refreshed, while the CSeq number is incremented.

     If Behavior

     Proxies need no "Expires" header is present additional behavior beyond that described in a SUBSCRIBE request, the
     implied default is defined by the event package being used.

     200-class responses SIP
     [1] to support SUBSCRIBE. If a proxy wishes to see all of the
     SUBSCRIBE and NOTIFY requests also for a given dialog, it MUST contain an
     "Expires" header. The period of time in the response MAY be
     shorter or
     record-route all SUBSCRIBE and NOTIFY requests.

4.1.6. Notifier SUBSCRIBE Behavior

4.1.6.1. Initial SUBSCRIBE Transaction Processing

     In no case should a SUBSCRIBE transaction extend for any longer
     than specified in the request. The period of time in the necessary for automated processing. In particular,
     notifiers MUST NOT wait for a user response before returning a
     final response is the one which defines the duration of the
     subscription.

     Similar to REGISTER requests, a SUBSCRIBE requests may be renewed
     at any time request.

         This requirement is imposed primarily to prevent them timer F from expiring at the end of
         firing during the
     "Expires" period. These renewals will contain SUBSCRIBE transaction, since interaction
         with a user would often exceed 64*T1 seconds.

     The notifier SHOULD check that the same "To,"
     "From," and "Call-ID" as event package specified in the original request, and an incremented
     "CSeq" number.

     Also similar to REGISTER requests, a natural consequence of this
     scheme
     "Event" header is that a SUBSCRIBE with an "Expires" of 0 constitutes understood. If not, the notifier SHOULD return
     a
     request to unsubscribe from an event.

     Notifiers may also wish to cancel subscriptions "489 Bad Event" response to events; this indicate that the specified
     event/event class is useful, for example, when not understood.

     The notifier SHOULD also perform any necessary authentication and
     authorization per its local policy. See section 4.1.6.3.

     If the resource notifier is able to which a subscription
     refers immediately determine that it
     understands the event package, that the authenticated subscriber
     is authorized to subscribe, and that there are no longer available. Further details on this mechanism
     are discussed in section 4.3.3.

4.2.3. Identification of Subscribed Events other barriers
     to creating the subscription, it creates the subscription and Event Classes

     Identification of events is provided by three pieces of
     information: Request URI, Event Type, a
     dialog (if necessary), and (optionally) message
     body.

     The Request URI of returns a SUBSCRIBE request, most importantly,
     contains enough information to route "200 OK" response (unless
     doing so would reveal authorization policy in an undesirable
     fashion; see section 6.2. ).

     If the request to notifier cannot immediately create the
     appropriate entity. It also contains enough information subscription (e.g.
     it needs to
     identify the resource wait for user input for authorization, or is acting
     for another node which event notification is desired,
     but not necessarily enough information to uniquely identify the
     nature of the event (e.g. "sip:adam.roach@ericsson.com" would be
     an appropriate URI to subscribe currently reachable), or wishes to for my presence state;
     mask authorization policy, it
     would also be an appropriate URI to subscribe to the state of my
     voice mailbox).

     Subscribers MUST include exactly one "Event" header in SUBSCRIBE
     requests, indicating to which event or class of events they are
     subscribing. The "Event" header will contain return a token which "202 Accepted"
     response. This response indicates that the type of state for which request has been
     received and understood, but does not necessarily imply that the
     subscription has been authorized yet.

     When a subscription is being
     requested. This token will be registered with created in the notifier, it stores the IANA and will
     correspond to an
     event package which further describes name and the
     semantics "Event" header "id" parameter (if
     present) as part of the event or event class. subscription information.

     The "Event" header is considered mandatory for the purposes of
     this document. However, to maintain compatibility with PINT (see
     [3] ), servers MAY interpret a "Expires" values present in SUBSCRIBE request with no "Event"
     header as requesting a subscription to PINT events. If 200-class responses
     behave in the
     servers do not support PINT, same way as they SHOULD return "489 Bad Event"
     to any SUBSCRIBE messages without an EVENT header.

     If the event package to which do in REGISTER responses: the event token corresponds defines
     behavior associated with
     server MAY shorten the body of its SUBSCRIBE requests,
     those semantics apply.

4.2.4. Additional SUBSCRIBE Header Values

     Each SUBSCRIBE request interval, but MUST have exactly one "Contact:" header,
     to be used as part of route handling, as described in section
     4.1.1.

     SUBSCRIBE requests MAY contain an "Accept" header. This header,
     if present, indicates NOT lengthen it. If the body formats allowed
     duration specified in subsequent
     NOTIFY requests. Event packages MUST define a SUBSCRIBE message is unacceptably short,
     the behavior for notifier SHOULD respond with a "423 Subscription Too Brief"
     message.

     200-class responses to SUBSCRIBE requests without "Accept" headers; usually, this will
     connote a single, default body type.

     Header values not described in this document are generally
     contain any useful information beyond subscription duration;
     their primary purpose is to be
     interpreted serve as described a reliability mechanism.
     State information will be communicated via a subsequent NOTIFY
     request from the notifier.

     The other response codes defined in RFC 2543 SIP [1] .

4.2.5. Subscriber may be used in
     response to SUBSCRIBE Behavior

4.2.5.1. Requesting a requests, as appropriate.

4.1.6.2. Confirmation of Subscription

     When a subscriber wishes to subscribe to Creation/Refreshing

     Upon successfully accepting or refreshing of a particular state for subscription,
     notifiers MUST send a
     resource, it forms a SUBSCRIBE message.

     The dialog correlation information is formed as if for an
     original INVITE: the Call-ID is a new call ID with the syntax
     described in RFC 2543; the To: field indicates the subscribed
     resource's persistent address (which will generally match NOTIFY message immediately to communicate
     the
     Request URI used current resource state to form the message); and subscriber. This NOTIFY message
     is sent on the From: field will
     indicate same dialog as created by the subscriber's persistent address (typically
     sip:user@domain).

     This SUBSCRIBE request will be confirmed with a final response.
     200-class responses indicate that
     If the subscription resource has been
     accepted, and no meaningful state at the time that the
     SUBSCRIBE message is processed, this NOTIFY message MAY contain
     an empty or neutral body. See section 4.2.2. for further details
     on NOTIFY message generation.

     Note that a NOTIFY will be message is always sent immediately. A 200 immediately after any
     200-class response indicates that to a SUBSCRIBE request, regardless of whether
     the subscription has already been accepted and authorized.

4.1.6.3. Authentication/Authorization of SUBSCRIBE requests

     Privacy concerns may require that the user notifiers apply policy to
     determine whether a particular subscriber is authorized to
     subscribe to the requested
     resource. A 202 response merely indicates that the subscription
     has been understood, and that authorization a certain set of events. Such policy may be defined
     by mechanisms such as access control lists or may not have
     been granted.

     The "Expires" header in real-time
     interaction with a 200-class response user. In general, authorization of subscribers
     prior to SUBSCRIBE
     indicates authentication is not particularly useful.

     SIP authentication mechanisms are discussed in SIP [1] . Note
     that, even if the actual duration notifier node typically acts as a proxy,
     authentication for which the subscription SUBSCRIBE requests will
     remain active (unless refreshed).

     Non-200 class final responses indicate that the subscription has always be performed
     via a "401" response, not been created, a "407;" notifiers always act as a user
     agents when accepting subscriptions and no subsequent NOTIFY message will sending notifications.

     If authorization fails based on an access list or some other
     automated mechanism (i.e. it can be sent.
     All non-200 class responses (with automatically authoritatively
     determined that the exception of "489,"
     described herein) have subscriber is not authorized to subscribe),
     the same meanings notifier SHOULD reply to the request with a "403 Forbidden"
     or "603 Decline" response, unless doing so might reveal
     information that should stay private; see section 6.2.

     If the notifier owner is interactively queried to determine
     whether a subscription is allowed, a "202 Accept" response is
     returned immediately. Note that a NOTIFY message is still formed
     and handling sent under these circumstances, as described in RFC 2543 [1] .

4.2.5.2. Refreshing of Subscriptions

     At any time before a subscription expires, the subscriber may
     refresh previous
     section.

     If subscription authorization was delayed and the timer on notifier wishes
     to convey that such a subscription authorization has been declined, it may do so
     by re-sending sending a
     SUBSCRIBE request. The handling for such NOTIFY message containing a request is the same as
     for the initial creation "Subscription-State"
     header with a value of "terminated" and a subscription except as described
     below.

     Subscription renewals will contain reason parameter of
     "rejected."

4.1.6.4. Refreshing of Subscriptions

     When a "To" field matching notifier receives a subscription refresh, assuming that
     the
     "From" field in subscriber is still authorized, the first NOTIFY request notifier updates the
     expiration time for subscription. As with the dialog
     containing initial
     subscription, the subscription to be refreshed. They will contain server MAY shorten the same "From" and "Call-ID" fields as the original SUBSCRIBE
     request, and an incremented "CSeq" number from the original
     SUBSCRIBE request. Route handling amount of time until
     expiration, but MUST NOT increase it. The final expiration time
     is as discussed placed in section
     4.1.1.

     If a SUBSCRIBE request to refresh a subscription receives a "481"
     response, this indicates that the subscription has been
     terminated and that the subscriber did not receive notification
     of this fact. In this case, the subscriber should consider "Expires" header in the
     subscription invalid. response. If the subscriber wishes to re-subscribe to
     the state, he does so by composing an unrelated initial
     duration specified in a SUBSCRIBE
     request message is unacceptably short,
     the notifier SHOULD respond with a freshly-generated Call-ID and a new, unique "From"
     tag (see section 4.2.5.1. ) "423 Subscription Too Brief"
     message.

     If a SUBSCRIBE request to no refresh for a subscription fails, notification address is received before its
     expiration time, the
     original subscription is still considered valid for removed. When removing a
     subscription, the duration notifier SHOULD send a NOTIFY message with a
     "Subscription-State" value of "terminated" to inform it that the most recently known "Expires" value as negotiated by
     SUBSCRIBE and its response, or as communicated by NOTIFY in
     "Subscription-Expires," except as described above.

4.2.5.3. Unsubscribing

     Unsubscribing
     subscription is handled in the same way as refreshing of being removed. If such a
     subscription, with message is sent, the "Expires"
     "Subscription-State" header set to "0." Note that a
     successful unsubscription will also trigger SHOULD contain a final "NOTIFY".

4.2.5.4. Confirmation of Subscription Creation "reason=timeout"
     parameter.

         The subscriber can expect to receive sending of a NOTIFY message from each
     node which has registered when a successful subscription or
     subscription refresh. Until expires allows
         the first corresponding dialog to be terminated, if appropriate.

4.2. Description of NOTIFY message arrives, the
     subscriber should consider the state of the subscribed resource Behavior

     NOTIFY messages are sent to be inform subscribers of changes in a neutral state. Event packages
     state to which define new event
     packages MUST define this "neutral state" in such the subscriber has a way subscription. Subscriptions
     are typically put in place using the SUBSCRIBE method; however,
     it is possible that
     makes sense for their application (see section 5.4.7. ).

     Due other means have been used.

     If any non-SUBSCRIBE mechanisms are defined to create
     subscriptions, it is the potential for both out-of-order messages and forking, responsibility of the subscriber MUST be prepared parties defining
     those mechanisms to receive ensure that correlation of a NOTIFY messages before message
     to the SUBSCRIBE transaction has completed.

     Except as noted above, processing corresponding subscription is possible. Designers of this such
     mechanisms are also warned to make a distinction between sending
     a NOTIFY message to a subscriber who is aware of the same as
     in section 4.3.5.

4.2.6. Proxy SUBSCRIBE Behavior

     Proxies need no additional
     subscription, and sending a NOTIFY message to an unsuspecting
     node. The latter behavior beyond that is invalid, and MUST receive a "481
     Subscription does not exist" response (unless some other 400- or
     500-class error code is more applicable), as described in RFC
     2543 [1] to support SUBSCRIBE. If a proxy wishes to see all section
     4.2.4. In other words, knowledge of a subscription must exist in
     both the SUBSCRIBE subscriber and the notifier to be valid, even if
     installed via a non-SUBSCRIBE mechanism.

     A NOTIFY requests for does not terminate its corresponding subscription; in
     other words, a given dialog, it MUST
     record-route all single SUBSCRIBE and request may trigger several
     NOTIFY requests.

4.2.7. Notifier SUBSCRIBE Behavior

4.2.7.1. SUBSCRIBE Transaction Processing

     In no case should

4.2.1. Identification of reported events, event classes, and current
state

     Identification of events being reported in a SUBSCRIBE transaction extend for any longer
     than the time necessary for automated processing. In particular,
     notifiers MUST NOT wait notification is very
     similar to that described for a user response before returning a
     final response subscription to a events (see section
     4.1.2. ).

     As in SUBSCRIBE request.

     The notifier SHOULD check that the requests, NOTIFY "Event" headers will contain a
     single event package specified name for which a notification is being
     generated. The package name in the "Event" header is understood. If not, MUST match the notifier SHOULD return
     a "489 Bad Event" response to indicate that
     "Event" header in the specified
     event/event class is not understood.

     The notifier SHOULD also perform any necessary authentication and
     authorization per its local policy. See section 4.2.7.3. corresponding SUBSCRIBE message. If an "id"
     parameter was present in the SUBSCRIBE request contains a tag message, that "id"
     parameter MUST also be present in the "To"
     field, but the notifier has no record of the indicated dialog,
     the notifier has two options. corresponding NOTIFY
     messages.

     If the notifier is able and willing event package to reconstruct subscription state, he may accept the subscription
     as an initial subscription. If which the notifier cannot or is not
     willing to reconstitute such state, it should respond event package name corresponds
     defines behavior associated with a "481
     Subscription does not exist."

     If the notifier body of its NOTIFY requests,
     those semantics apply. This information is able expected to immediately determine that it
     understands provide
     additional details about the event package, that nature of the authenticated subscriber
     is authorized to subscribe, event which has
     occurred and that there are no other barriers
     to creating the subscription, it creates the subscription and
     returns a "200 OK" response, unless doing so would reveal
     authorization policy in an undesirable fashion (see section 6.2.
     ).

     If the notifier cannot immediately create resultant resource state.

     When present, the subscription (e.g.
     it needs to wait for user input for authorization, or is acting
     for another node which is not currently reachable), or wishes to
     mask authorization policy, it will return a "202 Accepted"
     response. This response indicates that body of the NOTIFY request has been
     received and understood, but does not necessarily imply that the
     subscription has been created yet.

     The "Expires" values present in SUBSCRIBE 200-class responses
     behave in MUST be formatted
     into one of the same way as they do body formats specified in REGISTER responses: the
     server MAY shorten or lengthen "Accept" header of
     the interval.

     200-class responses to corresponding SUBSCRIBE requests request. This body will not generally contain any useful information beyond subscription duration;
     their primary purpose is to serve as a reliability mechanism.
     State information will be communicated via a subsequent NOTIFY
     request from
     either the notifier.

     The other response codes defined in RFC 2543 may be used in
     response to SUBSCRIBE requests, as appropriate.

4.2.7.2. Confirmation state of Subscription Creation/Refreshing

     Upon successfully accepting the subscribed resource or refreshing a pointer to such
     state in the form of a subscription,
     notifiers URI.

4.2.2. Notifier NOTIFY Behavior

     When a SUBSCRIBE request is answered with a 200-class response,
     the notifier MUST immediately construct and send a NOTIFY message immediately to communicate
     the current resource state request
     to the subscriber. If When a change in the resource has
     no meaningful subscribed state at the time that occurs,
     the SUBSCRIBE message is
     processed, this NOTIFY message MAY contain an empty or neutral
     body. See section 4.3.3. for further details on NOTIFY message
     generation.

     Note that a NOTIFY message is always sent notifier SHOULD immediately after any
     200-class response to construct and send a SUBSCRIBE NOTIFY
     request, regardless of whether
     the subscription has already been authorized.

4.2.7.3. Authentication/Authorization of SUBSCRIBE requests

     Privacy concerns may require that notifiers either use access
     lists or ask the notifier owner, on a per-subscription basis,
     whether a particular remote node is authorized to subscribe to a
     certain set of events. In general, authorization of users prior subject to authentication authorization, local policy, and throttling
     considerations.

     A NOTIFY request is not particularly useful.

     SIP authentication mechanisms are discussed in RFC2543 [1] . Note
     that, even considered failed if the notifier node typically acts as a proxy,
     authentication for SUBSCRIBE requests will always be performed
     via a "401" response, not a "407;" notifiers always act as response times out,
     or a user
     agents when accepting subscriptions non-200 class response code is received which has no
     "Retry-After" header and sending notifications.

     If authorization fails based on an access list or some other
     automated mechanism (i.e. it no implied further action which can be automatically authoritatively
     determined that the subscriber is not authorized to subscribe),
     the notifier SHOULD reply
     taken to retry the request with a "403 Forbidden"
     or "603 Decline" response, unless doing so might reveal
     information that should stay private; see section 6.2. (e.g. "401 Authorization Required.")

     If the notifier owner is interactively queried NOTIFY request fails (as defined above) due to determine
     whether a timeout
     condition, and the subscription is allowed, a "202 Accept" response is
     returned immediately. Note that was installed using a NOTIFY message is still formed
     and sent under these circumstances, soft-state
     mechanism (such as described in the previous
     section.

     If subscription authorization was delayed and SUBSCRIBE), the notifier wishes
     to convey that SHOULD remove the
     subscription.

         This behavior prevents unnecessary transmission of state
         information for subscribers who have crashed or disappeared
         from the network. Because such authorization has been declined, it may do so
     by sending a NOTIFY message containting a "Subscription-Expires"
     header with a value transmissions will be sent 11
         times (instead of "0" and the typical single transmission for
         functioning clients), continuing to service them when no
         client is available to acknowledge them could place undue
         strain on a reason parameter of "refused."

4.2.7.4. Refreshing network. Upon client restart or reestablishment
         of Subscriptions

     When a notifier receives a subscription refresh, assuming network connection, it is expected that clients will
         send SUBSCRIBE messages to refresh potentially stale state
         information; such messages will re-install subscriptions in
         all relevant nodes.

     If the subscriber is still authorized, NOTIFY request fails (as defined above) due to an error
     response, and the subscription was installed using a soft-state
     mechanism, the notifier updates MUST remove the
     expiration time for corresponding
     subscription. As

         A notify error response would generally indicate that
         something has gone wrong with the initial
     subscription, the server MAY shorten subscriber or increase with some
         proxy on the amount of
     time until expiration. The final expiration time way to the subscriber. If the subscriber is placed in
         error, it makes the
     "Expires" header in most sense to allow the response. subscriber to
         rectify the situation (by re-subscribing) once the error
         condition has been handled. If no refresh for a notification address proxy is received before its
     expiration time, in error, the
         periodic SUBSCRIBE refreshes will re-install subscription is removed. When removing a
     subscription,
         state once the notifier MAY send network problem has been resolved.

     If a NOTIFY message with request receives a
     "Subscription-Expires" value of "0" to inform it that 481 response, the notifier MUST
     remove the corresponding subscription is being removed. If even if such a message is sent, subscription
     was installed by non-SUBSCRIBE means (such as an administrative
     interface).

         If the
     "Subscription-Expires" header SHOULD contain above behavior were not required, subscribers
         receiving a "reason=timeout"
     parameter.

4.3. Description of NOTIFY Behavior

     NOTIFY messages are sent notify for an unknown subscription would need to inform subscribers of changes
         send an error status code in
     state response to which the subscriber has NOTIFY and also
         send a SUBSCRIBE request to remove the subscription. Subscriptions
     are typically put Since
         this behavior would make subscribers available for use as
         amplifiers in place using the SUBSCRIBE method; however,
     it is possible that other means denial of service attacks, we have been used.

     If any non-SUBSCRIBE mechanisms are defined instead
         elected to create
     subscriptions, give the 481 response special meaning: it is the responsibility of the parties defining
     those mechanisms used
         to ensure indicate that correlation of a NOTIFY message
     to the corresponding subscription is possible. Designers of such
     mechanisms are also warned to make a distinction between sending
     a must be cancelled under all
         circumstances.

     NOTIFY message to requests MUST contain a subscriber who is aware "Subscription-State" header with a
     value of "active," "pending," or "terminated." The "active" value
     indicates that the
     subscription, subscription has been accepted and sending a NOTIFY message has been
     authorized (in most cases; see section 6.2. ). The "pending"
     value indicates that the subscription has been received, but that
     policy information is insufficient to an unsuspecting
     node. accept or deny the
     subscription at this time. The latter behavior "terminated" value indicates that
     the subscription is invalid, and MUST receive a "481
     Subscription does not exist" response (unless some other 400- or
     500-class error code active.

     If the value of the "Subscription-State" header is more applicable), as described in section
     4.3.5. In other words, knowlege of a subscription must exist "active" or
     "pending," the notifier SHOULD also include in
     both the subscriber and
     "Subscription-State" header an "expires" parameter which
     indicates the time remaining on the subscription. The notifier
     MAY use this mechanism to be valid, even if
     installed via shorten a non-SUBSCRIBE mechanism.

     A NOTIFY does not cancel its corresponding subscription; in other
     words, however, this
     mechanism MUST NOT be used to lengthen a single subscription.

         Including expiration information for active and pending
         subscriptions is useful in case the SUBSCRIBE request forks,
         since the response to a forked SUBSCRIBE may trigger several NOTIFY
     requests.

4.3.1. Correlation

     NOTIFY requests MUST contain not be received
         by the same Call-ID as subscriber. Note well that this "expires" value is a
         parameter on the SUBSCRIBE
     request which ordered them; "Subscription-State" header, NOT an
         "Expires" header.

     If the "To" field MUST match value of the "From"
     field in "Subscription-State" header is "terminated,"
     the SUBSCRIBE that ordered them, and notifier SHOULD also include a "reason" parameter. The
     notifier MAY also include a "retry-after" parameter, where
     appropriate. For details on the "From" field
     MUST match value and semantics of the "To" field
     "reason" and "retry-after" parameters, see section 4.2.4.

4.2.3. Proxy NOTIFY Behavior

     Proxies need no additional behavior beyond that was sent described in the 200-class response SIP
     [1] to support NOTIFY. If a proxy wishes to see all of the SUBSCRIBE. In other words,
     SUBSCRIBE and NOTIFY requests for a given dialog, it MUST be in the
     same dialog as the
     record-route all SUBSCRIBE that ordered them.

     The From field of and NOTIFY requests.

4.2.4. Subscriber NOTIFY Behavior

     Upon receiving a NOTIFY request, like the "To" field subscriber should check that
     it matches at least one of a
     SUBSCRIBE response, its outstanding subscriptions; if not,
     it MUST contain return a tag; this allows for the
     subscriber to differentiate between events from different
     notifiers.

     Successful SUBSCRIBE requests will receive only one 200-class
     response; however, due to forking, the subscription may have been
     accepted by multiple nodes. "481 Subscription does not exist" response
     unless another 400- or 500-class response is more appropriate.
     The subscriber MUST therefore be
     prepared to receive rules for matching NOTIFY requests with "From:" tags which
     differ from the "To:" tag received subscriptions that
     create a new dialog is described in the SUBSCRIBE 200-class
     response.

     If multiple NOTIFY messages section 4.3.4. Notifications
     for subscriptions which were created inside an existing dialog
     match if they are received in response to a single
     SUBSCRIBE message, they represent different destinations to which the SUBSCRIBE request was forked. Unless same dialog and the "Event" headers
     match (as described in section 7.5.1. )

     If, for some reason, the event package
     specifies otherwise, the subscriber may either accept all such
     notifications as representing different dialogs (which are then
     refreshed separately), or send a 481 response to any NOTIFYs on
     dialogs that it does not want to keep alive.

     As expected, CSeq spaces are unique for each node; designated in other
     words, the notifier uses a different CSeq space than "Event"
     header of the NOTIFY request is not supported, the subscriber and any other notifiers.

4.3.2. Identification
     will respond with a "489 Bad Event" response.

     To prevent spoofing of reported events, event classes, and current
state

     Identification NOTIFY requests SHOULD be
     authenticated, using any defined SIP authentication mechanism.

     NOTIFY requests MUST contain "Subscription-State" headers which
     indicate the status of events being reported in a notification the subscription.

     If the "Subscription-State" header value is very
     similar to "active," it means
     that described for the subscription to events (see section
     4.2.3. ).

     The Request URI of a NOTIFY request contains enough information
     to route the request to the party which is subscribed to receive
     notifications. It is derived from has been accepted and (in general) has been
     authorized. If the "Contact" header present in also contains an "expires" parameter,
     the corresponding SUBSCRIBE request.

     If subscriber SHOULD take it as the same events for different resources are being subscribed
     to, implementors are expected to use different dialogs in order
     to be able to differentiate between notifications authoritative subscription
     duration and adjust accordingly. The "retry-after" and "reason"
     parameters have no semantics for them,
     unless "active."

     If the body for "Subscription-State" value is "pending," the event contains enough information for
     this correlation.

     As in SUBSCRIBE requests, NOTIFY "Event" headers will contain a
     single  token which identifies subscription
     has been received by the event or class of events for
     which a notification notifier, but there is being generated.

     If the event package insufficient
     policy information to which grant or deny the event token corresponds defines
     behavior associated with subscription yet. If the body of its NOTIFY requests, those
     semantics apply. This information is expected to provide
     additional details about
     header also contains an "expires" parameter, the nature of subscriber
     SHOULD take it as the event which has
     occurred authoritative subscription duration and
     adjust accordingly. No further action is necessary on the resultant resource state.

     When present, the body part of
     the NOTIFY request MUST be formatted
     into one of subscriber. The "retry-after" and "reason" parameters have no
     semantics for "pending."

     If the body formats specified in "Subscription-State" value is "terminated," the "Accept" header of subscriber
     should consider the corresponding SUBSCRIBE request.

4.3.3. Notifier NOTIFY Behavior

     When subscription terminated. The "expires"
     parameter has no semantics for "terminated." If a SUBSCRIBE request reason code is successfully processed or a relevant
     change in
     present, the subscribed state occurs, the notifier will
     immediately construct and send a NOTIFY request to the
     subscriber(s), per standard Route/Record-Route handling, client should behave as described in section 4.1.1. below. If the notifier no
     reason code or an unknown reason code is able, through any means, to determine that present, the
     subscriber is no longer available to receive notifications, it client MAY elect
     attempt to not send re-subscribe at any time (unless a notification. An example "retry-after"
     parameter is present, in which case the client SHOULD NOT attempt
     re-subscription until after the number of a method seconds specified by
     which such information may be known is
     the "SIP for Presence"
     event set (see [4] ).

     A NOTIFY request is considered failed if "retry-after" parameter). The defined reason codes are:

     deactivated: The subscription has been terminated, but the response times out,
     or client
         SHOULD retry immediately with a non-200 class response new subscription. One primary
         use of such a status code is received which to allow migration of
         subscriptions between nodes. The "retry-after" parameter has
         no
     "Retry-After" header and no implied further action which can be
     taken to retry semantics for "deactivated."

     probation: The subscription has been terminated, but the request (e.g. "401 Authorization Required.") client
         SHOULD retry at some later time. If the NOTIFY request fails (as defined above) due to a timeout
     condition, and the subscription was installed using a soft-state
     mechanism (such as SIP signalling), "retry-after" parameter
         is also present, the notifier client SHOULD remove
     the subscription.

     If wait at least the NOTIFY request fails (as defined above) number
         of seconds specified by that parameter before attempting to
         re-subscribe.

     rejected: The subscription has been terminated due to an error
     response, and the change in
         authorization policy. Clients SHOULD NOT attempt to
         re-subscribe. The "retry-after" parameter has no semantics
         for "rejected."

     timeout: The subscription has been terminated because it was installed using a soft-state
     mechanism, not
         refreshed before it expired. Clients MAY re-subscribe
         immediately. The "retry-after" parameter has no semantics for
         "timeout."
     giveup: The subscription has been terminated because the notifier MUST remove the corresponding
     subscription.

     If
         could not obtain authorization in a NOTIFY request receives timely fashion. If a 481 response, the notifier MUST
     remove
         "retry-after" parameter is also present, the corresponding subscription even if such subscription
     was installed by non-SUBSCRIBE means (such as an administrative
     interface).

     NOTIFY requests client SHOULD contain an "Subscription-Expires" header
     which indicates
         wait at least the remaining duration number of seconds specified by that
         parameter before attempting to re-subscribe; otherwise, the subscription (such
     a header
         client MAY retry immediately, but will likely get put back
         into pending state.

     Once the notification is  useful in case deemed acceptable to the SUBSCRIBE request forks, since subscriber, the response to
     subscriber SHOULD return a forked subscribe -- which contains the "Expire"
     header 200 response. In general, it is not
     expected that specifies NOTIFY responses will contain bodies; however, they
     MAY, if the agreed-upon expiration time -- NOTIFY request contained an "Accept" header.

     Other responses defined in SIP [1] may not also be received by returned, as
     appropriate.

4.3. General

4.3.1. Detecting support for SUBSCRIBE and NOTIFY

     Neither SUBSCRIBE nor NOTIFY necessitate the subscriber). The notifier SHOULD use this
     header to adjust of "Require" or
     "Proxy-Require" headers; similarly, there is no token defined for
     "Supported" headers. If necessary, clients may probe for the time remaining on
     support of SUBSCRIBE and NOTIFY using the subscription; however,
     this mechanism MUST not be used to lengthen OPTIONS request defined
     in SIP [1] .

     The presence of the "Allow-Events" header in a subscription, only message is
     sufficient to shorten it. indicate support for SUBSCRIBE and NOTIFY.

     The notifier may inform a subscriber that a
     subscription has been removed by sending a "methods" parameter for Contact may also be used to
     specifically announce support for SUBSCRIBE and NOTIFY message messages
     when registering. (See reference [7] for details on the "methods"
     parameter).

4.3.2. CANCEL requests

     No semantics are associated with an
     "Subscription-Expires" value of "0."

     If cancelling SUBSCRIBE or NOTIFY.

4.3.3. Forking

     Successful SUBSCRIBE requests will receive only one 200-class
     response; however, due to forking, the duration of a subscription has may have been shortened or
     terminated
     accepted by the "Subscription-Expires" header as compared multiple nodes. The subscriber MUST therefore be
     prepared to receive NOTIFY requests with "From:" tags which
     differ from the "To:" tag received in the most recent 200-class SUBSCRIBE 200-class
     response.

     If multiple NOTIFY messages are received in response sent, that header
     SHOULD include to a "reason" parameter indicating single
     SUBSCRIBE message, they represent different destinations to which
     the reason that
     such action SUBSCRIBE request was taken. Currently, four forked. For information on subscriber
     handling in such values are defined:
     "migration" indicates that the node acting as notifier situations, see section 5.4.9.

4.3.4. Dialog creation and termination

     If an initial SUBSCRIBE request is
     transferring responsibility for maintaing such state information
     to another node; this only makes sense when subscriptions are
     terminated, not when they are shortened. "Maint" indicates that sent on an pre-existing
     dialog, the subscription is being truncated or terminated due subscriber will wait for a response to server
     maintainance, and "refused" indicates that the subscription has
     been removed SUBSCRIBE
     request or shortened administratively (e.g. by a change in
     ACL policy). Finally, matching NOTIFY.

     Responses are matched to such SUBSCRIBE requests if they contain
     the notifier elects to send a NOTIFY
     upon timeout of same the subscription, they SHOULD include a
     "Subscription-Expires" same "Call-ID," the same "From" header with a value of "0" and a reason
     parameter field, the
     same "To" header field, excluding the "tag," and the same "CSeq."
     Rules for the comparison of "timeout."

4.3.4. Proxy NOTIFY Behavior

     Proxies need no additional behavior beyond that these headers are described in RFC
     2543 SIP
     [1] to support NOTIFY. . If a proxy wishes to see all of the
     SUBSCRIBE and NOTIFY requests for 200-class response matches such a given dialog, it MUST
     record-route all SUBSCRIBE request,
     it creates a new subscription and NOTIFY requests.

4.3.5. Subscriber NOTIFY Behavior

     Upon receiving a new dialog (unless they have
     already been created by a matching NOTIFY request, request; see below).

     NOTIFY requests are matched to such SUBSCRIBE requests if they
     contain the subscriber should check that
     it same "Call-ID," a "From" header field which matches at least one
     the "To" header field of its outstanding subscriptions; if not,
     it MUST return the SUBSCRIBE, excluding the "tag," a "481 Subscription does not exist" response
     unless another 400- or 500-class response is more appropriate.

     If, for some reason,
     "To" header field which matches the event package designated in "From" header field of the
     SUBSCRIBE, and the same "Event" header field. Rules for
     comparisons of the "Event" headers are described in section
     7.5.1. If a matching NOTIFY request is not supported, the subscriber
     will respond with contains a "489 Bad Event" response.

     To prevent spoofing
     "Subscription-State" of events, NOTIFY requests MAY be
     authenticated, using any defined SIP authentication mechanism.

     NOTIFY requests SHOULD contain "Subscription-Expires" headers
     which indicate the time remaining on the subscription. If this
     header is present, the subscriber SHOULD take "active" or "pending," it as the
     authoritative duration creates a new
     subscription and adjust accordingly. a new dialog (unless the have already been
     created by a matching response, as described above).

     If an expires
     value of "0" initial SUBSCRIBE is present, the subscriber should consider the
     subscription terminated.

     When the subscription is terminated sent on a pre-existing dialog, a
     matching 200-class response or shortened using the
     "Subscription-Expires" mechanism, there SHOULD successful NOTIFY request merely
     creates a new subscription associated with that dialog.

     Multiple subscriptions can be associated with a reason
     parameter present. If it is present single dialog.
     Subscriptions may also exist in dialogs associated with
     INVITE-created application state and the subscriber is still
     interested other application state
     created by mechanisms defined in receiving updates to the other specifications. These sets
     of application state information, do not interact beyond the
     subscriber SHOULD attempt re-subscribe upon expiration if it is behavior
     described for a dialog (e.g. route set to "migration," "timeout," is not present, or handling).

     A subscription is set to an
     unknown value. Such destroyed when a resubscription will be completely
     independant of the original subscription, and will not share notifier sends a
     dialog NOTIFY
     request with it; it will be generated as described in section
     4.2.5.1.

     If the "reason" parameter on a "Subscription-Expires" "Subscription-State" of "terminated".

         A subscriber may send a SUBSCRIBE request with an
         "Expiration" header  is
     set of 0 in order to either "maint" or "refused," the subscriber SHOULD NOT
     attempt re-subscription.

     Once trigger the notification is deemed acceptable to sending of
         such a NOTIFY request; however, for the subscriber, purposes of
         subscription and dialog lifetime, the
     subscriber SHOULD return a 200 response. In general, it subscription is not
     expected that NOTIFY responses will contain bodies; however, they
     MAY, if
         considered terminated until the NOTIFY request contained an "Accept" header.

     Other responses defined in RFC 2543 [1] may also be returned, as
     appropriate.

4.4. Polling Resource State

     A natural consequence with a
         "Subscription-State" of "terminated" is sent.

     If a subscription's destruction leaves no other application state
     associated with the behavior described in dialog, the preceding
     sections is dialog terminates. The
     destruction of other application state (such as that created by
     an immediate fetch without INVITE) will not terminate the dialog if a persistent subscription may be effected by sending an appropriate SUBSCRIBE is
     still associated with that dialog.

         Note that the above behavior means that a dialog created with
         an "Expires" INVITE does not necessarily terminate upon receipt of 0.

     Of course, an immediate fetch while a subscription
         BYE.

4.3.5. State Agents and Notifier Migration

     When state agents (see section 5.4.11. ) are used, it is active often
     useful to allow migration of subscriptions between state agents
     and the nodes for which they are providing state aggregation (or
     even among various state agents). Such migration may be effected
     by sending an appropriate SUBSCRIBE a "NOTIFY" with an "Expires"
     greater than 0. "Subscription-State" header of
     "terminated," and a reason parameter of "deactivated." This
     NOTIFY request is otherwise normal, and is formed as described in
     section 4.2.2.

     Upon receipt of this SUBSCRIBE request, the notifier (or
     notifiers, if the SUBSCRIBE request was forked) will send a NOTIFY request containing resource state to message, the address subscriber SHOULD
     attempt to re-subscribe (as described in the
     SUBSCRIBE "Contact" field. preceding sections).
     Note that normal Route this subscription is established on a new dialog, and
     Record-Route handle still applies; see section 4.1.1.

4.5. Allow-Events header usage
     does not re-use the route set from the previous subscription
     dialog.

     The "Allow-Events" header, if present, includes actual migration is effected by making a list change to the policy
     (such as routing decisions) of tokens one or more servers to which indicates the event packages supported by the client (if
     sent in a request) or server (if
     SUBSCRIBE request will be sent in such a response). In other
     words, way that a different
     node sending an "Allow-Events" header is advertising
     that it can process SUBSCRIBE requests and generate NOTIFY
     requests for all of ends up responding to the SUBSCRIBE request. This may be as
     simple as a change in the local policy in the notifier from which
     the subscription is migrating so that it serves as a proxy or
     redirect server instead of a notifier.

     Whether, when, and why to perform notifier migrations may be
     described in individual event packages; otherwise, such decisions
     are a matter of local notifier policy, and are left up to
     individual implementations.

4.3.6. Polling Resource State

     A natural consequence of the behavior described in the preceding
     sections is that an immediate fetch without a persistent
     subscription may be effected by sending a SUBSCRIBE with an
     "Expires" of 0.

     Of course, an immediate fetch while a subscription is active may
     be effected by sending a SUBSCRIBE with an "Expires" equal to the
     number of seconds remaining in the subscription.

     Upon receipt of this SUBSCRIBE request, the notifier (or
     notifiers, if the SUBSCRIBE request was forked) will send a
     NOTIFY request containing resource state in the same dialog.

     Note that the NOTIFY messages triggered by SUBSCRIBE messages
     with "Expire" headers of 0 will contain a "Subscription-State"
     value of "terminated," and a "reason" parameter of "timeout."

4.3.7. Allow-Events header usage

     The "Allow-Events" header, if present, includes a list of tokens
     which indicates the event packages supported by the client (if
     sent in a request) or server (if sent in a response). In other
     words, a node sending an "Allow-Events" header is advertising
     that it can process SUBSCRIBE requests and generate NOTIFY
     requests for all of the event packages listed in that header.

     Any node implementing one or more event packages SHOULD include
     an appropriate "Allow-Events" header indicating all supported
     events in INVITE requests all methods which initiate dialogs and responses, OPTIONS responses, their responses
     (such as INVITE) and
     REGISTER requests. "Allow-Events" headers MAY be included in any
     other type of request or response. OPTIONS responses.

     This information is very useful, for example, in allowing user
     agents to render particular interface elements appropriately
     according to whether the events required to implement the
     features they represent are supported by the appropriate nodes.

     Note that "Allow-Events" headers MUST NOT be inserted by proxies.

4.3.8. PINT Compatibility

     The "Event" header is considered mandatory for the purposes of
     this document. However, to maintain compatibility with PINT (see
     [3] ), servers MAY interpret a SUBSCRIBE request with no "Event"
     header as requesting a subscription to PINT events. If a server
     does not support PINT, it SHOULD return "489 Bad Event" to any
     SUBSCRIBE messages without an "Event" header.

5. Event Packages

     This section covers several issues which should be taken into
     consideration when event packages based on SUBSCRIBE and NOTIFY
     are proposed.

5.1. Appropriateness of Usage

     When designing an event package using the methods described in
     this draft for event notification, it is important to consider:
     is SIP an appropriate mechanism for the problem set? Is SIP being
     selected because of some unique feature provided by the protocol
     (e.g. user mobility), or merely because "it can be done?" If you
     find yourself defining event packages for notifications related
     to, for example, network management or the temperature inside
     your car's engine, you may want to reconsider your selection of
     protocols.

     Those interested in extending the mechanism defined in this
     document are urged to read "Guidelines for Authors of SIP
     Extensions" [2] for further guidance regarding appropriate uses
     of SIP.

     Further, it is expected that this mechanism is not to be used in
     applications where the frequency of reportable events is
     excessively rapid (e.g. more than about once per second). A SIP
     network is generally going to be provisioned for a reasonable
     signalling volume; sending a notification every time a user's GPS
     position changes by one hundreth of a second could easily
     overload such a network.

5.2. Sub-packages Event Template-packages

     Normal event packages define a set of state applied to a specific
     type of resource, such as user presence, call state, and
     messaging mailbox state.

     Sub-packages

     Event template-packages are a special type of package which
     define a set of state applied to other packages, such as
     statistics, access policy, and subscriber lists. Sub-packages Event
     template-packages may even be applied to other sub-packages. event
     template-packages.

     To extend the object-oriented analogy made earlier, sub-packages event
     template-packages can be thought of as templatized C++ packages
     which must be applied to other packages to be useful.

     The name of a sub-package an event template-package as applied to a package is
     formed by appending a period followed by the sub-package event
     template-package name to the end of the package. For example, if
     a subpackage template-package called "watcherinfo" "winfo" were being applied to a package
     called "presence," the event token used in "Event" and
     "Allow-Events" would be
     "presence.watcherinfo".

     Sub-packages "presence.winfo".

     Event template-packages must be defined so that they can be
     applied to any arbitrary package. In other words, sub-packages event
     template-packages cannot be specifically tied to one or a few
     "parent" packages in such a way that they will not work with
     other packages.

5.3. Amount of State to be Conveyed

     When designing event packages, it is important to consider the
     type of information which will be conveyed during a notification.

     A natural temptation is to convey merely the event (e.g. "a new
     voice message just arrived") without accompanying state (e.g. "7
     total voice messages"). This complicates implementation of
     subscribing entities (since they have to maintain complete state
     for the entity to which they have subscribed), and also is
     particularly susceptible to synchronization problems.

     There are two possible solutions to this problem that event
     packages may choose to implement.

5.3.1. Complete State Information

     For packages which typically convey state information that is
     reasonably small (on the order of 1 kb or so), it is suggested
     that event packages are designed so as to send complete state
     information when an event occurs.

     In the circumstances that state may not be sufficient for a
     particular class of events, the event packages should include
     complete state information along with the event that occurred.
     For example, "no customer service representatives available" may
     not be as useful "no customer service representatives available;
     representative sip:46@cs.xyz.int just logged off".

5.3.2. State Deltas

     In the case that the state information to be conveyed is large,
     the event package may choose to detail a scheme by which NOTIFY
     messages contain state deltas instead of complete state.

     Such a scheme would work as follows: any NOTIFY sent in immediate
     response to a SUBSCRIBE contains full state information. NOTIFY
     messages sent because of a state change will contain only the
     state information that has changed; the subscriber will then
     merge this information into its current knowledge about the state
     of the resource.

     Any event package that supports delta changes to states MUST use
     a payload which contains a version number that increases by
     exactly one for each NOTIFY message. Note that the state version
     number appears in the body of the message, not in a SIP header.

     If a NOTIFY arrives that has a version number that is incremented
     by more than one, the subscriber knows that a state delta has
     been missed; it ignores the NOTIFY message containing the state
     delta (except for the version number, which it retains to detect
     message loss), and re-sends a SUBSCRIBE to force a NOTIFY
     containing a complete state snapshot.

5.4. Event Package Responsibilities

     Event packages are not required to re-iterate any of the behavior
     described in this document, although they may choose to do so for
     clarity or emphasis. In general, though, such packages are
     expected to describe only the behavior that extends or modifies
     the behavior described in this document.

     Note that any behavior designated with "SHOULD" or "MUST" in this
     document is not allowed to be changed by extension documents;
     however, such documents may elect to strengthen "SHOULD"
     requirements to "MUST" strength if required by their application.

     In addition to the normal sections expected by "Instructions to
     RFC Authors" [6] [5] and "Guidelines for Authors of SIP Extensions"
     [2] , authors of event packages MUST address each of the issues
     detailed in the following subsections, whenever applicable.

5.4.1. Event Package Name

     This mandatory section of an event package defines the token name
     to be used to designate the event package. It MUST include the
     information which appears in the IANA registration of the token.
     For information on registering such types, see section 7.

5.4.2. Event Package Parameters

     If parameters are to be used on the "Event" header to modify the
     behavior of the event package, the syntax and semantics of such
     headers must MUST be clearly defined.

5.4.3. SUBSCRIBE Bodies

     It is expected that most, but not all, event packages will define
     syntax and semantics for SUBSCRIBE method bodies; these bodies
     will typically modify, expand, filter, throttle, and/or set
     thresholds for the class of events being requested. Designers of
     event packages are strongly encouraged to re-use existing MIME
     types for message bodies where practical.

     This mandatory section of an event package defines what type or
     types of event bodies are expected in SUBSCRIBE requests (or
     specify that no event bodies are expected). It should point to
     detailed definitions of syntax and semantics for all referenced
     body types.

5.4.4. Subscription Duration

     It is recommended RECOMMENDED that event packages give a suggested range of
     times considered reasonable for the duration of a subscription.
     Such packages MUST also define a default "Expires" value to be
     used if none is specified.

5.4.5. NOTIFY Bodies

     The NOTIFY body is used to report state on the resource being
     monitored. Each package must MUST define a what type or types of event
     bodies are expected in NOTIFY requests. Such packages must MUST
     specify or cite detailed specifications for the syntax and
     semantics associated with such event body.

     Event packages also need to MUST define which MIME type is to be assumed
     if none are specified in the "Accept" header of the SUBSCRIBE
     request.

5.4.6. Notifier processing of SUBSCRIBE requests

     This section describes the processing to be performed by the
     notifier upon receipt of a SUBSCRIBE request. Such a section is
     required.

     Information in this section includes details of how to
     authenticate subscribers and authorization issues for the
     package. Such authorization issues may include, for example,
     whether all SUBSCRIBE requests for this package are answered with
     202 responses (see section 6.2. ).

5.4.7. Notifier generation of NOTIFY requests

     This section of an event package describes the process by which
     the notifier generates and sends a NOTIFY request. This includes
     detailed information about what events cause a NOTIFY to be sent,
     how to compute the state information in the NOTIFY, how to
     generate "neutral" or "fake" state information to hide
     authorization delays and decisions from users, and whether state
     information is complete or deltas for notifications (see section
     5.3. )

     It may optionally describe the behavior used to processes the
     subsequent response. Such a section is required.

5.4.8. Subscriber processing of NOTIFY requests

     This section of an event package describes the process followed
     by the subscriber upon receipt of a NOTIFY request, including any
     logic required to form a coherent resource state (if applicable).

5.4.9. Handling of forked requests
     Each event package should SHOULD specify whether forked SUBSCRIBE
     requests are allowed to install multiple subscriptions.

     If such behavior is not allowed, any the first potential
     dialog-establishing message will create a dialog. All subsequent
     NOTIFY messages not matching the
     200-class response which correspond to the initial SUBSCRIBE message are responded
     to (i.e.
     match To, From, From tag, Call-ID, CSeq, Event, and Event id) but
     which do not match the dialog would be rejected with a 481. 481
     response.

     If installing of multiple subscriptions by way of a single forked
     INVITE is allowed, the subscriber establishes a new dialog
     towards each notifier by returning a 200-class response to each
     NOTIFY. Each dialog is then handled as its own entity, and is
     refreshed independent of the other dialogs.

     In the case that multiple subscriptions are allowed, the event
     package must MUST specify whether merging of the notifications to form
     a single state is required, and how such merging is to be
     performed. Note that it is possible that some event packages may
     be defined in such a way that each dialog is tied to a mutually
     exclusive state which is unaffected by the other dialogs; this
     must
     MUST be clearly stated if it is the case.

     If the event package does not specify which mode of operation to
     use, the subscriber may employ either mode of operation.

5.4.10. Rate of notifications

     Each event package is expected to define a requirement
     (RECOMMENDED, SHOULD (SHOULD or
     MUST strength) which defines an absolute maximum on the rate at
     which notifications are allowed to be generated by a single
     notifier.

     Such packages may MAY further define a throttle mechanism which
     allows subscribers to further limit the rate of notification.

5.4.11. State Agents

     Designers of event packages should consider whether their package
     can benefit from network aggregation points ("State Agents")
     and/or nodes which act on behalf of other nodes. (For example,
     nodes which provide state information about a resource when such
     a resource is unable or unwilling to provide such state
     information itself). An example of such an application is a node
     which tracks the presence and availability of a user in the
     network.

     If state agents are to be used by the package, the package must MUST
     specify how such state agents aggregate information and how they
     provide authentication and authorization.

     Event packages MAY also outline specific scenarios under which
     notifier migrations take place.

5.4.12. Examples

     Event packages should SHOULD include several demonstrative message flow
     diagrams paired with several typical, syntactically correct and
     complete messages.

     It is recommended RECOMMENDED that documents describing event packages
     clearly indicate that such examples are informative and not
     normative, with instructions that implementors refer to the main
     text of the draft for exact protocol details.

6. Security Considerations

6.1. Access Control

     The ability to accept subscriptions should be under the direct
     control of the user, since many

5.4.13. URI List handling

     Some types of events event packages may be considered
     sensitive for the purposes of privacy. Similarly, the notifier
     should have the ability to selectively reject subscriptions based define state information which
     is potentially too large to reasonably send in a SIP message. To
     alleviate this problem, event packages may include the ability to
     use a MIME body type of "application/uri-list" in NOTIFY
     messages. The URI or URIs contained in the NOTIFY body will then
     be used to retrieve the actual state information.

     If an event package elects to use this mechanism, it MUST define
     at least one baseline scheme (e.g. http) which is mandatory to
     support, as well as one mandatory baseline data format for the
     data so retrieved. Event packages using URIs to retrieve state
     information also MUST address the duration of the validity of the
     URIs passed to a subscriber in this fashion.

6. Security Considerations

6.1. Access Control

     The ability to accept subscriptions should be under the direct
     control of the user, since many types of events may be considered
     sensitive for the purposes of privacy. Similarly, the notifier
     should have the ability to selectively reject subscriptions based
     on the calling party subscriber identity (based on access control lists), using
     standard SIP authentication mechanisms. The methods for creation
     and distribution of such access control lists is outside the
     scope of this draft.

6.2. Release of Sensitive Policy Information

     The mere act of returning a 200 or certain 4xx and 6xx responses
     to SUBSCRIBE requests may, under certain circumstances, create
     privacy concerns by revealing sensitive policy information. In
     these cases, the notifier should SHOULD always return a 202 response.
     While the subsequent NOTIFY message may not convey true state, it
     MUST appear to contain a potentially correct piece of data from
     the point of view of the subscriber, indistinguishable from a
     valid response. Information about whether a user is authorized to
     subscribe to the requested state is never conveyed back to the
     original user under these circumstances.

6.3. Denial-of-Service attacks

     The current model (one SUBSCRIBE request triggers a SUBSCRIBE
     response and one or more NOTIFY requests) is a classic setup for
     an amplifier node to be used in a smurf attack.

     Also, the creation of state upon receipt of a SUBSCRIBE request
     can be used by attackers to consume resources on a victim's
     machine, rendering it unusable.

     To reduce the chances of such an attack, implementations of
     notifiers SHOULD require authentication. Authentication issues
     are discussed in RFC2543 SIP [1] .

7. IANA Considerations

     (This section is not applicable until this document is published
     as an RFC.)

     This document defines an event-type namespace

6.4. Replay Attacks

     Replaying of either SUBSCRIBE or NOTIFY can have detrimental
     effects.

     In the case of SUBSCRIBE messages, attackers may be able to
     install any arbitrary subscription which requires it witnessed being
     installed at some point in the past. Replaying of NOTIFY messages
     may be used to spoof old state information (although a
     central coordinating body. The body chosen for this coordination
     is good
     versioning mechanism in the Internet Assigned Numbers Authority (IANA).

     There are two different types body of event-types: normal event
     packages, and event sub-packages; see section 5.2. To avoid
     confusion, subpackage names and package names share the same
     namespace; NOTIFY messages may help
     mitigate such an attack).

     To prevent such attacks, implementations SHOULD require
     authentication. Authentication issues are discussed in other words, SIP [1] .

6.5. Man-in-the middle attacks

     Even with authentication, man-in-the-middle attacks using
     SUBSCRIBE may be used to install arbitrary subscriptions, hijack
     existing subscriptions, terminate outstanding subscriptions, or
     modify the resource to which a sub-package MUST NOT share subscription is being made. To
     prevent such attacks, implementations SHOULD provide integrity
     protection across "Contact," "Route," "Expires," "Event," and
     "To" headers of SUBSCRIBE messages, at a name
     with minimum. If SUBSCRIBE
     bodies are used to define further information about the state of
     the call, they SHOULD be included in the integrity protection
     scheme.

     Man-in-the-middle attacks may also attempt to use NOTIFY messages
     to spoof arbitrary state information and/or terminate outstanding
     subscriptions. To prevent such attacks, implementations SHOULD
     provide integrity protection across the "Call-ID," "CSeq," and
     "Subscription-State" headers and the bodies of NOTIFY messages.

     Integrity protection of message headers and bodies is discussed
     in SIP [1] .

6.6. Confidentiality

     The state information contained in a package.

     Following NOTIFY message has the policies outlined
     potential to contain sensitive information. Implementations MAY
     encrypt such information to ensure confidentiality.

     While less likely, it is also possible that the information
     contained in "Guidelines a SUBSCRIBE message contains information that users
     might not want to have revealed. Implementations MAY encrypt such
     information to ensure confidentiality.

     To allow the remote party to hide information it considers
     sensitive, all implementations SHOULD be able to handle encrypted
     SUBSCRIBE and NOTIFY messages.

     The mechanisms for Writing an providing confidentiality are detailed in SIP
     [1] .

7. IANA Considerations Section in RFCs" [7] , normal event package
     identification tokens are allocated

     (This section is not applicable until this document is published
     as First Come First Served,
     and event sub-package identification tokens are allocated on an RFC.)

     This document defines an event-type namespace which requires a
     IETF Consensus basis.

     Registrations
     central coordinating body. The body chosen for this coordination
     is the Internet Assigned Numbers Authority (IANA).

     There are two different types of event-types: normal event
     packages, and event template-packages; see section 5.2. To avoid
     confusion, template-package names and package names share the
     same namespace; in other words, an event template-package MUST
     NOT share a name with a package.

     Following the policies outlined in "Guidelines for Writing an
     IANA Considerations Section in RFCs" [6] , normal event package
     identification tokens are allocated as First Come First Served,
     and event template-package identification tokens are allocated on
     a IETF Consensus basis.

     Registrations with the IANA MUST include IANA MUST include the token being
     registered and whether the token is a package or a
     template-package. Further, packages MUST include contact
     information for the party responsible for the registration and/or
     a published document which describes the event package. Event
     template-package token registrations MUST include a pointer to
     the published RFC which defines the event template-package.

     Registered tokens to designate packages and template-packages
     MUST NOT contain the character ".", which is used to separate
     template-packages from packages.

7.1. Registration Information

     As this document specifies no package or template-package names,
     the initial IANA registration for event types will be empty. The
     remainder of the text in this section gives an example of the
     type of information to be maintained by the IANA; it also
     demonstrates all five possible permutations of package type,
     contact, and reference.

     The table below lists the event packages and template-packages
     defined in "SIP-Specific Event Notification" [RFC xxxx]. Each
     name is designated as a package or a template-package under
     "Type."

     Package Name      Type         Contact      Reference
     ------------      ----         -------      ---------
     example1          package      [Roach]
     example2          package      [Roach]      [RFC xxxx]
     example3          package                   [RFC xxxx]
     example4          template     [Roach]      [RFC xxxx]
     example5          template                  [RFC xxxx]

     PEOPLE
     ------
     [Roach] Adam Roach <adam@dynamicsoft.com>

     REFERENCES
     ----------
     [RFC xxxx] A. Roach "SIP-Specific Event Notification", RFC XXXX,
                August 2002.

7.2. Registration Template

     To: ietf-sip-events@iana.org
     Subject: Registration of new SIP event package
     Package Name:

         (Package names must conform to the syntax described in
         section 7.5.1. )

     Is this registration for a Template Package:

         (indicate yes or no)

     Published Specification(s):

         (Template packages require a published RFC. Other packages
         may reference a specification when appropriate).

     Person & email address to contact for further information:

7.3. Syntax

     This section describes the syntax extensions required for event
     notification in SIP. Semantics are described in section 4. Note
     that the formal syntax definitions described in this document are
     expressed in the ABNF format defined by [1] , and contain
     references to elements defined therein.

7.4. New Methods

     This document describes two new SIP methods: "SUBSCRIBE" and
     "NOTIFY."

     This table expands on tables 2 and 3 in SIP [1] .

     Header                    Where    SUB NOT
     ------                    -----    --- ---
     Accept                      R       o   o
     Accept                     2xx      -   -
     Accept                     415      o   o
     Accept-Encoding             R       o   o
     Accept-Encoding            2xx      -   -
     Accept-Encoding            415      o   o
     Accept-Language             R       o   o
     Accept-Language            2xx      -   -
     Accept-Language            415      o   o
     Alert-Info                  R       -   -
     Alert-Info                 180      -   -
     Allow                       R       o   o
     Allow                      2xx      o   o
     Allow                       r       o   o
     Allow                      405      m   m
     Authentication-Info        2xx      o   o
     Authorization               R       o   o
     Call-ID                     c       m   m
     Contact                     R       m   m
     Contact                    1xx      o   o
     Contact                    2xx      m   o
     Contact                    3xx      m   m
     Contact                    485      o   o
     Content-Disposition                 o   o
     Content-Encoding                    o   o
     Content-Language                    o   o
     Content-Length                      t   t
     Content-Type                        *   *
     CSeq                        c       m   m
     Date                                o   o
     Error-Info               300-699    o   o
     Expires                             o   -
     From                        c       m   m
     In-Reply-To                 R       -   -
     Max-Forwards                R       m   m
     Min-Expires                423      m   -
     MIME-Version                        o   o
     Organization                        o   -
     Priority                    R       o   -
     Proxy-Authenticate         407      m   m
     Proxy-Authorization         R       o   o
     Proxy-Require               R       o   o
     RAck                        R       -   -
     Record-Route                R       o   o
     Record-Route           2xx,401,484  o   o
     Reply-To                            -   -
     Require                             o   o
     Retry-After        404,413,480,486  o   o
     Retry-After              500,503    o   o
     Retry-After              600,603    o   o
     Route                       R       c   c
     RSeq                       1xx      o   o
     Server                      r       o   o
     Subject                     R       -   -
     Supported                   R       o   o
     Supported                  2xx      o   o
     Timestamp                           o   o
     To                         c(1)     m   m
     Unsupported                420      o   o
     User-Agent                          o   o
     Via                         c       m   m
     Warning                     r       o   o
     WWW-Authenticate           401      m   m

7.4.1. SUBSCRIBE method

     "SUBSCRIBE" is added to the definition of the token being
     registered and whether element "Method" in
     the token SIP message grammar.

     Like all SIP method names, the SUBSCRIBE method name is a package case
     sensitive. The SUBSCRIBE method is used to request asynchronous
     notification of an event or set of events at a subpackage.
     Further, packages MUST include contact information for later time.

7.4.2. NOTIFY method

     "NOTIFY" is added to the party
     responsible for definition of the registration and/or element "Method" in
     the SIP message grammar.

     The NOTIFY method is used to notify a published document SIP node that an event
     which describes has been requested by an earlier SUBSCRIBE method has
     occurred. It may also provide further details about the event package. Sub-package event.

7.5. New Headers

     This table expands on tables 2 and 3 in SIP [1] , as amended by
     the changes described in section 7.4.

     Header field      where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
     -----------------------------------------------------------------
     Allow-Events        R          o   o   -   o   o   o   o   o   o
     Allow-Events       2xx         -   o   -   o   o   o   o   o   o
     Allow-Events       489         -   -   -   -   -   -   -   m   m
     Event               R          -   -   -   -   -   -   -   m   m
     Subscription-State  R          -   -   -   -   -   -   -   -   m

7.5.1. "Event" header

     The following header is defined for the purposes of this
     specification.

     Event             =  ( "Event" | "o" ) HCOLON event-type
                          *( SEMI event-param )
     event-type        =  event-package *( "." event-template )
     event-package     =  token-nodot
     event-template    =  token-nodot
     token-nodot       =  1*( alphanum | "-"  | "!" | "%" | "*"
                              | "_" | "+" | "`" | "'" | "~" )
     event-param      =  generic-param | ( "id" EQUAL token
     registrations MUST include a pointer to the published RFC which
     defines the sub-package.

     Registered tokens to designate packages and sub-packages MUST NOT
     contain the character ".", which )

     Event is used added to separate sub-packages
     from packages.

7.1. Registration Template

     As this document specifies no package or sub-package names, the
     initial IANA registration for event types will be empty. The
     remainder definition of the text element "message-header"
     in this section gives an example of the
     type of information to be maintained by SIP message grammar.

     For the IANA; it also
     demonstrates all five possible permutations purposes of package type,
     contact, matching responses and reference.

     The table below lists NOTIFY messages with
     SUBSCRIBE messages, the event packages event-type portion of the "Event" header
     is compared byte-by-byte, and sub-packages defined
     in "SIP-Specific Event Notification" [RFC xxxx]. Each name the "id" parameter token (if
     present) is
     designated as a package or compared byte-by-byte. An "Event" header containing
     an "id" parameter never matches an "Event" header without an "id"
     parameter. No other parameters are considered when performing a subpackage under "Type."
     Package Name      Type         Contact      Reference
     ------------      ----         -------      ---------
     example1          package      [Roach]
     example2          package      [Roach]      [RFC xxxx]
     example3          package                   [RFC xxxx]
     example4          sub-package  [Roach]      [RFC xxxx]
     example5          sub-package               [RFC xxxx]

     PEOPLE
     ------
     [Roach] Adam Roach <adam.roach@ericsson.com>

     REFERENCES
     ----------
     [RFC xxxx] A. Roach "SIP-Specific Event Notification", RFC XXXX,
                August 2002.

8. Open Issues

     In addition to the three issues listed below, the BNF in this
     comparison.

     This document needs to does not define values for event-types. These
     values will be converted to explicit LWS to match defined by individual event packages, and MUST be
     registered with the IANA.

     There MUST be exactly one event type listed per event header.
     Multiple events per message are disallowed.

     For the
     latest bis draft; this change will be reflected in curious, the next
     version.

8.1. CANCEL Handling

     This "o" short form is actually a protocol-wide open issue which has impacts on
     this specification: there hasn't been a clear consensus about
     cancellation of non-INVITE requests yet. If non-INVITE requests
     cannot be cancelled, we need chosen to remove section 4.1.3.

8.2. Version represent
     "occurrence."

7.5.2. "Allow-Events" Header

     The following header is defined for the purposes of SIP this
     specification.

     Allow-Events =  ( "Allow-Events" | "u" ) HCOLON
                     1*event-type

     Allow-Events is added to reference

     Much the definition of the handling in this document is rather different than
     what is described in RFC2543; element
     "general-header" in fact, many of the recent changes SIP message grammar.

     For the curious, the "u" short form is chosen to this document have been tracking changes in represent
     "understands."

7.5.3. "Subscription-State" Header

     The following header is defined for the "bis" versions purposes of the SIP this
     specification. We can continue

     Subscription-State   =  "Subscription-State" HCOLON
                             substate-value )
                            *( SEMI subexp-params )

     substate-value      =  "active" | "pending" | "terminated"
     subexp-params        =   ("reason" EQUAL reason-code)
                             |("expires" EQUAL delta-seconds)
                             |("retry-after" EQUAL delta-seconds)
                            | generic-param

     reason-code          =   "deactivated"
                            | "probation"
                            | "rejected"
                            | "timeout"
                            | "giveup"
                            | reason-extension

     reason-extension      =   token

     Subscription-State is added to reference RFC2543
     while pulling in huge chunks of the bis draft for compatibility
     (for example, definition of the Route handling would essentially be copied
     word-for-word from element
     "request-header" in the bis draft), or we can start referencing SIP message grammar.

7.6. New Response Codes

7.6.1. "202 Accepted" Response Code

     The 202 response is added to the bis drafts.

     Of course, referencing "Success" header field
     definition:

     Success  = "200"  ;  OK
             |  "202"  ;  Accepted

     "202 Accepted" has the bis drafts allows us same meaning as that defined in HTTP/1.1
     [4] .

7.6.2. "489 Bad Event" Response Code

     The 489 event response is added to pick up
     changes the "Client-Error" header
     field definition:

     Client-Error = "400"  ; Bad Request
                  ...
                  | "489"  ; Bad Event

     "489 Bad Event" is used to protocol semantics "for free," while importing chunks
     of it requires constant maintanance and runs indicate that the risk of getting
     out of sync.

     On server did not
     understand the other hand, placing event package specified in a dependency on the "Event" header field.

8. Changes

8.1. Changes from draft-ietf-...-01
     - Changed dependancy from RFC2543 to new sip bis draft pushes
     the timeframe for this draft (and the drafts that depend on it)
     out past the time that the next SIP RFC is published.

8.3. Immediate NOTIFYs

     There has been discussion, but no consensus, on the issue draft.
       This allowed removal of
     whether each SUBSCRIBE must have certain sections of text.

     - Renamed "sub-packages" to "template-packages" in an immediate NOTIFY message sent
       attempt to mitigate exploding rampant misinterpretation.

     - Changed "Subscription-Expires" to "Subscription-State,"
       and added clearer semantics for "reason" codes.

     - Aligned "Subscription-State" "reason" codes with
       watcherinfo draft.

     - Made "Subscription-State" mandatory in response. In attempts NOTIFY
       requests, since it is integral to follow defining the prevailing sentiment, this
     draft had become internally inconsistent.

     This version
       creation and destruction of this document has eliminated these
     inconsistancies by requiring notifiers always subscriptions (and,
       consequently, dialogs)

     - Heavily revised section on dialog creation and
       termination.

     - Expanded migration section.

     - Added "id" parameter to send a Event header, to allow
       demultiplexing of NOTIFY
     immediately upon receiving requests when more than
       one subscription is associated with a SUBSCRIBE. This decision does not
     necessarily represent group consensus, and further discussion may
     be warranted.

9. Changes

9.1. single dialog.

     - Syncronized SUBSCRIBE "Expires" handling with REGISTER
       (again)

     - Added definitions section.

     - Restructuring for clarity.

     - Added statement explicitly allowing event
       packages to define additional parameters
       for the "Event" header.

     - Added motivational text in several places.

     - Synced up header table modifications with bis draft.

8.2. Changes from draft-ietf-...-00

     - Fixed confusing typo in section describing correlation
       of SUBSCRIBE requests

     - Added explanitory text to clarify tag handling when
       generating re-subscriptions

     - Expanded general handling section to include specific
       discussion of Route/Record-Route handling.

     - Included use of "methods" parameter on Contact as
       a means for detecting support for SUBSCRIBE and NOTIFY.

     - Added definition of term "dialog"; changed "leg" to
       "dialog" everwhere.

     - Added syntax for "Subscription-Expires" header.

     - Changed NOTIFY messages to refer to "Subscription-Expires"
       everywhere (instead of "Expires.")

     - Added information about generation and handling of
       481 responses to SUBSCRIBE requests

     - Changed having Expires header in SUBSCRIBE from
       MUST to SHOULD; this aligns more closely with
       REGISTER behavior

     - Removed experimental/private event package names,
       per list consensus
     - Cleaned up some legacy text left over from very early
       drafts that allowed multiple contacts per subscription

     - Strengthened language requiring the removal of subscriptions
       if a NOTIFY request fails with a 481. Clarified that such
       removal is required for all subscriptions, including
       administrative ones.

     - Removed description of delaying NOTIFY requests until
       authorization is granted. Such behavior was inconsistent
       with other parts of this document.

     - Moved description of event packages to later in document,
       to reduce the number of forward references.

     - Minor editorial and nits changes

     - Added new open issues to open issues section. All
       previous open issues have been resolved.

9.2.

8.3. Changes from draft-roach-...-03

     - Added DOS attacks section to open issues.

     - Added discussion of forking to open issues

     - Changed response to PINT request for notifiers who don't
       support PINT from 400 to 489.

     - Added sentence to security section to call attention to
       potential privacy issues of delayed NOTIFY responses.

     - Added clarification: access control list handling is out
       of scope.

     - (Hopefully) Final resolution on out-of-band subscriptions:
       mentioned in section
     4.3.
     4.2.

     Removed from open issues.

     - Made "Contact" header optional for SUBSCRIBE 1xx responses.

     - Added description clarifying tag handling (section
     4.2.1.
     4.3.4.
     )

     - Removed event throttling from open issues.

     - Editorial cleanup to remove term "extension draft" and
       similar; "event package" is now (hopefully) used consistently
       throughout the document.

     - Remove discussion of event agents from open issues.
       This is covered in the event packages section now.

     - Added discussion of forking to open issues.

     - Added discussion of sub-packages

     - Added clarification that, upon receiving a "NOTIFY"
       with an expires of "0", the subscriber can re-subscribe.
       This allows trivial migration of subscriptions between
       nodes.

     - Added preliminary IANA Considerations section

     - Changed syntax for experimental event tokens to avoid
       possibly ambiguity between experimental tokens and
       sub-packages.

     - Slight adjustment to "Event" syntax to accommodate sub-packages.

     - Added section describing the information which is to be
       included in documents describing event packages.

     - Made 481 responses mandatory for unexpected notifications
       (allowing notifiers to remove subscriptions in error cases)

     - Several minor non-semantic editorial changes.

9.3.

8.4. Changes from draft-roach-...-02

     - Clarification under "Notifier SUBSCRIBE behavior" which
       indicates that the first NOTIFY message (sent immediately
       in response to a SUBSCRIBE) may contain an empty body, if
       resource state doesn't make sense at that point in time.

     - Text on message flow in overview section corrected

     - Removed suggestion that clients attempt to unsubscribe
       whenever they receive a NOTIFY for an unknown event.
       Such behavior opens up DOS attacks, and will lead to
       message loops unless additional precautions are taken.
       The 481 response to the NOTIFY should serve the same
       purpose.

     - Changed processing of non-200 responses to NOTIFY from
       "SHOULD remove contact" to "MUST remove contact" to support
       the above change.

     - Re-added discussion of out-of-band subscription mechanisms
       (including open issue of resource identification).

     - Added text specifying that SUBSCRIBE transactions are not
       to be prolonged. This is based on the consensus that non-INVITE
       transactions should never be prolonged; such consensus within
       the SIP working group was reached at the 49th IETF.

     - Added "202 Accepted" response code to support the above
       change. The behavior of this 202 response code is a
       generalization of that described in the presence draft.

     - Updated to specify that the response to an unauthorized
       SUBSCRIBE request is 603 or 403.

     - Level-4 subheadings added to particularly long sections to
       break them up into logical units. This helps make the
       behavior description seem somewhat less rambling. This also
       caused some re-ordering of these paragraphs (hopefully in a
       way that makes them more readable).

     - Some final mopping up of old text describing "call related"
       and "third party" subscriptions (deprecated concepts).

     - Duplicate explanation of subscription duration removed from
       subscriber SUBSCRIBE behavior section.

     - Other text generally applicable to SUBSCRIBE (instead of just
       subscriber handling of SUBSCRIBE) moved to parent section.

     - Updated header table to reflect mandatory usage of "Expires"
       header in SUBSCRIBE requests and responses

     - Removed "Event" header usage in responses

     - Added sentence suggesting that notifiers may notify
       subscribers when a subscription has timed out.

     - Clarified that a failed attempt to refresh a subscription
       does not imply that the original subscription has been
       cancelled.

     - Clarified that 489 is a valid response to "NOTIFY" requests.

     - Minor editorial changes to clean up awkward and/or unclear
       grammar in several places

9.4.

8.5. Changes from draft-roach-...-01

     - Multiple contacts per SUBSCRIBE message disallowed.

     - Contact header now required in NOTIFY messages.

     - Distinction between third party/call member events removed.

     - Distinction between call-related/resource-related events removed.

     - Clarified that subscribers must expect NOTIFY messages before
       the SUBSCRIBE transaction completes

     - Added immediate NOTIFY message after successful SUBSCRIBE;
       this solves a myriad of issues, most having to do with forking.

     - Added discussion of "undefined state" (before a NOTIFY arrives).

     - Added mechanism for notifiers to shorten/cancel outstanding
       subscriptions.

     - Removed open issue about appropriateness of new "489" response.

     - Removed all discussion of out-of-band subscriptions.

     - Added brief discussion of event state polling.

10.

9. References

     [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, J. Rosenberg et. al., "SIP: Session Initiation Protocol", RFC 2543,
         <draft-ietf-sip-rfc2543bis-07>, IETF; March 1999. February 2002. Work in
         progress.

     [2] J. Rosenberg, H. Schulzrinne, "Guidelines for Authors of SIP
         Extensions", <draft-ietf-sip-guidelines-02.txt>, <draft-ietf-sip-guidelines-03.txt>, IETF; March
         November 2001. Work in progress.

     [3] S. Petrack, L. Conroy, "The PINT Service Protocol", RFC 2848,
         IETF; June 2000.

     [4] J. Rosenberg et. al., "SIP Extensions for Presence",
         <draft-ietf-simple-presence-03.txt>, IETF; September 2001.
         Work in progress.

     [5] R. Fielding et. al., "Hypertext Transfer Protocol --
         HTTP/1.1", RFC2068, IETF, January 1997.

     [6]

     [5] J. Postel, J. Reynolds, "Instructions to RFC Authors",
         RFC2223, IETF, October 1997.

     [7]

     [6] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, IETF, October 1998.

     [8]

     [7] Schulzrinne/Rosenberg, "SIP Caller Preferences and Callee
         Capabilities", <draft-ietf-sip-callerprefs-04.txt>, <draft-ietf-sip-callerprefs-05.txt>, IETF;
         June
         November 2001. Work in progress.

11.

10. Acknowledgements

     Thanks to the participants in the Events BOF at the 48th IETF
     meeting in Pittsburgh, as well as those who gave ideas and
     suggestions on the SIP Events mailing list. In particular, I wish
     to thank Henning Schulzrinne of Columbia University for coming up
     with the final three-tiered event identification scheme, Sean
     Olson of Ericsson for miscellaneous guidance, Jonathan Rosenberg for a
     thorough scrubbing of the -00 draft, and the authors of the "SIP
     Extensions for Presence" draft for their input to SUBSCRIBE and
     NOTIFY request semantics.

12.

11. Author's Address

     Adam Roach
     Ericsson Inc.
     Mailstop L-04
     740 E. Campbell Rd.
     Richardson,
     dynamicsoft
     5100 Tennyson Parkway
     Suite 1200
     Plano, TX 75081 75024
     USA
     Phone: +1 972 583 7594
     Fax: +1 972 669 0154
     E-Mail: adam.roach@ericsson.com <adam@dynamicsoft.com>
     Voice: <sip:adam@dynamicsoft.com>