draft-ietf-sipcore-rfc3265bis-07.txt   draft-ietf-sipcore-rfc3265bis-08.txt 
Network Working Group A. B. Roach Network Working Group A. B. Roach
Internet-Draft Tekelec Internet-Draft Tekelec
Obsoletes: 3265 (if approved) February 27, 2012 Obsoletes: 3265 (if approved) April 11, 2012
Updates: 4660 (if approved) Updates: 4660 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 30, 2012 Expires: October 13, 2012
SIP-Specific Event Notification SIP-Specific Event Notification
draft-ietf-sipcore-rfc3265bis-07 draft-ietf-sipcore-rfc3265bis-08
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 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2012. This Internet-Draft will expire on October 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 22 skipping to change at page 3, line 22
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 . . . . . . . . . . . . . . . 33 5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 33
5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33 5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33
5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 33 5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36 6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36
6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 36 6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 38 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Registration Information . . . . . . . . . . . . . . . 38 7.1.1. Registration Information . . . . . . . . . . . . . . . 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 . . . . . . . . . . 43
8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43 8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43
8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 43 8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 43
8.3.2. "489 Bad Event" Response Code . . . . . . . . . . . . 43 8.3.2. "489 Bad Event" Response Code . . . . . . . . . . . . 43
8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 43 8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . . 45 9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46
Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 47 Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 47
B.1. Bug 666: Clarify use of expires=xxx with terminated . . . 47 B.1. Bug 666: Clarify use of expires=xxx with terminated . . . 47
B.2. Bug 667: Reason code for unsub/poll not clearly B.2. Bug 667: Reason code for unsub/poll not clearly
spelled out . . . . . . . . . . . . . . . . . . . . . . . 47 spelled out . . . . . . . . . . . . . . . . . . . . . . . 47
B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be
answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 47 answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 47
B.4. Bug 670: Dialog State Machine needs clarification . . . . 47 B.4. Bug 670: Dialog State Machine needs clarification . . . . 47
B.5. Bug 671: Clarify timeout-based removal of subscriptions . 47 B.5. Bug 671: Clarify timeout-based removal of subscriptions . 48
B.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . . . 47 B.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . . . 48
B.7. Bug 673: INVITE 481 response effect clarification . . . . 48 B.7. Bug 673: INVITE 481 response effect clarification . . . . 48
B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 48 B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 48
B.9. Bug 695: Document is not explicit about response to B.9. Bug 695: Document is not explicit about response to
NOTIFY at subscription termination . . . . . . . . . . . . 48 NOTIFY at subscription termination . . . . . . . . . . . . 48
B.10. Bug 696: Subscription state machine needs clarification . 48 B.10. Bug 696: Subscription state machine needs clarification . 48
B.11. Bug 697: Unsubscription behavior could be clarified . . . 48 B.11. Bug 697: Unsubscription behavior could be clarified . . . 48
B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh
requests . . . . . . . . . . . . . . . . . . . . . . . . . 48 requests . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 48 B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 48
B.14. Bug 741: guidance needed on when to not include B.14. Bug 741: guidance needed on when to not include
Allow-Events . . . . . . . . . . . . . . . . . . . . . . . 48 Allow-Events . . . . . . . . . . . . . . . . . . . . . . . 49
B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but
should not . . . . . . . . . . . . . . . . . . . . . . . . 49 should not . . . . . . . . . . . . . . . . . . . . . . . . 49
B.16. Bug 752: Detection of forked requests is incorrect . . . . 49 B.16. Bug 752: Detection of forked requests is incorrect . . . . 49
B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 49 B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 49
B.18. Bug 774: Need new reason for terminating subscriptions B.18. Bug 774: Need new reason for terminating subscriptions
to resources that never change . . . . . . . . . . . . . . 49 to resources that never change . . . . . . . . . . . . . . 49
B.19. Clarify handling of Route/Record-Route in NOTIFY . . . . . 49 B.19. Clarify handling of Route/Record-Route in NOTIFY . . . . . 49
B.20. Eliminate implicit subscriptions . . . . . . . . . . . . . 49 B.20. Eliminate implicit subscriptions . . . . . . . . . . . . . 49
B.21. Deprecate dialog re-use . . . . . . . . . . . . . . . . . 49 B.21. Deprecate dialog re-use . . . . . . . . . . . . . . . . . 49
B.22. Rationalize dialog creation . . . . . . . . . . . . . . . 49 B.22. Rationalize dialog creation . . . . . . . . . . . . . . . 50
B.23. Refactor behavior sections . . . . . . . . . . . . . . . . 50 B.23. Refactor behavior sections . . . . . . . . . . . . . . . . 50
B.24. Clarify sections that need to be present in event B.24. Clarify sections that need to be present in event
packages . . . . . . . . . . . . . . . . . . . . . . . . . 50 packages . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.25. Make CANCEL handling more explicit . . . . . . . . . . . . 50 B.25. Make CANCEL handling more explicit . . . . . . . . . . . . 50
B.26. Remove State Agent Terminology . . . . . . . . . . . . . . 50 B.26. Remove State Agent Terminology . . . . . . . . . . . . . . 50
B.27. Miscellanous Changes . . . . . . . . . . . . . . . . . . . 51 B.27. Miscellanous Changes . . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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 10, line 8 skipping to change at page 10, line 8
the "Event" header field in the corresponding SUBSCRIBE request. the "Event" header field in the corresponding SUBSCRIBE request.
Event packages may define semantics associated with the body of their Event packages may define semantics associated with the body of their
NOTIFY requests; if they do so, those semantics apply. NOTIFY NOTIFY requests; if they do so, those semantics apply. NOTIFY
request bodies are expected to provide additional details about the request bodies are expected to provide additional details about the
nature of the event which has occurred and the resultant resource nature of the event which has occurred and the resultant resource
state. state.
When present, the body of the NOTIFY request MUST be formatted into When present, the body of the NOTIFY request MUST be formatted into
one of the body formats specified in the "Accept" header field of the one of the body formats specified in the "Accept" header field of the
corresponding SUBSCRIBE request. This body will contain either the corresponding SUBSCRIBE request (or the default type according to the
state of the subscribed resource or a pointer to such state in the event package description, if no Accept header field was specified).
form of a URI (see Section 5.4.13). This body will contain either the state of the subscribed resource or
a pointer to such state in the form of a URI (see Section 5.4.13).
4. Node Behavior 4. Node Behavior
4.1. Subscriber Behavior 4.1. Subscriber Behavior
4.1.1. Detecting Support for SIP Events 4.1.1. Detecting Support for SIP Events
The extension described in this document does not make use of the use The extension described in this document does not make use of the
of "Require" or "Proxy-Require" header fields; similarly, there is no "Require" or "Proxy-Require" header fields; similarly, there is no
token defined for "Supported" header fields. Potential subscribers token defined for "Supported" header fields. Potential subscribers
may probe for the support of SIP Events using the OPTIONS request may probe for the support of SIP Events using the OPTIONS request
defined in [RFC3261]. defined in [RFC3261].
The presence of "SUBSCRIBE" in the "Allow" header field of any The presence of "SUBSCRIBE" in the "Allow" header field of any
request or response indicates support for SIP Events; further, in the request or response indicates support for SIP Events; further, in the
absence of an "Allow" header field, the simple presence of an "Allow- absence of an "Allow" header field, the simple presence of an "Allow-
Events" header field is sufficient to indicate that the node that Events" header field is sufficient to indicate that the node that
sent the message is capable of acting as a notifier (see sent the message is capable of acting as a notifier (see
Section 4.4.4). Section 4.4.4).
skipping to change at page 12, line 28 skipping to change at page 12, line 28
The "Expires" header field in a 200-class response to SUBSCRIBE The "Expires" header field in a 200-class response to SUBSCRIBE
request indicates the actual duration for which the subscription will request indicates the actual duration for which the subscription will
remain active (unless refreshed). remain active (unless refreshed).
Non-200 class final responses indicate that no subscription or new Non-200 class final responses indicate that no subscription or new
dialog usage has been created, and no subsequent NOTIFY request will dialog usage has been created, and no subsequent NOTIFY request will
be sent. All non-200 class responses (with the exception of "489", be sent. All non-200 class responses (with the exception of "489",
described herein) have the same meanings and handling as described in described herein) have the same meanings and handling as described in
[RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains
an "Accept" header field, but that field does not indicate a MIME an "Accept" header field, but that field does not indicate a media
type that the notifier is capable of generating in its NOTIFY type that the notifier is capable of generating in its NOTIFY
requests, then the proper error response is 406 (Not Acceptable). requests, then the proper error response is 406 (Not Acceptable).
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.
skipping to change at page 14, line 33 skipping to change at page 14, line 33
dialog usage are described in Section 4.4.1. Notifications for dialog usage are described in Section 4.4.1. Notifications for
subscriptions which were created inside an existing dialog match if subscriptions which were created inside an existing dialog match if
they are in the same dialog and the "Event" header fields match (as they are in the same dialog and the "Event" header fields match (as
described in Section 8.2.1). described in Section 8.2.1).
If, for some reason, the event package designated in the "Event" If, for some reason, the event package designated in the "Event"
header field of the NOTIFY request is not supported, the subscriber header field of the NOTIFY request is not supported, the subscriber
will respond with a "489 Bad Event" response. will respond with a "489 Bad Event" response.
To prevent spoofing of events, NOTIFY requests SHOULD be To prevent spoofing of events, NOTIFY requests SHOULD be
authenticated, using any defined SIP authentication mechanism. authenticated, using any defined SIP authentication mechanism, such
as those described in sections 22.2 and 23 of [RFC3261].
NOTIFY requests MUST contain "Subscription-State" header fields which NOTIFY requests MUST contain "Subscription-State" header fields which
indicate the status of the subscription. indicate the status of the subscription.
If the "Subscription-State" header field value is "active", it means If the "Subscription-State" header field value is "active", it means
that the subscription has been accepted and (in general) has been that the subscription has been accepted and (in general) has been
authorized. If the header field also contains an "expires" authorized. If the header field also contains an "expires"
parameter, the subscriber SHOULD take it as the authoritative parameter, the subscriber SHOULD take it as the authoritative
subscription duration and adjust accordingly. The "retry-after" and subscription duration and adjust accordingly. The "retry-after" and
"reason" parameters have no semantics for "active". "reason" parameters have no semantics for "active".
skipping to change at page 19, line 8 skipping to change at page 19, line 8
Privacy concerns may require that notifiers apply policy to determine Privacy concerns may require that notifiers apply policy to determine
whether a particular subscriber is authorized to subscribe to a whether a particular subscriber is authorized to subscribe to a
certain set of events. Such policy may be defined by mechanisms such certain set of events. Such policy may be defined by mechanisms such
as access control lists or real-time interaction with a user. In as access control lists or real-time interaction with a user. In
general, authorization of subscribers prior to authentication is not general, authorization of subscribers prior to authentication is not
particularly useful. particularly useful.
SIP authentication mechanisms are discussed in [RFC3261]. Note that, SIP authentication mechanisms are discussed in [RFC3261]. Note that,
even if the notifier node typically acts as a proxy, authentication even if the notifier node typically acts as a proxy, authentication
for SUBSCRIBE requests will always be performed via a "401" response, for SUBSCRIBE requests will always be performed via a "401" response,
not a "407;" notifiers always act as a user agents when accepting not a "407". Notifiers always act as a user agents when accepting
subscriptions and sending notifications. subscriptions and sending notifications.
Of course, when acting as a proxy, a node will perform normal Of course, when acting as a proxy, a node will perform normal
proxy authentication (using 407). The foregoing explanation is a proxy authentication (using 407). The foregoing explanation is a
reminder that notifiers are always UAs, and as such perform UA reminder that notifiers are always UAs, and as such perform UA
authentication. authentication.
If authorization fails based on an access list or some other If authorization fails based on an access list or some other
automated mechanism (i.e., it can be automatically authoritatively automated mechanism (i.e., it can be automatically authoritatively
determined that the subscriber is not authorized to subscribe), the determined that the subscriber is not authorized to subscribe), the
skipping to change at page 33, line 11 skipping to change at page 33, line 11
such as the "id" parameter defined in this document. The restriction such as the "id" parameter defined in this document. The restriction
of a parameter to use with a single event package only applies to of a parameter to use with a single event package only applies to
parameters that are defined in conjunction with an event package. parameters that are defined in conjunction with an event package.
5.4.3. SUBSCRIBE Request Bodies 5.4.3. SUBSCRIBE Request Bodies
It is expected that most, but not all, event packages will define It is expected that most, but not all, event packages will define
syntax and semantics for SUBSCRIBE request bodies; these bodies will syntax and semantics for SUBSCRIBE request bodies; these bodies will
typically modify, expand, filter, throttle, and/or set thresholds for typically modify, expand, filter, throttle, and/or set thresholds for
the class of events being requested. Designers of event packages are the class of events being requested. Designers of event packages are
strongly encouraged to re-use existing MIME types for message bodies strongly encouraged to re-use existing media types for message bodies
where practical. where practical. See [RFC4288] for information on media type
specification and registration.
This mandatory section of an event package defines what type or types This mandatory section of an event package defines what type or types
of event bodies are expected in SUBSCRIBE requests (or specify that of event bodies are expected in SUBSCRIBE requests (or specify that
no event bodies are expected). It should point to detailed no event bodies are expected). It should point to detailed
definitions of syntax and semantics for all referenced body types. definitions of syntax and semantics for all referenced body types.
5.4.4. Subscription Duration 5.4.4. Subscription Duration
It is RECOMMENDED that event packages give a suggested range of times It is RECOMMENDED that event packages give a suggested range of times
considered reasonable for the duration of a subscription. Such considered reasonable for the duration of a subscription. Such
skipping to change at page 33, line 34 skipping to change at page 33, line 35
none is specified. none is specified.
5.4.5. NOTIFY Request Bodies 5.4.5. NOTIFY Request Bodies
The NOTIFY request body is used to report state on the resource being The NOTIFY request body is used to report state on the resource being
monitored. Each package MUST define what type or types of event monitored. Each package MUST define what type or types of event
bodies are expected in NOTIFY requests. Such packages MUST specify bodies are expected in NOTIFY requests. Such packages MUST specify
or cite detailed specifications for the syntax and semantics or cite detailed specifications for the syntax and semantics
associated with such event body. associated with such event body.
Event packages also MUST define which MIME type is to be assumed if Event packages also MUST define which media type is to be assumed if
none are specified in the "Accept" header field of the SUBSCRIBE none are specified in the "Accept" header field of the SUBSCRIBE
request. request.
5.4.6. Notifier processing of SUBSCRIBE requests 5.4.6. Notifier processing of SUBSCRIBE requests
This section describes the processing to be performed by the notifier This section describes the processing to be performed by the notifier
upon receipt of a SUBSCRIBE request. Such a section is required. upon receipt of a SUBSCRIBE request. Such a section is required.
Information in this section includes details of how to authenticate Information in this section includes details of how to authenticate
subscribers and authorization issues for the package. subscribers and authorization issues for the package.
skipping to change at page 46, line 17 skipping to change at page 46, line 23
[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 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004. (SIP) "Join" Header", RFC 3911, October 2004.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005. Protocol (SIP)", RFC 4235, November 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 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.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog [RFC4538] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)", Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006. RFC 4538, 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
skipping to change at page 51, line 37 skipping to change at page 51, line 43
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 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 media type in its Accept header field.
o Minor clarifications to Route and Record-Route behavior. o Minor clarifications to Route and Record-Route behavior.
o Added non-normative warning about the limitations of state o Added non-normative warning about the limitations of state
polling. polling.
o Added information about targeting subscriptions at specific o Added information about targeting subscriptions at specific
dialogs. dialogs.
Author's Address Author's Address
 End of changes. 21 change blocks. 
27 lines changed or deleted 33 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/