draft-ietf-sip-events-03.txt   draft-ietf-sip-events-04.txt 
Internet Engineering Task Force Adam Roach Internet Engineering Task Force Adam Roach
Internet Draft dynamicsoft Internet Draft dynamicsoft
Category: Standards Track February 2002 Category: Standards Track February 2002
Expires August 2002 Expires August 2002
<draft-ietf-sip-events-03.txt> <draft-ietf-sip-events-04.txt>
SIP-Specific Event Notification SIP-Specific Event Notification
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Note that the event notification mechanisms defined herein are Note that the event notification mechanisms defined herein are
NOT intended to be a general-purpose infrastructure for all NOT intended to be a general-purpose infrastructure for all
classes of event subscription and notification. classes of event subscription and notification.
1. Table of Contents 1. Table of Contents
1. Table of Contents...................................... 1 1. Table of Contents...................................... 1
2. Introduction........................................... 3 2. Introduction........................................... 3
2.1. Overview of Operation.................................. 4 2.1. Overview of Operation.................................. 4
2.2. Documentation Conventions.............................. 4 2.2. Documentation Conventions.............................. 4
3. Definitions............................................ 5 3. Definitions............................................ 4
4. Node Behavior.......................................... 5 4. Node Behavior.......................................... 5
4.1. Description of SUBSCRIBE Behavior...................... 5 4.1. Description of SUBSCRIBE Behavior...................... 5
4.1.1. Subscription Duration.................................. 6 4.1.1. Subscription Duration.................................. 6
4.1.2. Identification of Subscribed Events and Event Classes.. 6 4.1.2. Identification of Subscribed Events and Event Classes.. 6
4.1.3. Additional SUBSCRIBE Header Values..................... 7 4.1.3. Additional SUBSCRIBE Header Values..................... 7
4.1.4. Subscriber SUBSCRIBE Behavior.......................... 7 4.1.4. Subscriber SUBSCRIBE Behavior.......................... 7
4.1.5. Proxy SUBSCRIBE Behavior............................... 9 4.1.5. Proxy SUBSCRIBE Behavior............................... 9
4.1.6. Notifier SUBSCRIBE Behavior............................ 9 4.1.6. Notifier SUBSCRIBE Behavior............................ 9
4.2. Description of NOTIFY Behavior......................... 12 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.2. Notifier NOTIFY Behavior............................... 13
4.2.3. Proxy NOTIFY Behavior.................................. 15 4.2.3. Proxy NOTIFY Behavior.................................. 15
4.2.4. Subscriber NOTIFY Behavior............................. 15 4.2.4. Subscriber NOTIFY Behavior............................. 15
4.3. General................................................ 17 4.3. General................................................ 17
4.3.1. Detecting support for SUBSCRIBE and NOTIFY............. 17 4.3.1. Detecting support for SUBSCRIBE and NOTIFY............. 17
4.3.2. CANCEL requests........................................ 17 4.3.2. CANCEL requests........................................ 18
4.3.3. Forking................................................ 17 4.3.3. Forking................................................ 18
4.3.4. Dialog creation and termination........................ 17 4.3.4. Dialog creation and termination........................ 18
4.3.5. State Agents and Notifier Migration.................... 19 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.7. Allow-Events header usage.............................. 20
4.3.8. PINT Compatibility..................................... 20 4.3.8. PINT Compatibility..................................... 21
5. Event Packages......................................... 20 5. Event Packages......................................... 21
5.1. Appropriateness of Usage............................... 20 5.1. Appropriateness of Usage............................... 21
5.2. Event Template-packages................................ 21 5.2. Event Template-packages................................ 22
5.3. Amount of State to be Conveyed......................... 21 5.3. Amount of State to be Conveyed......................... 22
5.3.1. Complete State Information............................. 22 5.3.1. Complete State Information............................. 22
5.3.2. State Deltas........................................... 22 5.3.2. State Deltas........................................... 23
5.4. Event Package Responsibilities......................... 22 5.4. Event Package Responsibilities......................... 23
5.4.1. Event Package Name..................................... 23 5.4.1. Event Package Name..................................... 24
5.4.2. Event Package Parameters............................... 23 5.4.2. Event Package Parameters............................... 24
5.4.3. SUBSCRIBE Bodies....................................... 23 5.4.3. SUBSCRIBE Bodies....................................... 24
5.4.4. Subscription Duration.................................. 23 5.4.4. Subscription Duration.................................. 24
5.4.5. NOTIFY Bodies.......................................... 24 5.4.5. NOTIFY Bodies.......................................... 24
5.4.6. Notifier processing of SUBSCRIBE requests.............. 24 5.4.6. Notifier processing of SUBSCRIBE requests.............. 25
5.4.7. Notifier generation of NOTIFY requests................. 24 5.4.7. Notifier generation of NOTIFY requests................. 25
5.4.8. Subscriber processing of NOTIFY requests............... 24 5.4.8. Subscriber processing of NOTIFY requests............... 25
5.4.9. Handling of forked requests............................ 24 5.4.9. Handling of forked requests............................ 25
5.4.10. Rate of notifications.................................. 25 5.4.10. Rate of notifications.................................. 26
5.4.11. State Agents........................................... 25 5.4.11. State Agents........................................... 26
5.4.12. Examples............................................... 26 5.4.12. Examples............................................... 26
5.4.13. URI List handling...................................... 26 5.4.13. Use of URIs to Retrieve State.......................... 27
6. Security Considerations................................ 26 6. Security Considerations................................ 27
6.1. Access Control......................................... 26 6.1. Access Control......................................... 27
6.2. Release of Sensitive Policy Information................ 26 6.2. Notifier Privacy Mechanism............................. 27
6.3. Denial-of-Service attacks.............................. 27 6.3. Denial-of-Service attacks.............................. 27
6.4. Replay Attacks......................................... 27 6.4. Replay Attacks......................................... 28
6.5. Man-in-the middle attacks.............................. 27 6.5. Man-in-the middle attacks.............................. 28
6.6. Confidentiality........................................ 28 6.6. Confidentiality........................................ 28
7. IANA Considerations.................................... 28 7. IANA Considerations.................................... 29
7.1. Registration Information............................... 29 7.1. Registration Information............................... 29
7.2. Registration Template.................................. 29 7.2. Registration Template.................................. 30
7.3. Syntax................................................. 30 7.3. Syntax................................................. 31
7.4. New Methods............................................ 30 7.4. New Methods............................................ 31
7.4.1. SUBSCRIBE method....................................... 32 7.4.1. SUBSCRIBE method....................................... 32
7.4.2. NOTIFY method.......................................... 32 7.4.2. NOTIFY method.......................................... 33
7.5. New Headers............................................ 32 7.5. New Headers............................................ 33
7.5.1. "Event" header......................................... 32 7.5.1. "Event" header......................................... 33
7.5.2. "Allow-Events" Header.................................. 33 7.5.2. "Allow-Events" Header.................................. 34
7.5.3. "Subscription-State" Header............................ 33 7.5.3. "Subscription-State" Header............................ 34
7.6. New Response Codes..................................... 33 7.6. New Response Codes..................................... 34
7.6.1. "202 Accepted" Response Code........................... 33 7.6.1. "202 Accepted" Response Code........................... 34
7.6.2. "489 Bad Event" Response Code.......................... 33 7.6.2. "489 Bad Event" Response Code.......................... 34
7.7. Augmented BNF Definitions.............................. 33 7.7. Augmented BNF Definitions.............................. 34
8. Changes................................................ 34 8. References............................................. 35
8.1. Changes from draft-ietf-...-02......................... 34 9. Acknowledgements....................................... 36
8.2. Changes from draft-ietf-...-01......................... 35 10. Author's Address....................................... 36
8.3. Changes from draft-ietf-...-00......................... 37 11. Notice Regarding Intellectual Property Rights.......... 36
9. References............................................. 38 12. Full Copyright Statement............................... 36
10. Acknowledgements....................................... 39
11. Author's Address....................................... 39
2. Introduction 2. Introduction
The ability to request asynchronous notification of events proves The ability to request asynchronous notification of events proves
useful in many types of services for which cooperation between useful in many types of SIP services for which cooperation
end-nodes is required. Examples of such services include between end-nodes is required. Examples of such services include
automatic callback services (based on terminal state events), automatic callback services (based on terminal state events),
buddy lists (based on user presence events), message waiting buddy lists (based on user presence events), message waiting
indications (based on mailbox state change events), and PINT indications (based on mailbox state change events), and PSTN and
status (based on call state events). Internet Internetworking (PINT) [3] status (based on call state
events).
The methods described in this document allow a framework by which The methods described in this document provide a framework by
notification of these events can be ordered. which notification of these events can be ordered.
The event notification mechanisms defined herein are NOT intended The event notification mechanisms defined herein are NOT intended
to be a general-purpose infrastructure for all classes of event to be a general-purpose infrastructure for all classes of event
subscription and notification. Meeting requirements for the subscription and notification. Meeting requirements for the
general problem set of subscription and notification is far too general problem set of subscription and notification is far too
complex for a single protocol. Our goal is to provide a complex for a single protocol. Our goal is to provide a
SIP-specific framework for event notification which is not so SIP-specific framework for event notification which is not so
complex as to be unusable for simple features, but which is still complex as to be unusable for simple features, but which is still
flexible enough to provide powerful services. Note, however, that flexible enough to provide powerful services. Note, however, that
event packages based on this framework may define arbitrarily event packages based on this framework may define arbitrarily
complex rules which govern the subscription and notification for elaborate rules which govern the subscription and notification
the events or classes of events they describe. for the events or classes of events they describe.
This draft does not describe an extension which may be used This draft does not describe an extension which may be used
directly; it must be extended by other drafts (herein referred to directly; it must be extended by other drafts (herein referred to
as "event packages".) In object-oriented design terminology, it as "event packages".) In object-oriented design terminology, it
may be thought of as an abstract base class which must be derived may be thought of as an abstract base class which must be derived
into an instantiatable class by further extensions. Guidelines into an instantiatable class by further extensions. Guidelines
for creating these extensions are described in section 5. for creating these extensions are described in section 5.
2.1. Overview of Operation 2.1. Overview of Operation
skipping to change at page 4, line 43 skipping to change at page 4, line 42
provide motivational or clarifying text. Such passages are provide motivational or clarifying text. Such passages are
non-normative, and are provided only to assist with reader non-normative, and are provided only to assist with reader
comprehension. These passages are set off from the remainder of comprehension. These passages are set off from the remainder of
the text by being indented thus: the text by being indented thus:
This is an example of non-normative explanatory text. It does This is an example of non-normative explanatory text. It does
not form part of the specification, and is used only for not form part of the specification, and is used only for
clarification. clarification.
Numbers in square brackets (e.g. [1]) denote a reference to one 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 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 The use of quotation marks next to periods and commas follows the
convention used by the American Mathematical Society; although convention used by the American Mathematical Society; although
contrary to traditional American English convention, this usage contrary to traditional American English convention, this usage
lends clarity to certain passages. lends clarity to certain passages.
3. Definitions 3. Definitions
Event Package: An event package is an additional specification Event Package: An event package is an additional specification
which defines a set of state information to be reported by a which defines a set of state information to be reported by a
notifier to a subscriber. Event packages also define further notifier to a subscriber. Event packages also define further
syntax and semantics based on the framework defined by this syntax and semantics based on the framework defined by this
document required to convey such state information. document required to convey such state information.
Event Template-Package: An event template-package is a special Event Template-Package: An event template-package is a special
kind of event package which defines a set of state which may kind of event package which defines a set of state which may
be applied to all possible event packages, including itself. be applied to all possible event packages, including itself.
skipping to change at page 5, line 30 skipping to change at page 5, line 27
Notifier: A notifier is a user agent which generates NOTIFY Notifier: A notifier is a user agent which generates NOTIFY
requests for the purpose of notifying subscribers of the requests for the purpose of notifying subscribers of the
state of a resource. Notifiers typically also accept state of a resource. Notifiers typically also accept
SUBSCRIBE requests to create subscriptions. SUBSCRIBE requests to create subscriptions.
State Agent: A state agent is a notifier which publishes state State Agent: A state agent is a notifier which publishes state
information on behalf of a resource; in order to do so, it information on behalf of a resource; in order to do so, it
may need to gather such state information from multiple may need to gather such state information from multiple
sources. State agents always have complete state information 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 Subscriber: A subscriber is a user agent which receives NOTIFY
requests from notifiers; these NOTIFY requests contain requests from notifiers; these NOTIFY requests contain
information about the state of a resource in which the information about the state of a resource in which the
subscriber is interested. Subscribers typically also generate subscriber is interested. Subscribers typically also generate
SUBSCRIBE requests and send them to notifiers to create SUBSCRIBE requests and send them to notifiers to create
subscriptions. subscriptions.
Subscription: A subscription is a set of application state Subscription: A subscription is a set of application state
associated with a dialog. This application state includes a associated with a dialog. This application state includes a
skipping to change at page 6, line 48 skipping to change at page 6, line 48
are discussed in section 4.2.2. are discussed in section 4.2.2.
4.1.2. Identification of Subscribed Events and Event Classes 4.1.2. Identification of Subscribed Events and Event Classes
Identification of events is provided by three pieces of Identification of events is provided by three pieces of
information: Request URI, Event Type, and (optionally) message information: Request URI, Event Type, and (optionally) message
body. body.
The Request URI of a SUBSCRIBE request, most importantly, The Request URI of a SUBSCRIBE request, most importantly,
contains enough information to route the request to the contains enough information to route the request to the
appropriate entity. It also contains enough information to appropriate entity per the request routing procedures outlined in
identify the resource for which event notification is desired, SIP [1]. It also contains enough information to identify the
but not necessarily enough information to uniquely identify the resource for which event notification is desired, but not
nature of the event (e.g. "sip:adam@dynamicsoft.com" would be an 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 appropriate URI to subscribe to for my presence state; it would
also be an appropriate URI to subscribe to the state of my voice also be an appropriate URI to subscribe to the state of my voice
mailbox). mailbox).
Subscribers MUST include exactly one "Event" header in SUBSCRIBE Subscribers MUST include exactly one "Event" header in SUBSCRIBE
requests, indicating to which event or class of events they are requests, indicating to which event or class of events they are
subscribing. The "Event" header will contain a token which subscribing. The "Event" header will contain a token which
indicates the type of state for which a subscription is being indicates the type of state for which a subscription is being
requested. This token will be registered with the IANA and will requested. This token will be registered with the IANA and will
correspond to an event package which further describes the correspond to an event package which further describes the
skipping to change at page 7, line 28 skipping to change at page 7, line 28
If the event package to which the event token corresponds defines If the event package to which the event token corresponds defines
behavior associated with the body of its SUBSCRIBE requests, behavior associated with the body of its SUBSCRIBE requests,
those semantics apply. those semantics apply.
Event packages may also define parameters for the Event header; Event packages may also define parameters for the Event header;
if they do so, they must define the semantics for such if they do so, they must define the semantics for such
parameters. parameters.
4.1.3. Additional SUBSCRIBE Header Values 4.1.3. Additional SUBSCRIBE Header Values
Because SUBSCRIBE requests create a dialog as defined in SIP [1] Because SUBSCRIBE requests create a dialog as defined in SIP [1],
, they MAY contain an "Accept" header. This header, if present, they MAY contain an "Accept" header. This header, if present,
indicates the body formats allowed in subsequent NOTIFY requests. indicates the body formats allowed in subsequent NOTIFY requests.
Event packages MUST define the behavior for SUBSCRIBE requests Event packages MUST define the behavior for SUBSCRIBE requests
without "Accept" headers; usually, this will connote a single, without "Accept" headers; usually, this will connote a single,
default body type. default body type.
Header values not described in this document are to be Header values not described in this document are to be
interpreted as described in SIP [1]. interpreted as described in SIP [1].
4.1.4. Subscriber SUBSCRIBE Behavior 4.1.4. Subscriber SUBSCRIBE Behavior
skipping to change at page 9, line 5 skipping to change at page 9, line 5
the state, he does so by composing an unrelated initial SUBSCRIBE the state, he does so by composing an unrelated initial SUBSCRIBE
request with a freshly-generated Call-ID and a new, unique "From" request with a freshly-generated Call-ID and a new, unique "From"
tag (see section 4.1.4.1. ) tag (see section 4.1.4.1. )
If a SUBSCRIBE request to refresh a subscription fails with a If a SUBSCRIBE request to refresh a subscription fails with a
non-481 response, the original subscription is still considered non-481 response, the original subscription is still considered
valid for the duration of the most recently known "Expires" value valid for the duration of the most recently known "Expires" value
as negotiated by SUBSCRIBE and its response, or as communicated as negotiated by SUBSCRIBE and its response, or as communicated
by NOTIFY in the "Subscription-State" header "expires" parameter. 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 4.1.4.3. Unsubscribing
Unsubscribing is handled in the same way as refreshing of a Unsubscribing is handled in the same way as refreshing of a
subscription, with the "Expires" header set to "0". Note that a subscription, with the "Expires" header set to "0". Note that a
successful unsubscription will also trigger a final NOTIFY successful unsubscription will also trigger a final NOTIFY
message. message.
4.1.4.4. Confirmation of Subscription Creation 4.1.4.4. Confirmation of Subscription Creation
The subscriber can expect to receive a NOTIFY message from each The subscriber can expect to receive a NOTIFY message from each
skipping to change at page 9, line 38 skipping to change at page 9, line 42
4.1.5. Proxy SUBSCRIBE Behavior 4.1.5. Proxy SUBSCRIBE Behavior
Proxies need no additional behavior beyond that described in SIP Proxies need no additional behavior beyond that described in SIP
[1] to support SUBSCRIBE. If a proxy wishes to see all of the [1] to support SUBSCRIBE. If a proxy wishes to see all of the
SUBSCRIBE and NOTIFY requests for a given dialog, it MUST SUBSCRIBE and NOTIFY requests for a given dialog, it MUST
record-route the initial SUBSCRIBE and any dialog-establishing record-route the initial SUBSCRIBE and any dialog-establishing
NOTIFY requests. Such proxies SHOULD also record-route all other NOTIFY requests. Such proxies SHOULD also record-route all other
SUBSCRIBE and NOTIFY requests. 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. Notifier SUBSCRIBE Behavior
4.1.6.1. Initial SUBSCRIBE Transaction Processing 4.1.6.1. Initial SUBSCRIBE Transaction Processing
In no case should a SUBSCRIBE transaction extend for any longer In no case should a SUBSCRIBE transaction extend for any longer
than the time necessary for automated processing. In particular, than the time necessary for automated processing. In particular,
notifiers MUST NOT wait for a user response before returning a notifiers MUST NOT wait for a user response before returning a
final response to a SUBSCRIBE request. final response to a SUBSCRIBE request.
This requirement is imposed primarily to prevent timer F from This requirement is imposed primarily to prevent the
firing during the SUBSCRIBE transaction, since interaction non-INVITE transaction timeout timer F (see [1]) from firing
with a user would often exceed 64*T1 seconds. 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 The notifier SHOULD check that the event package specified in the
"Event" header is understood. If not, the notifier SHOULD return "Event" header is understood. If not, the notifier SHOULD return
a "489 Bad Event" response to indicate that the specified a "489 Bad Event" response to indicate that the specified
event/event class is not understood. event/event class is not understood.
The notifier SHOULD also perform any necessary authentication and The notifier SHOULD also perform any necessary authentication and
authorization per its local policy. See section 4.1.6.3. authorization per its local policy. See section 4.1.6.3.
If the notifier has local policy specifying a minimum allowed The notifier MAY also check that the duration in the "Expires"
duration for subscriptions, it SHOULD verify that the "Expires" header is not too small. If and only if the expiration interval
header in the SUBSCRIBE request is not smaller than such a is greater than zero AND smaller than one hour AND less than a
duration. If not, the notifier SHOULD return a "423 Interval too notifier-configured minimum, the notifier MAY return a "423
small" error which contains a "Min-Expires" header field. The Interval too small" error which contains a "Min-Expires" header
"Min-Expires" header field is describe in SIP [1]. field. The "Min-Expires" header field is described in SIP [1].
If the notifier is able to immediately determine that it If the notifier is able to immediately determine that it
understands the event package, that the authenticated subscriber understands the event package, that the authenticated subscriber
is authorized to subscribe, and that there are no other barriers is authorized to subscribe, and that there are no other barriers
to creating the subscription, it creates the subscription and a to creating the subscription, it creates the subscription and a
dialog (if necessary), and returns a "200 OK" response (unless dialog (if necessary), and returns a "200 OK" response (unless
doing so would reveal authorization policy in an undesirable doing so would reveal authorization policy in an undesirable
fashion; see section 6.2. ). fashion; see section 6.2. ).
If the notifier cannot immediately create the subscription (e.g. If the notifier cannot immediately create the subscription (e.g.
skipping to change at page 10, line 37 skipping to change at page 10, line 48
response. This response indicates that the request has been response. This response indicates that the request has been
received and understood, but does not necessarily imply that the received and understood, but does not necessarily imply that the
subscription has been authorized yet. subscription has been authorized yet.
When a subscription is created in the notifier, it stores the When a subscription is created in the notifier, it stores the
event package name and the "Event" header "id" parameter (if event package name and the "Event" header "id" parameter (if
present) as part of the subscription information. present) as part of the subscription information.
The "Expires" values present in SUBSCRIBE 200-class responses The "Expires" values present in SUBSCRIBE 200-class responses
behave in the same way as they do in REGISTER responses: the behave in the same way as they do in REGISTER responses: the
server MAY shorten the interval, but MUST NOT lengthen it. If the server MAY shorten the interval, but MUST NOT lengthen it.
duration specified in a SUBSCRIBE message is unacceptably short,
the notifier SHOULD respond with a "423 Subscription Too Brief" If the duration specified in a SUBSCRIBE message is
message. 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 200-class responses to SUBSCRIBE requests will not generally
contain any useful information beyond subscription duration; contain any useful information beyond subscription duration;
their primary purpose is to serve as a reliability mechanism. their primary purpose is to serve as a reliability mechanism.
State information will be communicated via a subsequent NOTIFY State information will be communicated via a subsequent NOTIFY
request from the notifier. request from the notifier.
The other response codes defined in SIP [1] may be used in The other response codes defined in SIP [1] may be used in
response to SUBSCRIBE requests, as appropriate. response to SUBSCRIBE requests, as appropriate.
4.1.6.2. Confirmation of Subscription Creation/Refreshing 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 notifiers MUST send a NOTIFY message immediately to communicate
the current resource state to the subscriber. This NOTIFY message the current resource state to the subscriber. This NOTIFY message
is sent on the same dialog as created by the SUBSCRIBE response. is sent on the same dialog as created by the SUBSCRIBE response.
If the resource has no meaningful state at the time that the If the resource has no meaningful state at the time that the
SUBSCRIBE message is processed, this NOTIFY message MAY contain SUBSCRIBE message is processed, this NOTIFY message MAY contain
an empty or neutral body. See section 4.2.2. for further details an empty or neutral body. See section 4.2.2. for further details
on NOTIFY message generation. on NOTIFY message generation.
Note that a NOTIFY message is always sent immediately after any Note that a NOTIFY message is always sent immediately after any
200-class response to a SUBSCRIBE request, regardless of whether 200-class response to a SUBSCRIBE request, regardless of whether
skipping to change at page 11, line 31 skipping to change at page 11, line 44
by mechanisms such as access control lists or real-time by mechanisms such as access control lists or real-time
interaction with a user. In general, authorization of subscribers interaction with a user. In general, authorization of subscribers
prior to authentication is not particularly useful. prior to authentication is not particularly useful.
SIP authentication mechanisms are discussed in SIP [1]. Note SIP authentication mechanisms are discussed in SIP [1]. Note
that, even if the notifier node typically acts as a proxy, that, even if the notifier node typically acts as a proxy,
authentication for SUBSCRIBE requests will always be performed authentication for SUBSCRIBE requests will always be performed
via a "401" response, not a "407;" notifiers always act as a user via a "401" response, not a "407;" notifiers always act as a user
agents when accepting subscriptions and sending notifications. 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 If authorization fails based on an access list or some other
automated mechanism (i.e. it can be automatically authoritatively automated mechanism (i.e. it can be automatically authoritatively
determined that the subscriber is not authorized to subscribe), determined that the subscriber is not authorized to subscribe),
the notifier SHOULD reply to the request with a "403 Forbidden" the notifier SHOULD reply to the request with a "403 Forbidden"
or "603 Decline" response, unless doing so might reveal or "603 Decline" response, unless doing so might reveal
information that should stay private; see section 6.2. information that should stay private; see section 6.2.
If the notifier owner is interactively queried to determine If the notifier owner is interactively queried to determine
whether a subscription is allowed, a "202 Accept" response is whether a subscription is allowed, a "202 Accept" response is
returned immediately. Note that a NOTIFY message is still formed returned immediately. Note that a NOTIFY message is still formed
skipping to change at page 13, line 46 skipping to change at page 14, line 13
"Retry-After" header and no implied further action which can be "Retry-After" header and no implied further action which can be
taken to retry the request (e.g. "401 Authorization Required".) taken to retry the request (e.g. "401 Authorization Required".)
If the NOTIFY request fails (as defined above) due to a timeout If the NOTIFY request fails (as defined above) due to a timeout
condition, and the subscription was installed using a soft-state condition, and the subscription was installed using a soft-state
mechanism (such as SUBSCRIBE), the notifier SHOULD remove the mechanism (such as SUBSCRIBE), the notifier SHOULD remove the
subscription. subscription.
This behavior prevents unnecessary transmission of state This behavior prevents unnecessary transmission of state
information for subscribers who have crashed or disappeared information for subscribers who have crashed or disappeared
from the network. Because such transmissions will be sent 11 from the network. Because such transmissions will be sent
times (instead of the typical single transmission for 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 functioning clients), continuing to service them when no
client is available to acknowledge them could place undue client is available to acknowledge them could place undue
strain on a network. Upon client restart or reestablishment strain on a network. Upon client restart or reestablishment
of a network connection, it is expected that clients will of a network connection, it is expected that clients will
send SUBSCRIBE messages to refresh potentially stale state send SUBSCRIBE messages to refresh potentially stale state
information; such messages will re-install subscriptions in information; such messages will re-install subscriptions in
all relevant nodes. all relevant nodes.
If the NOTIFY request fails (as defined above) due to an error If the NOTIFY request fails (as defined above) due to an error
response, and the subscription was installed using a soft-state response, and the subscription was installed using a soft-state
skipping to change at page 14, line 38 skipping to change at page 15, line 6
send a SUBSCRIBE request to remove the subscription. Since send a SUBSCRIBE request to remove the subscription. Since
this behavior would make subscribers available for use as this behavior would make subscribers available for use as
amplifiers in denial of service attacks, we have instead amplifiers in denial of service attacks, we have instead
elected to give the 481 response special meaning: it is used elected to give the 481 response special meaning: it is used
to indicate that a subscription must be cancelled under all to indicate that a subscription must be cancelled under all
circumstances. circumstances.
NOTIFY requests MUST contain a "Subscription-State" header with a NOTIFY requests MUST contain a "Subscription-State" header with a
value of "active", "pending", or "terminated". The "active" value value of "active", "pending", or "terminated". The "active" value
indicates that the subscription has been accepted and has been indicates that the subscription has been accepted and has been
authorized (in most cases; see section 6.2. ). The "pending" authorized (in most cases; see section 6.2.). The "pending" value
value indicates that the subscription has been received, but that indicates that the subscription has been received, but that
policy information is insufficient to accept or deny the policy information is insufficient to accept or deny the
subscription at this time. The "terminated" value indicates that subscription at this time. The "terminated" value indicates that
the subscription is not active. the subscription is not active.
If the value of the "Subscription-State" header is "active" or If the value of the "Subscription-State" header is "active" or
"pending", the notifier SHOULD also include in the "pending", the notifier SHOULD also include in the
"Subscription-State" header an "expires" parameter which "Subscription-State" header an "expires" parameter which
indicates the time remaining on the subscription. The notifier indicates the time remaining on the subscription. The notifier
MAY use this mechanism to shorten a subscription; however, this MAY use this mechanism to shorten a subscription; however, this
mechanism MUST NOT be used to lengthen a subscription. mechanism MUST NOT be used to lengthen a subscription.
skipping to change at page 15, line 23 skipping to change at page 15, line 41
4.2.3. Proxy NOTIFY Behavior 4.2.3. Proxy NOTIFY Behavior
Proxies need no additional behavior beyond that described in SIP Proxies need no additional behavior beyond that described in SIP
[1] to support NOTIFY. If a proxy wishes to see all of the [1] to support NOTIFY. If a proxy wishes to see all of the
SUBSCRIBE and NOTIFY requests for a given dialog, it MUST SUBSCRIBE and NOTIFY requests for a given dialog, it MUST
record-route the initial SUBSCRIBE and any dialog-establishing record-route the initial SUBSCRIBE and any dialog-establishing
NOTIFY requests. Such proxies SHOULD also record-route all other NOTIFY requests. Such proxies SHOULD also record-route all other
SUBSCRIBE and NOTIFY requests. 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 4.2.4. Subscriber NOTIFY Behavior
Upon receiving a NOTIFY request, the subscriber should check that Upon receiving a NOTIFY request, the subscriber should check that
it matches at least one of its outstanding subscriptions; if not, it matches at least one of its outstanding subscriptions; if not,
it MUST return a "481 Subscription does not exist" response it MUST return a "481 Subscription does not exist" response
unless another 400- or 500-class response is more appropriate. unless another 400- or 500-class response is more appropriate.
The rules for matching NOTIFY requests with subscriptions that The rules for matching NOTIFY requests with subscriptions that
create a new dialog are described in section 4.3.4. Notifications create a new dialog are described in section 4.3.4. Notifications
for subscriptions which were created inside an existing dialog for subscriptions which were created inside an existing dialog
match if they are in the same dialog and the "Event" headers match if they are in the same dialog and the "Event" headers
skipping to change at page 16, line 51 skipping to change at page 17, line 25
"timeout". "timeout".
giveup: The subscription has been terminated because the notifier giveup: The subscription has been terminated because the notifier
could not obtain authorization in a timely fashion. If a could not obtain authorization in a timely fashion. If a
"retry-after" parameter is also present, the client SHOULD "retry-after" parameter is also present, the client SHOULD
wait at least the number of seconds specified by that wait at least the number of seconds specified by that
parameter before attempting to re-subscribe; otherwise, the parameter before attempting to re-subscribe; otherwise, the
client MAY retry immediately, but will likely get put back client MAY retry immediately, but will likely get put back
into pending state. 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 Once the notification is deemed acceptable to the subscriber, the
subscriber SHOULD return a 200 response. In general, it is not subscriber SHOULD return a 200 response. In general, it is not
expected that NOTIFY responses will contain bodies; however, they expected that NOTIFY responses will contain bodies; however, they
MAY, if the NOTIFY request contained an "Accept" header. MAY, if the NOTIFY request contained an "Accept" header.
Other responses defined in SIP [1] may also be returned, as Other responses defined in SIP [1] may also be returned, as
appropriate. In no case should a NOTIFY transaction extend for appropriate. In no case should a NOTIFY transaction extend for
any longer than the time necessary for automated processing. In any longer than the time necessary for automated processing. In
particular, subscribers MUST NOT wait for a user response before particular, subscribers MUST NOT wait for a user response before
returning a final response to a NOTIFY request. returning a final response to a NOTIFY request.
skipping to change at page 17, line 26 skipping to change at page 18, line 6
Neither SUBSCRIBE nor NOTIFY necessitate the use of "Require" or Neither SUBSCRIBE nor NOTIFY necessitate the use of "Require" or
"Proxy-Require" headers; similarly, there is no token defined for "Proxy-Require" headers; similarly, there is no token defined for
"Supported" headers. If necessary, clients may probe for the "Supported" headers. If necessary, clients may probe for the
support of SUBSCRIBE and NOTIFY using the OPTIONS request defined support of SUBSCRIBE and NOTIFY using the OPTIONS request defined
in SIP [1]. in SIP [1].
The presence of the "Allow-Events" header in a message is The presence of the "Allow-Events" header in a message is
sufficient to indicate support for SUBSCRIBE and NOTIFY. sufficient to indicate support for SUBSCRIBE and NOTIFY.
The "methods" parameter for Contact may also be used to The "methods" parameter for Contact may also be used to
specifically announce support for SUBSCRIBE and NOTIFY messages specifically announce support for SUBSCRIBE and NOTIFY
when registering. (See reference [7] for details on the "methods" messages when registering. (See reference [6] for details on
parameter). the "methods" parameter).
4.3.2. CANCEL requests 4.3.2. CANCEL requests
No semantics are associated with cancelling SUBSCRIBE or NOTIFY. No semantics are associated with cancelling SUBSCRIBE or NOTIFY.
4.3.3. Forking 4.3.3. Forking
In accordance with the rules for proxying non-INVITE requests as In accordance with the rules for proxying non-INVITE requests as
defined in SIP [1], successful SUBSCRIBE requests will receive defined in SIP [1], successful SUBSCRIBE requests will receive
only one 200-class response; however, due to forking, the only one 200-class response; however, due to forking, the
skipping to change at page 18, line 6 skipping to change at page 18, line 36
the SUBSCRIBE request was forked. For information on subscriber the SUBSCRIBE request was forked. For information on subscriber
handling in such situations, see section 5.4.9. handling in such situations, see section 5.4.9.
4.3.4. Dialog creation and termination 4.3.4. Dialog creation and termination
If an initial SUBSCRIBE request is not sent on a pre-existing If an initial SUBSCRIBE request is not sent on a pre-existing
dialog, the subscriber will wait for a response to the SUBSCRIBE dialog, the subscriber will wait for a response to the SUBSCRIBE
request or a matching NOTIFY. request or a matching NOTIFY.
Responses are matched to such SUBSCRIBE requests if they contain Responses are matched to such SUBSCRIBE requests if they contain
the same the same "Call-ID", the same "From" header field, the the same the same "Call-ID", the same "From" header "tag", and
same "To" header field, excluding the "tag", and the same "CSeq". the same "CSeq". Rules for the comparison of these headers are
Rules for the comparison of these headers are described in SIP described in SIP [1]. If a 200-class response matches such a
[1]. If a 200-class response matches such a SUBSCRIBE request, SUBSCRIBE request, it creates a new subscription and a new dialog
it creates a new subscription and a new dialog (unless they have (unless they have already been created by a matching NOTIFY
already been created by a matching NOTIFY request; see below). request; see below).
NOTIFY requests are matched to such SUBSCRIBE requests if they NOTIFY requests are matched to such SUBSCRIBE requests if they
contain the same "Call-ID", a "From" header field which matches contain the same "Call-ID", a "To" header "tag" parameter which
the "To" header field of the SUBSCRIBE, excluding the "tag", a matches the "From" header "tag" parameter of the SUBSCRIBE, and
"To" header field which matches the "From" header field of the the same "Event" header field. Rules for comparisons of the
SUBSCRIBE, and the same "Event" header field. Rules for "Event" headers are described in section 7.5.1. If a matching
comparisons of the "Event" headers are described in section NOTIFY request contains a "Subscription-State" of "active" or
7.5.1. If a matching NOTIFY request contains a "pending", it creates a new subscription and a new dialog (unless
"Subscription-State" of "active" or "pending", it creates a new they have already been created by a matching response, as
subscription and a new dialog (unless they have already been described above).
created by a matching response, as described above).
If an initial SUBSCRIBE is sent on a pre-existing dialog, a If an initial SUBSCRIBE is sent on a pre-existing dialog, a
matching 200-class response or successful NOTIFY request merely matching 200-class response or successful NOTIFY request merely
creates a new subscription associated with that dialog. creates a new subscription associated with that dialog.
Multiple subscriptions can be associated with a single dialog. Multiple subscriptions can be associated with a single dialog.
Subscriptions may also exist in dialogs associated with Subscriptions may also exist in dialogs associated with
INVITE-created application state and other application state INVITE-created application state and other application state
created by mechanisms defined in other specifications. These sets created by mechanisms defined in other specifications. These sets
of application state do not interact beyond the behavior of application state do not interact beyond the behavior
skipping to change at page 20, line 6 skipping to change at page 20, line 34
number of seconds remaining in the subscription. number of seconds remaining in the subscription.
Upon receipt of this SUBSCRIBE request, the notifier (or Upon receipt of this SUBSCRIBE request, the notifier (or
notifiers, if the SUBSCRIBE request was forked) will send a notifiers, if the SUBSCRIBE request was forked) will send a
NOTIFY request containing resource state in the same dialog. NOTIFY request containing resource state in the same dialog.
Note that the NOTIFY messages triggered by SUBSCRIBE messages Note that the NOTIFY messages triggered by SUBSCRIBE messages
with "Expires" headers of 0 will contain a "Subscription-State" with "Expires" headers of 0 will contain a "Subscription-State"
value of "terminated", and a "reason" parameter of "timeout". 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 4.3.7. Allow-Events header usage
The "Allow-Events" header, if present, includes a list of tokens The "Allow-Events" header, if present, includes a list of tokens
which indicates the event packages supported by the client (if which indicates the event packages supported by the client (if
sent in a request) or server (if sent in a response). In other sent in a request) or server (if sent in a response). In other
words, a node sending an "Allow-Events" header is advertising words, a node sending an "Allow-Events" header is advertising
that it can process SUBSCRIBE requests and generate NOTIFY that it can process SUBSCRIBE requests and generate NOTIFY
requests for all of the event packages listed in that header. requests for all of the event packages listed in that header.
Any node implementing one or more event packages SHOULD include Any node implementing one or more event packages SHOULD include
skipping to change at page 21, line 6 skipping to change at page 21, line 43
this draft for event notification, it is important to consider: this draft for event notification, it is important to consider:
is SIP an appropriate mechanism for the problem set? Is SIP being is SIP an appropriate mechanism for the problem set? Is SIP being
selected because of some unique feature provided by the protocol selected because of some unique feature provided by the protocol
(e.g. user mobility), or merely because "it can be done?" If you (e.g. user mobility), or merely because "it can be done?" If you
find yourself defining event packages for notifications related find yourself defining event packages for notifications related
to, for example, network management or the temperature inside to, for example, network management or the temperature inside
your car's engine, you may want to reconsider your selection of your car's engine, you may want to reconsider your selection of
protocols. protocols.
Those interested in extending the mechanism defined in this Those interested in extending the mechanism defined in this
document are urged to read "Guidelines for Authors of SIP document are urged to follow the development of "Guidelines
Extensions" [2] for further guidance regarding appropriate for Authors of SIP Extensions"[2] for further guidance
uses of SIP. regarding appropriate uses of SIP.
Further, it is expected that this mechanism is not to be used in Further, it is expected that this mechanism is not to be used in
applications where the frequency of reportable events is applications where the frequency of reportable events is
excessively rapid (e.g. more than about once per second). A SIP excessively rapid (e.g. more than about once per second). A SIP
network is generally going to be provisioned for a reasonable network is generally going to be provisioned for a reasonable
signalling volume; sending a notification every time a user's GPS signalling volume; sending a notification every time a user's GPS
position changes by one hundreth of a second could easily position changes by one hundreth of a second could easily
overload such a network. overload such a network.
5.2. Event Template-packages 5.2. Event Template-packages
skipping to change at page 22, line 39 skipping to change at page 23, line 27
the event package may choose to detail a scheme by which NOTIFY the event package may choose to detail a scheme by which NOTIFY
messages contain state deltas instead of complete state. messages contain state deltas instead of complete state.
Such a scheme would work as follows: any NOTIFY sent in immediate Such a scheme would work as follows: any NOTIFY sent in immediate
response to a SUBSCRIBE contains full state information. NOTIFY response to a SUBSCRIBE contains full state information. NOTIFY
messages sent because of a state change will contain only the messages sent because of a state change will contain only the
state information that has changed; the subscriber will then state information that has changed; the subscriber will then
merge this information into its current knowledge about the state merge this information into its current knowledge about the state
of the resource. of the resource.
Any event package that supports delta changes to states MUST use Any event package that supports delta changes to states MUST
a payload which contains a version number that increases by include a version number that increases by exactly one for each
exactly one for each NOTIFY message. Note that the state version NOTIFY message in a subscription. Note that the state version
number appears in the body of the message, not in a SIP header. 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 If a NOTIFY arrives that has a version number that is incremented
by more than one, the subscriber knows that a state delta has by more than one, the subscriber knows that a state delta has
been missed; it ignores the NOTIFY message containing the state been missed; it ignores the NOTIFY message containing the state
delta (except for the version number, which it retains to detect delta (except for the version number, which it retains to detect
message loss), and re-sends a SUBSCRIBE to force a NOTIFY message loss), and re-sends a SUBSCRIBE to force a NOTIFY
containing a complete state snapshot. containing a complete state snapshot.
5.4. Event Package Responsibilities 5.4. Event Package Responsibilities
skipping to change at page 23, line 14 skipping to change at page 23, line 52
described in this document, although they may choose to do so for described in this document, although they may choose to do so for
clarity or emphasis. In general, though, such packages are clarity or emphasis. In general, though, such packages are
expected to describe only the behavior that extends or modifies expected to describe only the behavior that extends or modifies
the behavior described in this document. the behavior described in this document.
Note that any behavior designated with "SHOULD" or "MUST" in this Note that any behavior designated with "SHOULD" or "MUST" in this
document is not allowed to be weakened by extension documents; document is not allowed to be weakened by extension documents;
however, such documents may elect to strengthen "SHOULD" however, such documents may elect to strengthen "SHOULD"
requirements to "MUST" strength if required by their application. requirements to "MUST" strength if required by their application.
In addition to the normal sections expected by "Instructions In addition to the normal sections expected in
to RFC Authors" [5] and "Guidelines for Authors of SIP standards-track RFCs and SIP extension documents, authors of
Extensions" [2], authors of event packages need to address event packages need to address each of the issues detailed in
each of the issues detailed in the following subsections, the following subsections, whenever applicable.
whenever applicable.
5.4.1. Event Package Name 5.4.1. Event Package Name
This section, which MUST be present, defines the token name to be This section, which MUST be present, defines the token name to be
used to designate the event package. It MUST include the used to designate the event package. It MUST include the
information which appears in the IANA registration of the token. information which appears in the IANA registration of the token.
For information on registering such types, see section 7. For information on registering such types, see section 7.
5.4.2. Event Package Parameters 5.4.2. Event Package Parameters
skipping to change at page 24, line 8 skipping to change at page 24, line 45
5.4.4. Subscription Duration 5.4.4. Subscription Duration
It is RECOMMENDED that event packages give a suggested range of It is RECOMMENDED that event packages give a suggested range of
times considered reasonable for the duration of a subscription. times considered reasonable for the duration of a subscription.
Such packages MUST also define a default "Expires" value to be Such packages MUST also define a default "Expires" value to be
used if none is specified. used if none is specified.
5.4.5. NOTIFY Bodies 5.4.5. NOTIFY Bodies
The NOTIFY body is used to report state on the resource being 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 bodies are expected in NOTIFY requests. Such packages MUST
specify or cite detailed specifications for the syntax and specify or cite detailed specifications for the syntax and
semantics associated with such event body. semantics associated with such event body.
Event packages also MUST define which MIME type is to be assumed Event packages also MUST define which MIME type is to be assumed
if none are specified in the "Accept" header of the SUBSCRIBE if none are specified in the "Accept" header of the SUBSCRIBE
request. request.
5.4.6. Notifier processing of SUBSCRIBE requests 5.4.6. Notifier processing of SUBSCRIBE requests
skipping to change at page 24, line 51 skipping to change at page 25, line 39
the subsequent response. the subsequent response.
5.4.8. Subscriber processing of NOTIFY requests 5.4.8. Subscriber processing of NOTIFY requests
This section of an event package describes the process followed This section of an event package describes the process followed
by the subscriber upon receipt of a NOTIFY request, including any by the subscriber upon receipt of a NOTIFY request, including any
logic required to form a coherent resource state (if applicable). logic required to form a coherent resource state (if applicable).
5.4.9. Handling of forked requests 5.4.9. Handling of forked requests
Each event package SHOULD specify whether forked SUBSCRIBE Each event package MUST specify whether forked SUBSCRIBE requests
requests are allowed to install multiple subscriptions. are allowed to install multiple subscriptions.
If such behavior is not allowed, the first potential If such behavior is not allowed, the first potential
dialog-establishing message will create a dialog. All subsequent dialog-establishing message will create a dialog. All subsequent
NOTIFY messages which correspond to the SUBSCRIBE message (i.e. NOTIFY messages which correspond to the SUBSCRIBE message (i.e.
match "To", "From", "From" header "tag" parameter, "Call-ID", match "To", "From", "From" header "tag" parameter, "Call-ID",
"CSeq", "Event", and "Event" header "id" parameter) but which do "CSeq", "Event", and "Event" header "id" parameter) but which do
not match the dialog would be rejected with a 481 response. Note not match the dialog would be rejected with a 481 response. Note
that the 200-class response to the SUBSCRIBE can arrive after a that the 200-class response to the SUBSCRIBE can arrive after a
matching NOTIFY has been received; such responses might not matching NOTIFY has been received; such responses might not
correlate to the same dialog established by the NOTIFY. Except as correlate to the same dialog established by the NOTIFY. Except as
skipping to change at page 25, line 31 skipping to change at page 26, line 17
refreshed independent of the other dialogs. refreshed independent of the other dialogs.
In the case that multiple subscriptions are allowed, the event In the case that multiple subscriptions are allowed, the event
package MUST specify whether merging of the notifications to form package MUST specify whether merging of the notifications to form
a single state is required, and how such merging is to be a single state is required, and how such merging is to be
performed. Note that it is possible that some event packages may 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 be defined in such a way that each dialog is tied to a mutually
exclusive state which is unaffected by the other dialogs; this exclusive state which is unaffected by the other dialogs; this
MUST be clearly stated if it is the case. 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 5.4.10. Rate of notifications
Each event package is expected to define a requirement (SHOULD or Each event package is expected to define a requirement (SHOULD or
MUST strength) which defines an absolute maximum on the rate at MUST strength) which defines an absolute maximum on the rate at
which notifications are allowed to be generated by a single which notifications are allowed to be generated by a single
notifier. notifier.
Such packages MAY further define a throttle mechanism which Each package MAY further define a throttle mechanism which allows
allows subscribers to further limit the rate of notification. subscribers to further limit the rate of notification.
5.4.11. State Agents 5.4.11. State Agents
Designers of event packages should consider whether their package Designers of event packages should consider whether their package
can benefit from network aggregation points (state agents) and/or can benefit from network aggregation points (state agents) and/or
nodes which act on behalf of other nodes. (For example, nodes nodes which act on behalf of other nodes. (For example, nodes
which provide state information about a resource when such a which provide state information about a resource when such a
resource is unable or unwilling to provide such state information resource is unable or unwilling to provide such state information
itself). An example of such an application is a node which tracks itself). An example of such an application is a node which tracks
the presence and availability of a user in the network. the presence and availability of a user in the network.
skipping to change at page 26, line 21 skipping to change at page 27, line 5
Event packages SHOULD include several demonstrative message flow Event packages SHOULD include several demonstrative message flow
diagrams paired with several typical, syntactically correct and diagrams paired with several typical, syntactically correct and
complete messages. complete messages.
It is RECOMMENDED that documents describing event packages It is RECOMMENDED that documents describing event packages
clearly indicate that such examples are informative and not clearly indicate that such examples are informative and not
normative, with instructions that implementors refer to the main normative, with instructions that implementors refer to the main
text of the draft for exact protocol details. 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 Some types of event packages may define state information which
is potentially too large to reasonably send in a SIP message. To is potentially too large to reasonably send in a SIP message. To
alleviate this problem, event packages may include the ability to alleviate this problem, event packages may include the ability to
use a MIME body type of "application/uri-list" in NOTIFY convey a URI instead of state information; this URI will then be
messages. The URI or URIs contained in the NOTIFY body will then used to retrieve the actual state information.
be used to retrieve the actual state information.
If an event package elects to use this mechanism, it MUST define The precise mechanisms for conveying such URIs are out of the
at least one baseline scheme (e.g. http) which is mandatory to scope of this document.
support, as well as one mandatory baseline data format for the
data so retrieved. Event packages using URIs to retrieve state
information also MUST address the duration of the validity of the
URIs passed to a subscriber in this fashion.
6. Security Considerations 6. Security Considerations
6.1. Access Control 6.1. Access Control
The ability to accept subscriptions should be under the direct The ability to accept subscriptions should be under the direct
control of the user, since many types of events may be considered control of the notifier's user, since many types of events may be
sensitive for the purposes of privacy. Similarly, the notifier considered sensitive for the purposes of privacy. Similarly, the
should have the ability to selectively reject subscriptions based notifier should have the ability to selectively reject
on the subscriber identity (based on access control lists), using subscriptions based on the subscriber identity (based on access
standard SIP authentication mechanisms. The methods for creation control lists), using standard SIP authentication mechanisms. The
and distribution of such access control lists is outside the methods for creation and distribution of such access control
scope of this draft. 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 The mere act of returning a 200 or certain 4xx and 6xx responses
to SUBSCRIBE requests may, under certain circumstances, create to SUBSCRIBE requests may, under certain circumstances, create
privacy concerns by revealing sensitive policy information. In privacy concerns by revealing sensitive policy information. In
these cases, the notifier SHOULD always return a 202 response. these cases, the notifier SHOULD always return a 202 response.
While the subsequent NOTIFY message may not convey true state, it While the subsequent NOTIFY message may not convey true state, it
MUST appear to contain a potentially correct piece of data from MUST appear to contain a potentially correct piece of data from
the point of view of the subscriber, indistinguishable from a the point of view of the subscriber, indistinguishable from a
valid response. Information about whether a user is authorized to valid response. Information about whether a user is authorized to
subscribe to the requested state is never conveyed back to the subscribe to the requested state is never conveyed back to the
original user under these circumstances. 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 6.3. Denial-of-Service attacks
The current model (one SUBSCRIBE request triggers a SUBSCRIBE The current model (one SUBSCRIBE request triggers a SUBSCRIBE
response and one or more NOTIFY requests) is a classic setup for response and one or more NOTIFY requests) is a classic setup for
an amplifier node to be used in a smurf attack. an amplifier node to be used in a smurf attack.
Also, the creation of state upon receipt of a SUBSCRIBE request Also, the creation of state upon receipt of a SUBSCRIBE request
can be used by attackers to consume resources on a victim's can be used by attackers to consume resources on a victim's
machine, rendering it unusable. machine, rendering it unusable.
skipping to change at page 27, line 37 skipping to change at page 28, line 23
6.4. Replay Attacks 6.4. Replay Attacks
Replaying of either SUBSCRIBE or NOTIFY can have detrimental Replaying of either SUBSCRIBE or NOTIFY can have detrimental
effects. effects.
In the case of SUBSCRIBE messages, attackers may be able to In the case of SUBSCRIBE messages, attackers may be able to
install any arbitrary subscription which it witnessed being install any arbitrary subscription which it witnessed being
installed at some point in the past. Replaying of NOTIFY messages installed at some point in the past. Replaying of NOTIFY messages
may be used to spoof old state information (although a good may be used to spoof old state information (although a good
versioning mechanism in the body of the NOTIFY messages may help 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 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 6.5. Man-in-the middle attacks
Even with authentication, man-in-the-middle attacks using Even with authentication, man-in-the-middle attacks using
SUBSCRIBE may be used to install arbitrary subscriptions, hijack SUBSCRIBE may be used to install arbitrary subscriptions, hijack
existing subscriptions, terminate outstanding subscriptions, or existing subscriptions, terminate outstanding subscriptions, or
modify the resource to which a subscription is being made. To modify the resource to which a subscription is being made. To
prevent such attacks, implementations SHOULD provide integrity prevent such attacks, implementations SHOULD provide integrity
protection across "Contact", "Route", "Expires", "Event", and protection across "Contact", "Route", "Expires", "Event", and
"To" headers of SUBSCRIBE messages, at a minimum. If SUBSCRIBE "To" headers of SUBSCRIBE messages, at a minimum. If SUBSCRIBE
skipping to change at page 28, line 48 skipping to change at page 29, line 36
central coordinating body. The body chosen for this coordination central coordinating body. The body chosen for this coordination
is the Internet Assigned Numbers Authority (IANA). is the Internet Assigned Numbers Authority (IANA).
There are two different types of event-types: normal event There are two different types of event-types: normal event
packages, and event template-packages; see section 5.2. To avoid packages, and event template-packages; see section 5.2. To avoid
confusion, template-package names and package names share the confusion, template-package names and package names share the
same namespace; in other words, an event template-package MUST same namespace; in other words, an event template-package MUST
NOT share a name with a package. NOT share a name with a package.
Following the policies outlined in "Guidelines for Writing an 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, identification tokens are allocated as First Come First Served,
and event template-package identification tokens are allocated on and event template-package identification tokens are allocated on
a IETF Consensus basis. a IETF Consensus basis.
Registrations with the IANA MUST include the token being Registrations with the IANA MUST include the token being
registered and whether the token is a package or a registered and whether the token is a package or a
template-package. Further, packages MUST include contact template-package. Further, packages MUST include contact
information for the party responsible for the registration and/or information for the party responsible for the registration and/or
a published document which describes the event package. Event a published document which describes the event package. Event
template-package token registrations MUST include a pointer to template-package token registrations MUST include a pointer to
skipping to change at page 30, line 25 skipping to change at page 31, line 16
(Template packages require a published RFC. Other packages (Template packages require a published RFC. Other packages
may reference a specification when appropriate). may reference a specification when appropriate).
Person & email address to contact for further information: Person & email address to contact for further information:
7.3. Syntax 7.3. Syntax
This section describes the syntax extensions required for event This section describes the syntax extensions required for event
notification in SIP. Semantics are described in section 4. Note notification in SIP. Semantics are described in section 4. Note
that the formal syntax definitions described in this document are 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. references to elements defined therein.
7.4. New Methods 7.4. New Methods
This document describes two new SIP methods: SUBSCRIBE and This document describes two new SIP methods: SUBSCRIBE and
NOTIFY. NOTIFY.
This table expands on tables 2 and 3 in SIP [1]. This table expands on tables 2 and 3 in SIP [1].
Header Where SUB NOT Header Where SUB NOT
skipping to change at page 34, line 30 skipping to change at page 35, line 21
extension-substate = token extension-substate = token
subexp-params = ("reason" EQUAL reason-value) subexp-params = ("reason" EQUAL reason-value)
/ ("expires" EQUAL delta-seconds) / ("expires" EQUAL delta-seconds)
/ ("retry-after" EQUAL delta-seconds) / ("retry-after" EQUAL delta-seconds)
/ generic-param / generic-param
reason-value = "deactivated" reason-value = "deactivated"
/ "probation" / "probation"
/ "rejected" / "rejected"
/ "timeout" / "timeout"
/ "giveup" / "giveup"
/ "noresource"
/ reason-extension / reason-extension
reason-extension = token reason-extension = token
8. Changes 8. References
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.
9. References NOTE: Non-normative references are so labeled.
[1] J. Rosenberg et. al., "SIP: Session Initiation Protocol", [1] J. Rosenberg et. al., "SIP: Session Initiation Protocol",
<draft-ietf-sip-rfc2543bis-07>, IETF; February 2002. Work in <draft-ietf-sip-rfc2543bis-07>, IETF; February 2002. Work in
progress. progress.
[2] J. Rosenberg, H. Schulzrinne, "Guidelines for Authors of SIP [2] J. Rosenberg, H. Schulzrinne, "Guidelines for Authors of SIP
Extensions", <draft-ietf-sip-guidelines-03.txt>, IETF; Extensions", <draft-ietf-sip-guidelines-03.txt>, IETF;
November 2001. Work in progress. November 2001. Work in progress. Non-normative.
[3] S. Petrack, L. Conroy, "The PINT Service Protocol", RFC 2848, [3] S. Petrack, L. Conroy, "The PINT Service Protocol", RFC 2848,
IETF; June 2000. IETF; June 2000.
[4] R. Fielding et. al., "Hypertext Transfer Protocol -- [4] R. Fielding et. al., "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, IETF, June 1999. HTTP/1.1", RFC 2616, IETF, June 1999.
[5] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC [5] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
2223, IETF, October 1997.
[6] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, IETF, October 1998. 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", <draft-ietf-sip-callerprefs-05.txt>, IETF; Capabilities", <draft-ietf-sip-callerprefs-05.txt>, 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 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 Thanks to the participants in the Events BOF at the 48th IETF
meeting in Pittsburgh, as well as those who gave ideas and meeting in Pittsburgh, as well as those who gave ideas and
suggestions on the SIP Events mailing list. In particular, I wish suggestions on the SIP Events mailing list. In particular, I wish
to thank Henning Schulzrinne of Columbia University for coming up to thank Henning Schulzrinne of Columbia University for coming up
with the final three-tiered event identification scheme, Sean with the final three-tiered event identification scheme, Sean
Olson for miscellaneous guidance, Jonathan Rosenberg for a Olson for miscellaneous guidance, Jonathan Rosenberg for a
thorough scrubbing of the -00 draft, and the authors of the "SIP thorough scrubbing of the -00 draft, and the authors of the "SIP
Extensions for Presence" draft for their input to SUBSCRIBE and Extensions for Presence" draft for their input to SUBSCRIBE and
NOTIFY request semantics. NOTIFY request semantics.
11. Author's Address 10. Author's Address
Adam Roach Adam Roach
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75024 Plano, TX 75024
USA USA
E-Mail: <adam@dynamicsoft.com> E-Mail: <adam@dynamicsoft.com>
Voice: <sip:adam@dynamicsoft.com> Voice: <sip:adam@dynamicsoft.com>
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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/