draft-ietf-sipcore-rfc3265bis-00.txt   draft-ietf-sipcore-rfc3265bis-01.txt 
Network Working Group A. B. Roach Network Working Group A. B. Roach
Internet-Draft Tekelec Internet-Draft Tekelec
Expires: January 28, 2010 July 27, 2009 Expires: August 23, 2010 February 19, 2010
SIP-Specific Event Notification SIP-Specific Event Notification
draft-ietf-sipcore-rfc3265bis-00 draft-ietf-sipcore-rfc3265bis-01
Abstract
This document describes an extension to the Session Initiation
Protocol (SIP). The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred.
Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 28, 2010. This Internet-Draft will expire on August 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes an extension to the Session Initiation described in the BSD License.
Protocol (SIP). The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred.
Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Overview of Operation . . . . . . . . . . . . . . . . . . 5 1.1. Overview of Operation . . . . . . . . . . . . . . . . . . 5
1.2. Documentation Conventions . . . . . . . . . . . . . . . . 6 1.2. Documentation Conventions . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. SIP Methods for Event Notification . . . . . . . . . . . . . . 7 3. SIP Methods for Event Notification . . . . . . . . . . . . . . 7
3.1. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Subscription Duration . . . . . . . . . . . . . . . . 7 3.1.1. Subscription Duration . . . . . . . . . . . . . . . . 7
3.1.2. Identification of Subscribed Events and Event 3.1.2. Identification of Subscribed Events and Event
Classes . . . . . . . . . . . . . . . . . . . . . . . 8 Classes . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Additional SUBSCRIBE Header Values . . . . . . . . . . 9 3.1.3. Additional SUBSCRIBE Header Field Values . . . . . . . 9
3.2. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Identification of Reported Events, Event Classes, 3.2.1. Identification of Reported Events, Event Classes,
and Current State . . . . . . . . . . . . . . . . . . 9 and Current State . . . . . . . . . . . . . . . . . . 9
4. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10
4.1.1. Detecting Support for SIP Events . . . . . . . . . . . 10 4.1.1. Detecting Support for SIP Events . . . . . . . . . . . 10
4.1.2. Creating and Maintaining Subscriptions . . . . . . . . 10 4.1.2. Creating and Maintaining Subscriptions . . . . . . . . 10
4.1.3. Receiving and Processing State Information . . . . . . 13 4.1.3. Receiving and Processing State Information . . . . . . 13
4.1.4. Forking of SUBSCRIBE Messages . . . . . . . . . . . . 16 4.1.4. Forking of SUBSCRIBE Messages . . . . . . . . . . . . 16
4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 16 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Subscription Establishment and Maintenance . . . . . . 16 4.2.1. Subscription Establishment and Maintenance . . . . . . 16
4.2.2. Sending State Information to Subscribers . . . . . . . 20 4.2.2. Sending State Information to Subscribers . . . . . . . 20
4.2.3. PINT Compatibility . . . . . . . . . . . . . . . . . . 22 4.2.3. PINT Compatibility . . . . . . . . . . . . . . . . . . 22
4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 22
4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 23 4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Dialog Creation and Termination . . . . . . . . . . . 23 4.4.1. Dialog Creation and Termination . . . . . . . . . . . 23
4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 23 4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 23
4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 24 4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 24
4.4.4. Allow-Events header field usage . . . . . . . . . . . 24 4.4.4. Allow-Events header field usage . . . . . . . . . . . 25
4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 25 4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 25
4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 25 4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 26
4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 26 4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 26
4.6. CANCEL Requests for SUBSCRIBE and NOTIFY . . . . . . . . . 27 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY . . . . . . . . . 28
5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 28 5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 28
5.2. Event Template-packages . . . . . . . . . . . . . . . . . 28 5.2. Event Template-packages . . . . . . . . . . . . . . . . . 29
5.3. Amount of State to be Conveyed . . . . . . . . . . . . . . 29 5.3. Amount of State to be Conveyed . . . . . . . . . . . . . . 29
5.3.1. Complete State Information . . . . . . . . . . . . . . 29 5.3.1. Complete State Information . . . . . . . . . . . . . . 30
5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 29 5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 30
5.4. Event Package Responsibilities . . . . . . . . . . . . . . 30 5.4. Event Package Responsibilities . . . . . . . . . . . . . . 30
5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 30 5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 31
5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 30 5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 31
5.4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 30 5.4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 31
5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 31 5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 31
5.4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 31 5.4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 31
5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 31 5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 32
5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 31 5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 32
5.4.8. Subscriber processing of NOTIFY requests . . . . . . . 32 5.4.8. Subscriber processing of NOTIFY requests . . . . . . . 32
5.4.9. Handling of forked requests . . . . . . . . . . . . . 32 5.4.9. Handling of forked requests . . . . . . . . . . . . . 32
5.4.10. Rate of notifications . . . . . . . . . . . . . . . . 32 5.4.10. Rate of notifications . . . . . . . . . . . . . . . . 33
5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 33 5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 33
5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 33 5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 33 5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 33 6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 34
6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 34 6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 34
6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 34 6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 35
6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 34 6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 35
6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 35 6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 35
6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 35 6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 36 7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 36
7.1.1. Registration Information . . . . . . . . . . . . . . . 36 7.1.1. Registration Information . . . . . . . . . . . . . . . 37
7.1.2. Registration Template . . . . . . . . . . . . . . . . 37 7.1.2. Registration Template . . . . . . . . . . . . . . . . 38
7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 37 7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 38
7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 38 7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 39
7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 39 7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 39
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 40
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 . . . . . . . . . . . . . . . . . . . . 41 8.2. New Header Fields . . . . . . . . . . . . . . . . . . . . 42
8.2.1. "Event" Header Field . . . . . . . . . . . . . . . . . 41 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 . . . . . . . . . . 43
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 . . . . . . . . . . . . 42 8.3.2. "489 Bad Event" Response Code . . . . . . . . . . . . 43
8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 43
8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 42 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . . 43 9.2. Informative References . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . . 44 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 45 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 46
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 45 B.1. Bug 711: Allow-Events can't express template support . . . 47
B.1. Bug 711: Allow-Events can't express template support . . . 45 B.2. Remove 202 Response Code? . . . . . . . . . . . . . . . . 47
B.2. Remove 202 Response Code? . . . . . . . . . . . . . . . . 46 B.3. Timer N and Resubscribes . . . . . . . . . . . . . . . . . 47
B.3. Timer L and Resubscribes . . . . . . . . . . . . . . . . . 46 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 48
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 46 C.1. Changes from draft-ietf-sipcore-rfc3265bis-00 to
C.1. Changes since RFC 3265 . . . . . . . . . . . . . . . . . . 46 draft-ietf-sipcore-rfc3265bis-01 . . . . . . . . . . . . . 48
C.1.1. Bug 666: Clarify use of expires=xxx with terminated . 46 C.2. Changes from draft-roach-sipcore-rfc3265bis-00 to
C.1.2. Bug 667: Reason code for unsub/poll not clearly draft-ietf-sipcore-rfc3265bis-00 . . . . . . . . . . . . . 48
spelled out . . . . . . . . . . . . . . . . . . . . . 46 C.3. Changes since RFC 3265 . . . . . . . . . . . . . . . . . . 48
C.1.3. Bug 669: Clarify: SUBSCRIBE for a duration might C.3.1. Bug 666: Clarify use of expires=xxx with terminated . 48
be answered with a NOTIFY/expires=0 . . . . . . . . . 47 C.3.2. Bug 667: Reason code for unsub/poll not clearly
C.1.4. Bug 670: Dialog State Machine needs clarification . . 47 spelled out . . . . . . . . . . . . . . . . . . . . . 48
C.1.5. Bug 671: Clarify timeout-based removal of C.3.3. Bug 669: Clarify: SUBSCRIBE for a duration might
subscriptions . . . . . . . . . . . . . . . . . . . . 47 be answered with a NOTIFY/expires=0 . . . . . . . . . 48
C.1.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . 47 C.3.4. Bug 670: Dialog State Machine needs clarification . . 48
C.1.7. Bug 673: INVITE 481 response effect clarification . . 47 C.3.5. Bug 671: Clarify timeout-based removal of
C.1.8. Bug 677: SUBSCRIBE response matching text in error . . 47 subscriptions . . . . . . . . . . . . . . . . . . . . 49
C.1.9. Bug 695: Document is not explicit about response C.3.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . 49
to NOTIFY at subscription termination . . . . . . . . 47 C.3.7. Bug 673: INVITE 481 response effect clarification . . 49
C.1.10. Bug 696: Subscription state machine needs C.3.8. Bug 677: SUBSCRIBE response matching text in error . . 49
clarification . . . . . . . . . . . . . . . . . . . . 47 C.3.9. Bug 695: Document is not explicit about response
C.1.11. Bug 697: Unsubscription behavior could be clarified . 48 to NOTIFY at subscription termination . . . . . . . . 49
C.1.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh C.3.10. Bug 696: Subscription state machine needs
requests . . . . . . . . . . . . . . . . . . . . . . . 48 clarification . . . . . . . . . . . . . . . . . . . . 49
C.1.13. Bug 722: Inconsistent 423 reason phrase text . . . . . 48 C.3.11. Bug 697: Unsubscription behavior could be clarified . 49
C.1.14. Bug 741: guidance needed on when to not include C.3.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh
Allow-Events . . . . . . . . . . . . . . . . . . . . . 48 requests . . . . . . . . . . . . . . . . . . . . . . . 49
C.1.15. Bug 744: 5xx to NOTIFY terminates a subscription, C.3.13. Bug 722: Inconsistent 423 reason phrase text . . . . . 50
but should not . . . . . . . . . . . . . . . . . . . . 48 C.3.14. Bug 741: guidance needed on when to not include
C.1.16. Bug 752: Detection of forked requests is incorrect . . 48 Allow-Events . . . . . . . . . . . . . . . . . . . . . 50
C.1.17. Bug 773: Reason code needs IANA registry . . . . . . . 48 C.3.15. Bug 744: 5xx to NOTIFY terminates a subscription,
C.1.18. Bug 774: Need new reason for terminating but should not . . . . . . . . . . . . . . . . . . . . 50
subscriptions to resources that never change . . . . . 48 C.3.16. Bug 752: Detection of forked requests is incorrect . . 50
C.1.19. Clarify handling of Route/Record-Route in NOTIFY . . . 49 C.3.17. Bug 773: Reason code needs IANA registry . . . . . . . 50
C.1.20. Eliminate implicit subscriptions . . . . . . . . . . . 49 C.3.18. Bug 774: Need new reason for terminating
C.1.21. Deprecate dialog re-use . . . . . . . . . . . . . . . 49 subscriptions to resources that never change . . . . . 50
C.1.22. Rationalize dialog creation . . . . . . . . . . . . . 49 C.3.19. Clarify handling of Route/Record-Route in NOTIFY . . . 50
C.1.23. Refactor behavior sections . . . . . . . . . . . . . . 49 C.3.20. Eliminate implicit subscriptions . . . . . . . . . . . 50
C.1.24. Clarify sections that need to be present in event C.3.21. Deprecate dialog re-use . . . . . . . . . . . . . . . 51
packages . . . . . . . . . . . . . . . . . . . . . . . 49 C.3.22. Rationalize dialog creation . . . . . . . . . . . . . 51
C.1.25. Make CANCEL handling more explicit . . . . . . . . . . 49 C.3.23. Refactor behavior sections . . . . . . . . . . . . . . 51
C.1.26. Remove State Agent Terminology . . . . . . . . . . . . 50 C.3.24. Clarify sections that need to be present in event
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 packages . . . . . . . . . . . . . . . . . . . . . . . 51
C.3.25. Make CANCEL handling more explicit . . . . . . . . . . 51
C.3.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 9, line 5 skipping to change at page 9, line 5
correspond to an event package which further describes the semantics correspond to an event package which further describes the semantics
of the event or event class. of the event or event class.
If the event package to which the event token corresponds defines If the event package to which the event token corresponds defines
behavior associated with the body of its SUBSCRIBE requests, those behavior associated with the body of its SUBSCRIBE requests, those
semantics apply. semantics apply.
Event packages may also define parameters for the Event header field; Event packages may also define parameters for the Event header field;
if they do so, they must define the semantics for such parameters. if they do so, they must define the semantics for such parameters.
3.1.3. Additional SUBSCRIBE Header Values 3.1.3. Additional SUBSCRIBE Header Field Values
Because SUBSCRIBE requests create a dialog as defined in SIP Because SUBSCRIBE requests create a dialog as defined in SIP
[RFC3261], they MAY contain an "Accept" header field. This header [RFC3261], they MAY contain an "Accept" header field. This header
field, if present, indicates the body formats allowed in subsequent field, if present, indicates the body formats allowed in subsequent
NOTIFY requests. Event packages MUST define the behavior for NOTIFY requests. Event packages MUST define the behavior for
SUBSCRIBE requests without "Accept" header fields; usually, this will SUBSCRIBE requests without "Accept" header fields; usually, this will
connote a single, default body type. connote a single, default body type.
Header values not described in this document are to be interpreted as Header values not described in this document are to be interpreted as
described in SIP [RFC3261]. described in SIP [RFC3261].
skipping to change at page 11, line 11 skipping to change at page 11, line 11
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:
+-------------+ +-------------+
| init |<-----------------------+ | init |<-----------------------+
+-------------+ | +-------------+ |
| Retry-after | Retry-after
Send SUBSCRIBE expires Send SUBSCRIBE expires
| | | |
V Timer L Fires; | V Timer N Fires; |
+-------------+ SUBSCRIBE failure | +-------------+ SUBSCRIBE failure |
+------------| notify_wait |-- response; --------+ | +------------| notify_wait |-- response; --------+ |
| +-------------+ or NOTIFY, | | | +-------------+ or NOTIFY, | |
| | state=terminated | | | | state=terminated | |
| | | | | | | |
++========|===================|============================|==|====++ ++========|===================|============================|==|====++
|| | | V | || || | | V | ||
|| Receive NOTIFY, Receive NOTIFY, +-------------+ || || Receive NOTIFY, Receive NOTIFY, +-------------+ ||
|| state=active state=pending | terminated | || || state=active state=pending | terminated | ||
|| | | +-------------+ || || | | +-------------+ ||
skipping to change at page 12, line 22 skipping to change at page 12, line 22
authorization may or may not have been granted. authorization may or may not have been granted.
The "Expires" header field in a 200-class response to SUBSCRIBE The "Expires" header field in a 200-class response to SUBSCRIBE
indicates the actual duration for which the subscription will remain indicates the actual duration for which the subscription will remain
active (unless refreshed). active (unless refreshed).
Non-200 class final responses indicate that no subscription or dialog Non-200 class final responses indicate that no subscription or dialog
has been created, and no subsequent NOTIFY message will be sent. All has been created, and no subsequent NOTIFY message will be sent. All
non-200 class responses (with the exception of "489", described non-200 class responses (with the exception of "489", described
herein) have the same meanings and handling as described in SIP herein) have the same meanings and handling as described in SIP
[RFC3261]. [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains
an "Accept" header field, but that field does not indicate a MIME
type that the notifier is capable of generating in its NOTIFY
requests, then the proper error response is 406 (Not Acceptable).
4.1.2.2. Refreshing of Subscriptions 4.1.2.2. Refreshing of Subscriptions
At any time before a subscription expires, the subscriber may refresh At any time before a subscription expires, the subscriber may refresh
the timer on such a subscription by sending another SUBSCRIBE request the timer on such a subscription by sending another SUBSCRIBE request
on the same dialog as the existing subscription. The handling for on the same dialog as the existing subscription. The handling for
such a request is the same as for the initial creation of a such a request is the same as for the initial creation of a
subscription except as described below. subscription except as described below.
If a SUBSCRIBE request to refresh a subscription receives a 404, 405, If a SUBSCRIBE request to refresh a subscription receives a 404, 405,
skipping to change at page 13, line 24 skipping to change at page 13, line 24
The final NOTIFY may or may not contain information about the state The final NOTIFY may or may not contain information about the state
of the resource; subscribers need to be prepared to receive final of the resource; subscribers need to be prepared to receive final
NOTIFY messages both with and without state. NOTIFY messages both with and without state.
4.1.2.4. Confirmation of Subscription Creation 4.1.2.4. Confirmation of Subscription Creation
The subscriber can expect to receive a NOTIFY message from each node The subscriber can expect to receive a NOTIFY message from each node
which has processed a successful subscription or subscription which has processed a successful subscription or subscription
refresh. To ensure that subscribers do not wait indefinitely for a refresh. To ensure that subscribers do not wait indefinitely for a
subscription to be established, a subscriber starts a Timer L, set to subscription to be established, a subscriber starts a Timer N, set to
64*T1. If this Timer L expires prior to the receipt of a NOTIFY 64*T1. If this Timer N expires prior to the receipt of a NOTIFY
message, the subscriber considers the subscription failed, and cleans message, the subscriber considers the subscription failed, and cleans
up any state associated with the subscription attempt. up any state associated with the subscription attempt.
Until Timer L expires, several NOTIFY messages may arrive from Until Timer N expires, several NOTIFY messages may arrive from
different destinations (see Section 4.4.1). Each of these messages different destinations (see Section 4.4.1). Each of these messages
establish a new dialog and a new subscription. After the expiration establish a new dialog and a new subscription. After the expiration
of Timer L, the subscriber SHOULD reject any such NOTIFY messages of Timer N, the subscriber SHOULD reject any such NOTIFY messages
that would otherwise establish a new dialog with a "481" response that would otherwise establish a new dialog with a "481" response
code. code.
Until the first NOTIFY message arrives, the subscriber should Until the first NOTIFY message 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. Documents which define new event packages MUST define this state. Documents which define new event packages MUST define this
"neutral state" in such a way that makes sense for their application "neutral state" in such a way that makes sense for their application
(see Section 5.4.7). (see Section 5.4.7).
Due to the potential for both out-of-order messages and forking, the Due to the potential for both out-of-order messages and forking, the
skipping to change at page 23, line 5 skipping to change at page 22, line 49
4.3. Proxy Behavior 4.3. Proxy Behavior
Proxies need no additional behavior beyond that described in SIP Proxies need no additional behavior beyond that described in SIP
[RFC3261] to support SUBSCRIBE and NOTIFY. If a proxy wishes to see [RFC3261] to support SUBSCRIBE and NOTIFY. If a proxy wishes to see
all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST
add a Record-Route header field to the initial SUBSCRIBE request and add a Record-Route header field to the initial SUBSCRIBE request and
all NOTIFY requests. It MAY choose to include Record-Route in all NOTIFY requests. It MAY choose to include Record-Route in
subsequent SUBSCRIBE messages; however, these requests cannot cause subsequent SUBSCRIBE messages; however, these requests cannot cause
the dialog's route set to be modified. the dialog's route set to be modified.
Proxies that did not add a Record-Route header field to the initial
SUBSCRIBE request MUST NOT add a Record-Route header field to any of
the associated NOTIFY requests.
Note that subscribers and notifiers may elect to use S/MIME Note that subscribers and notifiers may elect to use S/MIME
encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies
cannot rely on being able to access any information that is not cannot rely on being able to access any information that is not
explicitly required to be proxy-readable by SIP [RFC3261]. explicitly required to be proxy-readable by SIP [RFC3261].
4.4. Common Behavior 4.4. Common Behavior
4.4.1. Dialog Creation and Termination 4.4.1. Dialog Creation and Termination
Dialogs are created upon completion of a NOTIFY transaction for a new Dialogs are created upon completion of a NOTIFY transaction for a new
subscription, unless the NOTIFY contains a "Subscription-State" of subscription, unless the NOTIFY contains a "Subscription-State" of
"terminated." "terminated."
Because the dialog is established by the NOTIFY request, the route
set at the subscriber is taken from the NOTIFY request itself, as
opposed to the route set present in the 200-class response to the
SUBSCRIBE request.
NOTIFY requests are matched to such SUBSCRIBE requests if they NOTIFY requests are matched to such SUBSCRIBE requests if they
contain the same "Call-ID", a "To" header field "tag" parameter which contain the same "Call-ID", a "To" header field "tag" parameter which
matches the "From" header field "tag" parameter of the SUBSCRIBE, and matches the "From" header field "tag" parameter of the SUBSCRIBE, and
the same "Event" header field. Rules for comparisons of the "Event" the same "Event" header field. Rules for comparisons of the "Event"
header fields are described in Section 8.2.1. header fields are described in Section 8.2.1.
A subscription is destroyed after a notifier sends a NOTIFY request A subscription is destroyed after a notifier sends a NOTIFY request
with a "Subscription-State" of "terminated." The subscriber will with a "Subscription-State" of "terminated." The subscriber will
generally answer such final requests with a "200 OK" response (unless generally answer such final requests with a "200 OK" response (unless
a condition warranting an alternate response has arisen). Except a condition warranting an alternate response has arisen). Except
skipping to change at page 24, line 44 skipping to change at page 25, line 5
Polling of event state can cause significant increases in load on the Polling of event state can cause significant increases in load on the
network and notifiers; as such, it should be used only sparingly. In network and notifiers; as such, it should be used only sparingly. In
particular, polling SHOULD NOT be used in circumstances in which it particular, polling SHOULD NOT be used in circumstances in which it
will typically result in more network messages than long-running will typically result in more network messages than long-running
subscriptions. subscriptions.
When polling is used, subscribers SHOULD attempt to cache When polling is used, subscribers SHOULD attempt to cache
authentication credentials between polls so as to reduce the number authentication credentials between polls so as to reduce the number
of messages sent. of messages sent.
Due to the requirement on notifiers to send a NOTIFY immediately
upon receipt of a SUBSCRIBE request, the state provided by polling
is limited to the information that the notifier has immediate
local access to when it receives the SUBSCRIBE. If, for example,
the notifier generally needs to retrieve state from another
network server, then that state will be absent from the NOTIFY
that results from polling.
4.4.4. Allow-Events header field usage 4.4.4. Allow-Events header field usage
The "Allow-Events" header field, if present, includes a list of The "Allow-Events" header field, if present, includes a list of
tokens which indicates the event packages supported by a notifier. tokens which indicates the event packages supported by a notifier.
In other words, a user agent sending an "Allow-Events" header field In other words, a user agent sending an "Allow-Events" header field
is advertising that it can process SUBSCRIBE requests and generate is advertising that it can process SUBSCRIBE requests and generate
NOTIFY requests for all of the event packages listed in that header NOTIFY requests for all of the event packages listed in that header
field. field.
Any user agent that can act as a notifier for one or more event Any user agent that can act as a notifier for one or more event
skipping to change at page 25, line 38 skipping to change at page 26, line 6
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
described in [I-D.ietf-sip-gruu] now provides a far more elegant and described in [I-D.ietf-sip-gruu] now provides a far more elegant and
unambiguous means to achieve the same goal. unambiguous means to achieve the same goal.
Consequently, the dialog re-use technique described in RFC 3265 is Consequently, the dialog re-use technique described in RFC 3265 is
now deprecated. now deprecated.
This dialog-sharing technique has also historically been used as a
means for targeting an event package at a dialog. This usage can be
seen, for example, in certain applications of the REFER method
[RFC3515]. With the removal of dialog re-use, an alternate (and more
explicit) means of targeting dialogs needs to be used for this type
of correlation. The appropriate means of such targeting is left up
to the actual event packages. Candidates include the "Target-Dialog"
header field [RFC4528], the "Join" header field [RFC3911], and the
"Replaces" header field [RFC3891], depending on the semantics
desired. Alternately, if the semantics of those header fields do not
match the event package's purpose for correlation, event packages can
devise their own means of identifying dialogs. For an example of
this approach, see the Dialog Event Package [RFC4235].
4.5.1. Using GRUUs to Route to Devices 4.5.1. Using GRUUs to Route to Devices
Notifiers MUST implement the GRUU extension defined in Notifiers MUST implement the GRUU extension defined in
[I-D.ietf-sip-gruu], and MUST use a GRUU as their local target. This [I-D.ietf-sip-gruu], and MUST use a GRUU as their local target. This
allows subscribers to explicitly target desired devices. allows subscribers to explicitly target desired devices.
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, it should check whether the remote contact as an established dialog, it should check whether the remote contact
in that dialog is a GRUU (i.e., whether it contains a "gr" URI in that dialog is a GRUU (i.e., whether it contains a "gr" URI
parameter). If so, the subscriber creates a new dialog, using the parameter). If so, the subscriber creates a new dialog, using the
skipping to change at page 40, line 6 skipping to change at page 40, line 39
Accept-Language 415 o o Accept-Language 415 o o
Alert-Info R - - Alert-Info R - -
Alert-Info 180 - - Alert-Info 180 - -
Allow R o o Allow R o o
Allow 2xx o o Allow 2xx o o
Allow r o o Allow r o o
Allow 405 m m Allow 405 m m
Authentication-Info 2xx o o Authentication-Info 2xx o o
Authorization R o o Authorization R o o
Call-ID c m m Call-ID c m m
Call-Info R o o
Contact R m m Contact R m m
Contact 1xx o o Contact 1xx o o
Contact 2xx m o Contact 2xx m o
Contact 3xx m m Contact 3xx m m
Contact 485 o o Contact 485 o o
Content-Disposition o o Content-Disposition o o
Content-Encoding o o Content-Encoding o o
Content-Language o o Content-Language o o
Content-Length t t Content-Length t t
Content-Type * * Content-Type * *
skipping to change at page 44, line 45 skipping to change at page 45, line 45
9.2. Informative References 9.2. Informative References
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)", of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006. RFC 4485, May 2006.
[RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Assertion Control", RFC 4528, June 2006.
[RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification Requena, "Functional Description of Event Notification
Filtering", RFC 4660, September 2006. Filtering", RFC 4660, September 2006.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007. Initiation Protocol", RFC 5057, November 2007.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks to the participants in the Events BOF at the 48th IETF meeting Thanks to the participants in the Events BOF at the 48th IETF meeting
skipping to change at page 46, line 19 skipping to change at page 47, line 36
B.2. Remove 202 Response Code? B.2. Remove 202 Response Code?
In practice, the 202 response code defined in RFC 3265 has proven to In practice, the 202 response code defined in RFC 3265 has proven to
be nearly useless, due to its redundancy with the "pending" state, be nearly useless, due to its redundancy with the "pending" state,
and its interaction with the HERFP problem. Given that 202 must be and its interaction with the HERFP problem. Given that 202 must be
treated as 200 if an implementation does not understand it: would treated as 200 if an implementation does not understand it: would
removing the 202 response code cause any issues for current removing the 202 response code cause any issues for current
implementations? implementations?
B.3. Timer L and Resubscribes B.3. Timer N and Resubscribes
Section 4.1.2.4 defines a new Timer L that is used upon initial Section 4.1.2.4 defines a new Timer N that is used upon initial
subscription to bound the amount of time that a subscriber needs to subscription to bound the amount of time that a subscriber needs to
wait for a NOTIFY. Should this also apply to resubscribes? On one wait for a NOTIFY. Should this also apply to resubscribes? On one
hand, the mechanism is not as necessary, since the subscriber already hand, the mechanism is not as necessary, since the subscriber already
has a negotiated expiration time associated with the subscription. has a negotiated expiration time associated with the subscription.
On the other hand, if no NOTIFY arrives in 64*T1, it is highly likely On the other hand, if no NOTIFY arrives in 64*T1, it is highly likely
that the notifier has gone off the rails, which means that the that the notifier has gone off the rails, which means that the
subscriber can safely clean up state associated with that subscriber can safely clean up state associated with that
subscription. The key question involved in applying Timer L to subscription. The key question involved in applying Timer N to
resubscriptions is whether doing so makes subscriptions unnecessarily resubscriptions is whether doing so makes subscriptions unnecessarily
brittle. brittle.
Appendix C. Changes Appendix C. 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/.
C.1. Changes since RFC 3265 C.1. Changes from draft-ietf-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-01
C.1.1. Bug 666: Clarify use of expires=xxx with terminated o Renamed Timer L to Timer N, to avoid a naming conflict.
o Added clarification about proper response when the SUBSCRIBE
indicates an unkonwn 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.
C.2. Changes from draft-roach-sipcore-rfc3265bis-00 to
draft-ietf-sipcore-rfc3265bis-00
None
C.3. Changes since RFC 3265
C.3.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.
C.1.2. Bug 667: Reason code for unsub/poll not clearly spelled out C.3.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).
C.1.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered C.3.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.
C.1.4. Bug 670: Dialog State Machine needs clarification C.3.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.
C.1.5. Bug 671: Clarify timeout-based removal of subscriptions C.3.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).
C.1.6. Bug 672: Mandate expires= in NOTIFY C.3.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.
C.1.7. Bug 673: INVITE 481 response effect clarification C.3.7. Bug 673: INVITE 481 response effect clarification
This bug was addressed in [RFC5057]. This bug was addressed in [RFC5057].
C.1.8. Bug 677: SUBSCRIBE response matching text in error C.3.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.
C.1.9. Bug 695: Document is not explicit about response to NOTIFY at C.3.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".
C.1.10. Bug 696: Subscription state machine needs clarification C.3.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 L 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.
C.1.11. Bug 697: Unsubscription behavior could be clarified C.3.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 message. Also added text to Section 4.1.2.3 state in final NOTIFY message. 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.
C.1.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh requests C.3.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.
C.1.13. Bug 722: Inconsistent 423 reason phrase text C.3.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].
C.1.14. Bug 741: guidance needed on when to not include Allow-Events C.3.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.
C.1.15. Bug 744: 5xx to NOTIFY terminates a subscription, but should C.3.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.
C.1.16. Bug 752: Detection of forked requests is incorrect C.3.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.
C.1.17. Bug 773: Reason code needs IANA registry C.3.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.
C.1.18. Bug 774: Need new reason for terminating subscriptions to C.3.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.
C.1.19. Clarify handling of Route/Record-Route in NOTIFY C.3.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 messages, and adding "MAY" level statements SUBSCRIBE and all NOTIFY messages, and adding "MAY" level statements
for subsequent SUBSCRIBE messages. for subsequent SUBSCRIBE messages.
C.1.20. Eliminate implicit subscriptions C.3.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.
C.1.21. Deprecate dialog re-use C.3.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.
C.1.22. Rationalize dialog creation C.3.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).
C.1.23. Refactor behavior sections C.3.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.
C.1.24. Clarify sections that need to be present in event packages C.3.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.
C.1.25. Make CANCEL handling more explicit C.3.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].
C.1.26. Remove State Agent Terminology C.3.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. 67 change blocks. 
150 lines changed or deleted 214 lines changed or added

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