draft-ietf-sipcore-rfc3265bis-03.txt   draft-ietf-sipcore-rfc3265bis-04.txt 
Network Working Group A. B. Roach Network Working Group A. B. Roach
Internet-Draft Tekelec Internet-Draft Tekelec
Obsoletes: 3265 (if approved) July 5, 2011 Obsoletes: 3265 (if approved) October 18, 2011
Updates: 4660 (if approved) Updates: 4660 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 6, 2012 Expires: April 20, 2012
SIP-Specific Event Notification SIP-Specific Event Notification
draft-ietf-sipcore-rfc3265bis-03 draft-ietf-sipcore-rfc3265bis-04
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 6, 2012. This Internet-Draft will expire on April 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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 . . . . . . . . . . . . . . . . . . . . 42
8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 42 8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 42
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 . . . . . . . . . . . . . . . . . . . . . . . 47
B.1. Changes from draft-ietf-sipcore-rfc3265bis-02 to B.1. Changes from draft-ietf-sipcore-rfc3265bis-03 to
draft-ietf-sipcore-rfc3265bis-04 . . . . . . . . . . . . . 47
B.2. Changes from draft-ietf-sipcore-rfc3265bis-02 to
draft-ietf-sipcore-rfc3265bis-03 . . . . . . . . . . . . . 47 draft-ietf-sipcore-rfc3265bis-03 . . . . . . . . . . . . . 47
B.2. Changes from draft-ietf-sipcore-rfc3265bis-01 to B.3. Changes from draft-ietf-sipcore-rfc3265bis-01 to
draft-ietf-sipcore-rfc3265bis-02 . . . . . . . . . . . . . 47 draft-ietf-sipcore-rfc3265bis-02 . . . . . . . . . . . . . 47
B.3. Changes from draft-ietf-sipcore-rfc3265bis-00 to B.4. Changes from draft-ietf-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-01 . . . . . . . . . . . . . 47 draft-ietf-sipcore-rfc3265bis-01 . . . . . . . . . . . . . 48
B.4. Changes from draft-roach-sipcore-rfc3265bis-00 to B.5. Changes from draft-roach-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-00 . . . . . . . . . . . . . 48 draft-ietf-sipcore-rfc3265bis-00 . . . . . . . . . . . . . 48
B.5. Changes since RFC 3265 . . . . . . . . . . . . . . . . . . 48 B.6. Changes since RFC 3265 . . . . . . . . . . . . . . . . . . 48
B.5.1. Bug 666: Clarify use of expires=xxx with terminated . 48 B.6.1. Bug 666: Clarify use of expires=xxx with terminated . 48
B.5.2. Bug 667: Reason code for unsub/poll not clearly B.6.2. Bug 667: Reason code for unsub/poll not clearly
spelled out . . . . . . . . . . . . . . . . . . . . . 48 spelled out . . . . . . . . . . . . . . . . . . . . . 48
B.5.3. Bug 669: Clarify: SUBSCRIBE for a duration might B.6.3. Bug 669: Clarify: SUBSCRIBE for a duration might
be answered with a NOTIFY/expires=0 . . . . . . . . . 48 be answered with a NOTIFY/expires=0 . . . . . . . . . 48
B.5.4. Bug 670: Dialog State Machine needs clarification . . 48 B.6.4. Bug 670: Dialog State Machine needs clarification . . 48
B.5.5. Bug 671: Clarify timeout-based removal of B.6.5. Bug 671: Clarify timeout-based removal of
subscriptions . . . . . . . . . . . . . . . . . . . . 48 subscriptions . . . . . . . . . . . . . . . . . . . . 48
B.5.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . 48 B.6.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . 49
B.5.7. Bug 673: INVITE 481 response effect clarification . . 49 B.6.7. Bug 673: INVITE 481 response effect clarification . . 49
B.5.8. Bug 677: SUBSCRIBE response matching text in error . . 49 B.6.8. Bug 677: SUBSCRIBE response matching text in error . . 49
B.5.9. Bug 695: Document is not explicit about response B.6.9. Bug 695: Document is not explicit about response
to NOTIFY at subscription termination . . . . . . . . 49 to NOTIFY at subscription termination . . . . . . . . 49
B.5.10. Bug 696: Subscription state machine needs B.6.10. Bug 696: Subscription state machine needs
clarification . . . . . . . . . . . . . . . . . . . . 49 clarification . . . . . . . . . . . . . . . . . . . . 49
B.5.11. Bug 697: Unsubscription behavior could be clarified . 49 B.6.11. Bug 697: Unsubscription behavior could be clarified . 49
B.5.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh B.6.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh
requests . . . . . . . . . . . . . . . . . . . . . . . 49 requests . . . . . . . . . . . . . . . . . . . . . . . 49
B.5.13. Bug 722: Inconsistent 423 reason phrase text . . . . . 49 B.6.13. Bug 722: Inconsistent 423 reason phrase text . . . . . 49
B.5.14. Bug 741: guidance needed on when to not include B.6.14. Bug 741: guidance needed on when to not include
Allow-Events . . . . . . . . . . . . . . . . . . . . . 49 Allow-Events . . . . . . . . . . . . . . . . . . . . . 49
B.5.15. Bug 744: 5xx to NOTIFY terminates a subscription, B.6.15. Bug 744: 5xx to NOTIFY terminates a subscription,
but should not . . . . . . . . . . . . . . . . . . . . 50 but should not . . . . . . . . . . . . . . . . . . . . 50
B.5.16. Bug 752: Detection of forked requests is incorrect . . 50 B.6.16. Bug 752: Detection of forked requests is incorrect . . 50
B.5.17. Bug 773: Reason code needs IANA registry . . . . . . . 50 B.6.17. Bug 773: Reason code needs IANA registry . . . . . . . 50
B.5.18. Bug 774: Need new reason for terminating B.6.18. Bug 774: Need new reason for terminating
subscriptions to resources that never change . . . . . 50 subscriptions to resources that never change . . . . . 50
B.5.19. Clarify handling of Route/Record-Route in NOTIFY . . . 50 B.6.19. Clarify handling of Route/Record-Route in NOTIFY . . . 50
B.5.20. Eliminate implicit subscriptions . . . . . . . . . . . 50 B.6.20. Eliminate implicit subscriptions . . . . . . . . . . . 50
B.5.21. Deprecate dialog re-use . . . . . . . . . . . . . . . 50 B.6.21. Deprecate dialog re-use . . . . . . . . . . . . . . . 50
B.5.22. Rationalize dialog creation . . . . . . . . . . . . . 50 B.6.22. Rationalize dialog creation . . . . . . . . . . . . . 50
B.5.23. Refactor behavior sections . . . . . . . . . . . . . . 51 B.6.23. Refactor behavior sections . . . . . . . . . . . . . . 51
B.5.24. Clarify sections that need to be present in event B.6.24. Clarify sections that need to be present in event
packages . . . . . . . . . . . . . . . . . . . . . . . 51 packages . . . . . . . . . . . . . . . . . . . . . . . 51
B.5.25. Make CANCEL handling more explicit . . . . . . . . . . 51 B.6.25. Make CANCEL handling more explicit . . . . . . . . . . 51
B.5.26. Remove State Agent Terminology . . . . . . . . . . . . 51 B.6.26. Remove State Agent Terminology . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 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
skipping to change at page 43, line 5 skipping to change at page 43, line 5
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
of the SIP Events Framework assigned specific semantics to the 202 of the SIP Events Framework assigned specific meaning to the 202
response code. Implementations conformant with the current response code.
specification MUST treat an incoming 202 response as identical to a
200 response, and MUST NOT generate 202 response codes to SUBSCRIBE Due to response handling in forking cases, any 202 response to a
or NOTIFY requests. SUBSCRIBE request may be absorbed by a proxy, and thus it can never
be guaranteed to be received by the UAC. Furthermore, there is no
actual processing difference for a 202 as compared to a 200; a NOTIFY
request is sent after the subscription is processed, and it conveys
the correct state. SIP interoperability tests found that
implementations were handling 202 differently from 200, leading to
incompatibilities. Therefore, the 202 response is being deprecated
to make it clear there is no such difference and 202 should not be
handled differently than 200.
Implementations conformant with the current specification MUST treat
an incoming 202 response as identical to a 200 response, and MUST NOT
generate 202 response codes to SUBSCRIBE or NOTIFY requests.
This document also updates [RFC4660], which reiterates the 202-based This document also updates [RFC4660], which reiterates the 202-based
behavior in several places. Implementations compliant with the behavior in several places. Implementations compliant with the
present document MUST NOT send a 202 response to a SUBSCRIBE request, present document MUST NOT send a 202 response to a SUBSCRIBE request,
and will send an alternate success response (such as 200) in its and will send an alternate success response (such as 200) in its
stead. stead.
8.3.2. "489 Bad Event" Response Code 8.3.2. "489 Bad Event" Response Code
The 489 event response is added to the "Client-Error" header field The 489 event response is added to the "Client-Error" header field
skipping to change at page 47, line 13 skipping to change at page 47, line 13
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
This section, and all of its subsections, will be consolidated into a This section, and all of its subsections, will be consolidated into a
single "Changes Since RFC 3265" section prior to publication. Bug single "Changes Since RFC 3265" section prior to publication. Bug
numbers refer to the identifiers for the bug reports kept on file at numbers refer to the identifiers for the bug reports kept on file at
http://bugs.sipit.net/. http://bugs.sipit.net/.
B.1. Changes from draft-ietf-sipcore-rfc3265bis-02 to 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 draft-ietf-sipcore-rfc3265bis-03
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.
o Several editorial updates after input from working group, o Several editorial updates after input from working group,
including proper designation of "dialog usage" rather than including proper designation of "dialog usage" rather than
"dialog" where appropriate. "dialog" where appropriate.
o Fixed left-over language that allowed implicit subscriptions (in o Fixed left-over language that allowed implicit subscriptions (in
contradiction to text elsewhere in the document) contradiction to text elsewhere in the document)
o Fixed subscriber state machine handling of Timer N o Fixed subscriber state machine handling of Timer N
o Clarified two normative statements about subscription termination o Clarified two normative statements about subscription termination
by changing from plain English prose to RFC2119 language. by changing from plain English prose to RFC2119 language.
B.2. Changes from draft-ietf-sipcore-rfc3265bis-01 to B.3. Changes from draft-ietf-sipcore-rfc3265bis-01 to
draft-ietf-sipcore-rfc3265bis-02 draft-ietf-sipcore-rfc3265bis-02
o Removed "Table 2" expansions, per WG consensus on how SIP table 2 o Removed "Table 2" expansions, per WG consensus on how SIP table 2
is to be handled. is to be handled.
o Removed 202 response code. o Removed 202 response code.
o Clarified that "Allow-Events" does not list event template o Clarified that "Allow-Events" does not list event template
packages. packages.
o Clarified that Timer N *does* apply to subscription refreshes. o Clarified that Timer N *does* apply to subscription refreshes.
B.3. Changes from draft-ietf-sipcore-rfc3265bis-00 to B.4. Changes from draft-ietf-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-01 draft-ietf-sipcore-rfc3265bis-01
o Renamed Timer L to Timer N, to avoid a naming conflict. o Renamed Timer L to Timer N, to avoid a naming conflict.
o Added clarification about proper response when the SUBSCRIBE o Added clarification about proper response when the SUBSCRIBE
indicates an unknown MIME type in its Accept header field. indicates an unknown MIME type in its Accept header field.
o Clarification around Route and Record-Route behavior. o Clarification around 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 "Call-Info" header field to RFC 3261 Table 2 expansion. o Added "Call-Info" header field to RFC 3261 Table 2 expansion.
B.4. Changes from draft-roach-sipcore-rfc3265bis-00 to B.5. Changes from draft-roach-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-00 draft-ietf-sipcore-rfc3265bis-00
None None
B.5. Changes since RFC 3265 B.6. Changes since RFC 3265
B.5.1. Bug 666: Clarify use of expires=xxx with terminated B.6.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.5.2. Bug 667: Reason code for unsub/poll not clearly spelled out B.6.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.5.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered B.6.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered
with a NOTIFY/expires=0 with 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.5.4. Bug 670: Dialog State Machine needs clarification B.6.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.5.5. Bug 671: Clarify timeout-based removal of subscriptions B.6.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.5.6. Bug 672: Mandate expires= in NOTIFY B.6.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.5.7. Bug 673: INVITE 481 response effect clarification B.6.7. Bug 673: INVITE 481 response effect clarification
This bug was addressed in [RFC5057]. This bug was addressed in [RFC5057].
B.5.8. Bug 677: SUBSCRIBE response matching text in error B.6.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.5.9. Bug 695: Document is not explicit about response to NOTIFY at B.6.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.5.10. Bug 696: Subscription state machine needs clarification B.6.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.5.11. Bug 697: Unsubscription behavior could be clarified B.6.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.5.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh requests B.6.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.5.13. Bug 722: Inconsistent 423 reason phrase text B.6.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.5.14. Bug 741: guidance needed on when to not include Allow-Events B.6.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.5.15. Bug 744: 5xx to NOTIFY terminates a subscription, but should B.6.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.5.16. Bug 752: Detection of forked requests is incorrect B.6.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.5.17. Bug 773: Reason code needs IANA registry B.6.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.5.18. Bug 774: Need new reason for terminating subscriptions to B.6.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.5.19. Clarify handling of Route/Record-Route in NOTIFY B.6.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.5.20. Eliminate implicit subscriptions B.6.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.5.21. Deprecate dialog re-use B.6.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.5.22. Rationalize dialog creation B.6.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.5.23. Refactor behavior sections B.6.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.5.24. Clarify sections that need to be present in event packages B.6.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.5.25. Make CANCEL handling more explicit B.6.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.5.26. Remove State Agent Terminology B.6.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
 End of changes. 51 change blocks. 
73 lines changed or deleted 91 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/