rfc3265.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,440 行 · 第 1/5 页

Network Working Group                                        A. B. Roach
Request for Comments: 3265                                   dynamicsoft
Updates: 2543                                                  June 2002
Category: Standards Track


     Session Initiation Protocol (SIP)-Specific Event Notification

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 (2002).  All Rights Reserved.

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.

Table of Contents

   1.       Introduction...........................................  3
   1.1.     Overview of Operation..................................  4
   1.2.     Documentation Conventions..............................  4
   2.       Definitions............................................  5
   3.       Node Behavior..........................................  6
   3.1.     Description of SUBSCRIBE Behavior......................  6
   3.1.1.   Subscription Duration..................................  6
   3.1.2.   Identification of Subscribed Events and Event Classes..  6
   3.1.3.   Additional SUBSCRIBE Header Values.....................  7
   3.1.4.   Subscriber SUBSCRIBE Behavior..........................  7
   3.1.5.   Proxy SUBSCRIBE Behavior...............................  9
   3.1.6.   Notifier SUBSCRIBE Behavior............................ 10



Roach                       Standards Track                     [Page 1]

RFC 3265            SIP-Specific Event Notification            June 2002


   3.2.     Description of NOTIFY Behavior......................... 13
   3.2.1.   Identification of Reported Events, Event Classes, and
            Current State.......................................... 13
   3.2.2.   Notifier NOTIFY Behavior............................... 14
   3.2.3.   Proxy NOTIFY Behavior.................................. 15
   3.2.4.   Subscriber NOTIFY Behavior............................. 16
   3.3.     General................................................ 18
   3.3.1.   Detecting support for SUBSCRIBE and NOTIFY............. 18
   3.3.2.   CANCEL requests........................................ 18
   3.3.3.   Forking................................................ 18
   3.3.4.   Dialog creation and termination........................ 18
   3.3.5.   State Agents and Notifier Migration.................... 19
   3.3.6.   Polling Resource State................................. 20
   3.3.7.   Allow-Events header usage.............................. 21
   3.3.8.   PINT Compatibility..................................... 21
   4.       Event Packages......................................... 21
   4.1.     Appropriateness of Usage............................... 21
   4.2.     Event Template-packages................................ 22
   4.3.     Amount of State to be Conveyed......................... 22
   4.3.1.   Complete State Information............................. 23
   4.3.2.   State Deltas........................................... 23
   4.4.     Event Package Responsibilities......................... 24
   4.4.1.   Event Package Name..................................... 24
   4.4.2.   Event Package Parameters............................... 24
   4.4.3.   SUBSCRIBE Bodies....................................... 24
   4.4.4.   Subscription Duration.................................. 25
   4.4.5.   NOTIFY Bodies.......................................... 25
   4.4.6.   Notifier processing of SUBSCRIBE requests.............. 25
   4.4.7.   Notifier generation of NOTIFY requests................. 25
   4.4.8.   Subscriber processing of NOTIFY requests............... 26
   4.4.9.   Handling of forked requests............................ 26
   4.4.10.  Rate of notifications.................................. 26
   4.4.11.  State Agents........................................... 27
   4.4.12.  Examples............................................... 27
   4.4.13.  Use of URIs to Retrieve State.......................... 27
   5.       Security Considerations................................ 28
   5.1.     Access Control......................................... 28
   5.2.     Notifier Privacy Mechanism............................. 28
   5.3.     Denial-of-Service attacks.............................. 28
   5.4.     Replay Attacks......................................... 29
   5.5.     Man-in-the middle attacks.............................. 29
   5.6.     Confidentiality........................................ 29
   6.       IANA Considerations.................................... 30
   6.1.     Registration Information............................... 30
   6.2.     Registration Template.................................. 31
   6.3.     Header Field Names..................................... 31
   6.4.     Response Codes......................................... 32
   7.       Syntax................................................. 32



Roach                       Standards Track                     [Page 2]

RFC 3265            SIP-Specific Event Notification            June 2002


   7.1.     New Methods............................................ 32
   7.1.1.   SUBSCRIBE method....................................... 34
   7.1.2.   NOTIFY method.......................................... 34
   7.2.     New Headers............................................ 34
   7.2.1.   "Event" header......................................... 34
   7.2.2.   "Allow-Events" Header.................................. 35
   7.2.3.   "Subscription-State" Header............................ 35
   7.3.     New Response Codes..................................... 35
   7.3.1.   "202 Accepted" Response Code........................... 35
   7.3.2.   "489 Bad Event" Response Code.......................... 35
   7.4.     Augmented BNF Definitions.............................. 35
   8.       Normative References................................... 36
   9.       Informative References................................. 37
   10.      Acknowledgements....................................... 37
   11.      Notice Regarding Intellectual Property Rights.......... 37
   12.      Author's Address....................................... 37
   13.      Full Copyright Statement............................... 38

1. Introduction

   The ability to request asynchronous notification of events proves
   useful in many types of SIP 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 PSTN and Internet
   Internetworking (PINT) [2] status (based on call state events).

   The methods described in this document provide 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 elaborate rules which govern the
   subscription and notification for the events or classes of events
   they describe.

   This document does not describe an extension which may be used
   directly; it must be extended by other documents (herein referred to
   as "event packages").  In object-oriented design terminology, it may





Roach                       Standards Track                     [Page 3]

RFC 3265            SIP-Specific Event Notification            June 2002


   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 4.

1.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------->|

   Subscriptions are expired and must be refreshed by subsequent
   SUBSCRIBE messages.

1.2. Documentation Conventions

   There are several paragraphs throughout this document which provide
   motivational or clarifying text.  Such passages are non-normative,
   and are provided only to assist with reader comprehension.  These
   passages are set off from the remainder of the text by being indented
   thus:

      This is an example of non-normative explanatory text.  It does not
      form part of the specification, and is used only for
      clarification.

   Numbers in square brackets (e.g., [1]) denote a reference to one of
   the entries in the reference sections; see sections 8 and 9.

   The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST
   NOT", and "RECOMMENDED" are used as defined in RFC 2119 [5].

   The use of quotation marks next to periods and commas follows the
   convention used by the American Mathematical Society; although
   contrary to traditional American English convention, this usage lends
   clarity to certain passages.





Roach                       Standards Track                     [Page 4]

RFC 3265            SIP-Specific Event Notification            June 2002


2. 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 and
      semantics based on the framework defined by this document required
      to convey such state information.

   Event Template-Package: An event template-package is a special kind
      of event package which defines a set of states 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 order to do so, it may
      need to gather such state information from multiple sources.
      State agents always have complete state information for the
      resource for which they are 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 which the subscriber is
      interested.  Subscribers typically also generate SUBSCRIBE
      requests and send them to notifiers to create subscriptions.

   Subscription: A subscription is a set of application state associated
      with a dialog.  This application state includes a pointer to the
      associated dialog, the 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 act of moving a
      subscription from one notifier to another notifier.









Roach                       Standards Track                     [Page 5]

RFC 3265            SIP-Specific Event Notification            June 2002


3. Node Behavior