draft-ietf-sip-events-01.txt   draft-ietf-sip-events-02.txt 
Internet Engineering Task Force Adam Roach Internet Engineering Task Force Adam Roach
Internet Draft Ericsson Inc. Internet Draft dynamicsoft
Category: Standards Track November 2001 Category: Standards Track February 2002
Expires May 2002 Expires August 2002
<draft-ietf-sip-events-01.txt> <draft-ietf-sip-events-02.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 1, line 54 skipping to change at page 1, line 54
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
3. Syntax................................................. 4 3. Definitions............................................ 4
3.1. New Methods............................................ 4 4. Node Behavior.......................................... 5
3.1.1. SUBSCRIBE method....................................... 5 4.1. Description of SUBSCRIBE Behavior...................... 5
3.1.2. NOTIFY method.......................................... 6 4.1.1. Subscription duration.................................. 5
3.2. New Headers............................................ 6 4.1.2. Identification of Subscribed Events and Event Classes.. 6
3.2.1. "Event" header......................................... 6 4.1.3. Additional SUBSCRIBE Header Values..................... 6
3.2.2. "Allow-Events" Header.................................. 7 4.1.4. Subscriber SUBSCRIBE Behavior.......................... 7
3.2.3. "Subscription-Expires" Header.......................... 7 4.1.5. Proxy SUBSCRIBE Behavior............................... 8
3.3. New Response Codes..................................... 7 4.1.6. Notifier SUBSCRIBE Behavior............................ 9
3.3.1. "202 Accepted" Response Code........................... 8 4.2. Description of NOTIFY Behavior......................... 11
3.3.2. "489 Bad Event" Response Code.......................... 8 4.2.1. Identification of reported events, event classes, and c 12
4. Node Behavior.......................................... 8 4.2.2. Notifier NOTIFY Behavior............................... 12
4.1. General................................................ 8 4.2.3. Proxy NOTIFY Behavior.................................. 14
4.1.1. Route Handling......................................... 8 4.2.4. Subscriber NOTIFY Behavior............................. 14
4.1.2. Detecting support for SUBSCRIBE and NOTIFY............. 9 4.3. General................................................ 16
4.1.3. CANCEL requests........................................ 9 4.3.1. Detecting support for SUBSCRIBE and NOTIFY............. 16
4.1.4. State Agents and Notifier Migration.................... 9 4.3.2. CANCEL requests........................................ 16
4.2. Description of SUBSCRIBE Behavior...................... 10 4.3.3. Forking................................................ 16
4.2.1. Correlation to dialogs, calls, and terminals........... 10 4.3.4. Dialog creation and termination........................ 17
4.2.2. Subscription duration.................................. 11 4.3.5. State Agents and Notifier Migration.................... 18
4.2.3. Identification of Subscribed Events and Event Classes.. 11 4.3.6. Polling Resource State................................. 18
4.2.4. Additional SUBSCRIBE Header Values..................... 12 4.3.7. Allow-Events header usage.............................. 19
4.2.5. Subscriber SUBSCRIBE Behavior.......................... 12 4.3.8. PINT Compatibility..................................... 19
4.2.6. Proxy SUBSCRIBE Behavior............................... 14 5. Event Packages......................................... 19
4.2.7. Notifier SUBSCRIBE Behavior............................ 14 5.1. Appropriateness of Usage............................... 19
4.3. Description of NOTIFY Behavior......................... 17 5.2. Event Template-packages................................ 20
4.3.1. Correlation............................................ 17 5.3. Amount of State to be Conveyed......................... 20
4.3.2. Identification of reported events, event classes, and c 18 5.3.1. Complete State Information............................. 21
4.3.3. Notifier NOTIFY Behavior............................... 18 5.3.2. State Deltas........................................... 21
4.3.4. Proxy NOTIFY Behavior.................................. 20 5.4. Event Package Responsibilities......................... 22
4.3.5. Subscriber NOTIFY Behavior............................. 20 5.4.1. Event Package Name..................................... 22
4.4. Polling Resource State................................. 21 5.4.2. Event Package Parameters............................... 22
4.5. Allow-Events header usage.............................. 21 5.4.3. SUBSCRIBE Bodies....................................... 22
5. Event Packages......................................... 21 5.4.4. Subscription Duration.................................. 22
5.1. Appropriateness of Usage............................... 22 5.4.5. NOTIFY Bodies.......................................... 23
5.2. Sub-packages........................................... 22 5.4.6. Notifier processing of SUBSCRIBE requests.............. 23
5.3. Amount of State to be Conveyed......................... 23 5.4.7. Notifier generation of NOTIFY requests................. 23
5.3.1. Complete State Information............................. 23 5.4.8. Subscriber processing of NOTIFY requests............... 23
5.3.2. State Deltas........................................... 23 5.4.9. Handling of forked requests............................ 23
5.4. Event Package Responsibilities......................... 24 5.4.10. Rate of notifications.................................. 24
5.4.1. Event Package Name..................................... 24 5.4.11. State Agents........................................... 24
5.4.2. Event Package Parameters............................... 24 5.4.12. Examples............................................... 25
5.4.3. SUBSCRIBE Bodies....................................... 24 5.4.13. URI List handling...................................... 25
5.4.4. Subscription Duration.................................. 25 6. Security Considerations................................ 25
5.4.5. NOTIFY Bodies.......................................... 25 6.1. Access Control......................................... 25
5.4.6. Notifier processing of SUBSCRIBE requests.............. 25 6.2. Release of Sensitive Policy Information................ 25
5.4.7. Notifier generation of NOTIFY requests................. 25 6.3. Denial-of-Service attacks.............................. 26
5.4.8. Subscriber processing of NOTIFY requests............... 25 6.4. Replay Attacks......................................... 26
5.4.9. Handling of forked requests............................ 26 6.5. Man-in-the middle attacks.............................. 26
5.4.10. Rate of notifications.................................. 26 6.6. Confidentiality........................................ 27
5.4.11. State Agents........................................... 26
5.4.12. Examples............................................... 26
6. Security Considerations................................ 27
6.1. Access Control......................................... 27
6.2. Release of Sensitive Policy Information................ 27
6.3. Denial-of-Service attacks.............................. 27
7. IANA Considerations.................................... 27 7. IANA Considerations.................................... 27
7.1. Registration Template.................................. 28 7.1. Registration Information............................... 28
8. Open Issues............................................ 29 7.2. Registration Template.................................. 28
8.1. CANCEL Handling........................................ 29 7.3. Syntax................................................. 29
8.2. Version of SIP to reference............................ 29 7.4. New Methods............................................ 29
8.3. Immediate NOTIFYs...................................... 30 7.4.1. SUBSCRIBE method....................................... 31
9. Changes................................................ 30 7.4.2. NOTIFY method.......................................... 31
9.1. Changes from draft-ietf-...-00......................... 30 7.5. New Headers............................................ 31
9.2. Changes from draft-roach-...-03........................ 31 7.5.1. "Event" header......................................... 31
9.3. Changes from draft-roach-...-02........................ 33 7.5.2. "Allow-Events" Header.................................. 32
9.4. Changes from draft-roach-...-01........................ 35 7.5.3. "Subscription-State" Header............................ 32
10. References............................................. 35 7.6. New Response Codes..................................... 33
11. Acknowledgements....................................... 36 7.6.1. "202 Accepted" Response Code........................... 33
12. Author's Address....................................... 36 7.6.2. "489 Bad Event" Response Code.......................... 33
8. Changes................................................ 33
8.1. Changes from draft-ietf-...-01......................... 33
8.2. Changes from draft-ietf-...-00......................... 35
8.3. Changes from draft-roach-...-03........................ 36
8.4. Changes from draft-roach-...-02........................ 38
8.5. Changes from draft-roach-...-01........................ 39
9. References............................................. 40
10. Acknowledgements....................................... 41
11. Author's Address....................................... 41
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 services for which cooperation between
end-nodes is required. Examples of such services include 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 PINT
status (based on call state events). status (based on call state events).
skipping to change at page 4, line 24 skipping to change at page 4, line 27
A typical flow of messages would be: A typical flow of messages would be:
Subscriber Notifier Subscriber Notifier
|-----SUBSCRIBE---->| Request state subscription |-----SUBSCRIBE---->| Request state subscription
|<-------200--------| Acknowledge subscription |<-------200--------| Acknowledge subscription
|<------NOTIFY----- | Return current state information |<------NOTIFY----- | Return current state information
|--------200------->| |--------200------->|
|<------NOTIFY----- | Return current state information |<------NOTIFY----- | Return current state information
|--------200------->| |--------200------->|
The subscriber and notifier entities need not necessarily be UAs, Subscriptions are expired and must be refreshed by subsequent
but often will be. SUBSCRIBE messages.
Subscriptions are expired and must be refreshed in exactly the
same manner as registrations (see RFC 2543 [1] ).
3. Syntax
This section describes the syntax extensions required for event
notification in SIP. Semantics are described in section 4.
3.1. New Methods
This document describes two new SIP methods: "SUBSCRIBE" and
"NOTIFY."
This table expands on tables 4 and 5 in RFC 2543 [1] .
Header Where SUB NOT
------ ----- --- ---
Accept R o o
Accept-Encoding R o o
Accept-Language R o o
Allow 200 - -
Allow 405 o o
Authorization R o o
Call-ID gc m m
Contact R m m
Contact 1xx o o
Contact 2xx m o
Contact 3xx m m
Contact 485 o o
Content-Encoding e o o
Content-Length e o o
Content-Type e * *
CSeq gc m m
Date g o o
Encryption g o o
Expires g o -
From gc m m
Hide R o o
Max-Forwards R o o
Organization g o o
Priority R o o
Proxy-Authenticate 407 o o
Proxy-Authorization R o o
Proxy-Require R o o
Require R o o
Retry-After R - -
Retry-After 404,480,486 o o
Retry-After 503 o o
Retry-After 600,603 o o
Response-Key R o o
Record-Route R o o
Record-Route 2xx o o
Route R o o
Server r o o
Subject R o o
Timestamp g o o
To gc(1) m m
Unsupported 420 o o
User-Agent g o o
Via gc(2) m m
Warning r o o
WWW-Authenticate 401 o o
3.1.1. SUBSCRIBE method
"SUBSCRIBE" is added to the definition of the element "Method" in
the SIP message grammar.
Like all SIP method names, the SUBSCRIBE method name is case
sensitive. The SUBSCRIBE method is used to request asynchronous
notification of an event or set of events at a later time.
3.1.2. NOTIFY method
"NOTIFY" is added to the definition of the element "Method" in
the SIP message grammar.
The NOTIFY method is used to notify a SIP node that an event
which has been requested by an earlier SUBSCRIBE method has
occurred. It may also provide further details about the event.
3.2. New Headers
This table expands on tables 4 and 5 in RFC 2543 [1] , as amended
by the changes described in section 3.1.
Header field where proxy ACK BYE CAN INV OPT REG SUB NOT
-----------------------------------------------------------------
Allow-Events g o o o o o o o o
Allow-Events 489 - - - - - - m m
Event R - - - - - - m m
Subscription-Expires R - - - - - - - o
3.2.1. "Event" header
The following header is defined for the purposes of this
specification.
Event = ( "Event" | "o" ) ":" event-type
*(( ";" parameter-name
["=" ( token | quoted-string ) ] )
event-type = event-package *( "." event-subpackage )
event-package = token-nodot
event-subpackage = token-nodot
token-nodot = 1*( alphanum | "-" | "!" | "%" | "*"
| "_" | "+" | "`" | "'" | "~" )
Event is added to the definition of the element "request-header"
in the SIP message grammar.
This document does not define values for event-types. These
values will be defined by individual event packages, and MUST be
registered with the IANA.
There must be exactly one event type listed per event header.
Multiple events per message are disallowed.
For the curious, the "o" short form is chosen to represent
"occurrence."
3.2.2. "Allow-Events" Header
The following header is defined for the purposes of this
specification.
Allow-Events = ( "Allow-Events" | "u" ) ":" 1#event-type
Allow-Events is added to the definition of the element
"general-header" in the SIP message grammar.
For the curious, the "u" short form is chosen to represent
"understands."
3.2.3. "Subscription-Expires" Header
The following header is defined for the purposes of this
specification.
Subscription-Expires = "Subscription-Expires" ":"
( SIP-date | delta-seconds )
*( ";" subexp-params )
subexp-params = "reason" "=" reason-code
| generic-param
reason-code = "migration"
| "maint"
| "refused"
| "timeout"
| reason-extension
reason-extension = token
Subscription-Expires is added to the definition of the element
"request-header" in the SIP message grammar.
3.3. New Response Codes 3. Definitions
3.3.1. "202 Accepted" Response Code 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.
The 202 response is added to the "Success" header field Event Template-Package: An event template-package is a special
definition: kind of event package which defines a set of state which may
be applied to all possible event packages, including itself.
Success = "200" ; OK Notification: Notification is the act of a notifier sending a
| "202" ; Accepted NOTIFY message to a subscriber to inform the subscriber of
the state of a resource.
"202 Accepted" has the same meaning as that defined in HTTP/1.1 Notifier: A notifier is a user agent which generates NOTIFY
[5] . requests for the purpose of notifying subscribers of the
state of a resource. Notifiers typically also accept
SUBSCRIBE requests to create subscriptions.
3.3.2. "489 Bad Event" Response Code 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 gather such state information from multiple sources.
State Agents always have complete state information for the
resource for which it is creating notifications.
The 489 event response is added to the "Client-Error" header Subscriber: A subscriber is a user agent which receives NOTIFY
field definition: 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.
Client-Error = "400" ; Bad Request Subscription: A subscription is a set of application state
... associated with a dialog. This application state includes a
| "489" ; Bad Event pointer to the associated dialog, the event package name, and
possibly an identification token. Event packages will define
additional subscription state information. By definition,
subscriptions exist in both a subscriber and a notifier.
"489 Bad Event" is used to indicate that the server did not Subscription Migration: Subscription migration is the act of
understand the event package specified in a "Event" header field. moving a subscription from one notifier to another notifier.
4. Node Behavior 4. Node Behavior
4.1. General 4.1. Description of SUBSCRIBE Behavior
Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the
same protocol rules governing the usage of tags, Route handling,
Record-Route handling, Via handling, and Contact handling as
INVITE; retransmission, reliability, CSeq handling and
provisional responses are the same as those defined for BYE.
For the purposes of this document, a "dialog" is defined as all
messages sharing the tuple of "To" (including tag), "From"
(including tag), and "Call-Id." As in INVITE-initiated dialogs,
requests containg no "To" tag are also considered to be part of
the same dialog as messages which contain a "To" tag but
otherwise match.
4.1.1. Route Handling
Route and Record-Route handling for SUBSCRIBE and NOTIFY dialogs
is generally the same as for INVITE and its subsequent responses.
The exact method for echoing Record-Route headers in responses
and using them to form Route headers in subsequent requests is
described in RFC2543 [1] . For the purposes of the following
discussion, the "Contact" header is considered part of the
"Record-Route" set.
From a subscriber perspective, the "Record-Route" headers
received in a SUBSCRIBE response are stored locally and placed in
the "Route" headers for SUBSCRIBE refreshes. To support forking
of SUBSCRIBE requests, "Record-Route" headers received in NOTIFY
requests MUST be echoed back in the NOTIFY responses; if no route
for the dialog has been established, these "Record-Route" headers
MUST be stored locally and MUST be placed in the "Route" headers
for SUBSCRIBE refreshes.
From a notifier perspective, SUBSCRIBE request "Record-Route"
headers are echoed back in the SUBSCRIBE response and stored
locally. The locally stored copy of the "Record-Route" headers is
placed in the "Route" headers when generating NOTIFY requests.
The result of the forgoing rules is that proxies wishing to
remain on the signalling path for subsequent requests in the
dialog MUST include themselves in a "Record-Route" for all
requests, not just the initial SUBSCRIBE.
4.1.2. Detecting support for SUBSCRIBE and NOTIFY
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 RFC2543 [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 [8] for details on the "methods"
parameter).
4.1.3. CANCEL requests
For the purposes of generality, both SUBSCRIBE and NOTIFY MAY be
canceled; however, doing so is not recommended. Successfully
cancelled SUBSCRIBE and NOTIFY requests MUST be completed with a
"487 Request Cancelled" response; the server acts as if the
request were never received. In general, since neither SUBSCRIBE
nor NOTIFY are allowed to have protracted transactions, attempts
to cancel them are expected to fail.
4.1.4. State Agents and Notifier Migration
When state agents (see section 5.4.11. ) are used, it is often
useful to allow migration of subscriptions between state agents
and the nodes for which they are providing state aggregation (or
even among various state agents). Such migration may be effected
by sending a "NOTIFY" with an "Subscription-Expires" header of
"0," and a reason parameter of "migration." This NOTIFY request
is otherwise normal, and is formed as described in section 4.3.3.
Upon receipt of this NOTIFY message, the subscriber SHOULD
attempt to re-subscribe (as described in the following sections).
The resulting SUBSCRIBE message can then be proxied or redirected
to the node to which notification responsibility is passing.
4.2. Description of SUBSCRIBE Behavior
The SUBSCRIBE method is used to request current state and state The SUBSCRIBE method is used to request current state and state
updates from a remote node. updates from a remote node.
4.2.1. Correlation to dialogs, calls, and terminals 4.1.1. Subscription duration
A subscription is uniquely identified by the combination of the
To, From, and Call-ID fields in the SUBSCRIBE request. Refreshes
of subscriptions SHOULD reuse the same Call-ID if possible, since
subscriptions are uniquely identified at presence servers using
the Call-ID. Two subscriptions from the same user, for the same
user, but with different Call-IDs, are considered different
subscriptions. Note this is exactly the same as usage of Call-ID
in registrations.
Initial SUBSCRIBE requests MUST contain a "tag" parameter (as
defined in RFC 2543 [1] ) in the "From" header, and MUST NOT
contain a "tag" parameter in the "To" header. Responses to
SUBSCRIBE requests MUST contain a "tag" parameter in the "To"
header.
The "tag" in the "To" header allows the subscriber to
differentiate between NOTIFY requests from different clients in
the case that the SUBSCRIBE request was forked. SUBSCRIBE
requests for re-subscription MUST contain "tag" parameters in
both the "To" and "From" headers (matching those previously
established for the dialog).
The relationship between subscriptions and (INVITE-initiated)
sessions sharing the same dialog correlation information is
undefined. Re-using dialog correlation information for
subscriptions is allowed, but sharing of such information does
not change the semantics of the INVITE session or the SUBSCRIBE
dialog.
Similarly, the relationship between a subscription in one
direction (e.g. from node A to node B) and a subscription in the
opposite direction (from B to A) with the same dialog correlation
information is undefined. While re-using such information is
allowed, the sharing of such information does not change the
semantics of either SUBSCRIBE dialog.
4.2.2. Subscription duration
SUBSCRIBE requests SHOULD contain an "Expires" header. This SUBSCRIBE requests SHOULD contain an "Expires" header (defined in
expires value indicates the duration of the subscription. The SIP [1] ). This expires value indicates the duration of the
formatting of these is described in RFC 2543. In order to keep subscription. In order to keep subscriptions effective beyond the
subscriptions effective beyond the duration communicated in the duration communicated in the "Expires" header, subscribers need
"Expires" header, subscribers need to refresh subscriptions on a to refresh subscriptions on a periodic basis using a new
periodic basis. This refreshing is performed in the same way as SUBSCRIBE message on the same dialog as defined in SIP [1] .
REGISTER refreshes: the To, From, and Call-ID match those in the
SUBSCRIBE being refreshed, while the CSeq number is incremented.
If no "Expires" header is present in a SUBSCRIBE request, the If no "Expires" header is present in a SUBSCRIBE request, the
implied default is defined by the event package being used. implied default is defined by the event package being used.
200-class responses to SUBSCRIBE requests also MUST contain an 200-class responses to SUBSCRIBE requests also MUST contain an
"Expires" header. The period of time in the response MAY be "Expires" header. The period of time in the response MAY be
shorter or longer than specified in the request. The period of shorter or longer than specified in the request. The period of
time in the response is the one which defines the duration of the time in the response is the one which defines the duration of the
subscription. subscription.
Similar to REGISTER requests, SUBSCRIBE requests may be renewed An "expires" parameter on the "Contact" header has no semantics
at any time to prevent them from expiring at the end of the for SUBSCRIBE and is explicitly not equivalent to an "Expires"
"Expires" period. These renewals will contain a the same "To," header in a SUBSCRIBE request or response.
"From," and "Call-ID" as the original request, and an incremented
"CSeq" number.
Also similar to REGISTER requests, a natural consequence of this A natural consequence of this scheme is that a SUBSCRIBE with an
scheme is that a SUBSCRIBE with an "Expires" of 0 constitutes a "Expires" of 0 constitutes a request to unsubscribe from an
request to unsubscribe from an event. event.
Notifiers may also wish to cancel subscriptions to events; this Notifiers may also wish to cancel subscriptions to events; this
is useful, for example, when the resource to which a subscription is useful, for example, when the resource to which a subscription
refers is no longer available. Further details on this mechanism refers is no longer available. Further details on this mechanism
are discussed in section 4.3.3. are discussed in section 4.2.2.
4.2.3. 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. It also contains enough information to
identify the resource for which event notification is desired, identify the resource for which event notification is desired,
but not necessarily enough information to uniquely identify the but not necessarily enough information to uniquely identify the
nature of the event (e.g. "sip:adam.roach@ericsson.com" would be nature of the event (e.g. "sip:adam@dynamicsoft.com" would be an
an appropriate URI to subscribe to for my presence state; it appropriate URI to subscribe to for my presence state; it would
would also be an appropriate URI to subscribe to the state of my also be an appropriate URI to subscribe to the state of my voice
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
semantics of the event or event class. semantics of the event or event class. The "Event" header MAY
also contain an "id" parameter. This "id" parameter, if present,
The "Event" header is considered mandatory for the purposes of contains an opaque token which identifies the specific
this document. However, to maintain compatibility with PINT (see subscription within a dialog. An "id" parameter is only valid
[3] ), servers MAY interpret a SUBSCRIBE request with no "Event" within the scope of a single dialog.
header as requesting a subscription to PINT events. If the
servers do not support PINT, they SHOULD return "489 Bad Event"
to any SUBSCRIBE messages without an EVENT header.
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.
4.2.4. Additional SUBSCRIBE Header Values Event packages may also define parameters for the Event header;
if they do so, they must define the semantics for such
parameters.
Each SUBSCRIBE request MUST have exactly one "Contact:" header, 4.1.3. Additional SUBSCRIBE Header Values
to be used as part of route handling, as described in section
4.1.1.
SUBSCRIBE requests MAY contain an "Accept" header. This header, Because SUBSCRIBE requests create a dialog as defined in SIP [1]
if present, indicates the body formats allowed in subsequent , they MAY contain an "Accept" header. This header, if present,
NOTIFY requests. Event packages MUST define the behavior for indicates the body formats allowed in subsequent NOTIFY requests.
SUBSCRIBE requests without "Accept" headers; usually, this will
connote a single, default body type. 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 Header values not described in this document are to be
interpreted as described in RFC 2543 [1] . interpreted as described in SIP [1] .
4.2.5. Subscriber SUBSCRIBE Behavior 4.1.4. Subscriber SUBSCRIBE Behavior
4.2.5.1. Requesting a Subscription 4.1.4.1. Requesting a Subscription
When a subscriber wishes to subscribe to a particular state for a SUBSCRIBE is a dialog-creating method, as described in SIP [1] .
resource, it forms a SUBSCRIBE message.
The dialog correlation information is formed as if for an When a subscriber wishes to subscribe to a particular state for a
original INVITE: the Call-ID is a new call ID with the syntax resource, it forms a SUBSCRIBE message. If the initial SUBSCRIBE
described in RFC 2543; the To: field indicates the subscribed represents a request outside of a dialog (as it typically will),
resource's persistent address (which will generally match the its construction follows the procedures outlined in SIP [1] for
Request URI used to form the message); and the From: field will UAC request generation outside of a dialog.
indicate the subscriber's persistent address (typically
sip:user@domain).
This SUBSCRIBE request will be confirmed with a final response. This SUBSCRIBE request will be confirmed with a final response.
200-class responses indicate that the subscription has been 200-class responses indicate that the subscription has been
accepted, and that a NOTIFY will be sent immediately. A 200 accepted, and that a NOTIFY will be sent immediately. A 200
response indicates that the subscription has been accepted and response indicates that the subscription has been accepted and
that the user is authorized to subscribe to the requested that the user is authorized to subscribe to the requested
resource. A 202 response merely indicates that the subscription resource. A 202 response merely indicates that the subscription
has been understood, and that authorization may or may not have has been understood, and that authorization may or may not have
been granted. been granted.
The "Expires" header in a 200-class response to SUBSCRIBE The "Expires" header in a 200-class response to SUBSCRIBE
indicates the actual duration for which the subscription will indicates the actual duration for which the subscription will
remain active (unless refreshed). remain active (unless refreshed).
Non-200 class final responses indicate that the subscription has Non-200 class final responses indicate that no subscription or
not been created, and no subsequent NOTIFY message will be sent. dialog has been created, and no subsequent NOTIFY message will be
All non-200 class responses (with the exception of "489," sent. All non-200 class responses (with the exception of "489,"
described herein) have the same meanings and handling as described herein) have the same meanings and handling as
described in RFC 2543 [1] . described in SIP [1] .
4.2.5.2. Refreshing of Subscriptions A SUBSCRIBE request MAY include an "id" parameter in its "Event"
header to allow differentiation between multiple subscriptions in
the same dialog.
4.1.4.2. Refreshing of Subscriptions
At any time before a subscription expires, the subscriber may At any time before a subscription expires, the subscriber may
refresh the timer on such a subscription by re-sending a refresh the timer on such a subscription by sending another
SUBSCRIBE request. The handling for such a request is the same as SUBSCRIBE request on the same dialog as the existing
for the initial creation of a subscription except as described subscription, and with the same "Event" header "id" parameter (if
below. one was present in the initial subscription). The handling for
such a request is the same as for the initial creation of a
subscription except as described below.
Subscription renewals will contain a "To" field matching the If the initial SUBSCRIBE message contained an "id" parameter
"From" field in the first NOTIFY request for the dialog on the "Event" header, then refreshes of the subscription
containing the subscription to be refreshed. They will contain must also contain an identical "id" parameter; they will
the same "From" and "Call-ID" fields as the original SUBSCRIBE otherwise be considered new subscriptions in an existing
request, and an incremented "CSeq" number from the original dialog.
SUBSCRIBE request. Route handling is as discussed in section
4.1.1.
If a SUBSCRIBE request to refresh a subscription receives a "481" If a SUBSCRIBE request to refresh a subscription receives a "481"
response, this indicates that the subscription has been response, this indicates that the subscription has been
terminated and that the subscriber did not receive notification terminated and that the subscriber did not receive notification
of this fact. In this case, the subscriber should consider the of this fact. In this case, the subscriber should consider the
subscription invalid. If the subscriber wishes to re-subscribe to subscription invalid. If the subscriber wishes to re-subscribe to
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.2.5.1. ) tag (see section 4.1.4.1. )
If a SUBSCRIBE request to refresh a subscription fails, 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
"Subscription-Expires," except as described above.
4.2.5.3. Unsubscribing 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.
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".
4.2.5.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
node which has registered a successful subscription or node which has processed a successful subscription or
subscription refresh. Until the first NOTIFY message arrives, the subscription refresh. Until the first NOTIFY message arrives, the
subscriber should consider the state of the subscribed resource subscriber should consider the state of the subscribed resource
to be in a neutral state. Event packages which define new event to be in a neutral state. Event packages which define new event
packages MUST define this "neutral state" in such a way that packages MUST define this "neutral state" in such a way that
makes sense for their application (see section 5.4.7. ). makes sense for their application (see section 5.4.7. ).
Due to the potential for both out-of-order messages and forking, Due to the potential for both out-of-order messages and forking,
the subscriber MUST be prepared to receive NOTIFY messages before the subscriber MUST be prepared to receive NOTIFY messages before
the SUBSCRIBE transaction has completed. the SUBSCRIBE transaction has completed.
Except as noted above, processing of this NOTIFY is the same as Except as noted above, processing of this NOTIFY is the same as
in section 4.3.5. in section 4.2.4.
4.2.6. Proxy SUBSCRIBE Behavior 4.1.5. Proxy SUBSCRIBE Behavior
Proxies need no additional behavior beyond that described in RFC Proxies need no additional behavior beyond that described in SIP
2543 [1] to support SUBSCRIBE. If a proxy wishes to see all of [1] to support SUBSCRIBE. If a proxy wishes to see all of the
the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST SUBSCRIBE and NOTIFY requests for a given dialog, it MUST
record-route all SUBSCRIBE and NOTIFY requests. record-route all SUBSCRIBE and NOTIFY requests.
4.2.7. Notifier SUBSCRIBE Behavior 4.1.6. Notifier SUBSCRIBE Behavior
4.2.7.1. 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
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 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.2.7.3. authorization per its local policy. See section 4.1.6.3.
If the SUBSCRIBE request contains a tag parameter in the "To"
field, but the notifier has no record of the indicated dialog,
the notifier has two options. If the notifier is able and willing
to reconstruct subscription state, he may accept the subscription
as an initial subscription. If the notifier cannot or is not
willing to reconstitute such state, it should respond with a "481
Subscription does not exist."
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 to creating the subscription, it creates the subscription and a
returns a "200 OK" response, unless doing so would reveal dialog (if necessary), and returns a "200 OK" response (unless
authorization policy in an undesirable fashion (see section 6.2. doing so would reveal authorization policy in an undesirable
). 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.
it needs to wait for user input for authorization, or is acting it needs to wait for user input for authorization, or is acting
for another node which is not currently reachable), or wishes to for another node which is not currently reachable), or wishes to
mask authorization policy, it will return a "202 Accepted" mask authorization policy, it will return a "202 Accepted"
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 created yet. 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 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 or lengthen the interval. 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.
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 RFC 2543 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.2.7.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 of 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. If the resource has the current resource state to the subscriber. This NOTIFY message
no meaningful state at the time that the SUBSCRIBE message is is sent on the same dialog as created by the SUBSCRIBE response.
processed, this NOTIFY message MAY contain an empty or neutral If the resource has no meaningful state at the time that the
body. See section 4.3.3. for further details on NOTIFY message SUBSCRIBE message is processed, this NOTIFY message MAY contain
generation. 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 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
the subscription has already been authorized. the subscription has already been authorized.
4.2.7.3. Authentication/Authorization of SUBSCRIBE requests 4.1.6.3. Authentication/Authorization of SUBSCRIBE requests
Privacy concerns may require that notifiers either use access Privacy concerns may require that notifiers apply policy to
lists or ask the notifier owner, on a per-subscription basis, determine whether a particular subscriber is authorized to
whether a particular remote node is authorized to subscribe to a subscribe to a certain set of events. Such policy may be defined
certain set of events. In general, authorization of users prior by mechanisms such as access control lists or real-time
to authentication is not particularly useful. interaction with a user. In general, authorization of subscribers
prior to authentication is not particularly useful.
SIP authentication mechanisms are discussed in RFC2543 [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.
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
and sent under these circumstances, as described in the previous and sent under these circumstances, as described in the previous
section. section.
If subscription authorization was delayed and the notifier wishes If subscription authorization was delayed and the notifier wishes
to convey that such authorization has been declined, it may do so to convey that such authorization has been declined, it may do so
by sending a NOTIFY message containting a "Subscription-Expires" by sending a NOTIFY message containing a "Subscription-State"
header with a value of "0" and a reason parameter of "refused." header with a value of "terminated" and a reason parameter of
"rejected."
4.2.7.4. Refreshing of Subscriptions 4.1.6.4. Refreshing of Subscriptions
When a notifier receives a subscription refresh, assuming that When a notifier receives a subscription refresh, assuming that
the subscriber is still authorized, the notifier updates the the subscriber is still authorized, the notifier updates the
expiration time for subscription. As with the initial expiration time for subscription. As with the initial
subscription, the server MAY shorten or increase the amount of subscription, the server MAY shorten the amount of time until
time until expiration. The final expiration time is placed in the expiration, but MUST NOT increase it. The final expiration time
"Expires" header in the response. is placed in the "Expires" header in the response. If the
duration specified in a SUBSCRIBE message is unacceptably short,
the notifier SHOULD respond with a "423 Subscription Too Brief"
message.
If no refresh for a notification address is received before its If no refresh for a notification address is received before its
expiration time, the subscription is removed. When removing a expiration time, the subscription is removed. When removing a
subscription, the notifier MAY send a NOTIFY message with a subscription, the notifier SHOULD send a NOTIFY message with a
"Subscription-Expires" value of "0" to inform it that the "Subscription-State" value of "terminated" to inform it that the
subscription is being removed. If such a message is sent, the subscription is being removed. If such a message is sent, the
"Subscription-Expires" header SHOULD contain a "reason=timeout" "Subscription-State" header SHOULD contain a "reason=timeout"
parameter. parameter.
4.3. Description of NOTIFY Behavior The sending of a NOTIFY when a subscription expires allows
the corresponding dialog to be terminated, if appropriate.
4.2. Description of NOTIFY Behavior
NOTIFY messages are sent to inform subscribers of changes in NOTIFY messages are sent to inform subscribers of changes in
state to which the subscriber has a subscription. Subscriptions state to which the subscriber has a subscription. Subscriptions
are typically put in place using the SUBSCRIBE method; however, are typically put in place using the SUBSCRIBE method; however,
it is possible that other means have been used. it is possible that other means have been used.
If any non-SUBSCRIBE mechanisms are defined to create If any non-SUBSCRIBE mechanisms are defined to create
subscriptions, it is the responsibility of the parties defining subscriptions, it is the responsibility of the parties defining
those mechanisms to ensure that correlation of a NOTIFY message those mechanisms to ensure that correlation of a NOTIFY message
to the corresponding subscription is possible. Designers of such to the corresponding subscription is possible. Designers of such
mechanisms are also warned to make a distinction between sending mechanisms are also warned to make a distinction between sending
a NOTIFY message to a subscriber who is aware of the a NOTIFY message to a subscriber who is aware of the
subscription, and sending a NOTIFY message to an unsuspecting subscription, and sending a NOTIFY message to an unsuspecting
node. The latter behavior is invalid, and MUST receive a "481 node. The latter behavior is invalid, and MUST receive a "481
Subscription does not exist" response (unless some other 400- or Subscription does not exist" response (unless some other 400- or
500-class error code is more applicable), as described in section 500-class error code is more applicable), as described in section
4.3.5. In other words, knowlege of a subscription must exist in 4.2.4. In other words, knowledge of a subscription must exist in
both the subscriber and the notifier to be valid, even if both the subscriber and the notifier to be valid, even if
installed via a non-SUBSCRIBE mechanism. installed via a non-SUBSCRIBE mechanism.
A NOTIFY does not cancel its corresponding subscription; in other A NOTIFY does not terminate its corresponding subscription; in
words, a single SUBSCRIBE request may trigger several NOTIFY other words, a single SUBSCRIBE request may trigger several
requests. NOTIFY requests.
4.3.1. Correlation
NOTIFY requests MUST contain the same Call-ID as the SUBSCRIBE
request which ordered them; the "To" field MUST match the "From"
field in the SUBSCRIBE that ordered them, and the "From" field
MUST match the "To" field that was sent in the 200-class response
to the SUBSCRIBE. In other words, NOTIFY requests MUST be in the
same dialog as the SUBSCRIBE that ordered them.
The From field of a NOTIFY request, like the "To" field of a
SUBSCRIBE response, MUST contain a tag; this allows for the
subscriber to differentiate between events from different
notifiers.
Successful SUBSCRIBE requests will receive only one 200-class
response; however, due to forking, the subscription may have been
accepted by multiple nodes. The subscriber MUST therefore be
prepared to receive NOTIFY requests with "From:" tags which
differ from the "To:" tag received in the SUBSCRIBE 200-class
response.
If multiple NOTIFY messages are received in response to a single
SUBSCRIBE message, they represent different destinations to which
the SUBSCRIBE request was forked. Unless the event package
specifies otherwise, the subscriber may either accept all such
notifications as representing different dialogs (which are then
refreshed separately), or send a 481 response to any NOTIFYs on
dialogs that it does not want to keep alive.
As expected, CSeq spaces are unique for each node; in other
words, the notifier uses a different CSeq space than the
subscriber and any other notifiers.
4.3.2. Identification of reported events, event classes, and current 4.2.1. Identification of reported events, event classes, and current
state state
Identification of events being reported in a notification is very Identification of events being reported in a notification is very
similar to that described for subscription to events (see section similar to that described for subscription to events (see section
4.2.3. ). 4.1.2. ).
The Request URI of a NOTIFY request contains enough information
to route the request to the party which is subscribed to receive
notifications. It is derived from the "Contact" header present in
the corresponding SUBSCRIBE request.
If the same events for different resources are being subscribed
to, implementors are expected to use different dialogs in order
to be able to differentiate between notifications for them,
unless the body for the event contains enough information for
this correlation.
As in SUBSCRIBE requests, NOTIFY "Event" headers will contain a As in SUBSCRIBE requests, NOTIFY "Event" headers will contain a
single token which identifies the event or class of events for single event package name for which a notification is being
which a notification is being generated. generated. The package name in the "Event" header MUST match the
"Event" header in the corresponding SUBSCRIBE message. If an "id"
parameter was present in the SUBSCRIBE message, that "id"
parameter MUST also be present in the corresponding NOTIFY
messages.
If the event package to which the event token corresponds defines If the event package to which the event package name corresponds
behavior associated with the body of its NOTIFY requests, those defines behavior associated with the body of its NOTIFY requests,
semantics apply. This information is expected to provide those semantics apply. This information is expected to provide
additional details about the nature of the event which has additional details about the nature of the event which has
occurred and the resultant resource state. occurred and the resultant resource state.
When present, the body of the NOTIFY request MUST be formatted When present, the body of the NOTIFY request MUST be formatted
into one of the body formats specified in the "Accept" header of into one of the body formats specified in the "Accept" header of
the corresponding SUBSCRIBE request. the corresponding SUBSCRIBE request. This body will contain
either the state of the subscribed resource or a pointer to such
4.3.3. Notifier NOTIFY Behavior state in the form of a URI.
When a SUBSCRIBE request is successfully processed or a relevant 4.2.2. Notifier NOTIFY Behavior
change in the subscribed state occurs, the notifier will
immediately construct and send a NOTIFY request to the
subscriber(s), per standard Route/Record-Route handling, as
described in section 4.1.1.
If the notifier is able, through any means, to determine that the When a SUBSCRIBE request is answered with a 200-class response,
subscriber is no longer available to receive notifications, it the notifier MUST immediately construct and send a NOTIFY request
MAY elect to not send a notification. An example of a method by to the subscriber. When a change in the subscribed state occurs,
which such information may be known is the "SIP for Presence" the notifier SHOULD immediately construct and send a NOTIFY
event set (see [4] ). request, subject to authorization, local policy, and throttling
considerations.
A NOTIFY request is considered failed if the response times out, A NOTIFY request is considered failed if the response times out,
or a non-200 class response code is received which has no or a non-200 class response code is received which has no
"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 SIP signalling), the notifier SHOULD remove mechanism (such as SUBSCRIBE), the notifier SHOULD remove the
the subscription. 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
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 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
mechanism, the notifier MUST remove the corresponding mechanism, the notifier MUST remove the corresponding
subscription. subscription.
A notify error response would generally indicate that
something has gone wrong with the subscriber or with some
proxy on the way to the subscriber. If the subscriber is in
error, it makes the most sense to allow the subscriber to
rectify the situation (by re-subscribing) once the error
condition has been handled. If a proxy is in error, the
periodic SUBSCRIBE refreshes will re-install subscription
state once the network problem has been resolved.
If a NOTIFY request receives a 481 response, the notifier MUST If a NOTIFY request receives a 481 response, the notifier MUST
remove the corresponding subscription even if such subscription remove the corresponding subscription even if such subscription
was installed by non-SUBSCRIBE means (such as an administrative was installed by non-SUBSCRIBE means (such as an administrative
interface). interface).
NOTIFY requests SHOULD contain an "Subscription-Expires" header If the above behavior were not required, subscribers
which indicates the remaining duration of the subscription (such receiving a notify for an unknown subscription would need to
a header is useful in case the SUBSCRIBE request forks, since send an error status code in response to the NOTIFY and also
the response to a forked subscribe -- which contains the "Expire" send a SUBSCRIBE request to remove the subscription. Since
header that specifies the agreed-upon expiration time -- may not this behavior would make subscribers available for use as
be received by the subscriber). The notifier SHOULD use this amplifiers in denial of service attacks, we have instead
header to adjust the time remaining on the subscription; however, elected to give the 481 response special meaning: it is used
this mechanism MUST not be used to lengthen a subscription, only to indicate that a subscription must be cancelled under all
to shorten it. The notifier may inform a subscriber that a circumstances.
subscription has been removed by sending a NOTIFY message with an
"Subscription-Expires" value of "0."
If the duration of a subscription has been shortened or NOTIFY requests MUST contain a "Subscription-State" header with a
terminated by the "Subscription-Expires" header as compared to value of "active," "pending," or "terminated." The "active" value
the most recent 200-class SUBSCRIBE response sent, that header indicates that the subscription has been accepted and has been
SHOULD include a "reason" parameter indicating the reason that authorized (in most cases; see section 6.2. ). The "pending"
such action was taken. Currently, four such values are defined: value indicates that the subscription has been received, but that
"migration" indicates that the node acting as notifier is policy information is insufficient to accept or deny the
transferring responsibility for maintaing such state information subscription at this time. The "terminated" value indicates that
to another node; this only makes sense when subscriptions are the subscription is not active.
terminated, not when they are shortened. "Maint" indicates that
the subscription is being truncated or terminated due to server
maintainance, and "refused" indicates that the subscription has
been removed or shortened administratively (e.g. by a change in
ACL policy). Finally, if the notifier elects to send a NOTIFY
upon timeout of the subscription, they SHOULD include a
"Subscription-Expires" header with a value of "0" and a reason
parameter of "timeout."
4.3.4. Proxy NOTIFY Behavior 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.
Proxies need no additional behavior beyond that described in RFC Including expiration information for active and pending
2543 [1] to support NOTIFY. If a proxy wishes to see all of the subscriptions is useful in case the SUBSCRIBE request forks,
since the response to a forked SUBSCRIBE may not be received
by the subscriber. Note well that this "expires" value is a
parameter on the "Subscription-State" header, NOT an
"Expires" header.
If the value of the "Subscription-State" header is "terminated,"
the notifier SHOULD also include a "reason" parameter. The
notifier MAY also include a "retry-after" parameter, where
appropriate. For details on the value and semantics of the
"reason" and "retry-after" parameters, see section 4.2.4.
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 SUBSCRIBE and NOTIFY requests for a given dialog, it MUST
record-route all SUBSCRIBE and NOTIFY requests. record-route all SUBSCRIBE and NOTIFY requests.
4.3.5. 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
create a new dialog is 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
match (as described in section 7.5.1. )
If, for some reason, the event package designated in the "Event" If, for some reason, the event package designated in the "Event"
header of the NOTIFY request is not supported, the subscriber header of the NOTIFY request is not supported, the subscriber
will respond with a "489 Bad Event" response. will respond with a "489 Bad Event" response.
To prevent spoofing of events, NOTIFY requests MAY be To prevent spoofing of events, NOTIFY requests SHOULD be
authenticated, using any defined SIP authentication mechanism. authenticated, using any defined SIP authentication mechanism.
NOTIFY requests SHOULD contain "Subscription-Expires" headers NOTIFY requests MUST contain "Subscription-State" headers which
which indicate the time remaining on the subscription. If this indicate the status of the subscription.
header is present, the subscriber SHOULD take it as the
authoritative duration and adjust accordingly. If an expires
value of "0" is present, the subscriber should consider the
subscription terminated.
When the subscription is terminated or shortened using the If the "Subscription-State" header value is "active," it means
"Subscription-Expires" mechanism, there SHOULD be a reason that the subscription has been accepted and (in general) has been
parameter present. If it is present and the subscriber is still authorized. If the header also contains an "expires" parameter,
interested in receiving updates to the state information, the the subscriber SHOULD take it as the authoritative subscription
subscriber SHOULD attempt re-subscribe upon expiration if it is duration and adjust accordingly. The "retry-after" and "reason"
set to "migration," "timeout," is not present, or is set to an parameters have no semantics for "active."
unknown value. Such a resubscription will be completely
independant of the original subscription, and will not share a
dialog with it; it will be generated as described in section
4.2.5.1.
If the "reason" parameter on a "Subscription-Expires" header is If the "Subscription-State" value is "pending," the subscription
set to either "maint" or "refused," the subscriber SHOULD NOT has been received by the notifier, but there is insufficient
attempt re-subscription. policy information to grant or deny the subscription yet. If the
header also contains an "expires" parameter, the subscriber
SHOULD take it as the authoritative subscription duration and
adjust accordingly. No further action is necessary on the part of
the subscriber. The "retry-after" and "reason" parameters have no
semantics for "pending."
If the "Subscription-State" value is "terminated," the subscriber
should consider the subscription terminated. The "expires"
parameter has no semantics for "terminated." If a reason code is
present, the client should behave as described below. If no
reason code or an unknown reason code is present, the client MAY
attempt to re-subscribe at any time (unless a "retry-after"
parameter is present, in which case the client SHOULD NOT attempt
re-subscription until after the number of seconds specified by
the "retry-after" parameter). The defined reason codes are:
deactivated: The subscription has been terminated, but the client
SHOULD retry immediately with a new subscription. One primary
use of such a status code is to allow migration of
subscriptions between nodes. The "retry-after" parameter has
no semantics for "deactivated."
probation: The subscription has been terminated, but the client
SHOULD retry at some later time. 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.
rejected: The subscription has been terminated due to change in
authorization policy. Clients SHOULD NOT attempt to
re-subscribe. The "retry-after" parameter has no semantics
for "rejected."
timeout: The subscription has been terminated because it was not
refreshed before it expired. Clients MAY re-subscribe
immediately. The "retry-after" parameter has no semantics for
"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.
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 RFC 2543 [1] may also be returned, as Other responses defined in SIP [1] may also be returned, as
appropriate. appropriate.
4.4. Polling Resource State 4.3. General
4.3.1. Detecting support for SUBSCRIBE and NOTIFY
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).
4.3.2. CANCEL requests
No semantics are associated with cancelling SUBSCRIBE or NOTIFY.
4.3.3. Forking
Successful SUBSCRIBE requests will receive only one 200-class
response; however, due to forking, the subscription may have been
accepted by multiple nodes. The subscriber MUST therefore be
prepared to receive NOTIFY requests with "From:" tags which
differ from the "To:" tag received in the SUBSCRIBE 200-class
response.
If multiple NOTIFY messages are received in response to a single
SUBSCRIBE message, they represent different destinations to which
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 an 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).
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 the 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
described for a dialog (e.g. route set handling).
A subscription is destroyed when a notifier sends a NOTIFY
request with a "Subscription-State" of "terminated".
A subscriber may send a SUBSCRIBE request with an
"Expiration" header of 0 in order to trigger the sending of
such a NOTIFY request; however, for the purposes of
subscription and dialog lifetime, the subscription is not
considered terminated until the NOTIFY with a
"Subscription-State" of "terminated" is sent.
If a subscription's destruction leaves no other application state
associated with the dialog, the dialog terminates. The
destruction of other application state (such as that created by
an INVITE) will not terminate the dialog if a subscription is
still associated with that dialog.
Note that the above behavior means that a dialog created with
an INVITE does not necessarily terminate upon receipt of a
BYE.
4.3.5. State Agents and Notifier Migration
When state agents (see section 5.4.11. ) are used, it is often
useful to allow migration of subscriptions between state agents
and the nodes for which they are providing state aggregation (or
even among various state agents). Such migration may be effected
by sending a "NOTIFY" with an "Subscription-State" header of
"terminated," and a reason parameter of "deactivated." This
NOTIFY request is otherwise normal, and is formed as described in
section 4.2.2.
Upon receipt of this NOTIFY message, the subscriber SHOULD
attempt to re-subscribe (as described in the preceding sections).
Note that this subscription is established on a new dialog, and
does not re-use the route set from the previous subscription
dialog.
The actual migration is effected by making a change to the policy
(such as routing decisions) of one or more servers to which the
SUBSCRIBE request will be sent in such a way that a different
node ends up responding to the SUBSCRIBE request. This may be as
simple as a change in the local policy in the notifier from which
the subscription is migrating so that it serves as a proxy or
redirect server instead of a notifier.
Whether, when, and why to perform notifier migrations may be
described in individual event packages; otherwise, such decisions
are a matter of local notifier policy, and are left up to
individual implementations.
4.3.6. Polling Resource State
A natural consequence of the behavior described in the preceding A natural consequence of the behavior described in the preceding
sections is that an immediate fetch without a persistent sections is that an immediate fetch without a persistent
subscription may be effected by sending an appropriate SUBSCRIBE subscription may be effected by sending a SUBSCRIBE with an
with an "Expires" of 0. "Expires" of 0.
Of course, an immediate fetch while a subscription is active may Of course, an immediate fetch while a subscription is active may
be effected by sending an appropriate SUBSCRIBE with an "Expires" be effected by sending a SUBSCRIBE with an "Expires" equal to the
greater than 0. 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 to the address in the NOTIFY request containing resource state in the same dialog.
SUBSCRIBE "Contact" field. Note that normal Route and
Record-Route handle still applies; see section 4.1.1.
4.5. Allow-Events header usage Note that the NOTIFY messages triggered by SUBSCRIBE messages
with "Expire" headers of 0 will contain a "Subscription-State"
value of "terminated," and a "reason" parameter of "timeout."
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
an appropriate "Allow-Events" header indicating all supported an appropriate "Allow-Events" header indicating all supported
events in INVITE requests and responses, OPTIONS responses, and events in all methods which initiate dialogs and their responses
REGISTER requests. "Allow-Events" headers MAY be included in any (such as INVITE) and OPTIONS responses.
other type of request or response.
This information is very useful, for example, in allowing user This information is very useful, for example, in allowing user
agents to render particular interface elements appropriately agents to render particular interface elements appropriately
according to whether the events required to implement the according to whether the events required to implement the
features they represent are supported by the appropriate nodes. features they represent are supported by the appropriate nodes.
Note that "Allow-Events" headers MUST NOT be inserted by proxies. Note that "Allow-Events" headers MUST NOT be inserted by proxies.
4.3.8. PINT Compatibility
The "Event" header is considered mandatory for the purposes of
this document. However, to maintain compatibility with PINT (see
[3] ), servers MAY interpret a SUBSCRIBE request with no "Event"
header as requesting a subscription to PINT events. If a server
does not support PINT, it SHOULD return "489 Bad Event" to any
SUBSCRIBE messages without an "Event" header.
5. Event Packages 5. Event Packages
This section covers several issues which should be taken into This section covers several issues which should be taken into
consideration when event packages based on SUBSCRIBE and NOTIFY consideration when event packages based on SUBSCRIBE and NOTIFY
are proposed. are proposed.
5.1. Appropriateness of Usage 5.1. Appropriateness of Usage
When designing an event package using the methods described in When designing an event package using the methods described in
this draft for event notification, it is important to consider: this draft for event notification, it is important to consider:
skipping to change at page 22, line 31 skipping to change at page 20, line 22
of SIP. 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. Sub-packages 5.2. Event Template-packages
Normal event packages define a set of state applied to a specific Normal event packages define a set of state applied to a specific
type of resource, such as user presence, call state, and type of resource, such as user presence, call state, and
messaging mailbox state. messaging mailbox state.
Sub-packages are a special type of package which define a set of Event template-packages are a special type of package which
state applied to other packages, such as statistics, access define a set of state applied to other packages, such as
policy, and subscriber lists. Sub-packages may even be applied to statistics, access policy, and subscriber lists. Event
other sub-packages. template-packages may even be applied to other event
template-packages.
To extend the object-oriented analogy made earlier, sub-packages To extend the object-oriented analogy made earlier, event
can be thought of as templatized C++ packages which must be template-packages can be thought of as templatized C++ packages
applied to other packages to be useful. which must be applied to other packages to be useful.
The name of a sub-package as applied to a package is formed by The name of an event template-package as applied to a package is
appending a period followed by the sub-package name to the end of formed by appending a period followed by the event
the package. For example, if a subpackage called "watcherinfo" template-package name to the end of the package. For example, if
were being applied to a package called "presence," the event a template-package called "winfo" were being applied to a package
token used in "Event" and "Allow-Events" would be called "presence," the event token used in "Event" and
"presence.watcherinfo". "Allow-Events" would be "presence.winfo".
Sub-packages must be defined so that they can be applied to any Event template-packages must be defined so that they can be
arbitrary package. In other words, sub-packages cannot be applied to any arbitrary package. In other words, event
specifically tied to one or a few "parent" packages in such a way template-packages cannot be specifically tied to one or a few
that they will not work with other packages. "parent" packages in such a way that they will not work with
other packages.
5.3. Amount of State to be Conveyed 5.3. Amount of State to be Conveyed
When designing event packages, it is important to consider the When designing event packages, it is important to consider the
type of information which will be conveyed during a notification. type of information which will be conveyed during a notification.
A natural temptation is to convey merely the event (e.g. "a new A natural temptation is to convey merely the event (e.g. "a new
voice message just arrived") without accompanying state (e.g. "7 voice message just arrived") without accompanying state (e.g. "7
total voice messages"). This complicates implementation of total voice messages"). This complicates implementation of
subscribing entities (since they have to maintain complete state subscribing entities (since they have to maintain complete state
skipping to change at page 24, line 26 skipping to change at page 22, line 19
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 changed by extension documents; document is not allowed to be changed 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 to In addition to the normal sections expected by "Instructions to
RFC Authors" [6] and "Guidelines for Authors of SIP Extensions" RFC Authors" [5] and "Guidelines for Authors of SIP Extensions"
[2] , authors of event packages MUST address each of the issues [2] , authors of event packages MUST address each of the issues
detailed in the following subsections, whenever applicable. detailed in the following subsections, whenever applicable.
5.4.1. Event Package Name 5.4.1. Event Package Name
This mandatory section of an event package defines the token name This mandatory section of an event package defines the token name
to be used to designate the event package. It MUST include the to be 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
If parameters are to be used on the "Event" header to modify the If parameters are to be used on the "Event" header to modify the
behavior of the event package, the syntax and semantics of such behavior of the event package, the syntax and semantics of such
headers must be clearly defined. headers MUST be clearly defined.
5.4.3. SUBSCRIBE Bodies 5.4.3. SUBSCRIBE Bodies
It is expected that most, but not all, event packages will define It is expected that most, but not all, event packages will define
syntax and semantics for SUBSCRIBE method bodies; these bodies syntax and semantics for SUBSCRIBE method bodies; these bodies
will typically modify, expand, filter, throttle, and/or set will typically modify, expand, filter, throttle, and/or set
thresholds for the class of events being requested. Designers of thresholds for the class of events being requested. Designers of
event packages are strongly encouraged to re-use existing MIME event packages are strongly encouraged to re-use existing MIME
types for message bodies where practical. types for message bodies where practical.
This mandatory section of an event package defines what type or This mandatory section of an event package defines what type or
types of event bodies are expected in SUBSCRIBE requests (or types of event bodies are expected in SUBSCRIBE requests (or
specify that no event bodies are expected). It should point to specify that no event bodies are expected). It should point to
detailed definitions of syntax and semantics for all referenced detailed definitions of syntax and semantics for all referenced
body types. body types.
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 a 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 need to define which MIME type is to be Event packages also MUST define which MIME type is to be assumed
assumed if none are specified in the "Accept" header of the if none are specified in the "Accept" header of the SUBSCRIBE
SUBSCRIBE request. request.
5.4.6. Notifier processing of SUBSCRIBE requests 5.4.6. Notifier processing of SUBSCRIBE requests
This section describes the processing to be performed by the This section describes the processing to be performed by the
notifier upon receipt of a SUBSCRIBE request. Such a section is notifier upon receipt of a SUBSCRIBE request. Such a section is
required. required.
Information in this section includes details of how to Information in this section includes details of how to
authenticate subscribers and authorization issues for the authenticate subscribers and authorization issues for the
package. Such authorization issues may include, for example, package. Such authorization issues may include, for example,
skipping to change at page 26, line 4 skipping to change at page 23, line 47
how to compute the state information in the NOTIFY, how to how to compute the state information in the NOTIFY, how to
generate "neutral" or "fake" state information to hide generate "neutral" or "fake" state information to hide
authorization delays and decisions from users, and whether state authorization delays and decisions from users, and whether state
information is complete or deltas for notifications (see section information is complete or deltas for notifications (see section
5.3. ) 5.3. )
It may optionally describe the behavior used to processes the It may optionally describe the behavior used to processes the
subsequent response. Such a section is required. subsequent response. Such a section is required.
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
requests are allowed to install multiple subscriptions.
Each event package should specify whether forked SUBSCRIBE If such behavior is not allowed, the first potential
requests are allowed to install multiple subscriptions. If such dialog-establishing message will create a dialog. All subsequent
behavior is not allowed, any NOTIFY messages not matching the NOTIFY messages which correspond to the SUBSCRIBE message (i.e.
200-class response to the initial SUBSCRIBE message are responded match To, From, From tag, Call-ID, CSeq, Event, and Event id) but
to with a 481. which do not match the dialog would be rejected with a 481
response.
If installing of multiple subscriptions by way of a single forked
INVITE is allowed, the subscriber establishes a new dialog
towards each notifier by returning a 200-class response to each
NOTIFY. Each dialog is then handled as its own entity, and is
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 Each event package is expected to define a requirement (SHOULD or
(RECOMMENDED, SHOULD or MUST strength) which defines an absolute MUST strength) which defines an absolute maximum on the rate at
maximum on the rate at which notifications are allowed to be which notifications are allowed to be generated by a single
generated by a single notifier. notifier.
Such packages may further define a throttle mechanism which Such packages MAY further define a throttle mechanism which
allows subscribers to further limit the rate of notification. allows 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") can benefit from network aggregation points ("State Agents")
and/or nodes which act on behalf of other nodes. (For example, and/or nodes which act on behalf of other nodes. (For example,
nodes which provide state information about a resource when such nodes which provide state information about a resource when such
a resource is unable or unwilling to provide such state a resource is unable or unwilling to provide such state
information itself). An example of such an application is a node information itself). An example of such an application is a node
which tracks the presence and availability of a user in the which tracks the presence and availability of a user in the
network. network.
If state agents are to be used by the package, the package must If state agents are to be used by the package, the package MUST
specify how such state agents aggregate information and how they specify how such state agents aggregate information and how they
provide authentication and authorization. provide authentication and authorization.
Event packages MAY also outline specific scenarios under which
notifier migrations take place.
5.4.12. Examples 5.4.12. Examples
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
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.
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.
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 user, since many types of events may be considered
sensitive for the purposes of privacy. Similarly, the notifier sensitive for the purposes of privacy. Similarly, the notifier
should have the ability to selectively reject subscriptions based should have the ability to selectively reject subscriptions based
on the calling party (based on access control lists), using on the subscriber identity (based on access control lists), using
standard SIP authentication mechanisms. The methods for creation standard SIP authentication mechanisms. The methods for creation
and distribution of such access control lists is outside the and distribution of such access control lists is outside the
scope of this draft. scope of this draft.
6.2. Release of Sensitive Policy Information 6.2. Release of Sensitive Policy Information
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.
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.
To reduce the chances of such an attack, implementations of To reduce the chances of such an attack, implementations of
notifiers SHOULD require authentication. Authentication issues notifiers SHOULD require authentication. Authentication issues
are discussed in RFC2543 [1] . are discussed in SIP [1] .
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).
To prevent such attacks, implementations SHOULD require
authentication. 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
bodies are used to define further information about the state of
the call, they SHOULD be included in the integrity protection
scheme.
Man-in-the-middle attacks may also attempt to use NOTIFY messages
to spoof arbitrary state information and/or terminate outstanding
subscriptions. To prevent such attacks, implementations SHOULD
provide integrity protection across the "Call-ID," "CSeq," and
"Subscription-State" headers and the bodies of NOTIFY messages.
Integrity protection of message headers and bodies is discussed
in SIP [1] .
6.6. Confidentiality
The state information contained in a NOTIFY message has the
potential to contain sensitive information. Implementations MAY
encrypt such information to ensure confidentiality.
While less likely, it is also possible that the information
contained in a SUBSCRIBE message contains information that users
might not want to have revealed. Implementations MAY encrypt such
information to ensure confidentiality.
To allow the remote party to hide information it considers
sensitive, all implementations SHOULD be able to handle encrypted
SUBSCRIBE and NOTIFY messages.
The mechanisms for providing confidentiality are detailed in SIP
[1] .
7. IANA Considerations 7. IANA Considerations
(This section is not applicable until this document is published (This section is not applicable until this document is published
as an RFC.) as an RFC.)
This document defines an event-type namespace which requires a This document defines an event-type namespace which requires a
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 sub-packages; see section 5.2. To avoid packages, and event template-packages; see section 5.2. To avoid
confusion, subpackage names and package names share the same confusion, template-package names and package names share the
namespace; in other words, a sub-package MUST NOT share a name same namespace; in other words, an event template-package MUST
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" [7] , normal event package IANA Considerations Section in RFCs" [6] , normal event package
identification tokens are allocated as First Come First Served, identification tokens are allocated as First Come First Served,
and event sub-package identification tokens are allocated on a and event template-package identification tokens are allocated on
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 subpackage. registered and whether the token is a package or a
Further, packages MUST include contact information for the party template-package. Further, packages MUST include contact
responsible for the registration and/or a published document information for the party responsible for the registration and/or
which describes the event package. Sub-package token a published document which describes the event package. Event
registrations MUST include a pointer to the published RFC which template-package token registrations MUST include a pointer to
defines the sub-package. the published RFC which defines the event template-package.
Registered tokens to designate packages and sub-packages MUST NOT Registered tokens to designate packages and template-packages
contain the character ".", which is used to separate sub-packages MUST NOT contain the character ".", which is used to separate
from packages. template-packages from packages.
7.1. Registration Template 7.1. Registration Information
As this document specifies no package or sub-package names, the As this document specifies no package or template-package names,
initial IANA registration for event types will be empty. The the initial IANA registration for event types will be empty. The
remainder of the text in this section gives an example of the remainder of the text in this section gives an example of the
type of information to be maintained by the IANA; it also type of information to be maintained by the IANA; it also
demonstrates all five possible permutations of package type, demonstrates all five possible permutations of package type,
contact, and reference. contact, and reference.
The table below lists the event packages and sub-packages defined The table below lists the event packages and template-packages
in "SIP-Specific Event Notification" [RFC xxxx]. Each name is defined in "SIP-Specific Event Notification" [RFC xxxx]. Each
designated as a package or a subpackage under "Type." name is designated as a package or a template-package under
"Type."
Package Name Type Contact Reference Package Name Type Contact Reference
------------ ---- ------- --------- ------------ ---- ------- ---------
example1 package [Roach] example1 package [Roach]
example2 package [Roach] [RFC xxxx] example2 package [Roach] [RFC xxxx]
example3 package [RFC xxxx] example3 package [RFC xxxx]
example4 sub-package [Roach] [RFC xxxx] example4 template [Roach] [RFC xxxx]
example5 sub-package [RFC xxxx] example5 template [RFC xxxx]
PEOPLE PEOPLE
------ ------
[Roach] Adam Roach <adam.roach@ericsson.com> [Roach] Adam Roach <adam@dynamicsoft.com>
REFERENCES REFERENCES
---------- ----------
[RFC xxxx] A. Roach "SIP-Specific Event Notification", RFC XXXX, [RFC xxxx] A. Roach "SIP-Specific Event Notification", RFC XXXX,
August 2002. August 2002.
8. Open Issues 7.2. Registration Template
In addition to the three issues listed below, the BNF in this To: ietf-sip-events@iana.org
document needs to be converted to explicit LWS to match the Subject: Registration of new SIP event package
latest bis draft; this change will be reflected in the next Package Name:
version.
8.1. CANCEL Handling (Package names must conform to the syntax described in
section 7.5.1. )
This is actually a protocol-wide open issue which has impacts on Is this registration for a Template Package:
this specification: there hasn't been a clear consensus about
cancellation of non-INVITE requests yet. If non-INVITE requests
cannot be cancelled, we need to remove section 4.1.3.
8.2. Version of SIP to reference (indicate yes or no)
Much of the handling in this document is rather different than Published Specification(s):
what is described in RFC2543; in fact, many of the recent changes
to this document have been tracking changes in the "bis" versions
of the SIP specification. We can continue to reference RFC2543
while pulling in huge chunks of the bis draft for compatibility
(for example, the Route handling would essentially be copied
word-for-word from the bis draft), or we can start referencing
the bis drafts.
Of course, referencing the bis drafts allows us to pick up (Template packages require a published RFC. Other packages
changes to protocol semantics "for free," while importing chunks may reference a specification when appropriate).
of it requires constant maintanance and runs the risk of getting
out of sync.
On the other hand, placing a dependency on the bis draft pushes Person & email address to contact for further information:
the timeframe for this draft (and the drafts that depend on it)
out past the time that the next SIP RFC is published.
8.3. Immediate NOTIFYs 7.3. Syntax
There has been discussion, but no consensus, on the issue of This section describes the syntax extensions required for event
whether each SUBSCRIBE must have an immediate NOTIFY message sent notification in SIP. Semantics are described in section 4. Note
in response. In attempts to follow the prevailing sentiment, this that the formal syntax definitions described in this document are
draft had become internally inconsistent. expressed in the ABNF format defined by [1] , and contain
references to elements defined therein.
This version of this document has eliminated these 7.4. New Methods
inconsistancies by requiring notifiers always to send a NOTIFY
immediately upon receiving a SUBSCRIBE. This decision does not
necessarily represent group consensus, and further discussion may
be warranted.
9. Changes This document describes two new SIP methods: "SUBSCRIBE" and
"NOTIFY."
9.1. Changes from draft-ietf-...-00 This table expands on tables 2 and 3 in SIP [1] .
Header Where SUB NOT
------ ----- --- ---
Accept R o o
Accept 2xx - -
Accept 415 o o
Accept-Encoding R o o
Accept-Encoding 2xx - -
Accept-Encoding 415 o o
Accept-Language R o o
Accept-Language 2xx - -
Accept-Language 415 o o
Alert-Info R - -
Alert-Info 180 - -
Allow R o o
Allow 2xx o o
Allow r o o
Allow 405 m m
Authentication-Info 2xx o o
Authorization R o o
Call-ID c m m
Contact R m m
Contact 1xx o o
Contact 2xx m o
Contact 3xx m m
Contact 485 o o
Content-Disposition o o
Content-Encoding o o
Content-Language o o
Content-Length t t
Content-Type * *
CSeq c m m
Date o o
Error-Info 300-699 o o
Expires o -
From c m m
In-Reply-To R - -
Max-Forwards R m m
Min-Expires 423 m -
MIME-Version o o
Organization o -
Priority R o -
Proxy-Authenticate 407 m m
Proxy-Authorization R o o
Proxy-Require R o o
RAck R - -
Record-Route R o o
Record-Route 2xx,401,484 o o
Reply-To - -
Require o o
Retry-After 404,413,480,486 o o
Retry-After 500,503 o o
Retry-After 600,603 o o
Route R c c
RSeq 1xx o o
Server r o o
Subject R - -
Supported R o o
Supported 2xx o o
Timestamp o o
To c(1) m m
Unsupported 420 o o
User-Agent o o
Via c m m
Warning r o o
WWW-Authenticate 401 m m
7.4.1. SUBSCRIBE method
"SUBSCRIBE" is added to the definition of the element "Method" in
the SIP message grammar.
Like all SIP method names, the SUBSCRIBE method name is case
sensitive. The SUBSCRIBE method is used to request asynchronous
notification of an event or set of events at a later time.
7.4.2. NOTIFY method
"NOTIFY" is added to the definition of the element "Method" in
the SIP message grammar.
The NOTIFY method is used to notify a SIP node that an event
which has been requested by an earlier SUBSCRIBE method has
occurred. It may also provide further details about the event.
7.5. New Headers
This table expands on tables 2 and 3 in SIP [1] , as amended by
the changes described in section 7.4.
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Allow-Events R o o - o o o o o o
Allow-Events 2xx - o - o o o o o o
Allow-Events 489 - - - - - - - m m
Event R - - - - - - - m m
Subscription-State R - - - - - - - - m
7.5.1. "Event" header
The following header is defined for the purposes of this
specification.
Event = ( "Event" | "o" ) HCOLON event-type
*( SEMI event-param )
event-type = event-package *( "." event-template )
event-package = token-nodot
event-template = token-nodot
token-nodot = 1*( alphanum | "-" | "!" | "%" | "*"
| "_" | "+" | "`" | "'" | "~" )
event-param = generic-param | ( "id" EQUAL token )
Event is added to the definition of the element "message-header"
in the SIP message grammar.
For the purposes of matching responses and NOTIFY messages with
SUBSCRIBE messages, the event-type portion of the "Event" header
is compared byte-by-byte, and the "id" parameter token (if
present) is compared byte-by-byte. An "Event" header containing
an "id" parameter never matches an "Event" header without an "id"
parameter. No other parameters are considered when performing a
comparison.
This document does not define values for event-types. These
values will be defined by individual event packages, and MUST be
registered with the IANA.
There MUST be exactly one event type listed per event header.
Multiple events per message are disallowed.
For the curious, the "o" short form is chosen to represent
"occurrence."
7.5.2. "Allow-Events" Header
The following header is defined for the purposes of this
specification.
Allow-Events = ( "Allow-Events" | "u" ) HCOLON
1*event-type
Allow-Events is added to the definition of the element
"general-header" in the SIP message grammar.
For the curious, the "u" short form is chosen to represent
"understands."
7.5.3. "Subscription-State" Header
The following header is defined for the purposes of this
specification.
Subscription-State = "Subscription-State" HCOLON
substate-value )
*( SEMI subexp-params )
substate-value = "active" | "pending" | "terminated"
subexp-params = ("reason" EQUAL reason-code)
|("expires" EQUAL delta-seconds)
|("retry-after" EQUAL delta-seconds)
| generic-param
reason-code = "deactivated"
| "probation"
| "rejected"
| "timeout"
| "giveup"
| reason-extension
reason-extension = token
Subscription-State is added to the definition of the element
"request-header" in the SIP message grammar.
7.6. New Response Codes
7.6.1. "202 Accepted" Response Code
The 202 response is added to the "Success" header field
definition:
Success = "200" ; OK
| "202" ; Accepted
"202 Accepted" has the same meaning as that defined in HTTP/1.1
[4] .
7.6.2. "489 Bad Event" Response Code
The 489 event response is added to the "Client-Error" header
field definition:
Client-Error = "400" ; Bad Request
...
| "489" ; Bad Event
"489 Bad Event" is used to indicate that the server did not
understand the event package specified in a "Event" header field.
8. Changes
8.1. Changes from draft-ietf-...-01
- Changed dependancy 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.
- Syncronized 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.2. Changes from draft-ietf-...-00
- Fixed confusing typo in section describing correlation - Fixed confusing typo in section describing correlation
of SUBSCRIBE requests of SUBSCRIBE requests
- Added explanitory text to clarify tag handling when - Added explanitory text to clarify tag handling when
generating re-subscriptions generating re-subscriptions
- Expanded general handling section to include specific - Expanded general handling section to include specific
discussion of Route/Record-Route handling. discussion of Route/Record-Route handling.
skipping to change at page 31, line 34 skipping to change at page 36, line 24
with other parts of this document. with other parts of this document.
- Moved description of event packages to later in document, - Moved description of event packages to later in document,
to reduce the number of forward references. to reduce the number of forward references.
- Minor editorial and nits changes - Minor editorial and nits changes
- Added new open issues to open issues section. All - Added new open issues to open issues section. All
previous open issues have been resolved. previous open issues have been resolved.
9.2. Changes from draft-roach-...-03 8.3. Changes from draft-roach-...-03
- Added DOS attacks section to open issues. - Added DOS attacks section to open issues.
- Added discussion of forking to open issues - Added discussion of forking to open issues
- Changed response to PINT request for notifiers who don't - Changed response to PINT request for notifiers who don't
support PINT from 400 to 489. support PINT from 400 to 489.
- Added sentence to security section to call attention to - Added sentence to security section to call attention to
potential privacy issues of delayed NOTIFY responses. potential privacy issues of delayed NOTIFY responses.
- Added clarification: access control list handling is out - Added clarification: access control list handling is out
of scope. of scope.
- (Hopefully) Final resolution on out-of-band subscriptions: - (Hopefully) Final resolution on out-of-band subscriptions:
mentioned in section mentioned in section
4.3. 4.2.
Removed from open issues. Removed from open issues.
- Made "Contact" header optional for SUBSCRIBE 1xx responses. - Made "Contact" header optional for SUBSCRIBE 1xx responses.
- Added description clarifying tag handling (section - Added description clarifying tag handling (section
4.2.1. 4.3.4.
) )
- Removed event throttling from open issues. - Removed event throttling from open issues.
- Editorial cleanup to remove term "extension draft" and - Editorial cleanup to remove term "extension draft" and
similar; "event package" is now (hopefully) used consistently similar; "event package" is now (hopefully) used consistently
throughout the document. throughout the document.
- Remove discussion of event agents from open issues. - Remove discussion of event agents from open issues.
This is covered in the event packages section now. This is covered in the event packages section now.
skipping to change at page 33, line 18 skipping to change at page 38, line 10
- Slight adjustment to "Event" syntax to accommodate sub-packages. - Slight adjustment to "Event" syntax to accommodate sub-packages.
- Added section describing the information which is to be - Added section describing the information which is to be
included in documents describing event packages. included in documents describing event packages.
- Made 481 responses mandatory for unexpected notifications - Made 481 responses mandatory for unexpected notifications
(allowing notifiers to remove subscriptions in error cases) (allowing notifiers to remove subscriptions in error cases)
- Several minor non-semantic editorial changes. - Several minor non-semantic editorial changes.
9.3. Changes from draft-roach-...-02 8.4. Changes from draft-roach-...-02
- Clarification under "Notifier SUBSCRIBE behavior" which - Clarification under "Notifier SUBSCRIBE behavior" which
indicates that the first NOTIFY message (sent immediately indicates that the first NOTIFY message (sent immediately
in response to a SUBSCRIBE) may contain an empty body, if in response to a SUBSCRIBE) may contain an empty body, if
resource state doesn't make sense at that point in time. resource state doesn't make sense at that point in time.
- Text on message flow in overview section corrected - Text on message flow in overview section corrected
- Removed suggestion that clients attempt to unsubscribe - Removed suggestion that clients attempt to unsubscribe
whenever they receive a NOTIFY for an unknown event. whenever they receive a NOTIFY for an unknown event.
skipping to change at page 35, line 10 skipping to change at page 39, line 37
- Clarified that a failed attempt to refresh a subscription - Clarified that a failed attempt to refresh a subscription
does not imply that the original subscription has been does not imply that the original subscription has been
cancelled. cancelled.
- Clarified that 489 is a valid response to "NOTIFY" requests. - Clarified that 489 is a valid response to "NOTIFY" requests.
- Minor editorial changes to clean up awkward and/or unclear - Minor editorial changes to clean up awkward and/or unclear
grammar in several places grammar in several places
9.4. Changes from draft-roach-...-01 8.5. Changes from draft-roach-...-01
- Multiple contacts per SUBSCRIBE message disallowed. - Multiple contacts per SUBSCRIBE message disallowed.
- Contact header now required in NOTIFY messages. - Contact header now required in NOTIFY messages.
- Distinction between third party/call member events removed. - Distinction between third party/call member events removed.
- Distinction between call-related/resource-related events removed. - Distinction between call-related/resource-related events removed.
- Clarified that subscribers must expect NOTIFY messages before - Clarified that subscribers must expect NOTIFY messages before
skipping to change at page 35, line 37 skipping to change at page 40, line 26
- Added mechanism for notifiers to shorten/cancel outstanding - Added mechanism for notifiers to shorten/cancel outstanding
subscriptions. subscriptions.
- Removed open issue about appropriateness of new "489" response. - Removed open issue about appropriateness of new "489" response.
- Removed all discussion of out-of-band subscriptions. - Removed all discussion of out-of-band subscriptions.
- Added brief discussion of event state polling. - Added brief discussion of event state polling.
10. References 9. References
[1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: [1] J. Rosenberg et. al., "SIP: Session Initiation Protocol",
Session Initiation Protocol", RFC 2543, IETF; March 1999. <draft-ietf-sip-rfc2543bis-07>, IETF; February 2002. Work in
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-02.txt>, IETF; March Extensions", <draft-ietf-sip-guidelines-03.txt>, IETF;
2001. Work in progress. November 2001. Work in progress.
[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] J. Rosenberg et. al., "SIP Extensions for Presence", [4] R. Fielding et. al., "Hypertext Transfer Protocol --
<draft-ietf-simple-presence-03.txt>, IETF; September 2001.
Work in progress.
[5] R. Fielding et. al., "Hypertext Transfer Protocol --
HTTP/1.1", RFC2068, IETF, January 1997. HTTP/1.1", RFC2068, IETF, January 1997.
[6] J. Postel, J. Reynolds, "Instructions to RFC Authors", [5] J. Postel, J. Reynolds, "Instructions to RFC Authors",
RFC2223, IETF, October 1997. RFC2223, IETF, October 1997.
[7] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [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.
[8] Schulzrinne/Rosenberg, "SIP Caller Preferences and Callee [7] Schulzrinne/Rosenberg, "SIP Caller Preferences and Callee
Capabilities", <draft-ietf-sip-callerprefs-04.txt>, IETF; Capabilities", <draft-ietf-sip-callerprefs-05.txt>, IETF;
June 2001. Work in progress. November 2001. Work in progress.
11. Acknowledgements 10. 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 of Ericsson for miscellaneous guidance, Jonathan Rosenberg Olson for miscellaneous guidance, Jonathan Rosenberg for a
for a thorough scrubbing of the -00 draft, and the authors of the thorough scrubbing of the -00 draft, and the authors of the "SIP
"SIP Extensions for Presence" draft for their input to SUBSCRIBE Extensions for Presence" draft for their input to SUBSCRIBE and
and NOTIFY request semantics. NOTIFY request semantics.
12. Author's Address 11. Author's Address
Adam Roach Adam Roach
Ericsson Inc. dynamicsoft
Mailstop L-04 5100 Tennyson Parkway
740 E. Campbell Rd. Suite 1200
Richardson, TX 75081 Plano, TX 75024
USA USA
Phone: +1 972 583 7594 E-Mail: <adam@dynamicsoft.com>
Fax: +1 972 669 0154 Voice: <sip:adam@dynamicsoft.com>
E-Mail: adam.roach@ericsson.com
 End of changes. 

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