draft-ietf-sipcore-refer-explicit-subscription-03.txt   rfc7614.txt 
Network Working Group R. Sparks Internet Engineering Task Force (IETF) R. Sparks
Internet-Draft Oracle Request for Comments: 7614 Oracle
Intended status: Standards Track June 25, 2015 Category: Standards Track August 2015
Expires: December 27, 2015 ISSN: 2070-1721
Explicit Subscriptions for the REFER Method Explicit Subscriptions for the REFER Method
draft-ietf-sipcore-refer-explicit-subscription-03
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 RFC 3515, 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 that remove the implicit
subscription and, if desired, replace it with an explicit one. subscription and, if desired, replace it with an explicit one.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 27, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7614.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions .....................................................3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview ........................................................4
3.1. Explicit Subscriptions . . . . . . . . . . . . . . . . . 3 3.1. Explicit Subscriptions .....................................4
3.2. No Subscriptions . . . . . . . . . . . . . . . . . . . . 4 3.2. No Subscriptions ...........................................5
4. The Explicit Subscription Extension . . . . . . . . . . . . . 5 4. The Explicit Subscription Extension .............................5
4.1. Sending a REFER . . . . . . . . . . . . . . . . . . . . . 5 4.1. Sending a REFER ............................................5
4.2. Processing a REFER Response . . . . . . . . . . . . . . . 5 4.2. Processing a REFER Response ................................5
4.3. Processing a Received REFER . . . . . . . . . . . . . . . 5 4.3. Processing a Received REFER ................................6
4.4. Subscribing to the 'refer' Event . . . . . . . . . . . . 6 4.4. Subscribing to the 'refer' Event ...........................7
4.5. Processing a Received SUBSCRIBE . . . . . . . . . . . . . 7 4.5. Processing a Received SUBSCRIBE ............................7
4.6. Sending a NOTIFY . . . . . . . . . . . . . . . . . . . . 7 4.6. Sending a NOTIFY ...........................................7
4.7. Managing 'refer' Event State . . . . . . . . . . . . . . 7 4.7. Managing 'refer' Event State ...............................8
4.8. The Refer-Events-At Header Field . . . . . . . . . . . . 8 4.8. The Refer-Events-At Header Field ...........................8
5. The No Subscription Extension . . . . . . . . . . . . . . . . 8 5. The No Subscription Extension ...................................9
5.1. Sending a REFER . . . . . . . . . . . . . . . . . . . . . 8 5.1. Sending a REFER ............................................9
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 ......................10
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 ............................................12
9.1. Register the 'explicitsub' Option Tag . . . . . . . . . . 11 9.1. Register the 'explicitsub' Option Tag .....................12
9.2. Register the 'nosub' Option Tag . . . . . . . . . . . . . 11 9.2. Register the 'nosub' Option Tag ...........................12
9.3. Register the 'Refer-Events-At' Header Field . . . . . . . 12 9.3. Register the Refer-Events-At Header Field .................12
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References ....................................................13
10.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References .....................................13
10.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References ...................................13
10.3. -sparks- 02 to -ietf- 00 . . . . . . . . . . . . . . . . 12 Author's Address ..................................................14
10.4. -sparks- 01 to 02 . . . . . . . . . . . . . . . . . . . 13
10.5. -sparks- 00 to 01 . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction 1. Introduction
REFER as defined by [RFC3515] triggers an implicit SIP-Specific Event REFER, as defined by [RFC3515], triggers an implicit SIP-Specific
Framework subscription. Sending a REFER within a dialog established Event Framework subscription. Sending a REFER within a dialog
by an INVITE results in dialog reuse and the associated problems established by an INVITE results in dialog reuse and the associated
described in [RFC5057]. The SIP-Specific Event Notification problems described in [RFC5057]. The SIP-Specific Event Notification
framework definition [RFC6665] disallows such dialog reuse. Call framework definition [RFC6665] disallows such dialog reuse. Call
transfer, as defined in [RFC5589], thus requires sending a REFER transfer, as defined in [RFC5589], thus requires sending a REFER
request on a new dialog, associating it with an existing dialog using request on a new dialog, associating it with an existing dialog using
the 'Target-Dialog' mechanism defined in [RFC4538]. the 'Target-Dialog' mechanism defined in [RFC4538].
Because there is no explicit SUBSCRIBE request, the tools for Because there is no explicit SUBSCRIBE request, the tools for
negotiating subscription details are unavailable for REFER negotiating subscription details are unavailable for REFER
subscriptions. This includes negotiating subscription duration and subscriptions. This includes negotiating subscription duration and
providing information through Event header field parameters. The use providing information through Event header field parameters. The use
of the SIP 'Supported' and 'Require' extension mechanisms [RFC3261] of the SIP 'Supported' and 'Require' extension mechanisms [RFC3261]
is complicated by the implicit subscription. It is unclear whether is complicated by the implicit subscription. It is unclear whether
the extension applies to handling the REFER request itself, or to the or not the extension applies to handling the REFER request itself, to
messages in the subscription created by the REFER, or both. Avoiding the messages in the subscription created by the REFER, or to both.
this confusion requires careful specification in each extension. Avoiding this confusion requires careful specification in each
Existing extensions do not provide this clarity. extension. Existing extensions do not provide this clarity.
This document defines two mechanisms that remove the implicit This document defines two mechanisms that remove the implicit
subscription, one of which replaces it with an explicit one. The subscription, one of which replaces it with an explicit one. The
benefits of doing so include: benefits of doing so include:
o Allowing REFER to be used within INVITE-created dialogs without o Allowing REFER to be used within INVITE-created dialogs without
creating dialog reuse. creating dialog reuse.
o Allowing standard subscription parameter negotiation. o Allowing standard subscription parameter negotiation.
o Allowing standard negotiation of SIP extensions. o Allowing standard negotiation of SIP extensions.
There are limitations on when it is appropriate to use the extension There are limitations on when it is appropriate to use the extension
that allows an explicit subscription, related directly to definition that allows an explicit subscription, related directly to definition
of non-INVITE transaction handling SIP. These limitations are of non-INVITE transaction handling SIP. These limitations are
discussed in Section 4.1. discussed in Section 4.1.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Overview 3. Overview
This section provides a non-normative overview of the behaviors This section provides a non-normative overview of the behaviors
defined in subsequent sections. defined in subsequent sections.
3.1. Explicit Subscriptions 3.1. Explicit Subscriptions
A SIP User-Agent (UA) that wishes to issue a REFER request that will A SIP User Agent (UA) that wishes to issue a REFER request that will
not create an implicit subscription, but will allow an explicit one, not create an implicit subscription, but will allow an explicit one,
will include a new option tag, 'explicitsub', in the Require header will include a new option tag, 'explicitsub', in the Require header
field of the REFER request. This REFER could be sent either within field of the REFER request. This REFER could be sent either within
an existing dialog, or as an out-of-dialog request. an existing dialog or as an out-of-dialog request.
If the recipient of the REFER accepts the request, it will begin If the recipient of the REFER accepts the request, it will begin
managing the 'refer' event state described in RFC 3515, and will managing the 'refer' event state described in RFC 3515 and will
provide a URI that will reach an event server that will service provide a URI that will reach an event server that will service
subscriptions to that state. (In many cases, the recipient of the subscriptions to that state. (In many cases, the recipient of the
REFER will perform the role of event server itself.) That URI is REFER will perform the role of event server itself.) That URI is
returned in a new header field in the REFER response named 'Refer- returned in a new header field in the REFER response named 'Refer-
Events-At'. Events-At'.
The UA that issued the REFER can now subscribe to the 'refer' event The UA that issued the REFER can now subscribe to the 'refer' event
at the provided URI, using a SUBSCRIBE request with a new dialog at the provided URI, using a SUBSCRIBE request with a new dialog
identifier. The full range of negotiation mechanisms is available identifier. The full range of negotiation mechanisms is available
for its use in that request. As detailed in RFC 6665 and RFC 3515, for its use in that request. As detailed in RFCs 6665 and 3515, the
the event server accepting the subscription will send an immediate event server accepting the subscription will send an immediate NOTIFY
NOTIFY with the current refer event state, additional NOTIFY messages with the current refer event state, additional NOTIFY messages as the
as the refer state changes, and a terminal NOTIFY message when the refer state changes, and a terminal NOTIFY message when the referred
referred action is complete. It is, of course, possible that the action is complete. It is, of course, possible that the initial
initial NOTIFY is also the terminal NOTIFY. NOTIFY is also the terminal NOTIFY.
It is possible that the referred action is completed before the It is possible that the referred action is completed before the
SUBSCRIBE arrives at the event server. The server needs to retain SUBSCRIBE arrives at the event server. The server needs to retain
the final refer event state for some period of time to include in the the final refer event state for some period of time to include in the
terminal NOTIFY that will be sent for such subscriptions. It is also terminal NOTIFY that will be sent for such subscriptions. It is also
possible that a SUBSCRIBE will never arrive. possible that a SUBSCRIBE will never arrive.
This extension makes it possible to separate the event server that This extension makes it possible to separate the event server that
will handle subscriptions from the UA that accepted the REFER. Such will handle subscriptions from the UA that accepted the REFER. Such
a UA could use mechanisms such as PUBLISH [RFC3903] to convey the a UA could use mechanisms such as PUBLISH [RFC3903] to convey the
refer event state to the event server. This extension also makes it refer event state to the event server. This extension also makes it
possible to allow more than one subscription to the refer event possible to allow more than one subscription to the refer event
state. state.
3.2. No Subscriptions 3.2. No Subscriptions
A UA that wishes to issue a REFER request that will not create an A UA that wishes to issue a REFER request that will not create an
implicit subscription, and tell the recipient that it is not implicit subscription and wishes to tell the recipient that it is not
interested in creating an explicit subscription, will include a new interested in creating an explicit subscription will include a new
option tag, 'nosub', in the Require header field of the REFER option tag, 'nosub', in the Require header field of the REFER
request. This REFER could be sent either within an existing dialog request. This REFER could be sent either within an existing dialog
or as an out-of-dialog request. or as an out-of-dialog request.
If the recipient of the REFER accepts the request, it knows not to If the recipient of the REFER accepts the request, it knows not to
create an implicit subscription, and that no explicit subscription create an implicit subscription and knows that no explicit
will be forthcoming. The recipient will continue to process the subscription will be forthcoming. The recipient will continue to
request indicated in the Refer-To header field as specified in RFC process the request indicated in the Refer-To header field as
3515, but it can avoid the cost of preparing to handle any specified in RFC 3515, but it can avoid the cost of preparing to
subscriptions to the state of handling that request. handle any 'refer' event subscriptions related to this REFER request.
4. The Explicit Subscription Extension 4. The Explicit Subscription Extension
4.1. Sending a REFER 4.1. Sending a REFER
To suppress the creation of any implicit subscription, and allow for To suppress the creation of any implicit subscription, and allow for
an explicit one, a UA forming a REFER request will include the option an explicit one, a UA forming a REFER request will include the option
tag 'explicitsub' in the "Require" header field of the request. The tag 'explicitsub' in the Require header field of the request. The
REFER request is otherwise formed following the requirements of REFER request is otherwise formed following the requirements of
[RFC3515]. Since this REFER has no chance of creating an implicit [RFC3515]. Since this REFER has no chance of creating an implicit
subscription, the UA MAY send the REFER request within an existing subscription, the UA MAY send the REFER request within an existing
dialog or out-of-dialog. dialog or out-of-dialog.
Note that if the REFER forks (see [RFC3261]), only one final response Note that if the REFER forks (see [RFC3261]), only one final response
will be returned to the issuing UA. If it is important that the UA will be returned to the issuing UA. If it is important that the UA
be able to subscribe to any refer state generated by accepting this be able to subscribe to any refer state generated by accepting this
request, the UA needs to form the request so that it will only be request, the UA needs to form the request so that it will only be
acepted in one place. This can be achieved by sending the REFER accepted in one place. This can be achieved by sending the REFER
request within an existing dialog, or by using the Target-Dialog request within an existing dialog or by using the 'Target-Dialog'
mechanism defined in [RFC4538]. If it is possible for the request to mechanism defined in [RFC4538]. If it is possible for the request to
be accepted in more than one location, and things would go wrong if be accepted in more than one location, and things would go wrong if
the UA did not learn about each location that the request was the UA did not learn about each location that the request was
accepted, using this extension is not appropriate. accepted, using this extension is not appropriate.
4.2. Processing a REFER Response 4.2. Processing a REFER Response
The UA will process responses to the REFER request as specified in The UA will process responses to the REFER request as specified in
[RFC3515] (and, consequently, [RFC3261]). In particular, if the [RFC3515] (and, consequently, [RFC3261]). In particular, if the
REFER was sent to an element that does not support or is unwilling to REFER was sent to an element that does not support or is unwilling to
use this extension, the response will contain a 420 Bad Extension use this extension, the response will contain a 420 (Bad Extension)
response code (see section 8.1.3.5 of [RFC3261]). As that document response code (see Section 8.1.3.5 of [RFC3261]). As that document
states, the UA can retry the request without using this extension. states, the UA can retry the request without using this extension.
If the UA receives a 2xx-class response, it will contain a Refer- If the UA receives a 2xx-class response, it will contain a Refer-
Events-At header field (Section 4.8) with a single URI as its value. Events-At header field (Section 4.8) with a single URI as its value.
If the UA is interested in the state of the referenced action, it If the UA is interested in the state of the referenced action, it
will subscribe to the 'refer' event at that URI. will subscribe to the 'refer' event at that URI.
4.3. Processing a Received REFER 4.3. Processing a Received REFER
An element receiving a REFER request requiring the 'explicitsub' An element receiving a REFER request requiring the 'explicitsub'
extension will use the same admissions policies that would be used extension will use the same admissions policies that are used without
without the extension, with the addition that it is acceptable to the extension, with the addition that it is acceptable to admit an
admit an in-dialog REFER request requiring this extension since it in-dialog REFER request requiring this extension since it cannot
can not create another usage inside that dialog. In particular, see create another usage inside that dialog. In particular, see
section 5.2 of [RFC3515]. Section 5.2 of [RFC3515].
Accepting a REFER request that requires 'explicitsub' does not create Accepting a REFER request that requires 'explicitsub' does not create
a dialog, or a new usage within an existing dialog. The element MUST a dialog or a new usage within an existing dialog. The element MUST
NOT create an implicit subscription when accepting the REFER request. NOT create an implicit subscription when accepting the REFER request.
If the REFER request was received within an existing dialog, the If the REFER request was received within an existing dialog, the
accepting element will not be acting as a SIP-Events notifier in the accepting element will not be acting as a SIP-Events notifier in the
context of that dialog. If it is not otherwise subject to becoming a context of that dialog. If it is not otherwise subject to becoming a
notifier in the context of the dialog, none of the requirements in notifier in the context of the dialog, none of the requirements in
RFC6665, particularly the requirement to provide a GRUU as the local [RFC6665], particularly the requirement to provide a Globally
contact, apply to the message accepting the REFER request. Routable User Agent URI (GRUU) as the local contact, apply to the
message accepting the REFER request.
An element that accepts a REFER request with 'explicitsub' in its An element that accepts a REFER request with 'explicitsub' in its
Require header field MUST return a 200 response containing a sip: or Require header field MUST return a 200 response containing a sip: or
sips: URI in the Refer-Events-At header field that can be used to sips: URI in the Refer-Events-At header field that can be used to
subscribe to the refer event state associated with this REFER subscribe to the refer event state associated with this REFER
request. This URI MUST uniquely identify this refer event state. request. This URI MUST uniquely identify this refer event state.
The URI needs to reach the event server when used in a SUBSCRIBE The URI needs to reach the event server when used in a SUBSCRIBE
request from the element that sent the REFER. One good way to ensure request from the element that sent the REFER. One good way to ensure
the URI provided has that property is to use a GRUU [RFC5627] for the the URI provided has that property is to use a GRUU [RFC5627] for the
event server. As discussed in Section 8, possession of this URI is event server. As discussed in Section 8, possession of this URI is
often the only requirement for authorizing a subscription to it. often the only requirement for authorizing a subscription to it.
Implementations SHOULD provide a URI constructed in a way that is Implementations SHOULD provide a URI constructed in a way that is
hard to guess. Again, using a GRUU (specifically, a temporary GRUU) hard to guess. Again, using a GRUU (specifically, a temporary GRUU)
is one good way to achieve this property. is one good way to achieve this property.
The accepting element will otherwise proceed with the processing The accepting element will otherwise proceed with the processing
defined in [RFC3515]. defined in [RFC3515].
The event server identified by the Refer-Events-At URI could receive The event server identified by the Refer-Events-At URI could receive
SUBSCRIBE requests at any point after the response containing the SUBSCRIBE requests at any point after the response containing the
Refer-Events-At header is sent. Implementations should take care to Refer-Events-At header field is sent. Implementations should take
ensure the event server is ready to receive those SUBSCRIBE requests care to ensure the event server is ready to receive those SUBSCRIBE
before sending the REFER response, but as with all non-INVITE requests before sending the REFER response, but as with all non-
responses, the response should be sent as soon as possible (see INVITE responses, the response should be sent as soon as possible
[RFC4321]). It is also possible that the referred action may (see [RFC4321]). It is also possible that the referred action may
complete before any SUBSCRIBE request arrives. The event server will complete before any SUBSCRIBE request arrives. The event server will
need to maintain the final refer event state for a period of time need to maintain the final refer event state for a period of time
after the action completes in order to serve such subscriptions (see after the action completes in order to serve such subscriptions (see
Section 4.6). Section 4.7).
4.4. Subscribing to the 'refer' Event 4.4. Subscribing to the 'refer' Event
A UA that possesses a URI obtained from a Refer-Events-At header A UA that possesses a URI obtained from a Refer-Events-At header
field, MAY subscribe to the refer event state at that URI. It does field MAY subscribe to the refer event state at that URI. It does so
so following the requirements of [RFC6665], placing the token 'refer' following the requirements of [RFC6665], placing the token 'refer' in
in the Event: header field and the URI in the Request-URI of the the Event header field and the URI in the Request-URI of the
SUBSCRIBE request. The SUBSCRIBE request MUST NOT reuse any existing SUBSCRIBE request. The SUBSCRIBE request MUST NOT reuse any existing
dialog identifiers. dialog identifiers.
Subsequent handling of the subscription MUST follow the requirements Subsequent handling of the subscription MUST follow the requirements
of [RFC6665] and [RFC3515]. In particular, as discussed in section of [RFC6665] and [RFC3515]. In particular, as discussed in
2.4.6, the NOTIFY messages in the subscription might include an id Section 2.4.6 of [RFC3515], the NOTIFY messages in the subscription
parameter in their Event header fields. Subsequent SUBSCRIBE might include an id parameter in their Event header fields.
requests used to refresh or terminate this subscription MUST contain Subsequent SUBSCRIBE requests used to refresh or terminate this
this id parameter. Note that the rationale for the id parameter subscription MUST contain this id parameter. Note that the rationale
provided in that section is not relevant when this extension is used. for the id parameter provided in that section is not relevant when
The URI returned in the Refer-Events-At header field uniquely this extension is used. The URI returned in the Refer-Events-At
identifies appropriate state, making the id parameter redundant. header field uniquely identifies appropriate state, making the id
However, this behavioral requirement is preserved to reduce the parameter redundant. However, this behavioral requirement is
number of changes to existing implementations in order to support preserved to reduce the number of changes to existing implementations
this extension, and to make it more likely that existing diagnostic in order to support this extension and to make it more likely that
tools will work with little or no modification. existing diagnostic tools will work with little or no modification.
4.5. Processing a Received SUBSCRIBE 4.5. Processing a Received SUBSCRIBE
An event server receiving a SUBSCRIBE request will process it An event server receiving a SUBSCRIBE request will process it
according to the requirements of [RFC6665]. The event server MAY according to the requirements of [RFC6665]. The event server MAY
choose to authorize the SUBSCRIBE request based on the Request-URI choose to authorize the SUBSCRIBE request based on the Request-URI
corresponding to existing refer event state. It MAY also require corresponding to existing refer event state. It MAY also require
further authorization as discussed in Section 8. further authorization as discussed in Section 8.
When accepting a subscription, the event server will establish the When accepting a subscription, the event server will establish the
initial subscription duration using the guidance in section 3.4 of initial subscription duration using the guidance in Section 3.4 of
[RFC3515]. [RFC3515].
4.6. Sending a NOTIFY 4.6. Sending a NOTIFY
NOTIFY messages within a subscription are formed and sent following NOTIFY messages within a subscription are formed and sent following
the requirements in [RFC3515]. See, in particular, section 2.4.5 of the requirements in [RFC3515]. See, in particular, Section 2.4.5 of
that document. that document.
4.7. Managing 'refer' Event State 4.7. Managing 'refer' Event State
As described in [RFC3515], an element creates the state for event As described in [RFC3515], an element creates the state for event
'refer' when it accepts a REFER request. It updates that state as 'refer' when it accepts a REFER request. It updates that state as
the referred request proceeds, ultimately reaching a state where the the referred request proceeds, ultimately reaching a state where the
request has completed, and the final state is known. request has completed and the final state is known.
In RFC 3515 implementations, it was a reasonable design choice to In RFC 3515 implementations, it was a reasonable design choice to
destroy the refer event state immediately after sending the NOTIFY destroy the refer event state immediately after sending the NOTIFY
that terminated the implicit subscription. This is not the case when that terminated the implicit subscription. This is not the case when
using this extension. It is possible for the referenced request to using this extension. It is possible for the referenced request to
complete very quickly, perhaps sooner than the time it takes the complete very quickly, perhaps sooner than the time it takes the
response to the REFER to traverse the network to the UA that sent the response to the REFER to traverse the network to the UA that sent the
request, and the time it takes that agent to send the SUBSCRIBE request and the time it takes that agent to send the SUBSCRIBE
request for the event state to the URI the response provides. Thus request for the event state to the URI the response provides. Thus,
the event server MUST retain the final refer event state for a the event server MUST retain the final refer event state for a
reasonable period of time, which SHOULD be at least 2*64*T1 (that is, reasonable period of time, which SHOULD be at least 2*64*T1 (that is,
64 seconds), representing an upper-bound estimate of the time it 64 seconds), representing an upper-bound estimate of the time it
would take to complete two non-INVITE transactions: the REFER, and an would take to complete two non-INVITE transactions: the REFER and an
immediate SUBSCRIBE. immediate SUBSCRIBE.
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
terminated with a NOTIFY containing the final event state with a with a NOTIFY containing the final event state with a Subscription-
Subscription-State of terminated with a reason value of "noresource". 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
by [RFC3261]. Its ABNF is as follows: [RFC3261]. Its ABNF [RFC5234] 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
Refer-Events-At: sip:wsXa9mkHtPcGu8@example.com Refer-Events-At: sip:wsXa9mkHtPcGu8@example.com
is invalid. is invalid.
The 'Refer-Events-At' header field is only meaningful in a 2xx-class The Refer-Events-At header field is only meaningful in a 2xx-class
response to a REFER request. If it appears in the header of any response to a REFER request. If it appears in the header of any
other SIP message, its meaning is undefined and it MUST be ignored. other SIP message, its meaning is undefined, and it MUST be ignored.
5. The No Subscription Extension 5. The No Subscription Extension
5.1. Sending a REFER 5.1. Sending a REFER
To suppress the creation of any implicit subscription, and signal To suppress the creation of any implicit subscription and signal that
that no explicit subscription will be forthcoming, a UA forming a no explicit subscription will be forthcoming, a UA forming a REFER
REFER request will include the option tag 'nosub' in the "Require" request will include the option tag 'nosub' in the Require header
header field of the request. The REFER request is otherwise formed field of the request. The REFER request is otherwise formed
following the requirements of [RFC3515]. Since this REFER has no following the requirements of [RFC3515]. Since this REFER has no
chance of creating an implicit subscription, the UA MAY send the chance of creating an implicit subscription, the UA MAY send the
REFER request within an existing dialog or out-of-dialog. REFER request within an existing dialog or out-of-dialog.
5.2. Processing a REFER Response 5.2. Processing a REFER Response
The UA will process responses to the REFER request as specified in The UA will process responses to the REFER request as specified in
[RFC3515] (and, consequently, [RFC3261]). In particular, if the [RFC3515] (and, consequently, [RFC3261]). In particular, if the
REFER was sent to an element that does not support or is unwilling to REFER was sent to an element that does not support or is unwilling to
use this extension, the response will contain a 420 Bad Extension use this extension, the response will contain a 420 (Bad Extension)
response code (see section 8.1.3.5 of [RFC3261]). As that document response code (see Section 8.1.3.5 of [RFC3261]). As that document
states, the UA can retry the request without using this extension. states, the UA can retry the request without using this extension.
5.3. Processing a Received REFER 5.3. Processing a Received REFER
An element receiving a REFER request requiring the 'nosub' extension An element receiving a REFER request requiring the 'nosub' extension
will use the same admissions policies that would be used without the will use the same admissions policies that would be used without the
extension, with the addition that it is acceptable to admit an in- extension, with the addition that it is acceptable to admit an in-
dialog REFER request requiring this extension since it can not create dialog REFER request requiring this extension since it cannot create
another usage inside that dialog. In particular, see section 5.2 of another usage inside that dialog. In particular, see Section 5.2 of
[RFC3515]. [RFC3515].
Accepting a REFER request that requires 'nosub' does not create a Accepting a REFER request that requires 'nosub' does not create a
dialog, or a new usage within an existing dialog. The element MUST dialog or a new usage within an existing dialog. The element MUST
NOT create an implicit subscription when accepting the REFER request. NOT create an implicit subscription when accepting the REFER request.
Futhermore, the element accepting the REFER request is not required Furthermore, the element accepting the REFER request is not required
to maintain any state for serving refer event subscriptions. to maintain any state for serving refer event subscriptions.
If the REFER is received within an existing dialog, the accepting If the REFER is received within an existing dialog, the accepting
element will not be acting as a SIP-Events notifier in the context of element will not be acting as a SIP-Events notifier in the context of
that dialog. If it is not otherwise subject to becoming a notifier that dialog. If it is not otherwise subject to becoming a notifier
in the context of the dialog, none of the requirements in RFC6665, in the context of the dialog, none of the requirements in [RFC6665],
particularly the requirement to provide a GRUU as the local contact, particularly the requirement to provide a GRUU as the local contact,
apply to the message accepting the REFER request. apply to the message accepting the REFER request.
The accepting element will otherwise proceed with the processing The accepting element will otherwise proceed with the processing
defined in [RFC3515]. defined in [RFC3515].
6. The 'explicitsub' and 'nosub' Option Tags 6. The 'explicitsub' and 'nosub' Option Tags
This document defines the 'explicitsub' option tag, used to signal This document defines the 'explicitsub' option tag, used to signal
the use of the extension defined in Section 4, and the 'nosub' option the use of the extension defined in Section 4, and the 'nosub' option
skipping to change at page 10, line 6 skipping to change at page 10, line 23
The use of either option tag in a Require header field is only The use of either option tag in a Require header field is only
defined when it appears in a REFER request or a response to a REFER defined when it appears in a REFER request or a response to a REFER
request. A UA MUST NOT include the 'explicitsub' or 'nosub' option request. A UA MUST NOT include the 'explicitsub' or 'nosub' option
tag in the Require header field of any request other than REFER. A tag in the Require header field of any request other than REFER. A
UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the
Require header field of any SIP response other than a 200 or 421 Require header field of any SIP response other than a 200 or 421
response to a REFER request. response to a REFER request.
The 'explicitsub' and 'nosub' option tags MAY appear in the Supported The 'explicitsub' and 'nosub' option tags MAY appear in the Supported
header field of SIP messages, and in sip.extensions feature tag header field of SIP messages and in the sip.extensions feature tag
defined in [RFC3840]. This signals only that the UA including the defined in [RFC3840]. This signals only that the UA including the
value is aware of the extensions. In particular, a UA can only value is aware of the extensions. In particular, a UA can only
invoke the use of one of the extensions in a request. A UA MUST NOT invoke the use of one of the extensions in a request. A UA MUST NOT
include either option tag in the Require header field of a 200 include either option tag in the Require header field of a 200
response to a REFER request if that tag was not present in the response to a REFER request if that tag was not present in the
Require header field of the request. A User-Agent Server (UAS) that Require header field of the request. A User Agent Server (UAS) that
is processing a REFER request that lists 'explicitsub' or 'nosub' in is processing a REFER request that lists 'explicitsub' or 'nosub' in
its Supported header field and wishes to use one of those extensions its Supported header field and wishes to use one of those extensions
will return a 421 response indicating which extension is required. will return a 421 response indicating which extension is required.
7. Updates to RFC 3515 7. Updates to RFC 3515
The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog The requirement in Section 2.4.4 of [RFC3515] to reject out-of-dialog
SUBSCRIBE requests to event 'refer' is removed. An element MAY SUBSCRIBE requests to event 'refer' is removed. An element MAY
accept a SUBSCRIBE request to event 'refer', following the accept a SUBSCRIBE request to event 'refer', following the
requirements and guidance in this document. REFER is no longer the requirements and guidance in this document. REFER is no longer the
only mechanism that can create a subscription to event 'refer'. only mechanism that can create a subscription to event 'refer'.
8. Security Considerations 8. Security Considerations
The considerations of [RFC3515] all still apply to a REFER request The security considerations of [RFC3515] all still apply to a REFER
using this extension. The considerations there for the implicit request using this extension. The security considerations there for
subscription apply to any explicit subscription for the 'refer' the implicit subscription apply to any explicit subscription for the
event. 'refer' event.
This update to RFC 3515 introduces a new authorization consideration. This update to RFC 3515 introduces a new authorization consideration.
An element receiving an initial SUBSCRIBE request to the 'refer' An element receiving an initial SUBSCRIBE request to the 'refer'
event needs to decide whether the subscriber should be allowed to see event needs to decide whether the subscriber should be allowed to see
the refer event state. In RFC 3515, this decision was conflated with the refer event state. In RFC 3515, this decision was conflated with
accepting the REFER request, and the only possible subscriber was the accepting the REFER request, and the only possible subscriber was the
element that sent the REFER. With this update, there may be multiple element that sent the REFER. With this update, there may be multiple
subscribers to any given refer event state. subscribers to any given refer event state.
This document allows an element to accept an initial SUBSCRIBE This document allows an element to accept an initial SUBSCRIBE
request based on having a Request-URI that identifies existing refer request based on having a Request-URI that identifies existing refer
event state. (Such a URI will have previously been sent in the event state. (Such a URI will have previously been sent in the
Refer-Events-At header field in a successful REFER response). The Refer-Events-At header field in a successful REFER response). The
element retrieving that URI from the response, and any elements that element retrieving that URI from the response and any elements that
element shares the URI with are authorized to SUBSCRIBE to the event element shares the URI with are authorized to SUBSCRIBE to the event
state. Consequently, the URI should be constructed so that it is not state. Consequently, the URI should be constructed so that it is not
easy to guess, and should be protected against eavesdroppers when easy to guess and should be protected against eavesdroppers when
transmitted. [RFC3261] details mechanisms for providing such transmitted. [RFC3261] details mechanisms for providing such
protection, such as sending SIP messages over TLS or DTLS. See the protection, such as sending SIP messages over Transport Layer
security considerations section of [RFC3261] for considerations when Security (TLS) or Datagram TLS (DTLS). See the Security
using other security mechanisms. An event server receiving a REFER Considerations section of [RFC3261] for considerations when using
request over an unprotected transport can redirect the requester to other security mechanisms. An event server receiving a REFER request
use a protected transport before accepting the request. A good way over an unprotected transport can redirect the requester to use a
to ensure that subscriptions use a protected transport is to only protected transport before accepting the request. A good way to
ensure that subscriptions use a protected transport is to only
construct sips: URIs. The event server can also require any of the construct sips: URIs. The event server can also require any of the
additional authorization mechanisms allowed for any SIP request. For additional authorization mechanisms allowed for any SIP request. For
example, the event server could require a valid assertion of the example, the event server could require a valid assertion of the
subscriber's identity using [RFC4474]. subscriber's identity using [RFC4474].
The URI provided in a 'Refer-Events-At' header field will be used as The URI provided in a Refer-Events-At header field will be used as
the Request-URI of SUBSCRIBE requests. A malicious agent could take the Request-URI of SUBSCRIBE requests. A malicious agent could take
advantage of being able to choose this URI in ways similar to the advantage of being able to choose this URI in ways similar to the
ways an agent sending a REFER request can take advantage of the ways an agent sending a REFER request can take advantage of the
Refer-To URI, as described in the security considerations section of Refer-To URI, as described in the Security Considerations section of
RFC 3515. In particular, the malicious agent could cause a SIP [RFC3515]. In particular, the malicious agent could cause a SIP
SUBSCRIBE to be sent as raw traffic towards a victim. If the victim SUBSCRIBE to be sent as raw traffic towards a victim. If the victim
is not SIP aware, and the SUBSCRIBE is sent over UDP, there is (at is not SIP aware and the SUBSCRIBE is sent over UDP, there is (at
most) a factor of 11 amplification due to retransmissions of the most) a factor of 11 amplification due to retransmissions of the
request. The potential for abuse in this situation is lower than request. The potential for abuse in this situation is lower than
that of the Refer-To URI, since the URI can only have a sip: or sips: that of the Refer-To URI, since the URI can only have a sip: or sips:
scheme, and is only provided in a REFER response. A malicious agent scheme, and is only provided in a REFER response. A malicious agent
would have to first receive a REFER request to take advantage of would have to first receive a REFER request to take advantage of
providing a Refer-Events-At URI. providing a Refer-Events-At URI.
9. IANA Considerations 9. IANA Considerations
9.1. Register the 'explicitsub' Option Tag 9.1. Register the 'explicitsub' Option Tag
The option tag 'explicitsub' is registered in the 'Option Tag' The option tag 'explicitsub' has been registered in the 'Option Tags'
subregistry of the 'Session Initiation Protocol (SIP) Parameters' subregistry of the 'Session Initiation Protocol (SIP) Parameters'
registry by adding a row with these values: registry by adding a row with these values:
Name: explicitsub Name: explicitsub
Description: This option tag identifies an extension to REFER to Description: This option tag identifies an extension to REFER to
suppress the implicit subscription, and provide a URI for an explicit suppress the implicit subscription and provide a URI for an explicit
subscription. subscription.
Reference: (this document) Reference: RFC 7614 (this document)
9.2. Register the 'nosub' Option Tag 9.2. Register the 'nosub' Option Tag
The option tag 'nosub' is registered in the 'Option Tag' subregistry The option tag 'nosub' has been registered in the 'Option Tags'
of the 'Session Initiation Protocol (SIP) Parameters' registry by subregistry of the 'Session Initiation Protocol (SIP) Parameters'
adding a row with these values: registry by adding a row with these values:
Name: nosub Name: nosub
Description: This option tag identifies an extension to REFER to Description: This option tag identifies an extension to REFER to
suppress the implicit subscription, and indicate that no explicit suppress the implicit subscription and indicate that no explicit
subscription is forthcoming. subscription is forthcoming.
Reference: (this document) Reference: RFC 7614 (this document)
9.3. Register the 'Refer-Events-At' Header Field 9.3. Register the Refer-Events-At Header Field
The header field described in Section 4.8 is registered in the The header field described in Section 4.8 has been registered in the
'Header Fields' subregistry of the 'Session Initiation Protocol (SIP) 'Header Fields' subregistry of the 'Session Initiation Protocol (SIP)
Parameters' registry by adding a row with these values: Parameters' registry by adding a row with these values:
Header Name: Refer-Events-At Header Name: Refer-Events-At
compact: (none: the entry in this column should be blank) compact: none
Reference: (this document)
10. Changelog
RFC Editor - please remove this section when formatting this document
as an RFC.
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
mechanisms other than TLS or DTLS.
10.3. -sparks- 02 to -ietf- 00
1. Incorporated the change to section 6 discussed on list
2. Changed "only meaningful in 200" to "only meaningful in 2xx-
class"
3. Explicitly stated that the RFC6665 rules on populating Contact
when becoming a notifier do not apply to the message accepting a
REFER request requiring either of these extensions
4. Pointed out that _temporary_ GRUUs are what have the good
security property discussed in the security considerations
section
10.4. -sparks- 01 to 02
1. Added the 'nosub' option tag
2. Added text calling out the limitations on explicitsub when the
REFER might be accepted in more than one place.
10.5. -sparks- 00 to 01
1. Replaced strawman proposal with a formal definition of the Reference: RFC 7614 (this document)
mechanism. Added an overview, and detailed security
considerations.
11. References 10. References
11.1. Normative References 10.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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[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, DOI 10.17487/RFC3515, April 2003,
<http://www.rfc-editor.org/info/rfc3515>.
[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,
DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
July 2012. DOI 10.17487/RFC6665, July 2012,
<http://www.rfc-editor.org/info/rfc6665>.
11.2. Informative References 10.2. Informative References
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP)
for Event State Publication", RFC 3903, October 2004. Extension for Event State Publication", RFC 3903,
DOI 10.17487/RFC3903, October 2004,
<http://www.rfc-editor.org/info/rfc3903>.
[RFC4321] Sparks, R., "Problems Identified Associated with the [RFC4321] Sparks, R., "Problems Identified Associated with the
Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4321, January 2006. Transaction", RFC 4321, DOI 10.17487/RFC4321, January
2006, <http://www.rfc-editor.org/info/rfc4321>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>.
[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, DOI 10.17487/RFC4538, June 2006,
<http://www.rfc-editor.org/info/rfc4538>.
[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, DOI 10.17487/RFC5057,
November 2007, <http://www.rfc-editor.org/info/rfc5057>.
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session
Initiation Protocol (SIP) Call Control - Transfer", BCP Initiation Protocol (SIP) Call Control - Transfer",
149, RFC 5589, June 2009. BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009,
<http://www.rfc-editor.org/info/rfc5589>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
<http://www.rfc-editor.org/info/rfc5627>.
Author's Address Author's Address
Robert Sparks Robert Sparks
Oracle Oracle
7460 Warren Parkway 7460 Warren Parkway, Suite 300
Suite 300
Frisco, Texas 75034 Frisco, Texas 75034
US United States
Email: rjsparks@nostrum.com Email: rjsparks@nostrum.com
 End of changes. 81 change blocks. 
238 lines changed or deleted 209 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/