draft-ietf-sipcore-rfc3265bis-04.txt   draft-ietf-sipcore-rfc3265bis-05.txt 
Network Working Group A. B. Roach Network Working Group A. B. Roach
Internet-Draft Tekelec Internet-Draft Tekelec
Obsoletes: 3265 (if approved) October 18, 2011 Obsoletes: 3265 (if approved) February 23, 2012
Updates: 4660 (if approved) Updates: 4660 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 20, 2012 Expires: August 26, 2012
SIP-Specific Event Notification SIP-Specific Event Notification
draft-ietf-sipcore-rfc3265bis-04 draft-ietf-sipcore-rfc3265bis-05
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
original mechanism described by RFC 3265, taking into account several
years of implementation experience. Accordingly, this document
obsoletes RFC 3265. This document also updates RFC 4660 slightly to
accomodate some small changes to the mechanism that were discussed 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 April 20, 2012. This Internet-Draft will expire on August 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Copyright (c) 2011 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 44 skipping to change at page 3, line 4
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 . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . 32
5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 32 5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 32
5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . . 33
5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 33 5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 33
5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 33 5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 33
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 . . . . . . . . . . . . . . . . 34 5.4.10. Rate of notifications . . . . . . . . . . . . . . . . 34
5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35 5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35
5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 35 5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 35
5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 35 5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . 36
6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 36 6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 36
6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 37 6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 37
6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 37 6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 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 . . . . . . . . . . . . . . . 38
7.1.2. Registration Template . . . . . . . . . . . . . . . . 39 7.1.2. Registration Template . . . . . . . . . . . . . . . . 39
7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 39 7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 39
7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 40 7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 40
7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41 7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 41 8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 41
8.1.1. SUBSCRIBE method . . . . . . . . . . . . . . . . . . . 41 8.1.1. SUBSCRIBE method . . . . . . . . . . . . . . . . . . . 41
8.1.2. NOTIFY method . . . . . . . . . . . . . . . . . . . . 41 8.1.2. NOTIFY method . . . . . . . . . . . . . . . . . . . . 41
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 . . . . . . . . . . . . . 42
8.2.3. "Subscription-State" Header Field . . . . . . . . . . 42 8.2.3. "Subscription-State" Header Field . . . . . . . . . . 42
8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 42 8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43
8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 42 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 . . . . . . . . . . . . 43
8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 43 8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . . 45 9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 47
B.1. Changes from draft-ietf-sipcore-rfc3265bis-03 to B.1. Bug 666: Clarify use of expires=xxx with terminated . . . 47
draft-ietf-sipcore-rfc3265bis-04 . . . . . . . . . . . . . 47 B.2. Bug 667: Reason code for unsub/poll not clearly
B.2. Changes from draft-ietf-sipcore-rfc3265bis-02 to spelled out . . . . . . . . . . . . . . . . . . . . . . . 47
draft-ietf-sipcore-rfc3265bis-03 . . . . . . . . . . . . . 47 B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be
B.3. Changes from draft-ietf-sipcore-rfc3265bis-01 to answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 47
draft-ietf-sipcore-rfc3265bis-02 . . . . . . . . . . . . . 47 B.4. Bug 670: Dialog State Machine needs clarification . . . . 47
B.4. Changes from draft-ietf-sipcore-rfc3265bis-00 to B.5. Bug 671: Clarify timeout-based removal of subscriptions . 47
draft-ietf-sipcore-rfc3265bis-01 . . . . . . . . . . . . . 48 B.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . . . 47
B.5. Changes from draft-roach-sipcore-rfc3265bis-00 to B.7. Bug 673: INVITE 481 response effect clarification . . . . 48
draft-ietf-sipcore-rfc3265bis-00 . . . . . . . . . . . . . 48 B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 48
B.6. Changes since RFC 3265 . . . . . . . . . . . . . . . . . . 48 B.9. Bug 695: Document is not explicit about response to
B.6.1. Bug 666: Clarify use of expires=xxx with terminated . 48 NOTIFY at subscription termination . . . . . . . . . . . . 48
B.6.2. Bug 667: Reason code for unsub/poll not clearly B.10. Bug 696: Subscription state machine needs clarification . 48
spelled out . . . . . . . . . . . . . . . . . . . . . 48 B.11. Bug 697: Unsubscription behavior could be clarified . . . 48
B.6.3. Bug 669: Clarify: SUBSCRIBE for a duration might B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh
be answered with a NOTIFY/expires=0 . . . . . . . . . 48 requests . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.6.4. Bug 670: Dialog State Machine needs clarification . . 48 B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 48
B.6.5. Bug 671: Clarify timeout-based removal of B.14. Bug 741: guidance needed on when to not include
subscriptions . . . . . . . . . . . . . . . . . . . . 48 Allow-Events . . . . . . . . . . . . . . . . . . . . . . . 48
B.6.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . 49 B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but
B.6.7. Bug 673: INVITE 481 response effect clarification . . 49 should not . . . . . . . . . . . . . . . . . . . . . . . . 49
B.6.8. Bug 677: SUBSCRIBE response matching text in error . . 49 B.16. Bug 752: Detection of forked requests is incorrect . . . . 49
B.6.9. Bug 695: Document is not explicit about response B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 49
to NOTIFY at subscription termination . . . . . . . . 49 B.18. Bug 774: Need new reason for terminating subscriptions
B.6.10. Bug 696: Subscription state machine needs to resources that never change . . . . . . . . . . . . . . 49
clarification . . . . . . . . . . . . . . . . . . . . 49 B.19. Clarify handling of Route/Record-Route in NOTIFY . . . . . 49
B.6.11. Bug 697: Unsubscription behavior could be clarified . 49 B.20. Eliminate implicit subscriptions . . . . . . . . . . . . . 49
B.6.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh B.21. Deprecate dialog re-use . . . . . . . . . . . . . . . . . 49
requests . . . . . . . . . . . . . . . . . . . . . . . 49 B.22. Rationalize dialog creation . . . . . . . . . . . . . . . 49
B.6.13. Bug 722: Inconsistent 423 reason phrase text . . . . . 49 B.23. Refactor behavior sections . . . . . . . . . . . . . . . . 50
B.6.14. Bug 741: guidance needed on when to not include B.24. Clarify sections that need to be present in event
Allow-Events . . . . . . . . . . . . . . . . . . . . . 49 packages . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.6.15. Bug 744: 5xx to NOTIFY terminates a subscription, B.25. Make CANCEL handling more explicit . . . . . . . . . . . . 50
but should not . . . . . . . . . . . . . . . . . . . . 50 B.26. Remove State Agent Terminology . . . . . . . . . . . . . . 50
B.6.16. Bug 752: Detection of forked requests is incorrect . . 50 B.27. Miscellanous Changes . . . . . . . . . . . . . . . . . . . 51
B.6.17. Bug 773: Reason code needs IANA registry . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.6.18. Bug 774: Need new reason for terminating
subscriptions to resources that never change . . . . . 50
B.6.19. Clarify handling of Route/Record-Route in NOTIFY . . . 50
B.6.20. Eliminate implicit subscriptions . . . . . . . . . . . 50
B.6.21. Deprecate dialog re-use . . . . . . . . . . . . . . . 50
B.6.22. Rationalize dialog creation . . . . . . . . . . . . . 50
B.6.23. Refactor behavior sections . . . . . . . . . . . . . . 51
B.6.24. Clarify sections that need to be present in event
packages . . . . . . . . . . . . . . . . . . . . . . . 51
B.6.25. Make CANCEL handling more explicit . . . . . . . . . . 51
B.6.26. Remove State Agent Terminology . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52
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 27, line 52 skipping to change at page 28, line 5
Subscribers MUST NOT attempt to re-use dialogs whose remote target is Subscribers MUST NOT attempt to re-use dialogs whose remote target is
a GRUU. a GRUU.
Note that the techniques described in this section are included Note that the techniques described in this section are included
for backwards compatibility purposes only. Because subscribers for backwards compatibility purposes only. Because subscribers
cannot re-use dialogs with a GRUU for their remote target, and cannot re-use dialogs with a GRUU for their remote target, and
because notifiers must use GRUUs as their local target, any two because notifiers must use GRUUs as their local target, any two
implementations that conform to this specification will implementations that conform to this specification will
automatically use the mechanism described in Section 4.5.1. automatically use the mechanism described in Section 4.5.1.
Further note that the prohibition on re-using dialogs does not
exempt implicit subscriptions created by the REFER method. This
means that implementations complying with this specification are
required to use the "Target-Dialog" mechanism described in
[RFC4538] when the remote target is a GRUU.
If a subscriber wishes to subscribe to a resource on the same device If a subscriber wishes to subscribe to a resource on the same device
as an established dialog and the remote contact is not a GRUU, it MAY as an established dialog and the remote contact is not a GRUU, it MAY
revert to dialog sharing behavior. Alternately, it MAY choose to revert to dialog sharing behavior. Alternately, it MAY choose to
treat the remote party as incapable of servicing the subscription treat the remote party as incapable of servicing the subscription
(i.e., the same way it would behave if the remote party did not (i.e., the same way it would behave if the remote party did not
support SIP events at all). support SIP events at all).
If a notifier receives a SUBSCRIBE request for a new subscription on If a notifier receives a SUBSCRIBE request for a new subscription on
an existing dialog, it MAY choose to implement dialog sharing an existing dialog, it MAY choose to implement dialog sharing
behavior. Alternately, it may choose to fail the SUBSCRIBE request behavior. Alternately, it may choose to fail the SUBSCRIBE request
skipping to change at page 42, line 33 skipping to change at page 42, line 33
does not match) or "Event: Foo; id=1234" (event portion does not does not match) or "Event: Foo; id=1234" (event portion does not
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
NOTIFY requests. 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
request or response, as long as it includes a comprehensive and
inclusive list of the packages for which the User Agent can act as a
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. described in Section 4.1.3. "Subscription-State" header fields are
defined for use in NOTIFY requests only. They MUST NOT appear in
other SIP requests or responses.
8.3. New Response Codes 8.3. New Response Codes
8.3.1. "202 Accepted" Response Code 8.3.1. "202 Accepted" Response Code
For historical purposes, the 202 (Accepted) response code is added to For historical purposes, the 202 (Accepted) response code is added to
the "Success" header field definition. the "Success" header field definition.
This document does not specify the use of the 202 response code in This document does not specify the use of the 202 response code in
conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions
skipping to change at page 47, line 6 skipping to change at page 47, line 9
semantics. semantics.
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 Appendix B. Changes from RFC 3265
This section, and all of its subsections, will be consolidated into a
single "Changes Since RFC 3265" section prior to publication. Bug
numbers refer to the identifiers for the bug reports kept on file at
http://bugs.sipit.net/.
B.1. Changes from draft-ietf-sipcore-rfc3265bis-03 to
draft-ietf-sipcore-rfc3265bis-04
Added rationale text to deprecation of 202 response code.
B.2. Changes from draft-ietf-sipcore-rfc3265bis-02 to
draft-ietf-sipcore-rfc3265bis-03
o Clarified scope of Event header field parameters. In RFC3265, the
scope is ambiguous, which causes problems with the RFC3968
registry. The new text ensures that Event header field parameters
are unique across all event packages.
o Removed obsoleted language around IANA registration policies for
event packages. Instead, we now cite RFC5727, which supersedes
RFC3265, and is authoritative on event package registration
policy.
o Several editorial updates after input from working group,
including proper designation of "dialog usage" rather than
"dialog" where appropriate.
o Fixed left-over language that allowed implicit subscriptions (in
contradiction to text elsewhere in the document)
o Fixed subscriber state machine handling of Timer N
o Clarified two normative statements about subscription termination
by changing from plain English prose to RFC2119 language.
B.3. Changes from draft-ietf-sipcore-rfc3265bis-01 to
draft-ietf-sipcore-rfc3265bis-02
o Removed "Table 2" expansions, per WG consensus on how SIP table 2
is to be handled.
o Removed 202 response code.
o Clarified that "Allow-Events" does not list event template
packages.
o Clarified that Timer N *does* apply to subscription refreshes.
B.4. Changes from draft-ietf-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-01
o Renamed Timer L to Timer N, to avoid a naming conflict.
o Added clarification about proper response when the SUBSCRIBE
indicates an unknown MIME type in its Accept header field.
o Clarification around Route and Record-Route behavior.
o Added non-normative warning about the limitations of state
polling.
o Added information about targeting subscriptions at specific
dialogs.
o Added "Call-Info" header field to RFC 3261 Table 2 expansion.
B.5. Changes from draft-roach-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-00
None
B.6. Changes since RFC 3265 This document represents several changes from the mechainsm
originally described in RFC 3265. This section summarizes those
changes. Bug numbers refer to the identifiers for the bug reports
kept on file at http://bugs.sipit.net/.
B.6.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.6.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
Clarified description of "timeout" in Section 4.1.3. (n.b., the text Clarified description of "timeout" in Section 4.1.3. (n.b., the text
in Section 4.4.3 is actually pretty clear about this). in Section 4.4.3 is actually pretty clear about this).
B.6.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered with
with a NOTIFY/expires=0 a NOTIFY/expires=0
Added clarifying text to Section 4.2.2 explaining that shortening a Added clarifying text to Section 4.2.2 explaining that shortening a
subscription to zero seconds is valid. Also added sentence to subscription to zero seconds is valid. Also added sentence to
Section 3.1.1 explicitly allowing shortening to zero. Section 3.1.1 explicitly allowing shortening to zero.
B.6.4. Bug 670: Dialog State Machine needs clarification B.4. Bug 670: Dialog State Machine needs clarification
The issues associated with the bug deal exclusively with the handling The issues associated with the bug deal exclusively with the handling
of multiple usages with a dialog. This behavior has been deprecated of multiple usages with a dialog. This behavior has been deprecated
and moved to Section 4.5.2. This section, in turn, cites [RFC5057], and moved to Section 4.5.2. This section, in turn, cites [RFC5057],
which addresses all of the issues in Bug 670. which addresses all of the issues in Bug 670.
B.6.5. Bug 671: Clarify timeout-based removal of subscriptions B.5. Bug 671: Clarify timeout-based removal of subscriptions
Changed Section 4.2.2 to specifically cite Timer F (so as to avoid Changed Section 4.2.2 to specifically cite Timer F (so as to avoid
ambiguity between transaction timeouts and retransmission timeouts). ambiguity between transaction timeouts and retransmission timeouts).
B.6.6. Bug 672: Mandate expires= in NOTIFY B.6. Bug 672: Mandate expires= in NOTIFY
Changed strength of including of "expires" in a NOTIFY from SHOULD to Changed strength of including of "expires" in a NOTIFY from SHOULD to
MUST in Section 4.2.2. MUST in Section 4.2.2.
B.6.7. Bug 673: INVITE 481 response effect clarification B.7. Bug 673: INVITE 481 response effect clarification
This bug was addressed in [RFC5057]. This bug was addressed in [RFC5057].
B.6.8. Bug 677: SUBSCRIBE response matching text in error B.8. Bug 677: SUBSCRIBE response matching text in error
Fixed Section 8.2.1 to remove incorrect "...responses and..." -- Fixed Section 8.2.1 to remove incorrect "...responses and..." --
explicitly pointed to SIP for transaction response handling. explicitly pointed to SIP for transaction response handling.
B.6.9. Bug 695: Document is not explicit about response to NOTIFY at B.9. Bug 695: Document is not explicit about response to NOTIFY at
subscription termination subscription termination
Added text to Section 4.4.1 indicating that the typical response to a Added text to Section 4.4.1 indicating that the typical response to a
terminal NOTIFY is a "200 OK". terminal NOTIFY is a "200 OK".
B.6.10. Bug 696: Subscription state machine needs clarification B.10. Bug 696: Subscription state machine needs clarification
Added state machine diagram to Section 4.1.2 with explicit handling Added state machine diagram to Section 4.1.2 with explicit handling
of what to do when a SUBSCRIBE never shows up. Added definition of of what to do when a SUBSCRIBE never shows up. Added definition of
and handling for new Timer N to Section 4.1.2.4. Added state machine and handling for new Timer N to Section 4.1.2.4. Added state machine
to Section 4.2.2 to reinforce text. to Section 4.2.2 to reinforce text.
B.6.11. Bug 697: Unsubscription behavior could be clarified B.11. Bug 697: Unsubscription behavior could be clarified
Added text to Section 4.2.1.4 encouraging (but not requiring) full Added text to Section 4.2.1.4 encouraging (but not requiring) full
state in final NOTIFY request. Also added text to Section 4.1.2.3 state in final NOTIFY request. Also added text to Section 4.1.2.3
warning subscribers that full state may or may not be present in the warning subscribers that full state may or may not be present in the
final NOTIFY. final NOTIFY.
B.6.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh requests B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh requests
Added text to both Section 3.1 and Section 3.2 explicitly indicating Added text to both Section 3.1 and Section 3.2 explicitly indicating
that SUBSCRIBE and NOTIFY are target refresh methods. that SUBSCRIBE and NOTIFY are target refresh methods.
B.6.13. Bug 722: Inconsistent 423 reason phrase text B.13. Bug 722: Inconsistent 423 reason phrase text
Changed reason code to "Interval Too Brief" in Section 4.2.1.1 and Changed reason code to "Interval Too Brief" in Section 4.2.1.1 and
Section 4.2.1.4, to match 423 reason code in SIP [RFC3261]. Section 4.2.1.4, to match 423 reason code in SIP [RFC3261].
B.6.14. Bug 741: guidance needed on when to not include Allow-Events B.14. Bug 741: guidance needed on when to not include Allow-Events
Added non-normative clarification to Section 4.4.4 regarding Added non-normative clarification to Section 4.4.4 regarding
inclusion of Allow-Events in a NOTIFY for the one-and-only package inclusion of Allow-Events in a NOTIFY for the one-and-only package
supported by the notifier. supported by the notifier.
B.6.15. Bug 744: 5xx to NOTIFY terminates a subscription, but should B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but should not
not
Issue of subscription (usage) termination versus dialog termination Issue of subscription (usage) termination versus dialog termination
is handled in [RFC5057]. The text in Section 4.2.2 has been updated is handled in [RFC5057]. The text in Section 4.2.2 has been updated
to summarize the behavior described by 5057, and cites it for to summarize the behavior described by 5057, and cites it for
additional detail and rationale. additional detail and rationale.
B.6.16. Bug 752: Detection of forked requests is incorrect B.16. Bug 752: Detection of forked requests is incorrect
Removed erroneous "CSeq" from list of matching criteria in Removed erroneous "CSeq" from list of matching criteria in
Section 5.4.9. Section 5.4.9.
B.6.17. Bug 773: Reason code needs IANA registry B.17. Bug 773: Reason code needs IANA registry
Added Section 7.2 to create and populate IANA registry. Added Section 7.2 to create and populate IANA registry.
B.6.18. Bug 774: Need new reason for terminating subscriptions to B.18. Bug 774: Need new reason for terminating subscriptions to
resources that never change resources that never change
Added new "invariant" reason code to Section 4.1.3, ABNF syntax. Added new "invariant" reason code to Section 4.1.3, ABNF syntax.
B.6.19. Clarify handling of Route/Record-Route in NOTIFY B.19. Clarify handling of Route/Record-Route in NOTIFY
Changed text in Section 4.3 mandating Record-Route in initial Changed text in Section 4.3 mandating Record-Route in initial
SUBSCRIBE and all NOTIFY requests, and adding "MAY" level statements SUBSCRIBE and all NOTIFY requests, and adding "MAY" level statements
for subsequent SUBSCRIBE requests. for subsequent SUBSCRIBE requests.
B.6.20. Eliminate implicit subscriptions B.20. Eliminate implicit subscriptions
Added text to Section 4.2.1 explaining some of the problems Added text to Section 4.2.1 explaining some of the problems
associated with implicit subscriptions, normative language associated with implicit subscriptions, normative language
prohibiting them. Removed language from Section 3.2 describing "non- prohibiting them. Removed language from Section 3.2 describing "non-
SUBSCRIBE" mechanisms for creating subscriptions. Simplified SUBSCRIBE" mechanisms for creating subscriptions. Simplified
language in Section 4.2.2, now that the soft-state/non-soft-state language in Section 4.2.2, now that the soft-state/non-soft-state
distinction is unnecessary. distinction is unnecessary.
B.6.21. Deprecate dialog re-use B.21. Deprecate dialog re-use
Moved handling of dialog re-use and "id" handling to Section 4.5.2. Moved handling of dialog re-use and "id" handling to Section 4.5.2.
It is documented only for backwards-compatibility purposes. It is documented only for backwards-compatibility purposes.
B.6.22. Rationalize dialog creation B.22. Rationalize dialog creation
Section 4.4.1 has been updated to specify that dialogs should be Section 4.4.1 has been updated to specify that dialogs should be
created when the NOTIFY arrives. Previously, the dialog was created when the NOTIFY arrives. Previously, the dialog was
established by the SUBSCRIBE 200, or by the NOTIFY transaction. This established by the SUBSCRIBE 200, or by the NOTIFY transaction. This
was unnecessarily complicated; the newer rules are easier to was unnecessarily complicated; the newer rules are easier to
implement (and result in effectively the same behavior on the wire). implement (and result in effectively the same behavior on the wire).
B.6.23. Refactor behavior sections B.23. Refactor behavior sections
Reorganized Section 4 to consolidate behavior along role lines Reorganized Section 4 to consolidate behavior along role lines
(subscriber/notifier/proxy) instead of method lines. (subscriber/notifier/proxy) instead of method lines.
B.6.24. Clarify sections that need to be present in event packages B.24. Clarify sections that need to be present in event packages
Added sentence to Section 5 clarifying that event packages are Added sentence to Section 5 clarifying that event packages are
expected to include explicit sections covering the issues discussed expected to include explicit sections covering the issues discussed
in this section. in this section.
B.6.25. Make CANCEL handling more explicit B.25. Make CANCEL handling more explicit
Text in Section 4.6 now clearly calls out behavior upon receipt of a Text in Section 4.6 now clearly calls out behavior upon receipt of a
CANCEL. We also echo the "...SHOULD NOT send..." requirement from CANCEL. We also echo the "...SHOULD NOT send..." requirement from
[RFC3261]. [RFC3261].
B.6.26. Remove State Agent Terminology B.26. Remove State Agent Terminology
As originally planned, we anticipated a fairly large number of event As originally planned, we anticipated a fairly large number of event
packages that would move back and forth between end-user devices and packages that would move back and forth between end-user devices and
servers in the network. In practice, this has ended up not being the servers in the network. In practice, this has ended up not being the
case. Certain events, like dialog state, are inherently hosted at case. Certain events, like dialog state, are inherently hosted at
end-user devices; others, like presence, are almost always hosted in end-user devices; others, like presence, are almost always hosted in
the network (due to issues like composition, and the ability to the network (due to issues like composition, and the ability to
deliver information when user devices are offline). Further, the deliver information when user devices are offline). Further, the
concept of State Agents is the most misunderstood by event package concept of State Agents is the most misunderstood by event package
authors. In my expert review of event packages, I have yet to find authors. In my expert review of event packages, I have yet to find
skipping to change at page 52, line 4 skipping to change at page 50, line 49
simply eliminated this term. Instead, we talk about the behaviors simply eliminated this term. Instead, we talk about the behaviors
required to create state agents (state aggregation, subscription required to create state agents (state aggregation, subscription
notification) without defining a formal term to describe the servers notification) without defining a formal term to describe the servers
that exhibit these behaviors. In effect, this is an editorial change that exhibit these behaviors. In effect, this is an editorial change
to make life easier for event package authors; the actual protocol to make life easier for event package authors; the actual protocol
does not change as a result. does not change as a result.
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
The following changes are relatively minor revisions to the document
that resulted primarily from review of this document in the working
group rather than implementation reports.
o Clarified scope of Event header field parameters. In RFC3265, the
scope is ambiguous, which causes problems with the RFC3968
registry. The new text ensures that Event header field parameters
are unique across all event packages.
o Removed obsoleted language around IANA registration policies for
event packages. Instead, we now cite RFC5727, which supersedes
RFC3265, and is authoritative on event package registration
policy.
o Several editorial updates after input from working group,
including proper designation of "dialog usage" rather than
"dialog" where appropriate.
o Clarified two normative statements about subscription termination
by changing from plain English prose to RFC2119 language.
o Removed "Table 2" expansions, per WG consensus on how SIP table 2
is to be handled.
o Removed 202 response code.
o Clarified that "Allow-Events" does not list event template
packages.
o Added clarification about proper response when the SUBSCRIBE
indicates an unknown MIME type in its Accept header field.
o Minor clarifications to Route and Record-Route behavior.
o Added non-normative warning about the limitations of state
polling.
o Added information about targeting subscriptions at specific
dialogs.
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. 46 change blocks. 
152 lines changed or deleted 148 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/