[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 3857

Internet Engineering Task Force                                SIMPLE WG
Internet Draft                                              J. Rosenberg
                                                             dynamicsoft
draft-ietf-simple-winfo-package-01.txt
March 1, 2002
Expires: September 2002


          A SIP Event Template-Package for Watcher Information

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

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

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


Abstract

   This document defines the watcher information template-package for
   the SIP event framework. Watcher information refers to the set of
   users subscribed to a particular resource within a particular event
   package. Watcher information changes dynamically as users subscribe,
   unsubscribe, are approved, or are rejected. A user can subscribe to
   this information, and therefore learn about changes to it. This event
   package is a template-package because it can be applied to any event
   package, including itself.









J. Rosenberg                                                  [Page 1]

Internet Draft               winfo-package                 March 1, 2002






                           Table of Contents



   1          Introduction ........................................    3
   2          Terminology .........................................    3
   3          Usage Scenarios .....................................    4
   3.1        Presence Authorization ..............................    4
   3.2        Blacklist Alerts ....................................    5
   4          Package Definition ..................................    5
   4.1        Event Package Name ..................................    5
   4.2        Event Package Parameters ............................    6
   4.3        SUBSCRIBE Bodies ....................................    6
   4.4        Subscription Duration ...............................    6
   4.5        NOTIFY Bodies .......................................    7
   4.6        Notifier Processing of SUBSCRIBE Requests ...........    7
   4.7        Notifier Generation of NOTIFY Requests ..............    8
   4.7.1      The Subscription State Machine ......................    8
   4.7.2      Applying the state machine ..........................   11
   4.8        Subscriber Processing of NOTIFY Requests ............   12
   4.9        Handling of Forked Requests .........................   12
   4.10       Rate of Notifications ...............................   13
   4.11       State Agents ........................................   13
   5          Example Usage .......................................   13
   6          Security Considerations .............................   16
   7          IANA Considerations .................................   16
   8          Authors Addresses ...................................   16
   9          Normative References ................................   16
   10         Informative References ..............................   17



















J. Rosenberg                                                  [Page 2]

Internet Draft               winfo-package                 March 1, 2002


1 Introduction

   The SIP event framework is described in [1]. It defines a generic
   framework for subscription to, and notification of, events related to
   SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY,
   and introduces the notion of a package. A package is a concrete
   application of the event framework to a particular class of events.
   Packages have been defined for user presence [5], for example.

   This draft defines a "template-package" within the SIP events
   framework. A template-package has all the properties of a regular SIP
   event package. However, it is always associated with some other event
   package, and can always be applied to any event package, including
   the sub-package itself.

   The template-package defined here is for watcher information, and is
   denoted with the token "winfo". For any event package, such as
   presence, there is a set of users who are subscribed to a particular
   resource within that package. This set of users changes over time as
   new subscriptions come, old subscriptions expire, and subscriptions
   are approved or rejected. The set of users subscribed to a particular
   resource for a specific event package, and the state of their
   subscriptions, is referred to as watcher information. Since this
   state is itself dynamic, it is reasonable to subscribe to it in order
   to learn about changes to it. The watcher information event
   template-package is meant to facilitate exactly that - tracking the
   state of subscriptions to a resource in another package.

   To denote this template-package, the name is constructed by appending
   ".winfo" to the name of whatever package is being tracked. For
   example, the set of people subscribed to presence is defined by the
   "presence.winfo" package.

2 Terminology

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

   This document fundamentally deals with recursion - subscriptions to
   subscriptions. Therefore, the term "subscription" itself can be
   confusing in this document. To reduce confusion, the term
   "watcherinfo subscription" refers to a subscription to watcher
   information, and the term "watcherinfo subscriber" refers to a user
   that has subscribed to watcher information. The term "watcherinfo
   notification" refers to a NOTIFY request sent as part of a
   watcherinfo subscription. When the terms "subscription",



J. Rosenberg                                                  [Page 3]

Internet Draft               winfo-package                 March 1, 2002


   "subscriber", and "notification" are used unqualified, they refer to
   the "inner" subscribers, subscriptions, and notifications. We also
   use the term "watcher" to refer to a subscriber to the "inner"
   resource.

3 Usage Scenarios

   There are many useful applications for the watcher information
   template-package.

3.1 Presence Authorization

   The motivating application for this package is presence
   authorization. When user A subscribes to the presence of user B, the
   subscription needs to be authorized. Frequently, that authorization
   needs to occur through direct user intervention. For that to happen,
   B's software needs to become aware that a presence subscription has
   been requested. This is supported through watcher information. B's
   client software would SUBSCRIBE to the watcher information for the
   presence of B:


   SUBSCRIBE sip:B@foo.com SIP/2.0
   Via: SIP/2.0/UDP pc34.foo.com;branch=z9hG4bKnashds7
   From: sip:B@foo.com;tag=123s8a
   To: sip:B@foo.com
   Call-ID: 9987@pc34.foo.com
   Max-Forwards: 70
   CSeq: 9887 SUBSCRIBE
   Contact: sip:B@pc34.foo.com
   Event: presence.winfo



   The policy of the server is such that it allows B to subscribe to its
   own watcher information. So, when A subscribes to B's presence, B
   gets a notification of the change in watcher information state:


   NOTIFY sip:B@pc34.foo.com SIP/2.0
   Via: SIP/2.0/UDP pc34.foo.com;branch=z9hG4bKna66g
   From: sip:B@foo.com;tag=xyz887
   To: sip:B@foo.com;tag=123s8a
   Call-ID: 9987@pc34.foo.com
   CSeq: 1288 NOTIFY
   Contact: sip:B@server.foo.com
   Event: presence.winfo
   Content-Type: application/watcherinfo+xml



J. Rosenberg                                                  [Page 4]

Internet Draft               winfo-package                 March 1, 2002


   Content-Length: ...

   <watcherinfo>
     <resource uri="sip:B@foo.com" package="presence">
       <watcher uri="sip:A@foo.com" id="7768a77s" version="0"
                status="pending"/>
     </resource>
   </watcherinfo>



   This indicates to B that A has subscribed, and that the subscription
   is pending (meaning, it is awaiting authorization). B's software can
   alert B that this subscription is awaiting authorization. B can then
   go to a web page and set policy for that subscriber.

3.2 Blacklist Alerts

   Applications can subscribe to watcher information in order to provide
   value-added features. An example application is "blacklist alerts".
   In this scenario, an application server maintains a list of known
   "bad guys". A user, Joe, signs up for service with the application
   provider, presumably by going to a web page and entering in his
   presence URI. The application server subscribes to the watcher
   information for Joe's presence. When someone attempts to SUBSCRIBE to
   Joe's user presence, the application learns of this subscription as a
   result of its watcher info subscription. It checks the watcher's URI
   against the database of known bad guys. If there is a match, it sends
   email to Joe letting him know about this.

   For this application to work, Joe needs to make sure that the
   application is allowed to subscribe to his presence.winfo.

4 Package Definition

   This section fills in the details needed to specify an event package
   as defined in Section 5.4 of [1].

4.1 Event Package Name

   The SIP Events specification requires package definitions to specify
   the name of their package or template-package.

   The name of this template-package is "winfo". It can be applied to
   any other package. Watcher information for any package foo is denoted
   by the name "foo.winfo". Recursive template-packaging is explicitly
   allowed (and useful), so that "foo.winfo.winfo" is a valid package
   name.



J. Rosenberg                                                  [Page 5]

Internet Draft               winfo-package                 March 1, 2002


4.2 Event Package Parameters

   The SIP Events specification requires package and template-package
   definitions to specify any package specific parameters of the Event
   header that are used by it.

   No package specific Event header parameters are defined for this
   event template-package.

4.3 SUBSCRIBE Bodies

   The SIP Events specification requires package or template-package
   definitions to define the usage, if any, of bodies in SUBSCRIBE
   requests.

   A SUBSCRIBE for watcher information MAY contain a body. This body
   would serve the purpose of filtering the watcherinfo subscription.
   For example, in the case of presence, the body might indicate that
   notifications should contain full state every time something changes,
   and that the time the subscription was first made should not be
   included in the watcherinfo notifications.

   A SUBSCRIBE for a watcher information package MAY be sent without a
   body. This implies the default watcherinfo subscription filtering
   policy. The default policy is:

        o Watcherinfo notifications are generated every time there is
          any change in the state of the watcher information.

        o Watcherinfo notifications do not normally contain full state;
          rather, they only indicate the watcher whose state has
          changed. Full state (the list of all watchers that the
          watcherinfo subscriber is permitted to know about) is sent in
          the NOTIFY triggered from a SUBSCRIBE.

4.4 Subscription Duration

   The SIP Events specification requires package definitions to define a
   default value for subscription durations, and to discuss reasonable
   choices for durations when they are explicitly specified.

   Watcher information changes as users subscribe to a particular a
   resource for some package, or their subscriptions time out. As a
   result, the state of watcher information can change very dynamically,
   depending on the number of subscribers for a particular resource in a
   given package. The rate at which subscriptions time out depends on
   how long a user maintains its subscription.




J. Rosenberg                                                  [Page 6]

Internet Draft               winfo-package                 March 1, 2002


   As a result of these factors, it is difficult to define a broadly
   useful default value for the lifetime of a watcherinfo subscription.
   We arbitrarily choose one hour. However, clients SHOULD include in
   Expires header specifying their preferred duration.

4.5 NOTIFY Bodies

   The SIP Events specification requires package definitions to describe
   the allowed set of body types in NOTIFY requests, and to specify the
   default value to be used when there is no Accept header in the
   SUBSCRIBE request.

   The body of the watcherinfo notification contains a watcher
   information document. This document describes some or all of the
   watchers for a given package, and the state of their subscriptions.
   All watcherinfo subscribers MUST support the
   application/watcherinfo+xml format described in [3], and MUST list
   its MIME type, application/watcherinfo+xml, in any Accept header
   present in the SUBSCRIBE request. The default value of the Accept
   header, when not present, is application/watcherinfo+xml.

   Other watcher information formats might be defined in the future. In
   that case, the watcherinfo subscriptions MAY indicate support for
   other formats. However, they MUST always support and list
   application/watcherinfo+xml as an allowed format.

   Of course, the watcherinfo notifications generated by the server MUST
   be in one of the formats specified in the Accept header in the
   SUBSCRIBE request.

4.6 Notifier Processing of SUBSCRIBE Requests

   The SIP Events framework specifies that packages should define any
   package-specific processing of SUBSCRIBE requests at a notifier,
   specifically with regards to authentication and authorization.

   The watcher information for a particular package contains sensitive
   information. Therefore, all watcherinfo subscriptions SHOULD be
   authenticated and then authorized before approval. Authentication MAY
   be performed using any of the techniques available through SIP,
   including digest, S/MIME, TLS or other transport specific mechanisms
   [4]. Authorization policy is at the discretion of the administrator,
   as always. However, a few recommendations can be made.

   It is RECOMMENDED that watcherinfo subscriptions for some package foo
   for user A be allowed from user A themselves. That is, it is
   RECOMMENDED that a user be allowed to subscribe to their own watcher
   information. This is true recursively, so that it is RECOMMENDED that



J. Rosenberg                                                  [Page 7]

Internet Draft               winfo-package                 March 1, 2002


   a user be able to subscribe to the watcher information for their
   watcher information for any package.

   It is RECOMMENDED that watcherinfo subscriptions for some package foo
   for user A be allowed from some other user B, if B is an authorized
   subscriber to A within the package foo. However, it is RECOMMENDED
   that the watcherinfo notifications sent to B only contain the state
   of B's own subscription. In other words, it is RECOMMENDED that a
   user be allowed to monitor the state of their own subscription.

   To avoid infinite recursion of authorization policy, it is
   RECOMMENDED that only user A be allowed to subscribe to
   foo.winfo.winfo for user A, for any foo (such a subscription from A
   is actually needed to approve the blacklisting application). It is
   also RECOMMENDED that by default, a server does not authorize any
   subscriptions to foo.winfo.winfo.winfo or any other deeper
   recursions.

4.7 Notifier Generation of NOTIFY Requests

   The SIP Event framework requests that packages specify the conditions
   under which notifications are sent for that package, and how such
   notifications are constructed.

   Watcherinfo notifications MAY be generated for watcher information on
   package foo, when the subscription state for a user on package foo
   changes. The watcher information package therefore needs a model of
   subscription state. This is accomplished by specifying a subscription
   state machine, described below, which governs the subscription state
   of a user in any package. Watcherinfo notifications MAY be generated
   on transitions in this state machine. Its important to note that this
   FSM is just a model of the subscription state machinery maintained by
   a server. An implementation would map its own state machines to this
   one in an implementation-specific manner.

4.7.1 The Subscription State Machine

   The underlying state machine for a subscription is shown in Figure 1.
   It derives almost entirely from the descriptions in the SIP Events
   framework [1], but adds the notion of a waiting state.

   Initially, there is no state allocated for a subscription (the init
   state). When a SUBSCRIBE request arrives, the subscription FSM is
   created. The next state depends on whether policy exists for the
   subscription. If there is an existing policy that determines that the
   subscription is forbidden, it moves into the terminated state
   immediately, where the FSM can be destroyed. If there is existing
   policy that determines that the subscription is authorized, the FSM



J. Rosenberg                                                  [Page 8]

Internet Draft               winfo-package                 March 1, 2002


   moves into the active state. This state indicates that the subscriber
   will receive notifications.






       subscribe,
       policy=       +----------+
       reject        |          |<------------------------+
       +------------>|terminated|<---------+              |
       |             |          |          |              |
       |             |          |          |noresource    |
       |             +----------+          |rejected      |
       |                  ^noresource      |deactivated   |
       |                  |rejected        |probation     |
       |                  |deactivated     |timeout       |noresource
       |                  |probation       |              |rejected
       |                  |giveup          |              |deactivated
       |                  |                |              |probation
    +-------+         +-------+        +-------+          |giveup
    |       |subscribe|       |approved|       |          |approved
    | init  |-------->|pending|------->|active |          |
    |       |no policy|       |        |       |          |
    |       |         |       |        |       |          |
    +-------+         +-------+        +-------+          |
       |                  | ^              ^              |
       | subscribe,       | |              |              |
       +-----------------------------------+              |
         policy = accept  | |          +-------+          |
                          | |subscribe |       |          |
                          | +----------|waiting|----------+
                          +----------->|       |
                           timeout     |       |
                                       +-------+




   Figure 1: Subscription State Machine



   If, when a subscription arrives, there is no authorization policy in
   existence, the subscription moves into the pending state. In this
   state, the server is awaiting an authorization decision. No
   notifications are generated, but the subscription FSM is maintained.
   If the authorization decision comes back positive, the subscription



J. Rosenberg                                                  [Page 9]

Internet Draft               winfo-package                 March 1, 2002


   is approved, and moves into the active state. If the authorization is
   negative, the subscription is rejected, and the FSM goes into the
   terminated state. It is possible that the authorization decision can
   take a very long time. In fact, no authorization decision may arrive
   until after the subscription itself expires. If a pending
   subscription suffers a timeout, it moves into the waiting state. At
   any time, the server can decide to end a pending or waiting
   subscription because it is concerned about allocating memory and CPU
   resources to unauthorized subscription state. If this happens, a
   "giveup" event is generated by the server, moving the subscription to
   terminated.

   The waiting state is similar to pending, in that no notifications are
   generated. However, if the subscription is approved or denied, the
   FSM is destroyed. The purpose of the waiting state is so that a user
   can fetch watcherinfo state at any time, and learn of any
   subscriptions that arrived previously (and which may arrive again)
   which require an authorization decision. Consider an example. A
   subscribes to B. B has not defined policy about this subscription, so
   it moves into the pending state. B is not "online", so that B's
   software agent cannot be contacted to approve the subscription. The
   subscription expires. Lets say it were destroyed. B logs in, and
   fetches its watcherinfo state. There is no record of the subscription
   from A, so no policy decision is made about subscriptions from A. B
   logs off. A refreshes its subscription. Once more, the subscription
   is pending since no policy is defined for it. This process could
   continue indefinitely. The waiting state ensures that B can find out
   about this subscription attempt.

   The waiting state is also needed to allow for authorization of fetch
   attempts, which are subscriptions that expire immediately.

   Of course, policy may never be specified for the subscription. As a
   result, the server can generate a giveup event to move the waiting
   subscription to the terminated state. The amount of time to wait
   before issuing a giveup event is system dependent. If, while in the
   waiting state, the subscription is refreshed through another
   SUBSCRIBE, it moves back into the pending state.

   The giveup event is generated in either the waiting or pending states
   to destroy resources associated with unauthorized subscriptions.
   Servers need to exercise care in selecting this value. It needs to be
   large in order to provide a useful user experience; a user should be
   able to log in days later and see that someone tried to subscribe to
   them. However, allocating state to unauthorized subscriptions can be
   used as a source of DoS attacks. Therefore, it is RECOMMENDED that
   servers which retain state for unauthorized subscriptions add
   policies which prohibit a particular subscriber from having more than



J. Rosenberg                                                 [Page 10]

Internet Draft               winfo-package                 March 1, 2002


   some number of pending or waiting subscriptions.

   At any time, the server can deactivate a subscription. Deactivation
   implies that the subscription is discarded without a change in
   authorization policy. This may be done in order to trigger refreshes
   of subscriptions for a graceful shutdown or subscription migration
   operation. A related event is probation, where a subscription is
   terminated, and the subscriber is requested to wait some amount of
   time before trying again. The meaning of these events is described in
   more detail in [1].

   A subscription can be terminated at any time because the resource
   associated with that subscription no longer exists. This corresponds
   to the noresource event.

4.7.2 Applying the state machine

   The server MAY generate a notification to watcherinfo subscribers on
   a transition of the state machine. Whether it does or does not is
   policy dependent. However, several guidelines are defined.

   Consider some event package foo. A subscribes to B for events within
   that package. A also subscribes to foo.winfo for B. In this scenario
   (where the subscriber to foo.winfo is also a subscriber to foo for
   the same resource), it is RECOMMENDED that A receive watcherinfo
   notifications only about the changes in its own subscription.
   Furthermore, it is RECOMMENDED that state machine transitions be
   reported only if A's subscription to B for package foo was approved.
   That is, the first watcherinfo notification that A should ever
   receive for foo.winfo is its transition to approved. If A's
   subscription to B for foo is later rejected, it is RECOMMENDED that,
   in the absence of explicit opt in policies saying otherwise, A not
   receive watcherinfo notifications of this, or any other changes. All
   of these guidelines are to protect the privacy of B; specifically, so
   that A cannot know about rejections of its subscriptions to B for
   some particular package unless explicitly permitted by B.

   As a general rule, when a watcherinfo subscriber is authorized to
   receive watcherinfo notifications about more than one watcher, it is
   RECOMMENDED that watcherinfo notifications contain information about
   those watchers which have changed state (and thus triggered a
   notification), instead of delivering the current state of every
   watcher in every watcherinfo notification. However, watcherinfo
   notifications triggered as a result of a fetch operation (a SUBSCRIBE
   with Expires of 0) SHOULD result in the full state of all watchers
   (of course, only those watchers that have been authorized to be
   divulged to the watcherinfo subscriber) to be present in the NOTIFY.




J. Rosenberg                                                 [Page 11]

Internet Draft               winfo-package                 March 1, 2002


   The notifier MUST maintain, for each subscription created by a
   watcher, a unique identifier. That identifier MUST be globally unique
   in space and time. Specifically, it MUST differ from any other
   identifier for any other subscription to any other resource at that
   server, or on any other server. For each subscription, the notifier
   MUST also maintain a version number. This version number MUST start
   at zero when the subscription is created, and MUST increment by one
   for each change in state of the subscription. The version number and
   identifier MUST be included in the watcherinfo notifications; both
   are parameters of the watcher element defined in [3].

4.8 Subscriber Processing of NOTIFY Requests

   The SIP Events framework expects packages to specify how a subscriber
   processes NOTIFY requests in any package specific ways, and in
   particular, how it uses the NOTIFY requests to contruct a coherent
   view of the state of the subscribed resource.

   Typically, the NOTIFY for watcherinfo will only contain information
   about those watchers whose state has changed. To construct a coherent
   view of the total state of all watchers, a watcherinfo subscriber
   will need to combine NOTIFYs received over time. The watcherinfo
   subscriber maintains is complete watcher list in a table, indexed by
   subscription ID. This subscription ID is unique for each subscription
   to the watched resource. It is conveyed in the id attribute of the
   watcher element of the application/watcherinfo+xml type [3].  If the
   watcher information in a NOTIFY has a watcher listed with a
   subscription ID not in the table, an entry is added to that table.
   The version number from the watcher element is also extracted, and
   placed in the table. If the watcher information in a NOTIFY has a
   watcher listed with a subscription ID in the table, and the version
   in the NOTIFY is greater than the version stored in the table, the
   watcher information in the table for that watcher is updated,
   including the version number. If a subscription is updated such that
   its state is now terminated, that entry MAY be removed from the table
   at any time.

4.9 Handling of Forked Requests

   The SIP Events framework mandates that packages indicate whether or
   not forked SUBSCRIBE requests can install multiple subscriptions.

   When a user wishes to obtain watcher information about their own
   subscription to some resource B for some package foo, it is important
   that the watcherinfo subscription be handled by the same server
   handling the users subscription to B for package foo. It is
   RECOMMENDED that a watcherinfo subscription be made on the same
   dialog as the subscription to B for package foo. As described in [1],



J. Rosenberg                                                 [Page 12]

Internet Draft               winfo-package                 March 1, 2002


   this will require the usage of a different subscription ID in the
   Event header. In this case, there will be no forking of the
   SUBSCRIBE, and as a result, installation of only a single watcherinfo
   subscription.

   When a user wishes to obtain watcher information about all watchers
   for some resource for package foo, the SUBSCRIBE to the watcher
   information will need to reach a collection of servers that have,
   unioned together, complete information about all watchers on that
   resource for package foo. If there are a multiplicity of servers
   handling subscriptions for that resource for package foo (for load
   balancing reasons, typically), it is very likely that no single
   server will have the complete set of watcher information. There are
   two solutions in this case. First, the network can be designed so
   that a SUBSCRIBE for watcher information forks, and is delivered to
   all servers which maintain subscriptions for that user for that
   package. The second approach is to design a network with a central
   server that is aware of all watcher information, even if the
   subscriptions are handled by a different set of servers. To ensure
   that a provider can implement either model, watcherinfo subscribers
   MUST be prepared to install multiple subscriptions as a result of a
   multiplicity of NOTIFY messages in response to a single SUBSCRIBE.

4.10 Rate of Notifications

   The SIP Events framework mandates that packages define a maximum rate
   of notifications for their package.

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive. As a result, it is RECOMMENDED
   that the server not generate watcherinfo notifications for a single
   watcherinfo subscriber at a rate faster than once every 5 seconds.

4.11 State Agents

   The SIP Events framework asks packages to consider the role of state
   agents in their design.

   State agents are permitted for this package. However, their benefit
   is not clear. Typically, the server(s) that are best suited to
   handled subscriptions for watcher information are those servers that
   are handling the subscriptions to the resource being watched.

5 Example Usage

   The following section discusses an example application and call flows
   using the watcherinfo package.




J. Rosenberg                                                 [Page 13]

Internet Draft               winfo-package                 March 1, 2002


   In this example, a user Joe, sip:joe@bar.com provides presence
   through the bar.com presence server. Joe subscribes to his own
   watcher information, in order to learn about people who subscribe to
   his presence, in order to approve them. Joe sends the following
   SUBSCRIBE request:


   SUBSCRIBE sip:joe@bar.com SIP/2.0
   Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnashds7
   From: sip:joe@bar.com;tag=123aa9
   To: sip:joe@bar.com
   Call-ID: 9987@pc34.bar.com
   CSeq: 9887 SUBSCRIBE
   Contact: sip:joe@pc34.bar.com
   Event: presence.winfo
   Max-Forwards: 70



   The server responds with a 401 to authenticate, and Joe resubmits the
   SUBSCRIBE with credentials (message not shown). The server then
   authorizes the subscription, since it allows Joe to subscribe to his
   own watcher information for presence. It responds with a 200 OK:


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnashds8
     ;received=1.2.3.4
   From: sip:joe@bar.com;tag=123aa9
   To: sip:joe@bar.com;tag=xyzygg
   Call-ID: 9987@pc34.bar.com
   CSeq: 9988 SUBSCRIBE
   Contact: sip:server19.bar.com
   Expires: 3600
   Event: presence.winfo



   The server then sends a NOTIFY with the current state of
   presence.winfo for joe@bar.com:


   NOTIFY sip:joe@pc34.bar.com SIP/2.0
   Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaii
   From: sip:joe@bar.com;tag=xyzygg
   To: sip:joe@bar.com;tag=123aa9
   Call-ID: 9987@pc34.bar.com
   CSeq: 1288 NOTIFY



J. Rosenberg                                                 [Page 14]

Internet Draft               winfo-package                 March 1, 2002


   Contact: sip:server19.bar.com
   Event: presence.winfo
   Max-Forwards: 70
   Content-Type: application/watcherinfo+xml
   Content-Length: ...

   <watcherinfo>
     <resource uri="sip:joe@bar.com" package="presence">
       <watcher uri="sip:A@foo.com" id="77ajsyy76" version="0"
                status="pending"/>
     </resource>
   </watcherinfo>



   B then responds with a 200 OK to the NOTIFY:


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaii
     ;received=1.2.3.8
   From: sip:joe@bar.com;tag=xyzygg
   To: sip:joe@bar.com;tag=123aa9
   Call-ID: 9987@pc34.bar.com
   CSeq: 1288 NOTIFY



   The NOTIFY tells B that A currently has a pending subscription. B
   goes to a web page, and enters form data which tells the server to
   allow A's subscription. This causes a change in the status of the
   subscription (which moves from pending to active), and the delivery
   of another notification:


   NOTIFY sip:joe@pc34.bar.com SIP/2.0
   Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij
   From: sip:joe@bar.com;tag=xyzygg
   To: sip:joe@bar.com;tag=123aa9
   Call-ID: 9987@pc34.bar.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.bar.com
   Event: presence.winfo
   Max-Forwards: 70
   Content-Type: application/watcherinfo+xml
   Content-Length: ...

   <watcherinfo>



J. Rosenberg                                                 [Page 15]

Internet Draft               winfo-package                 March 1, 2002


     <resource uri="sip:joe@bar.com" package="presence">
       <watcher uri="sip:A@foo.com" id="77ajsyy76" version="1"
                status="active" event="approved" />
     </resource>
   </watcherinfo>



   B then responds with a 200 OK to the NOTIFY:


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij
     ;received=1.2.3.8
   From: sip:joe@bar.com;tag=xyzygg
   To: sip:joe@bar.com;tag=123aa9
   Call-ID: 9987@pc34.bar.com
   CSeq: 1289 NOTIFY



6 Security Considerations

   Watcher information is very sensitive information. As such,
   authentication and authorization of subscriptions to this package are
   critical, and are described in detail throughout this document.

7 IANA Considerations

   There are no IANA considerations associated with this specification.

8 Authors Addresses


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



9 Normative References

   [1] A. Roach et al.  , "SIP-specific event notification," Internet
   Draft, Internet Engineering Task Force, Feb. 2002.  Work in progress.




J. Rosenberg                                                 [Page 16]

Internet Draft               winfo-package                 March 1, 2002


   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [3] J. Rosenberg, "An XML based format for watcher information,"
   Internet Draft, Internet Engineering Task Force, July 2001.  Work in
   progress.

   [4] J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Feb.
   2002.  Work in progress.

10 Informative References

   [5] J. Rosenberg, "SIP extensions for presence," Internet Draft,
   Internet Engineering Task Force, Nov. 2001.  Work in progress.


   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.






J. Rosenberg                                                 [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/