draft-ietf-sipcore-rfc3265bis-08.txt   draft-ietf-sipcore-rfc3265bis-09.txt 
Network Working Group A. B. Roach Network Working Group A. B. Roach
Internet-Draft Tekelec Internet-Draft Tekelec
Obsoletes: 3265 (if approved) April 11, 2012 Obsoletes: 3265 (if approved) April 30, 2012
Updates: 4660 (if approved) Updates: 3261, 4660
(if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 13, 2012 Expires: November 1, 2012
SIP-Specific Event Notification SIP-Specific Event Notification
draft-ietf-sipcore-rfc3265bis-08 draft-ietf-sipcore-rfc3265bis-09
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) defined by RFC 3261. The purpose of this extension is
extensible framework by which SIP nodes can request notification from to provide an extensible framework by which SIP nodes can request
remote nodes indicating that certain events have occurred. notification from 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
accommodate some small changes to the mechanism that were discussed accommodate some small changes to the mechanism that were discussed
skipping to change at page 1, line 46 skipping to change at page 1, line 48
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 October 13, 2012. This Internet-Draft will expire on November 1, 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 3, line 4 skipping to change at page 3, line 6
4.2.3. PINT Compatibility . . . . . . . . . . . . . . . . . . 23 4.2.3. PINT Compatibility . . . . . . . . . . . . . . . . . . 23
4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 23 4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 23 4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Dialog Creation and Termination . . . . . . . . . . . 24 4.4.1. Dialog Creation and Termination . . . . . . . . . . . 24
4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 24 4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 24
4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 25 4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 25
4.4.4. Allow-Events header field usage . . . . . . . . . . . 26 4.4.4. Allow-Events header field usage . . . . . . . . . . . 26
4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 26 4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 26
4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 27 4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 27
4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 27 4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 27
4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions . . 29 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions . . 29
5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 29 5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 30
5.2. Event Template-packages . . . . . . . . . . . . . . . . . 30 5.2. Event Template-packages . . . . . . . . . . . . . . . . . 30
5.3. Amount of State to be Conveyed . . . . . . . . . . . . . . 30 5.3. Amount of State to be Conveyed . . . . . . . . . . . . . . 31
5.3.1. Complete State Information . . . . . . . . . . . . . . 31 5.3.1. Complete State Information . . . . . . . . . . . . . . 31
5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 31 5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 32
5.4. Event Package Responsibilities . . . . . . . . . . . . . . 32 5.4. Event Package Responsibilities . . . . . . . . . . . . . . 32
5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 32 5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 33
5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 32 5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 33
5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 33 5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 33
5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33 5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33
5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 33 5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 34
5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 33 5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 34
5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 33 5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 34
5.4.8. Subscriber processing of NOTIFY requests . . . . . . . 34 5.4.8. Subscriber processing of NOTIFY requests . . . . . . . 34
5.4.9. Handling of forked requests . . . . . . . . . . . . . 34 5.4.9. Handling of forked requests . . . . . . . . . . . . . 34
5.4.10. Rate of notifications . . . . . . . . . . . . . . . . 35 5.4.10. Rate of notifications . . . . . . . . . . . . . . . . 35
5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35 5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35
5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 35 5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 35 5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36 6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36
6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 36 6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 37
6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 36 6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 37
6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 37 6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 37
6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 37 6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Registration Information . . . . . . . . . . . . . . . 38 7.1.1. Registration Information . . . . . . . . . . . . . . . 39
7.1.2. Registration Template . . . . . . . . . . . . . . . . 39 7.1.2. Registration Template . . . . . . . . . . . . . . . . 40
7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 39 7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 40
7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 40 7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 41
7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41 7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 41 8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.1. SUBSCRIBE method . . . . . . . . . . . . . . . . . . . 41 8.1.1. SUBSCRIBE method . . . . . . . . . . . . . . . . . . . 42
8.1.2. NOTIFY method . . . . . . . . . . . . . . . . . . . . 41 8.1.2. NOTIFY method . . . . . . . . . . . . . . . . . . . . 42
8.2. New Header Fields . . . . . . . . . . . . . . . . . . . . 42 8.2. New Header Fields . . . . . . . . . . . . . . . . . . . . 42
8.2.1. "Event" Header Field . . . . . . . . . . . . . . . . . 42 8.2.1. "Event" Header Field . . . . . . . . . . . . . . . . . 42
8.2.2. "Allow-Events" Header Field . . . . . . . . . . . . . 42 8.2.2. "Allow-Events" Header Field . . . . . . . . . . . . . 43
8.2.3. "Subscription-State" Header Field . . . . . . . . . . 43 8.2.3. "Subscription-State" Header Field . . . . . . . . . . 43
8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43 8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43
8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 43 8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 43
8.3.2. "489 Bad Event" Response Code . . . . . . . . . . . . 43 8.3.2. "489 Bad Event" Response Code . . . . . . . . . . . . 44
8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 44 8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Normative References . . . . . . . . . . . . . . . . . . . 45 9.1. Normative References . . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . . 45 9.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 47
Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 47 Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 48
B.1. Bug 666: Clarify use of expires=xxx with terminated . . . 47 B.1. Bug 666: Clarify use of expires=xxx with terminated . . . 48
B.2. Bug 667: Reason code for unsub/poll not clearly B.2. Bug 667: Reason code for unsub/poll not clearly
spelled out . . . . . . . . . . . . . . . . . . . . . . . 47 spelled out . . . . . . . . . . . . . . . . . . . . . . . 48
B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be
answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 47 answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 48
B.4. Bug 670: Dialog State Machine needs clarification . . . . 47 B.4. Bug 670: Dialog State Machine needs clarification . . . . 48
B.5. Bug 671: Clarify timeout-based removal of subscriptions . 48 B.5. Bug 671: Clarify timeout-based removal of subscriptions . 48
B.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . . . 48 B.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . . . 48
B.7. Bug 673: INVITE 481 response effect clarification . . . . 48 B.7. Bug 673: INVITE 481 response effect clarification . . . . 49
B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 48 B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 49
B.9. Bug 695: Document is not explicit about response to B.9. Bug 695: Document is not explicit about response to
NOTIFY at subscription termination . . . . . . . . . . . . 48 NOTIFY at subscription termination . . . . . . . . . . . . 49
B.10. Bug 696: Subscription state machine needs clarification . 48 B.10. Bug 696: Subscription state machine needs clarification . 49
B.11. Bug 697: Unsubscription behavior could be clarified . . . 48 B.11. Bug 697: Unsubscription behavior could be clarified . . . 49
B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh
requests . . . . . . . . . . . . . . . . . . . . . . . . . 48 requests . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 48 B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 49
B.14. Bug 741: guidance needed on when to not include B.14. Bug 741: guidance needed on when to not include
Allow-Events . . . . . . . . . . . . . . . . . . . . . . . 49 Allow-Events . . . . . . . . . . . . . . . . . . . . . . . 49
B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but
should not . . . . . . . . . . . . . . . . . . . . . . . . 49 should not . . . . . . . . . . . . . . . . . . . . . . . . 50
B.16. Bug 752: Detection of forked requests is incorrect . . . . 49 B.16. Bug 752: Detection of forked requests is incorrect . . . . 50
B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 49 B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 50
B.18. Bug 774: Need new reason for terminating subscriptions B.18. Bug 774: Need new reason for terminating subscriptions
to resources that never change . . . . . . . . . . . . . . 49 to resources that never change . . . . . . . . . . . . . . 50
B.19. Clarify handling of Route/Record-Route in NOTIFY . . . . . 49 B.19. Clarify handling of Route/Record-Route in NOTIFY . . . . . 50
B.20. Eliminate implicit subscriptions . . . . . . . . . . . . . 49 B.20. Eliminate implicit subscriptions . . . . . . . . . . . . . 50
B.21. Deprecate dialog re-use . . . . . . . . . . . . . . . . . 49 B.21. Deprecate dialog re-use . . . . . . . . . . . . . . . . . 50
B.22. Rationalize dialog creation . . . . . . . . . . . . . . . 50 B.22. Rationalize dialog creation . . . . . . . . . . . . . . . 50
B.23. Refactor behavior sections . . . . . . . . . . . . . . . . 50 B.23. Refactor behavior sections . . . . . . . . . . . . . . . . 51
B.24. Clarify sections that need to be present in event B.24. Clarify sections that need to be present in event
packages . . . . . . . . . . . . . . . . . . . . . . . . . 50 packages . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.25. Make CANCEL handling more explicit . . . . . . . . . . . . 50 B.25. Make CANCEL handling more explicit . . . . . . . . . . . . 51
B.26. Remove State Agent Terminology . . . . . . . . . . . . . . 50 B.26. Remove State Agent Terminology . . . . . . . . . . . . . . 51
B.27. Miscellanous Changes . . . . . . . . . . . . . . . . . . . 51 B.27. Miscellanous Changes . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
The ability to request asynchronous notification of events proves The ability to request asynchronous notification of events proves
useful in many types of SIP services for which cooperation between useful in many types of SIP services for which cooperation between
end-nodes is required. Examples of such services include automatic end-nodes is required. Examples of such services include automatic
callback services (based on terminal state events), buddy lists callback services (based on terminal state events), buddy lists
(based on user presence events), message waiting indications (based (based on user presence events), message waiting indications (based
on mailbox state change events), and PSTN and Internet on mailbox state change events), and PSTN and Internet
Internetworking (PINT) [RFC2848] status (based on call state events). Internetworking (PINT) [RFC2848] status (based on call state events).
skipping to change at page 6, line 27 skipping to change at page 6, line 27
form part of the specification, and is used only for form part of the specification, and is used only for
clarification. clarification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In particular, implementors need to take careful note of the meaning In particular, implementors need to take careful note of the meaning
of "SHOULD" defined in RFC 2119. To rephrase: violation of SHOULD- of "SHOULD" defined in RFC 2119. To rephrase: violation of SHOULD-
strength requirements requires careful analysis and clearly strength requirements requires careful analysis and clearly
enumerable reasons. It is inappropriate to fail to comply with enumerable reasons. It is a protocol violation to fail to comply
"SHOULD"-strength requirements whimsically or for ease of with "SHOULD"-strength requirements whimsically or for ease of
implementation. implementation.
The use of quotation marks next to periods and commas follows the The use of quotation marks next to periods and commas follows the
convention used by the American Mathematical Society; although convention used by the American Mathematical Society; although
contrary to traditional American English convention, this usage lends contrary to traditional American English convention, this usage lends
clarity to certain passages. clarity to certain passages.
2. Definitions 2. Definitions
Event Package: An event package is an additional specification which Event Package: An event package is an additional specification which
skipping to change at page 8, line 14 skipping to change at page 8, line 14
shorter but MUST NOT be longer than specified in the request. The shorter but MUST NOT be longer than specified in the request. The
notifier is explicitly allowed to shorten the duration to zero. The notifier is explicitly allowed to shorten the duration to zero. The
period of time in the response is the one which defines the duration period of time in the response is the one which defines the duration
of the subscription. of the subscription.
An "expires" parameter on the "Contact" header field has no semantics An "expires" parameter on the "Contact" header field has no semantics
for the SUBSCRIBE method and is explicitly not equivalent to an for the SUBSCRIBE method and is explicitly not equivalent to an
"Expires" header field in a SUBSCRIBE request or response. "Expires" header field in a SUBSCRIBE request or response.
A natural consequence of this scheme is that a SUBSCRIBE request with A natural consequence of this scheme is that a SUBSCRIBE request with
an "Expires" of 0 constitutes a request to unsubscribe from an event. an "Expires" of 0 constitutes a request to unsubscribe from the
matching subscription.
In addition to being a request to unsubscribe, a SUBSCRIBE request In addition to being a request to unsubscribe, a SUBSCRIBE request
with "Expires" of 0 also causes a fetch of state; see with "Expires" of 0 also causes a fetch of state; see
Section 4.4.3. Section 4.4.3.
Notifiers may also wish to cancel subscriptions to events; this is Notifiers may also wish to cancel subscriptions to events; this is
useful, for example, when the resource to which a subscription refers useful, for example, when the resource to which a subscription refers
is no longer available. Further details on this mechanism are is no longer available. Further details on this mechanism are
discussed in Section 4.2.2. discussed in Section 4.2.2.
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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. Events which result in a transition
back to the same state are not represented in this diagram.
+-------------+ +-------------+
| init |<-----------------------+ | init |<-----------------------+
+-------------+ | +-------------+ |
| Retry-after | Retry-after
Send SUBSCRIBE expires Send SUBSCRIBE expires
| | | |
V Timer N Fires; | V Timer N Fires; |
+-------------+ SUBSCRIBE failure | +-------------+ SUBSCRIBE failure |
+------------| notify_wait |-- response; --------+ | +------------| notify_wait |-- response; --------+ |
skipping to change at page 12, line 21 skipping to change at page 12, line 21
request represents a request outside of a dialog (as it typically request represents a request outside of a dialog (as it typically
will), its construction follows the procedures outlined in [RFC3261] will), its construction follows the procedures outlined in [RFC3261]
for UAC request generation outside of a dialog. for UAC request generation outside of a dialog.
This SUBSCRIBE request will be confirmed with a final response. 200- This SUBSCRIBE request will be confirmed with a final response. 200-
class responses indicate that the subscription has been accepted, and class responses indicate that the subscription has been accepted, and
that a NOTIFY request will be sent immediately. that a NOTIFY request will be sent immediately.
The "Expires" header field in a 200-class response to SUBSCRIBE The "Expires" header field in a 200-class response to SUBSCRIBE
request indicates the actual duration for which the subscription will request indicates the actual duration for which the subscription will
remain active (unless refreshed). remain active (unless refreshed). The received value might be
smaller than the value indicated in the SUBSCRIBE request, but cannot
be larger; see Section 4.2.1 for details.
Non-200 class final responses indicate that no subscription or new Non-200 class final responses indicate that no subscription or new
dialog usage has been created, and no subsequent NOTIFY request will dialog usage has been created, and no subsequent NOTIFY request will
be sent. All non-200 class responses (with the exception of "489", be sent. All non-200 class responses (with the exception of "489",
described herein) have the same meanings and handling as described in described herein) have the same meanings and handling as described in
[RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains
an "Accept" header field, but that field does not indicate a media an "Accept" header field, but that field does not indicate a media
type that the notifier is capable of generating in its NOTIFY type that the notifier is capable of generating in its NOTIFY
requests, then the proper error response is 406 (Not Acceptable). requests, then the proper error response is 406 (Not Acceptable).
skipping to change at page 14, line 6 skipping to change at page 14, line 8
expiration of Timer N, the subscriber SHOULD reject any such NOTIFY expiration of Timer N, the subscriber SHOULD reject any such NOTIFY
requests that would otherwise establish a new dialog usage with a requests that would otherwise establish a new dialog usage with a
"481" response code. "481" response code.
Until the first NOTIFY request arrives, the subscriber should Until the first NOTIFY request arrives, the subscriber should
consider the state of the subscribed resource to be in a neutral consider the state of the subscribed resource to be in a neutral
state. Event package specifications MUST define this "neutral state" state. Event package specifications MUST define this "neutral state"
in such a way that makes sense for their application (see in such a way that makes sense for their application (see
Section 5.4.7). Section 5.4.7).
Due to the potential for both out-of-order messages and forking, the Due to the potential for out-of-order messages, packet loss, and
subscriber MUST be prepared to receive NOTIFY requests before the forking, the subscriber MUST be prepared to receive NOTIFY requests
SUBSCRIBE transaction has completed. before the SUBSCRIBE transaction has completed.
Except as noted above, processing of this NOTIFY request is the same Except as noted above, processing of this NOTIFY request is the same
as in Section 4.1.3. as in Section 4.1.3.
4.1.3. Receiving and Processing State Information 4.1.3. Receiving and Processing State Information
Subscribers receive information about the state of a resource to Subscribers receive information about the state of a resource to
which they have subscribed in the form of NOTIFY requests. which they have subscribed in the form of NOTIFY requests.
Upon receiving a NOTIFY request, the subscriber should check that it Upon receiving a NOTIFY request, the subscriber should check that it
skipping to change at page 15, line 27 skipping to change at page 15, line 29
seconds specified by the "retry-after" parameter). The reason codes seconds specified by the "retry-after" parameter). The reason codes
defined by this document are: defined by this document are:
deactivated: The subscription has been terminated, but the deactivated: The subscription has been terminated, but the
subscriber SHOULD retry immediately with a new subscription. One subscriber SHOULD retry immediately with a new subscription. One
primary use of such a status code is to allow migration of primary use of such a status code is to allow migration of
subscriptions between nodes. The "retry-after" parameter has no subscriptions between nodes. The "retry-after" parameter has no
semantics for "deactivated". semantics for "deactivated".
probation: The subscription has been terminated, but the client probation: The subscription has been terminated, but the client
SHOULD retry at some later time. If a "retry-after" parameter is SHOULD retry at some later time (as long as the resource's state
also present, the client SHOULD wait at least the number of is still relevant to the client at that time). If a "retry-after"
seconds specified by that parameter before attempting to re- parameter is also present, the client SHOULD wait at least the
subscribe. number of seconds specified by that parameter before attempting to
re-subscribe.
rejected: The subscription has been terminated due to change in rejected: The subscription has been terminated due to change in
authorization policy. Clients SHOULD NOT attempt to re-subscribe. authorization policy. Clients SHOULD NOT attempt to re-subscribe.
The "retry-after" parameter has no semantics for "rejected". The "retry-after" parameter has no semantics for "rejected".
timeout: The subscription has been terminated because it was not timeout: The subscription has been terminated because it was not
refreshed before it expired. Clients MAY re-subscribe refreshed before it expired. Clients MAY re-subscribe
immediately. The "retry-after" parameter has no semantics for immediately. The "retry-after" parameter has no semantics for
"timeout". This reason code is also associated with polling of "timeout". This reason code is also associated with polling of
resource state, as detailed in Section 4.4.3 resource state, as detailed in Section 4.4.3
skipping to change at page 20, line 24 skipping to change at page 20, line 24
notifier may choose to omit state information from the terminal notifier may choose to omit state information from the terminal
NOTIFY request. NOTIFY request.
The sending of a NOTIFY request when a subscription expires allows The sending of a NOTIFY request when a subscription expires allows
the corresponding dialog usage to be terminated, if appropriate. the corresponding dialog usage to be terminated, if appropriate.
4.2.2. Sending State Information to Subscribers 4.2.2. Sending State Information to Subscribers
Notifiers use the NOTIFY method to send information about the state Notifiers use the NOTIFY method to send information about the state
of a resource to subscribers. The notifier's view of a subscription of a resource to subscribers. The notifier's view of a subscription
is shown in the following state diagram: is shown in the following state diagram. Events which result in a
transition back to the same state are not represented in this
diagram.
+-------------+ +-------------+
| init | | init |
+-------------+ +-------------+
| |
Receive SUBSCRIBE, Receive SUBSCRIBE,
Send NOTIFY Send NOTIFY
| |
V NOTIFY failure, V NOTIFY failure,
+-------------+ subscription expires, +-------------+ subscription expires,
skipping to change at page 21, line 40 skipping to change at page 21, line 40
| | | | | |
| V NOTIFY failure, | | V NOTIFY failure, |
| +-------------+ subscription expires, | | +-------------+ subscription expires, |
+----------->| active |-- or terminated ---------+ +----------->| active |-- or terminated ---------+
+-------------+ per local policy +-------------+ per local policy
When a SUBSCRIBE request is answered with a 200-class response, the When a SUBSCRIBE request is answered with a 200-class response, the
notifier MUST immediately construct and send a NOTIFY request to the notifier MUST immediately construct and send a NOTIFY request to the
subscriber. When a change in the subscribed state occurs, the subscriber. When a change in the subscribed state occurs, the
notifier SHOULD immediately construct and send a NOTIFY request, notifier SHOULD immediately construct and send a NOTIFY request,
subject to authorization, local policy, and throttling unless the state transition is caused by a NOTIFY transaction
considerations. failure. The sending of this NOTIFY message is also subject to
authorization, local policy, and throttling considerations.
If the NOTIFY request fails due to expiration of SIP Timer F If the NOTIFY request fails due to expiration of SIP Timer F
(transaction timeout), the notifier SHOULD remove the subscription. (transaction timeout), the notifier SHOULD remove the subscription.
This behavior prevents unnecessary transmission of state This behavior prevents unnecessary transmission of state
information for subscribers who have crashed or disappeared from information for subscribers who have crashed or disappeared from
the network. Because such transmissions will be sent multiple the network. Because such transmissions will be sent multiple
times, per the retransmission algorithm defined in [RFC3261] times, per the retransmission algorithm defined in [RFC3261]
(instead of the typical single transmission for functioning (instead of the typical single transmission for functioning
clients), continuing to service them when no client is available clients), continuing to service them when no client is available
skipping to change at page 26, line 38 skipping to change at page 26, line 38
Note that "Allow-Events" header fields MUST NOT be inserted by Note that "Allow-Events" header fields MUST NOT be inserted by
proxies. proxies.
The "Allow-Events" header field does not include a list of the event The "Allow-Events" header field does not include a list of the event
template packages supported by an implementation. If a subscriber template packages supported by an implementation. If a subscriber
wishes to determine which event template packages are supported by a wishes to determine which event template packages are supported by a
notifier, it can probe for such support by attempting to subscribe to notifier, it can probe for such support by attempting to subscribe to
the event template packages it wishes to use. the event template packages it wishes to use.
For example: to check for support for the templatized package
"presence.winfo", a client may attempt to subscribe to that event
package for a known resource, using an "Expires" header value of
0. if the response is a 489 error code, then the client can deduce
that "presence.winfo" is unsupported.
4.5. Targeting Subscriptions at Devices 4.5. Targeting Subscriptions at Devices
[RFC3265] defined a mechanism by which subscriptions could share [RFC3265] defined a mechanism by which subscriptions could share
dialogs with invite usages and with other subscriptions. The purpose dialogs with invite usages and with other subscriptions. The purpose
of this behavior was to allow subscribers to ensure that a of this behavior was to allow subscribers to ensure that a
subscription arrived at the same device as an established dialog. subscription arrived at the same device as an established dialog.
Unfortunately, the re-use of dialogs has proven to be exceedingly Unfortunately, the re-use of dialogs has proven to be exceedingly
confusing. [RFC5057] attempted to clarify proper behavior in a confusing. [RFC5057] attempted to clarify proper behavior in a
variety of circumstances; however, the ensuing rules remain confusing variety of circumstances; however, the ensuing rules remain confusing
and prone to implementation error. At the same time, the mechanism and prone to implementation error. At the same time, the mechanism
skipping to change at page 29, line 39 skipping to change at page 29, line 46
ignore it. In particular, the CANCEL request MUST NOT affect ignore it. In particular, the CANCEL request MUST NOT affect
processing of the SUBSCRIBE or NOTIFY request in any way. processing of the SUBSCRIBE or NOTIFY request in any way.
UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY
transactions. transactions.
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 the SUBSCRIBE and NOTIFY consideration when event packages based on the SUBSCRIBE and NOTIFY
methods are proposed. Event package definitions contain sections methods are proposed.
addressing each of these issues, ideally in the same order and with
the same titles as the following sections.
5.1. Appropriateness of Usage 5.1. Appropriateness of Usage
When designing an event package using the methods described in this When designing an event package using the methods described in this
document for event notification, it is important to consider: is SIP document for event notification, it is important to consider: is SIP
an appropriate mechanism for the problem set? Is SIP being selected an appropriate mechanism for the problem set? Is SIP being selected
because of some unique feature provided by the protocol (e.g., user because of some unique feature provided by the protocol (e.g., user
mobility), or merely because "it can be done?" If you find yourself mobility), or merely because "it can be done?" If you find yourself
defining event packages for notifications related to, for example, defining event packages for notifications related to, for example,
network management or the temperature inside your car's engine, you network management or the temperature inside your car's engine, you
skipping to change at page 30, line 41 skipping to change at page 31, line 5
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 the "Event" header field would be event token used in the "Event" header field would be
"presence.winfo". "presence.winfo".
This scheme may be arbitrarily extended. For example, application
of the "winfo" package to the the "presence.winfo" state of a
resource would be represented by the name "presence.winfo.winfo".
It naturally follows from this syntax that the order in which
templates are specified is significant.
For example: consider a theoretical event template-package called
"list". The event "presence.winfo.list" would be the application
of the "list" template to "presence.winfo", which would presumably
be a list of winfo state associated with presence. On the other
hand, the event "presence.list.winfo" would represent the
application of winfo to "presence.list", which would be represent
the winfo state of a list of presence information.
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
of information which will be conveyed during a notification. of information which will be conveyed during a notification.
skipping to change at page 32, line 25 skipping to change at page 32, line 49
described in this document, although they may choose to do so for described in this document, although they may choose to do so for
clarity or emphasis. In general, though, such packages are expected clarity or emphasis. In general, though, such packages are expected
to describe only the behavior that extends or modifies the behavior to describe only the behavior that extends or modifies the behavior
described in this document. described in this document.
Note that any behavior designated with "SHOULD" or "MUST" in this Note that any behavior designated with "SHOULD" or "MUST" in this
document is not allowed to be weakened by extension documents; document is not allowed to be weakened by extension documents;
however, such documents may elect to strengthen "SHOULD" requirements however, such documents may elect to strengthen "SHOULD" requirements
to "MUST" strength if required by their application. to "MUST" strength if required by their application.
In addition to the normal sections expected in standards-track In addition to the normal sections expected in standards-track RFCs
RFCs and SIP extension documents, authors of event packages need and SIP extension documents, authors of event packages need to
to address each of the issues detailed in the following address each of the issues detailed in the following subsections.
subsections, whenever applicable.
For clarity: well-formed event package definitions contain sections
addressing each of these issues, ideally in the same order and with
the same titles as these subsections.
5.4.1. Event Package Name 5.4.1. Event Package Name
This section, which MUST be present, defines the token name to be This section, which MUST be present, defines the token name to be
used to designate the event package. It MUST include the information used to designate the event package. It MUST include the information
which appears in the IANA registration of the token. For information which appears in the IANA registration of the token. For information
on registering such types, see Section 7. on registering such types, see Section 7.
5.4.2. Event Package Parameters 5.4.2. Event Package Parameters
skipping to change at page 38, line 14 skipping to change at page 38, line 38
NOTIFY requests. NOTIFY requests.
The mechanisms for providing confidentiality are detailed in The mechanisms for providing confidentiality are detailed in
[RFC3261]. [RFC3261].
7. IANA Considerations 7. IANA Considerations
(This section is not applicable until this document is published as (This section is not applicable until this document is published as
an RFC.) an RFC.)
With the exception of Section 7.2, the subsections here are for
current reference, carried over from the original specification. The
only IANA actions requested here are updating all registry references
that point to RFC 3265 to instead indicate this document, and
creating the new "reason code" registry described in Section 7.2.
7.1. Event Packages 7.1. Event Packages
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 is central coordinating body. The body chosen for this coordination is
the Internet Assigned Numbers Authority (IANA). the Internet Assigned Numbers Authority (IANA).
There are two different types of event-types: normal event packages, There are two different types of event-types: normal event packages,
and event template-packages; see Section 5.2. To avoid confusion, and event template-packages; see Section 5.2. To avoid confusion,
template-package names and package names share the same namespace; in template-package names and package names share the same namespace; in
other words, an event template-package MUST NOT share a name with a other words, an event template-package are forbidden from sharing a
package. name with a package.
Policies for registration of SIP event packages and SIP event package Policies for registration of SIP event packages and SIP event package
templates are defined in section 4.1 of [RFC5727]. templates are defined in section 4.1 of [RFC5727].
Registrations with the IANA MUST include the token being registered Registrations with the IANA are required to include the token being
and whether the token is a package or a template-package. Further, registered and whether the token is a package or a template-package.
packages MUST include contact information for the party responsible Further, packages must include contact information for the party
for the registration and/or a published document which describes the responsible for the registration and/or a published document which
event package. Event template-package token registrations MUST describes the event package. Event template-package token
include a pointer to the published RFC which defines the event registrations are also required to include a pointer to the published
template-package. RFC which defines the event template-package.
Registered tokens to designate packages and template-packages MUST Registered tokens to designate packages and template-packages are
NOT contain the character ".", which is used to separate template- disallowed from containing the character ".", which is used to
packages from packages. separate template-packages from packages.
7.1.1. Registration Information 7.1.1. Registration Information
As this document specifies no package or template-package names, the As this document specifies no package or template-package names, the
initial IANA registration for event types will be empty. The initial IANA registry for event types will be empty. The remainder
remainder of the text in this section gives an example of the type of of the text in this section gives an example of the type of
information to be maintained by the IANA; it also demonstrates all information to be maintained by the IANA; it also demonstrates all
five possible permutations of package type, contact, and reference. five possible permutations of package type, contact, and reference.
The table below lists the event packages and template-packages The table below lists the event packages and template-packages
defined in "SIP-Specific Event Notification" [RFC xxxx]. Each name defined in "SIP-Specific Event Notification" [RFC xxxx]. Each name
is designated as a package or a template-package under "Type". 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]
skipping to change at page 40, line 10 skipping to change at page 40, line 39
This document further defines "reason" codes for use in the This document further defines "reason" codes for use in the
"Subscription-State" header field (see Section 4.1.3). "Subscription-State" header field (see Section 4.1.3).
Following the policies outlined in "Guidelines for Writing an IANA Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" [RFC5226], new reason codes require a Considerations Section in RFCs" [RFC5226], new reason codes require a
Standards Action. Standards Action.
Registrations with the IANA include the reason code being registered Registrations with the IANA include the reason code being registered
and a reference to a published document which describes the event and a reference to a published document which describes the event
package. Insertion of such values takes place as part of the RFC package. Insertion of such values takes place as part of the RFC
publication process or as the result of inter-SDO liaison activity. publication process or as the result of inter-SDO liaison activity,
New reason codes must conform to the syntax of the ABNF "token" the result of which will be publication of an associated RFC. New
element defined in [RFC3261]. reason codes must conform to the syntax of the ABNF "token" element
defined in [RFC3261].
[RFC4660] defined a new reason code prior to the establishment of an [RFC4660] defined a new reason code prior to the establishment of an
IANA registry. We include its reason code ("badfilter") in the IANA registry. We include its reason code ("badfilter") in the
initial list of reason codes to ensure a complete registry. initial list of reason codes to ensure a complete registry.
The IANA registry for reason code will be initialized with the The IANA registry for reason code will be initialized with the
following values: following values:
Reason Code Reference Reason Code Reference
----------- --------- ----------- ---------
skipping to change at page 51, line 15 skipping to change at page 52, line 9
The definition of "State Agent" has been removed from Section 2. The definition of "State Agent" has been removed from Section 2.
Section 4.4.2 has been retooled to discuss migration of subscription Section 4.4.2 has been retooled to discuss migration of subscription
in general, without calling out the specific example of state agents. in general, without calling out the specific example of state agents.
Section 5.4.11 has been focused on state aggregation in particular, Section 5.4.11 has been focused on state aggregation in particular,
instead of state aggregation as an aspect of state agents. instead of state aggregation as an aspect of state agents.
B.27. Miscellanous Changes B.27. Miscellanous Changes
The following changes are relatively minor revisions to the document The following changes are relatively minor revisions to the document
that resulted primarily from review of this document in the working that resulted primarily from review of this document in the working
group rather than implementation reports. group and IESG, rather than implementation reports.
o Clarified scope of Event header field parameters. In RFC3265, the o Clarified scope of Event header field parameters. In RFC3265, the
scope is ambiguous, which causes problems with the RFC3968 scope is ambiguous, which causes problems with the RFC3968
registry. The new text ensures that Event header field parameters registry. The new text ensures that Event header field parameters
are unique across all event packages. are unique across all event packages.
o Removed obsoleted language around IANA registration policies for o Removed obsoleted language around IANA registration policies for
event packages. Instead, we now cite RFC5727, which supersedes event packages. Instead, we now cite RFC5727, which supersedes
RFC3265, and is authoritative on event package registration RFC3265, and is authoritative on event package registration
policy. policy.
skipping to change at page 52, line 5 skipping to change at page 52, line 47
indicates an unknown media type in its Accept header field. indicates an unknown media type in its Accept header field.
o Minor clarifications to Route and Record-Route behavior. o Minor clarifications to Route and Record-Route behavior.
o Added non-normative warning about the limitations of state o Added non-normative warning about the limitations of state
polling. polling.
o Added information about targeting subscriptions at specific o Added information about targeting subscriptions at specific
dialogs. dialogs.
o Added RFC 3261 to list of documents updated by this one (rather
than the "2543" indicated by RFC3265).
o Clarified text in Section 3.1.1 explaining the meaning of
"Expires: 0".
o Changed text in definition of "probation" reason code to indicate
that subscribers don't need to re-subscribe if the associated
state is no longer of use to them.
o Specified that the termination of a subscription due to a NOTIFY
transaction failure does not require sending another NOTIFY
message.
o Clarified how order of template application affects the meaning of
an Event header field value. (e.g., "foo.bar.baz" is different
than "foo.baz.bar").
Author's Address Author's Address
Adam Roach Adam Roach
Tekelec Tekelec
17210 Campbell Rd. 17210 Campbell Rd.
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
US US
Email: adam@nostrum.com Email: adam@nostrum.com
 End of changes. 49 change blocks. 
100 lines changed or deleted 157 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/