--- 1/draft-ietf-sip-events-03.txt 2006-02-05 01:43:07.000000000 +0100
+++ 2/draft-ietf-sip-events-04.txt 2006-02-05 01:43:07.000000000 +0100
@@ -1,15 +1,15 @@
Internet Engineering Task Force Adam Roach
Internet Draft dynamicsoft
Category: Standards Track February 2002
Expires August 2002
-
+
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
@@ -44,117 +44,116 @@
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
2.2. Documentation Conventions.............................. 4
- 3. Definitions............................................ 5
+ 3. Definitions............................................ 4
4. Node Behavior.......................................... 5
4.1. Description of SUBSCRIBE Behavior...................... 5
4.1.1. Subscription Duration.................................. 6
4.1.2. Identification of Subscribed Events and Event Classes.. 6
4.1.3. Additional SUBSCRIBE Header Values..................... 7
4.1.4. Subscriber SUBSCRIBE Behavior.......................... 7
4.1.5. Proxy SUBSCRIBE Behavior............................... 9
4.1.6. Notifier SUBSCRIBE Behavior............................ 9
4.2. Description of NOTIFY Behavior......................... 12
- 4.2.1. Identification of Reported Events, Event Classes, and C 12
+ 4.2.1. Identification of Reported Events, Event Classes, and C 13
4.2.2. Notifier NOTIFY Behavior............................... 13
4.2.3. Proxy NOTIFY Behavior.................................. 15
4.2.4. Subscriber NOTIFY Behavior............................. 15
4.3. General................................................ 17
4.3.1. Detecting support for SUBSCRIBE and NOTIFY............. 17
- 4.3.2. CANCEL requests........................................ 17
- 4.3.3. Forking................................................ 17
- 4.3.4. Dialog creation and termination........................ 17
+ 4.3.2. CANCEL requests........................................ 18
+ 4.3.3. Forking................................................ 18
+ 4.3.4. Dialog creation and termination........................ 18
4.3.5. State Agents and Notifier Migration.................... 19
- 4.3.6. Polling Resource State................................. 19
+ 4.3.6. Polling Resource State................................. 20
4.3.7. Allow-Events header usage.............................. 20
- 4.3.8. PINT Compatibility..................................... 20
- 5. Event Packages......................................... 20
- 5.1. Appropriateness of Usage............................... 20
- 5.2. Event Template-packages................................ 21
- 5.3. Amount of State to be Conveyed......................... 21
+ 4.3.8. PINT Compatibility..................................... 21
+ 5. Event Packages......................................... 21
+ 5.1. Appropriateness of Usage............................... 21
+ 5.2. Event Template-packages................................ 22
+ 5.3. Amount of State to be Conveyed......................... 22
5.3.1. Complete State Information............................. 22
- 5.3.2. State Deltas........................................... 22
- 5.4. Event Package Responsibilities......................... 22
- 5.4.1. Event Package Name..................................... 23
- 5.4.2. Event Package Parameters............................... 23
- 5.4.3. SUBSCRIBE Bodies....................................... 23
- 5.4.4. Subscription Duration.................................. 23
+ 5.3.2. State Deltas........................................... 23
+ 5.4. Event Package Responsibilities......................... 23
+ 5.4.1. Event Package Name..................................... 24
+ 5.4.2. Event Package Parameters............................... 24
+ 5.4.3. SUBSCRIBE Bodies....................................... 24
+ 5.4.4. Subscription Duration.................................. 24
5.4.5. NOTIFY Bodies.......................................... 24
- 5.4.6. Notifier processing of SUBSCRIBE requests.............. 24
- 5.4.7. Notifier generation of NOTIFY requests................. 24
- 5.4.8. Subscriber processing of NOTIFY requests............... 24
- 5.4.9. Handling of forked requests............................ 24
- 5.4.10. Rate of notifications.................................. 25
- 5.4.11. State Agents........................................... 25
+ 5.4.6. Notifier processing of SUBSCRIBE requests.............. 25
+ 5.4.7. Notifier generation of NOTIFY requests................. 25
+ 5.4.8. Subscriber processing of NOTIFY requests............... 25
+ 5.4.9. Handling of forked requests............................ 25
+ 5.4.10. Rate of notifications.................................. 26
+ 5.4.11. State Agents........................................... 26
5.4.12. Examples............................................... 26
- 5.4.13. URI List handling...................................... 26
- 6. Security Considerations................................ 26
- 6.1. Access Control......................................... 26
- 6.2. Release of Sensitive Policy Information................ 26
+ 5.4.13. Use of URIs to Retrieve State.......................... 27
+ 6. Security Considerations................................ 27
+ 6.1. Access Control......................................... 27
+ 6.2. Notifier Privacy Mechanism............................. 27
6.3. Denial-of-Service attacks.............................. 27
- 6.4. Replay Attacks......................................... 27
- 6.5. Man-in-the middle attacks.............................. 27
+ 6.4. Replay Attacks......................................... 28
+ 6.5. Man-in-the middle attacks.............................. 28
6.6. Confidentiality........................................ 28
- 7. IANA Considerations.................................... 28
+ 7. IANA Considerations.................................... 29
7.1. Registration Information............................... 29
- 7.2. Registration Template.................................. 29
- 7.3. Syntax................................................. 30
- 7.4. New Methods............................................ 30
+ 7.2. Registration Template.................................. 30
+ 7.3. Syntax................................................. 31
+ 7.4. New Methods............................................ 31
7.4.1. SUBSCRIBE method....................................... 32
- 7.4.2. NOTIFY method.......................................... 32
- 7.5. New Headers............................................ 32
- 7.5.1. "Event" header......................................... 32
- 7.5.2. "Allow-Events" Header.................................. 33
- 7.5.3. "Subscription-State" Header............................ 33
- 7.6. New Response Codes..................................... 33
- 7.6.1. "202 Accepted" Response Code........................... 33
- 7.6.2. "489 Bad Event" Response Code.......................... 33
- 7.7. Augmented BNF Definitions.............................. 33
- 8. Changes................................................ 34
- 8.1. Changes from draft-ietf-...-02......................... 34
- 8.2. Changes from draft-ietf-...-01......................... 35
- 8.3. Changes from draft-ietf-...-00......................... 37
- 9. References............................................. 38
- 10. Acknowledgements....................................... 39
- 11. Author's Address....................................... 39
+ 7.4.2. NOTIFY method.......................................... 33
+ 7.5. New Headers............................................ 33
+ 7.5.1. "Event" header......................................... 33
+ 7.5.2. "Allow-Events" Header.................................. 34
+ 7.5.3. "Subscription-State" Header............................ 34
+ 7.6. New Response Codes..................................... 34
+ 7.6.1. "202 Accepted" Response Code........................... 34
+ 7.6.2. "489 Bad Event" Response Code.......................... 34
+ 7.7. Augmented BNF Definitions.............................. 34
+ 8. References............................................. 35
+ 9. Acknowledgements....................................... 36
+ 10. Author's Address....................................... 36
+ 11. Notice Regarding Intellectual Property Rights.......... 36
+ 12. Full Copyright Statement............................... 36
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
+ 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 PINT
- status (based on call state events).
+ indications (based on mailbox state change events), and PSTN and
+ Internet Internetworking (PINT) [3] 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 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
- complex rules which govern the subscription and notification for
- the events or classes of events they describe.
+ elaborate 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
@@ -182,32 +181,31 @@
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 References section; see section 9.
+ of the entries in the References section; see section 8.
The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", and
- "MUST NOT" are used as defined in RFC 2119 [8].
+ "MUST NOT" are used as defined in RFC 2119 [7].
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.
3. 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 state which may
be applied to all possible event packages, including itself.
@@ -217,21 +215,21 @@
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 it is creating notifications.
+ 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
@@ -286,24 +284,25 @@
are discussed in section 4.2.2.
4.1.2. Identification of Subscribed Events and Event Classes
Identification of events is provided by three pieces of
information: Request URI, Event Type, and (optionally) message
body.
The Request URI of a SUBSCRIBE request, most importantly,
contains enough information to route the request to the
- appropriate entity. It also contains enough information to
- identify the resource for which event notification is desired,
- but not necessarily enough information to uniquely identify the
- nature of the event (e.g. "sip:adam@dynamicsoft.com" would be an
+ appropriate entity per the request routing procedures outlined in
+ SIP [1]. It also contains enough information to identify the
+ resource for which event notification is desired, but not
+ necessarily enough information to uniquely identify the nature of
+ the 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 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 a token which
indicates the type of state for which a subscription is being
requested. This token will be registered with the IANA and will
correspond to an event package which further describes the
@@ -316,22 +315,22 @@
If the event package to which the event token corresponds defines
behavior associated with the body of its SUBSCRIBE requests,
those semantics apply.
Event packages may also define parameters for the 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 as defined in SIP [1]
- , they MAY contain an "Accept" header. This header, if present,
+ Because SUBSCRIBE requests create a dialog as defined in SIP [1],
+ they MAY contain an "Accept" header. This header, if present,
indicates the body formats allowed in subsequent NOTIFY requests.
Event packages MUST define the behavior for SUBSCRIBE requests
without "Accept" headers; usually, this will connote a single,
default body type.
Header values not described in this document are to be
interpreted as described in SIP [1].
4.1.4. Subscriber SUBSCRIBE Behavior
@@ -392,20 +391,24 @@
the state, he does so by composing an unrelated initial SUBSCRIBE
request with 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 still considered
valid for the duration of the most recently known "Expires" value
as negotiated by SUBSCRIBE and its response, or as communicated
by NOTIFY in the "Subscription-State" header "expires" parameter.
+ Note that many such errors indicate that there may be a
+ problem with the network or the notifier such that no further
+ NOTIFY messages will be received.
+
4.1.4.3. Unsubscribing
Unsubscribing is handled in the same way as refreshing of a
subscription, with the "Expires" header set to "0". Note that a
successful unsubscription will also trigger a final NOTIFY
message.
4.1.4.4. Confirmation of Subscription Creation
The subscriber can expect to receive a NOTIFY message from each
@@ -425,47 +428,54 @@
4.1.5. Proxy SUBSCRIBE Behavior
Proxies need no additional behavior beyond that described in SIP
[1] to support SUBSCRIBE. If a proxy wishes to see all of the
SUBSCRIBE and NOTIFY requests for a given dialog, it MUST
record-route the initial SUBSCRIBE and any dialog-establishing
NOTIFY requests. Such proxies SHOULD also record-route all other
SUBSCRIBE and NOTIFY requests.
+ Note that subscribers and notifiers may elect to use S/MIME
+ encryption of SUBSCRIBE and NOTIFY requests; consequently,
+ proxies cannot rely on being able to access any information
+ that is not explicitly required to be proxy-readable by SIP
+ [1].
+
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 the time necessary for automated processing. In particular,
notifiers MUST NOT wait for a user response before returning a
final response to a SUBSCRIBE request.
- This requirement is imposed primarily to prevent timer F from
- firing during the SUBSCRIBE transaction, since interaction
- with a user would often exceed 64*T1 seconds.
+ This requirement is imposed primarily to prevent the
+ non-INVITE transaction timeout timer F (see [1]) from firing
+ during the SUBSCRIBE transaction, since interaction with a
+ user would often exceed 64*T1 seconds.
The notifier SHOULD check that the event package specified in the
"Event" header is understood. If not, the notifier SHOULD return
a "489 Bad Event" response to indicate that 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.1.6.3.
- If the notifier has local policy specifying a minimum allowed
- duration for subscriptions, it SHOULD verify that the "Expires"
- header in the SUBSCRIBE request is not smaller than such a
- duration. If not, the notifier SHOULD return a "423 Interval too
- small" error which contains a "Min-Expires" header field. The
- "Min-Expires" header field is describe in SIP [1].
+ The notifier MAY also check that the duration in the "Expires"
+ header is not too small. If and only if the expiration interval
+ is greater than zero AND smaller than one hour AND less than a
+ notifier-configured minimum, the notifier MAY return a "423
+ Interval too small" error which contains a "Min-Expires" header
+ field. The "Min-Expires" header field is described in SIP [1].
If the notifier is able to immediately determine that it
understands the event package, that the authenticated subscriber
is authorized to subscribe, and that there are no other barriers
to creating the subscription, it creates the subscription and a
dialog (if necessary), 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 the subscription (e.g.
@@ -475,37 +485,38 @@
response. This response indicates that the request has been
received and understood, but does not necessarily imply that the
subscription has been authorized yet.
When a subscription is created in the notifier, it stores the
event package name and the "Event" header "id" parameter (if
present) as part of the subscription information.
The "Expires" values present in SUBSCRIBE 200-class responses
behave in the same way as they do in REGISTER responses: the
- server MAY shorten the interval, but MUST NOT lengthen it. If the
- duration specified in a SUBSCRIBE message is unacceptably short,
- the notifier SHOULD respond with a "423 Subscription Too Brief"
- message.
+ server MAY shorten the interval, but MUST NOT lengthen it.
+
+ If the duration specified in a SUBSCRIBE message is
+ unacceptably short, the notifier may be able to send a 423
+ response, as described earlier in this section.
200-class responses to SUBSCRIBE requests 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 the notifier.
The other response codes defined in SIP [1] may be used in
response to SUBSCRIBE requests, as appropriate.
4.1.6.2. Confirmation of Subscription Creation/Refreshing
- Upon successfully accepting or refreshing of a subscription,
+ Upon successfully accepting or refreshing a subscription,
notifiers MUST send a NOTIFY message immediately to communicate
the current resource state to the subscriber. This NOTIFY message
is sent on the same dialog as created by the SUBSCRIBE response.
If the resource has 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 message is always sent immediately after any
200-class response to a SUBSCRIBE request, regardless of whether
@@ -519,20 +530,25 @@
by mechanisms such as access control lists or real-time
interaction with a user. In general, authorization of subscribers
prior to authentication is not particularly useful.
SIP authentication mechanisms are discussed in SIP [1]. Note
that, even 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 a user
agents when accepting subscriptions and sending notifications.
+ Of course, when acting as a proxy, a node will perform normal
+ proxy authentication (using 407). The foregoing explanation
+ is a reminder that notifiers are always UAs, and as such
+ perform UA authentication.
+
If authorization fails based on an access list or some other
automated mechanism (i.e. it can be automatically authoritatively
determined that the subscriber is not authorized to subscribe),
the 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
@@ -634,22 +650,23 @@
"Retry-After" header and no implied further action which can be
taken to retry the request (e.g. "401 Authorization Required".)
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 SUBSCRIBE), the notifier SHOULD remove the
subscription.
This behavior prevents unnecessary transmission of state
information for subscribers who have crashed or disappeared
- from the network. Because such transmissions will be sent 11
- times (instead of the typical single transmission for
+ from the network. Because such transmissions will be sent
+ multiple times, per the retransmission algorithm defined in
+ SIP [1] (instead of 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 network. Upon client restart or reestablishment
of a 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 NOTIFY request fails (as defined above) due to an error
response, and the subscription was installed using a soft-state
@@ -676,22 +693,22 @@
send a SUBSCRIBE request to remove the subscription. Since
this behavior would make subscribers available for use as
amplifiers in denial of service attacks, we have instead
elected to give the 481 response special meaning: it is used
to indicate that a subscription must be cancelled under all
circumstances.
NOTIFY requests MUST contain a "Subscription-State" header with a
value of "active", "pending", or "terminated". The "active" value
indicates that the subscription has been accepted and has been
- authorized (in most cases; see section 6.2. ). The "pending"
- value indicates that the subscription has been received, but that
+ 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 accept or deny the
subscription at this time. The "terminated" value indicates that
the subscription is not active.
If the value of the "Subscription-State" header is "active" or
"pending", the notifier SHOULD also include in the
"Subscription-State" header an "expires" parameter which
indicates the time remaining on the subscription. The notifier
MAY use this mechanism to shorten a subscription; however, this
mechanism MUST NOT be used to lengthen a subscription.
@@ -711,20 +728,26 @@
4.2.3. Proxy NOTIFY Behavior
Proxies need no additional behavior beyond that described in SIP
[1] to support NOTIFY. If a proxy wishes to see all of the
SUBSCRIBE and NOTIFY requests for a given dialog, it MUST
record-route the initial SUBSCRIBE and any dialog-establishing
NOTIFY requests. Such proxies SHOULD also record-route all other
SUBSCRIBE and NOTIFY requests.
+ Note that subscribers and notifiers may elect to use S/MIME
+ encryption of SUBSCRIBE and NOTIFY requests; consequently,
+ proxies cannot rely on being able to access any information
+ that is not explicitly required to be proxy-readable by SIP
+ [1].
+
4.2.4. Subscriber NOTIFY Behavior
Upon receiving a NOTIFY request, the subscriber should check that
it matches at least one of its outstanding subscriptions; if not,
it MUST return a "481 Subscription does not exist" response
unless another 400- or 500-class response is more appropriate.
The rules for matching NOTIFY requests with subscriptions that
create a new dialog are described in section 4.3.4. Notifications
for subscriptions which were created inside an existing dialog
match if they are in the same dialog and the "Event" headers
@@ -789,20 +812,25 @@
"timeout".
giveup: The subscription has been terminated because the notifier
could not obtain authorization in a timely fashion. If a
"retry-after" parameter is also present, the client SHOULD
wait at least the number of seconds specified by that
parameter before attempting to re-subscribe; otherwise, the
client MAY retry immediately, but will likely get put back
into pending state.
+ noresource: The subscription has been terminated because the
+ resource state which was being monitored no longer exists.
+ Clients SHOULD NOT attempt to re-subscribe. The "retry-after"
+ parameter has no semantics for "noresource".
+
Once the notification is deemed acceptable to the subscriber, the
subscriber SHOULD return a 200 response. In general, it is not
expected that NOTIFY responses will contain bodies; however, they
MAY, if the NOTIFY request contained an "Accept" header.
Other responses defined in SIP [1] may also be returned, as
appropriate. In no case should a NOTIFY transaction extend for
any longer than the time necessary for automated processing. In
particular, subscribers MUST NOT wait for a user response before
returning a final response to a NOTIFY request.
@@ -814,23 +842,23 @@
Neither SUBSCRIBE nor NOTIFY necessitate the use of "Require" or
"Proxy-Require" headers; similarly, there is no token defined for
"Supported" headers. If necessary, clients may probe for the
support of SUBSCRIBE and NOTIFY using the OPTIONS request defined
in SIP [1].
The presence of the "Allow-Events" header in a message is
sufficient to indicate support for SUBSCRIBE and NOTIFY.
The "methods" parameter for Contact may also be used to
- specifically announce support for SUBSCRIBE and NOTIFY messages
- when registering. (See reference [7] for details on the "methods"
- parameter).
+ specifically announce support for SUBSCRIBE and NOTIFY
+ messages when registering. (See reference [6] for details on
+ the "methods" parameter).
4.3.2. CANCEL requests
No semantics are associated with cancelling SUBSCRIBE or NOTIFY.
4.3.3. Forking
In accordance with the rules for proxying non-INVITE requests as
defined in SIP [1], successful SUBSCRIBE requests will receive
only one 200-class response; however, due to forking, the
@@ -844,37 +872,36 @@
the SUBSCRIBE request was forked. For information on subscriber
handling in such situations, see section 5.4.9.
4.3.4. Dialog creation and termination
If an initial SUBSCRIBE request is not sent on a pre-existing
dialog, the subscriber will wait for a response to the SUBSCRIBE
request or a matching NOTIFY.
Responses are matched to such SUBSCRIBE requests if they contain
- the same the same "Call-ID", the same "From" header field, the
- same "To" header field, excluding the "tag", and the same "CSeq".
- Rules for the comparison of these headers are described in SIP
- [1]. If a 200-class response matches such a SUBSCRIBE request,
- it creates a new subscription and a new dialog (unless they have
- already been created by a matching NOTIFY request; see below).
+ the same the same "Call-ID", the same "From" header "tag", and
+ the same "CSeq". Rules for the comparison of these headers are
+ described in SIP [1]. If a 200-class response matches such a
+ SUBSCRIBE request, it creates a new subscription and a new dialog
+ (unless they have already been created by a matching NOTIFY
+ request; see below).
NOTIFY requests are matched to such SUBSCRIBE requests if they
- contain the same "Call-ID", a "From" header field which matches
- the "To" header field of the SUBSCRIBE, excluding the "tag", a
- "To" header field which matches the "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 contains a
- "Subscription-State" of "active" or "pending", it creates a new
- subscription and a new dialog (unless they have already been
- created by a matching response, as described above).
+ contain the same "Call-ID", a "To" header "tag" parameter which
+ matches the "From" header "tag" parameter 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 contains a "Subscription-State" of "active" or
+ "pending", it creates a new subscription and a new dialog (unless
+ they have already been created by a matching response, as
+ described above).
If an initial SUBSCRIBE is sent on a pre-existing dialog, a
matching 200-class response or successful NOTIFY request merely
creates a new subscription associated with that dialog.
Multiple subscriptions can be associated with a single dialog.
Subscriptions may also exist in dialogs associated with
INVITE-created application state and other application state
created by mechanisms defined in other specifications. These sets
of application state do not interact beyond the behavior
@@ -944,20 +971,30 @@
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 "Expires" headers of 0 will contain a "Subscription-State"
value of "terminated", and a "reason" parameter of "timeout".
+ Polling of event state can cause significant increases in load on
+ the network and notifiers; as such, it should be used only
+ sparingly. In particular, polling SHOULD NOT be used in
+ circumstances in which it will typically result in more network
+ messages than long-running subscriptions.
+
+ When polling is used, subscribers SHOULD attempt to cache
+ authentication credentials between polls so as to reduce the
+ number of messages sent.
+
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
@@ -993,23 +1030,23 @@
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.
+ document are urged to follow the development of "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. Event Template-packages
@@ -1077,23 +1114,23 @@
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
+ Any event package that supports delta changes to states MUST
+ include a version number that increases by exactly one for each
+ NOTIFY message in a subscription. 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
@@ -1102,25 +1139,24 @@
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 weakened 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" [5] and "Guidelines for Authors of SIP
- Extensions" [2], authors of event packages need to address
- each of the issues detailed in the following subsections,
- whenever applicable.
+ In addition to the normal sections expected in
+ standards-track RFCs and SIP extension documents, authors of
+ event packages need to address each of the issues detailed in
+ the following subsections, whenever applicable.
5.4.1. Event Package Name
This section, which MUST be present, 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
@@ -1146,21 +1182,21 @@
5.4.4. Subscription Duration
It is 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 define a what type or types of event
+ monitored. Each package MUST define what type or types of event
bodies are expected in NOTIFY requests. Such packages MUST
specify or cite detailed specifications for the syntax and
semantics associated with such event body.
Event packages also 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
@@ -1189,22 +1225,22 @@
the subsequent response.
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 specify whether forked SUBSCRIBE
- requests are allowed to install multiple subscriptions.
+ Each event package MUST specify whether forked SUBSCRIBE requests
+ are allowed to install multiple subscriptions.
If such behavior is not allowed, the first potential
dialog-establishing message will create a dialog. All subsequent
NOTIFY messages which correspond to the SUBSCRIBE message (i.e.
match "To", "From", "From" header "tag" parameter, "Call-ID",
"CSeq", "Event", and "Event" header "id" parameter) but which do
not match the dialog would be rejected with a 481 response. Note
that the 200-class response to the SUBSCRIBE can arrive after a
matching NOTIFY has been received; such responses might not
correlate to the same dialog established by the NOTIFY. Except as
@@ -1218,32 +1254,29 @@
refreshed independent of the other dialogs.
In the case that multiple subscriptions are allowed, the event
package 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 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 (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 further define a throttle mechanism which
- allows subscribers to further limit the rate of notification.
+ Each package 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.
@@ -1259,62 +1292,63 @@
Event packages SHOULD include several demonstrative message flow
diagrams paired with several typical, syntactically correct and
complete messages.
It is 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.
-5.4.13. URI List handling
+5.4.13. Use of URIs to Retrieve State
Some types of event packages may 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.
+ convey a URI instead of state information; this URI 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.
+ The precise mechanisms for conveying such URIs are out of the
+ scope of this document.
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 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.
+ control of the notifier's 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 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
+6.2. Notifier Privacy Mechanism
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 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.
+ Individual packages and their related drafts for which such a
+ mode of operation makes sense can further describe how and why to
+ generate such potentially correct data. For example, such a mode
+ of operation is mandated by RFC 2779 [8] for user presence
+ information.
+
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.
@@ -1325,24 +1359,27 @@
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 it witnessed being
installed at some point in the past. Replaying of NOTIFY messages
may be used to spoof old state information (although a good
versioning mechanism in the body of the NOTIFY messages may help
- mitigate such an attack).
+ mitigate such an attack). Note that the prohibition on sending
+ NOTIFY messages to nodes which have not subscribed to an event
+ also aids in mitigating the effects of such an attack.
To prevent such attacks, implementations SHOULD require
- authentication. Authentication issues are discussed in SIP [1].
+ authentication with anti-replay protection. Authentication issues
+ are discussed in 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 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 minimum. If SUBSCRIBE
@@ -1386,21 +1422,21 @@
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
+ IANA Considerations Section in RFCs"[5], 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 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
@@ -1459,21 +1494,21 @@
(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
+ expressed in the ABNF format used in SIP [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
@@ -1656,208 +1691,103 @@
extension-substate = token
subexp-params = ("reason" EQUAL reason-value)
/ ("expires" EQUAL delta-seconds)
/ ("retry-after" EQUAL delta-seconds)
/ generic-param
reason-value = "deactivated"
/ "probation"
/ "rejected"
/ "timeout"
/ "giveup"
+ / "noresource"
/ reason-extension
reason-extension = token
-8. Changes
-
-8.1. Changes from draft-ietf-...-02
-
- - Fixes in section
- 4.1.1.
- to align with rest of spec:
- missed one reference to notifier being able to increase
- subscription interval.
-
- - Changed Record-Routing description in
- 4.1.5.
- and
-
- 4.2.3.
-
- Now mandatory only for 1st SUBSCRIBE and
- dialog-establishing NOTIFY messages.
-
- - Added language to
- 4.2.4.
- requiring an immediate
- NOTIFY response.
-
- - Added clarifying text to
- 4.3.3.
- to explain that
- the forking behavior comes from the SIP spec.
-
- - Fixed ABNF to use "/" instead of "|". Other minor
- ABNF updates to make consistent and correct.
-
- - Grouped ABNF into a single section.
-
- - Pointed to correct version of HTTP/1.1 spec.
-
- - Added generation of 423 error response to
- notifier handling of SUBSCRIBE requests.
-
- - Update to allow "Warning" headers in NOTIFY
- requests
-
- - Several small editorial changes.
-
- - Adjusted usage of quotation marks next to periods and
- commas to match that used by the American Mathematical
- Society; although contrary to traditional American
- English convention, this usage lends clarity to certain
- passages.
-
-8.2. Changes from draft-ietf-...-01
-
- - Changed dependency from RFC2543 to new sip bis draft.
- This allowed removal of certain sections of text.
-
- - Renamed "sub-packages" to "template-packages" in an
- 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 NOTIFY
- requests, since it is integral to defining the
- creation and destruction of subscriptions (and,
- consequently, dialogs)
-
- - Heavily revised section on dialog creation and
- termination.
-
- - Expanded migration section.
-
- - Added "id" parameter to Event header, to allow
- demultiplexing of NOTIFY requests when more than
- one subscription is associated with a single dialog.
-
- - Synchronized 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.3. Changes from draft-ietf-...-00
-
- - Fixed confusing typo in section describing correlation
- of SUBSCRIBE requests
-
- - Added explanatory 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" everywhere.
-
- - 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.
+8. References
-9. References
+ NOTE: Non-normative references are so labeled.
[1] J. Rosenberg et. al., "SIP: Session Initiation Protocol",
, IETF; February 2002. Work in
progress.
[2] J. Rosenberg, H. Schulzrinne, "Guidelines for Authors of SIP
Extensions", , IETF;
- November 2001. Work in progress.
+ November 2001. Work in progress. Non-normative.
[3] S. Petrack, L. Conroy, "The PINT Service Protocol", RFC 2848,
IETF; June 2000.
[4] R. Fielding et. al., "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, IETF, June 1999.
- [5] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC
- 2223, IETF, October 1997.
-
- [6] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
+ [5] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, IETF, October 1998.
- [7] Schulzrinne/Rosenberg, "SIP Caller Preferences and Callee
+ [6] Schulzrinne/Rosenberg, "SIP Caller Preferences and Callee
Capabilities", , IETF;
- November 2001. Work in progress.
+ November 2001. Work in progress. Non-normative.
- [8] S. Bradner, "Key words for use in RFCs to indicate
+ [7] S. Bradner, "Key words for use in RFCs to indicate
requirement levels", RFC 2119, IETF, March 1997
-10. Acknowledgements
+ [8] M. Day et. al., "Instant Messaging/Presence Protocol
+ Requirements", RFC 2779, IETF, February 2000
+
+9. 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 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.
-11. Author's Address
+10. Author's Address
Adam Roach
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
E-Mail:
Voice:
+
+11. Notice Regarding Intellectual Property Rights
+
+ The IETF has been notified of intellectual property rights
+ claimed in regard to some or all of the specification contained
+ in this document. For more information, consult the online list
+ of claimed rights at http://www.ietf.org/ipr.html
+
+12. 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.