draft-ietf-sipcore-rfc3265bis-05.txt   draft-ietf-sipcore-rfc3265bis-06.txt 
Network Working Group A. B. Roach Network Working Group A. B. Roach
Internet-Draft Tekelec Internet-Draft Tekelec
Obsoletes: 3265 (if approved) February 23, 2012 Obsoletes: 3265 (if approved) February 27, 2012
Updates: 4660 (if approved) Updates: 4660 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 26, 2012 Expires: August 30, 2012
SIP-Specific Event Notification SIP-Specific Event Notification
draft-ietf-sipcore-rfc3265bis-05 draft-ietf-sipcore-rfc3265bis-06
Abstract Abstract
This document describes an extension to the Session Initiation This document describes an extension to the Session Initiation
Protocol (SIP). The purpose of this extension is to provide an Protocol (SIP). The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred. remote nodes indicating that certain events have occurred.
Note that the event notification mechanisms defined herein are NOT Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of intended to be a general-purpose infrastructure for all classes of
event subscription and notification. event subscription and notification.
This document represents a backwards-compatible improvement on the This document represents a backwards-compatible improvement on the
original mechanism described by RFC 3265, taking into account several original mechanism described by RFC 3265, taking into account several
years of implementation experience. Accordingly, this document years of implementation experience. Accordingly, this document
obsoletes RFC 3265. This document also updates RFC 4660 slightly to obsoletes RFC 3265. This document also updates RFC 4660 slightly to
accomodate some small changes to the mechanism that were discussed in accommodate some small changes to the mechanism that were discussed
that document. in that document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2012. This Internet-Draft will expire on August 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 10, line 29 skipping to change at page 10, line 29
of "Require" or "Proxy-Require" header fields; similarly, there is no of "Require" or "Proxy-Require" header fields; similarly, there is no
token defined for "Supported" header fields. Potential subscribers token defined for "Supported" header fields. Potential subscribers
may probe for the support of SIP Events using the OPTIONS request may probe for the support of SIP Events using the OPTIONS request
defined in [RFC3261]. defined in [RFC3261].
The presence of "SUBSCRIBE" in the "Allow" header field of any The presence of "SUBSCRIBE" in the "Allow" header field of any
request or response indicates support for SIP Events; further, in the request or response indicates support for SIP Events; further, in the
absence of an "Allow" header field, the simple presence of an "Allow- absence of an "Allow" header field, the simple presence of an "Allow-
Events" header field is sufficient to indicate that the node that Events" header field is sufficient to indicate that the node that
sent the message is capable of acting as a notifier (see sent the message is capable of acting as a notifier (see
Section 4.4.4. Section 4.4.4).
The "methods" parameter for Contact may also be used to The "methods" parameter for Contact may also be used to
specifically announce support for SUBSCRIBE and NOTIFY requests specifically announce support for SUBSCRIBE and NOTIFY requests
when registering. (See [RFC3840] for details on the "methods" when registering. (See [RFC3840] for details on the "methods"
parameter). parameter).
4.1.2. Creating and Maintaining Subscriptions 4.1.2. Creating and Maintaining Subscriptions
From the subscriber's perspective, a subscription proceeds according From the subscriber's perspective, a subscription proceeds according
to the following state diagram: to the following state diagram:
skipping to change at page 26, line 7 skipping to change at page 26, line 7
Due to the requirement on notifiers to send a NOTIFY request Due to the requirement on notifiers to send a NOTIFY request
immediately upon receipt of a SUBSCRIBE request, the state immediately upon receipt of a SUBSCRIBE request, the state
provided by polling is limited to the information that the provided by polling is limited to the information that the
notifier has immediate local access to when it receives the notifier has immediate local access to when it receives the
SUBSCRIBE request. If, for example, the notifier generally needs SUBSCRIBE request. If, for example, the notifier generally needs
to retrieve state from another network server, then that state to retrieve state from another network server, then that state
will be absent from the NOTIFY request that results from polling. will be absent from the NOTIFY request that results from polling.
4.4.4. Allow-Events header field usage 4.4.4. Allow-Events header field usage
The "Allow-Events" header field, if present, includes a list of The "Allow-Events" header field, if present, MUST include a
tokens which indicates the event packages supported by a notifier. comprehensive and inclusive list of tokens for which the User Agent
In other words, a user agent sending an "Allow-Events" header field can act as a notifier. In other words, a user agent sending an
is advertising that it can process SUBSCRIBE requests and generate "Allow-Events" header field is advertising that it can process
NOTIFY requests for all of the event packages listed in that header SUBSCRIBE requests and generate NOTIFY requests for all of the event
field. packages listed in that header field.
Any user agent that can act as a notifier for one or more event Any user agent that can act as a notifier for one or more event
packages SHOULD include an appropriate "Allow-Events" header field packages SHOULD include an appropriate "Allow-Events" header field
indicating all supported events in all methods which initiate dialogs indicating all supported events in all methods which initiate dialogs
and their responses (such as INVITE) and OPTIONS responses. and their responses (such as INVITE) and OPTIONS responses.
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 features according to whether the events required to implement the features
they represent are supported by the appropriate nodes. they represent are supported by the appropriate nodes.
skipping to change at page 30, line 38 skipping to change at page 30, line 38
applied to other event template-packages. applied to other event template-packages.
To extend the object-oriented analogy made earlier, event template- To extend the object-oriented analogy made earlier, event template-
packages can be thought of as templatized C++ packages which must be packages can be thought of as templatized C++ packages which must be
applied to other packages to be useful. applied to other packages to be useful.
The name of an event template-package as applied to a package is The name of an event template-package as applied to a package is
formed by appending a period followed by the event template-package formed by appending a period followed by the event template-package
name to the end of the package. For example, if a template-package name to the end of the package. For example, if a template-package
called "winfo" were being applied to a package called "presence", the called "winfo" were being applied to a package called "presence", the
event token used in "Event" and "Allow-Events" would be event token used in the "Event" header field would be
"presence.winfo". "presence.winfo".
Event template-packages must be defined so that they can be applied Event template-packages must be defined so that they can be applied
to any arbitrary package. In other words, event template-packages to any arbitrary package. In other words, event template-packages
cannot be specifically tied to one or a few "parent" packages in such cannot be specifically tied to one or a few "parent" packages in such
a way that they will not work with other packages. 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 type When designing event packages, it is important to consider the type
skipping to change at page 42, line 34 skipping to change at page 42, line 34
match). match).
This document does not define values for event-types. These values This document does not define values for event-types. These values
will be defined by individual event packages, and MUST be registered will be defined by individual event packages, and MUST be registered
with the IANA. with the IANA.
There MUST be exactly one event type listed per event header field. There MUST be exactly one event type listed per event header field.
Multiple events per message are disallowed. Multiple events per message are disallowed.
The "Event" header field is defined only for use in SUBSCRIBE and The "Event" header field is defined only for use in SUBSCRIBE and
NOTIFY requests. It MUST NOT appear in any other SIP requests, and NOTIFY requests, and other requests whose definition explicitly calls
must not appear in responses. for its use. It MUST NOT appear in any other SIP requests, and MUST
NOT appear in responses.
8.2.2. "Allow-Events" Header Field 8.2.2. "Allow-Events" Header Field
Allow-Events is added to the definition of the element "general- Allow-Events is added to the definition of the element "general-
header field" in the SIP message grammar. Its usage is described in header field" in the SIP message grammar. Its usage is described in
Section 4.4.4. Section 4.4.4.
User Agents MAY include the "Allow-Events" header field in any User Agents MAY include the "Allow-Events" header field in any
request or response, as long as it includes a comprehensive and request or response, as long as its contents comply with the behavior
inclusive list of the packages for which the User Agent can act as a described in Section 4.4.4.
notifier.
8.2.3. "Subscription-State" Header Field 8.2.3. "Subscription-State" Header Field
Subscription-State is added to the definition of the element Subscription-State is added to the definition of the element
"request-header field" in the SIP message grammar. Its usage is "request-header field" in the SIP message grammar. Its usage is
described in Section 4.1.3. "Subscription-State" header fields are described in Section 4.1.3. "Subscription-State" header fields are
defined for use in NOTIFY requests only. They MUST NOT appear in defined for use in NOTIFY requests only. They MUST NOT appear in
other SIP requests or responses. other SIP requests or responses.
8.3. New Response Codes 8.3. New Response Codes
skipping to change at page 47, line 11 skipping to change at page 47, line 11
I also owe a debt of gratitude to all the implementors who have I also owe a debt of gratitude to all the implementors who have
provided feedback on areas of confusion or difficulty in the original provided feedback on areas of confusion or difficulty in the original
specification. In particular, Robert Sparks' Herculean efforts specification. In particular, Robert Sparks' Herculean efforts
organizing, running, and collecting data from the SIPit events have organizing, running, and collecting data from the SIPit events have
proven invaluable in shaking out specification bugs. Robert Sparks proven invaluable in shaking out specification bugs. Robert Sparks
is also responsible for untangling the dialog usage mess, in the form is also responsible for untangling the dialog usage mess, in the form
of RFC 5057 [RFC5057]. of RFC 5057 [RFC5057].
Appendix B. Changes from RFC 3265 Appendix B. Changes from RFC 3265
This document represents several changes from the mechainsm This document represents several changes from the mechanism
originally described in RFC 3265. This section summarizes those originally described in RFC 3265. This section summarizes those
changes. Bug numbers refer to the identifiers for the bug reports changes. Bug numbers refer to the identifiers for the bug reports
kept on file at http://bugs.sipit.net/. kept on file at http://bugs.sipit.net/.
B.1. Bug 666: Clarify use of expires=xxx with terminated B.1. Bug 666: Clarify use of expires=xxx with terminated
Strengthened language in Section 4.1.3 to clarify that expires should Strengthened language in Section 4.1.3 to clarify that expires should
not be sent with terminated, and must be ignored if received. not be sent with terminated, and must be ignored if received.
B.2. Bug 667: Reason code for unsub/poll not clearly spelled out B.2. Bug 667: Reason code for unsub/poll not clearly spelled out
 End of changes. 11 change blocks. 
20 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/