rfc3857 a watcher information event template-package for.txt

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

Network Working Group                                       J. Rosenberg
Request for Comments: 3857                                   dynamicsoft
Category: Standards Track                                    August 2004


           A Watcher Information Event Template-Package for
                 the Session Initiation Protocol (SIP)

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document defines the watcher information template-package for
   the Session Initiation Protocol (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.




















Rosenberg                   Standards Track                     [Page 1]

RFC 3857                  Watcher Information                August 2004


Table of Contents

   1.   Introduction ........................................    2
   2.   Terminology .........................................    3
   3.   Usage Scenarios .....................................    3
        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 ......................    5
        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.........    9
              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 .......................................   14
   6.   Security Considerations .............................   17
        6.1.  Denial of Service Attacks .....................   17
        6.2.  Divulging Sensitive Information ...............   17
   7.   IANA Considerations .................................   18
   8.   Acknowledgements ....................................   18
   9.   Normative References ................................   18
   10.  Informative References ..............................   19
   11.  Author's Address ....................................   19
   12.  Full Copyright Statement ............................   20

1.  Introduction

   The Session Initiation Protocol (SIP) event framework is described in
   RFC 3265 [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 document defines a "template-package" within the SIP event
   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 template-package itself.




Rosenberg                   Standards Track                     [Page 2]

RFC 3857                  Watcher Information                August 2004


   The template-package defined here is for watcher information, and is
   denoted with the token "winfo".  For any event package, such as
   presence, there exists a set (perhaps an empty set) of subscriptions
   that have been created or requested by users trying to ascertain the
   state of a resource in that package.  This set of subscriptions
   changes over time as new subscriptions are requested by users, old
   subscriptions expire, and subscriptions are approved or rejected by
   the owners of that resource.  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 BCP14, 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",
   "subscriber", and "notification" are used unqualified, they refer to
   the "inner" subscriptions, subscribers and notifications - those that
   are being monitored through the watcherinfo subscriptions.  We also
   use the term "watcher" to refer to a subscriber to the "inner"
   resource.  Information on watchers is reported through watcherinfo
   subscriptions.

3.  Usage Scenarios

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





Rosenberg                   Standards Track                     [Page 3]

RFC 3857                  Watcher Information                August 2004


3.1.  Presence Authorization

   The motivating application for this template-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:[e-mail] SIP/2.0
   Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
   From: sip:[e-mail];tag=123s8a
   To: sip:[e-mail]
   Call-ID: [e-mail]
   Max-Forwards: 70
   CSeq: 9887 SUBSCRIBE
   Contact: sip:[e-mail]
   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:[e-mail] SIP/2.0
   Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g
   From: sip:[e-mail];tag=xyz887
   To: sip:[e-mail];tag=123s8a
   Call-ID: [e-mail]
   Max-Forwards: 70
   CSeq: 1288 NOTIFY
   Contact: sip:[e-mail]
   Event: presence.winfo
   Content-Type: application/watcherinfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
                version="0" state="full">
      <watcher-list resource="sip:[e-mail]" package="presence">
        <watcher id="7768a77s" event="subscribe"
                 status="pending">sip:[e-mail]</watcher>
      </watcher-list>
   </watcherinfo>






Rosenberg                   Standards Track                     [Page 4]

RFC 3857                  Watcher Information                August 2004


   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
   set policy for that subscription.

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 4.4 of RFC 3265 [1].

4.1.  Event Package Name

   RFC 3265 [1] 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.

4.2.  Event Package Parameters

   RFC 3265 [1] requires package and template-package definitions to
   specify any package specific parameters of the Event header field.

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






Rosenberg                   Standards Track                     [Page 5]