draft-ietf-sipcore-refer-explicit-subscription-01.txt   draft-ietf-sipcore-refer-explicit-subscription-02.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track March 3, 2015 Intended status: Standards Track April 22, 2015
Expires: September 4, 2015 Expires: October 24, 2015
Explicit Subscriptions for the REFER Method Explicit Subscriptions for the REFER Method
draft-ietf-sipcore-refer-explicit-subscription-01 draft-ietf-sipcore-refer-explicit-subscription-02
Abstract Abstract
The Session Initiation Protocol (SIP) REFER request, as defined by The Session Initiation Protocol (SIP) REFER request, as defined by
RFC3515, triggers an implicit SIP-Specific Event Notification RFC3515, triggers an implicit SIP-Specific Event Notification
framework subscription. Conflating the start of the subscription framework subscription. Conflating the start of the subscription
with handling the REFER request makes negotiating SUBSCRIBE with handling the REFER request makes negotiating SUBSCRIBE
extensions impossible, and complicates avoiding SIP dialog sharing. extensions impossible, and complicates avoiding SIP dialog sharing.
This document defines extensions to REFER to remove the implicit This document defines extensions to REFER to remove the implicit
subscription and, if desired, replace it with an explicit one. subscription and, if desired, replace it with an explicit one.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 4, 2015. This Internet-Draft will expire on October 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 35 skipping to change at page 2, line 35
5.2. Processing a REFER Response . . . . . . . . . . . . . . . 9 5.2. Processing a REFER Response . . . . . . . . . . . . . . . 9
5.3. Processing a Received REFER . . . . . . . . . . . . . . . 9 5.3. Processing a Received REFER . . . . . . . . . . . . . . . 9
6. The 'explicitsub' and 'nosub' Option Tags . . . . . . . . . . 9 6. The 'explicitsub' and 'nosub' Option Tags . . . . . . . . . . 9
7. Updates to RFC 3515 . . . . . . . . . . . . . . . . . . . . . 10 7. Updates to RFC 3515 . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. Register the 'explicitsub' Option Tag . . . . . . . . . . 11 9.1. Register the 'explicitsub' Option Tag . . . . . . . . . . 11
9.2. Register the 'nosub' Option Tag . . . . . . . . . . . . . 11 9.2. Register the 'nosub' Option Tag . . . . . . . . . . . . . 11
9.3. Register the 'Refer-Events-At' Header Field . . . . . . . 12 9.3. Register the 'Refer-Events-At' Header Field . . . . . . . 12
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. -sparks- 02 to -ietf- 00 . . . . . . . . . . . . . . . . 12 10.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 12
10.3. -sparks- 01 to 02 . . . . . . . . . . . . . . . . . . . 13 10.3. -sparks- 02 to -ietf- 00 . . . . . . . . . . . . . . . . 12
10.4. -sparks- 00 to 01 . . . . . . . . . . . . . . . . . . . 13 10.4. -sparks- 01 to 02 . . . . . . . . . . . . . . . . . . . 13
10.5. -sparks- 00 to 01 . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Conventions and Definitions 1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 8, line 19 skipping to change at page 8, line 19
If an otherwise acceptable SUBSCRIBE arrives during this retention If an otherwise acceptable SUBSCRIBE arrives during this retention
period, the subscription would be accepted, and immediately period, the subscription would be accepted, and immediately
terminated with a NOTIFY containing the final event state with a terminated with a NOTIFY containing the final event state with a
Subscription-State of terminated with a reason value of "noresource". Subscription-State of terminated with a reason value of "noresource".
4.8. The Refer-Events-At Header Field 4.8. The Refer-Events-At Header Field
The 'Refer-Events-At' header field is an extension-header as defined The 'Refer-Events-At' header field is an extension-header as defined
by [RFC3261]. Its ABNF is as follows: by [RFC3261]. Its ABNF is as follows:
Refer-Events-At: "Refer-Events-At" HCOLON Refer-Events-At = "Refer-Events-At" HCOLON
LAQUOT ( SIP-URI / SIPS-URI ) RAQUOT LAQUOT ( SIP-URI / SIPS-URI ) RAQUOT
* ( SEMI generic-param ) *( SEMI generic-param )
See [RFC3261] for the definition of the elements used in that See [RFC3261] for the definition of the elements used in that
production. production.
Note that this rule does not allow a full addr-spec as defined in RFC Note that this rule does not allow a full addr-spec as defined in RFC
3261, and it mandates the use of the angle brackets. That is: 3261, and it mandates the use of the angle brackets. That is:
Refer-Events-At: <sips:vPT3izGmo8NTxaPADRZvEAY22BKx@example.com;gr> Refer-Events-At: <sips:vPT3izGmo8NTxaPADRZvEAY22BKx@example.com;gr>
is well formed, but is well formed, but
skipping to change at page 12, line 30 skipping to change at page 12, line 30
compact: (none: the entry in this column should be blank) compact: (none: the entry in this column should be blank)
Reference: (this document) Reference: (this document)
10. Changelog 10. Changelog
RFC Editor - please remove this section when formatting this document RFC Editor - please remove this section when formatting this document
as an RFC. as an RFC.
10.1. -00 to -01 10.1. -01 to -02
1. Corrected ABNF per Paul Kyzivat's review.
10.2. -00 to -01
1. Added pointer to rfc3261 for considerations when using security 1. Added pointer to rfc3261 for considerations when using security
mechanisms other than TLS or DTLS. mechanisms other than TLS or DTLS.
10.2. -sparks- 02 to -ietf- 00 10.3. -sparks- 02 to -ietf- 00
1. Incorporated the change to section 6 discussed on list 1. Incorporated the change to section 6 discussed on list
2. Changed "only meaningful in 200" to "only meaningful in 2xx- 2. Changed "only meaningful in 200" to "only meaningful in 2xx-
class" class"
3. Explicitly stated that the RFC6665 rules on populating Contact 3. Explicitly stated that the RFC6665 rules on populating Contact
when becoming a notifier do not apply to the message accepting a when becoming a notifier do not apply to the message accepting a
REFER request requiring either of these extensions REFER request requiring either of these extensions
4. Pointed out that _temporary_ GRUUs are what have the good 4. Pointed out that _temporary_ GRUUs are what have the good
security property discussed in the security considerations security property discussed in the security considerations
section section
10.3. -sparks- 01 to 02 10.4. -sparks- 01 to 02
1. Added the 'nosub' option tag 1. Added the 'nosub' option tag
2. Added text calling out the limitations on explicitsub when the 2. Added text calling out the limitations on explicitsub when the
REFER might be accepted in more than one place. REFER might be accepted in more than one place.
10.4. -sparks- 00 to 01 10.5. -sparks- 00 to 01
1. Replaced strawman proposal with a formal definition of the 1. Replaced strawman proposal with a formal definition of the
mechanism. Added an overview, and detailed security mechanism. Added an overview, and detailed security
considerations. considerations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 9 change blocks. 
15 lines changed or deleted 20 lines changed or added

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