Network Working Group R. Sparks
Internet-Draft Oracle
Intended status: Standards Track June 17, 2014
Expires: December 19, 2014
Explicit Subscriptions for the REFER Method
draft-sparks-sipcore-refer-explicit-subscription-00
Abstract
The SIP REFER request, as defined by RFC3515, triggers an implicit
SIP-Specific Event Notification framework subscription. Conflating
the start of the subscription with handling the REFER request makes
negotiating SUBSCRIBE extensions impossible, and complicates avoiding
SIP dialog sharing. This document defines an extension to REFER to
remove the implicit subscription and replace it with an explicit one.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Sparks Expires December 19, 2014 [Page 1]
Internet-Draft REFER Explicit Subscriptions June 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Strawman Mechanism . . . . . . . . . . . . . . . . . . . . . 3
5. Discussion Points . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Backward compatibility . . . . . . . . . . . . . . . . . 4
5.2. Should this be a different method? . . . . . . . . . . . 4
5.3. Should this use a different event package? . . . . . . . 4
5.4. Could this deprecate RFC4488? . . . . . . . . . . . . . . 4
5.5. Should this tighten down what can appear in a Refer-To
header field? . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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. Status
This version of the document is a strawman proposal of mechanism, and
seeds for discussion of that proposal. The material in this version
of the document is not yet appropriate for early implementation.
3. Introduction
REFER as defined by [RFC3515] triggers an implicit SIP-Specific Event
Framework subscription. Sending a REFER within a dialog established
by an INVITE results in dialog reuse and the associated problems
described in [RFC5057]. The SIP-Specific Event Notification
framework definition [RFC6665] disallows such dialog reuse. Call
transfer, as defined in [RFC5589], thus requires sending a REFER
request on a new dialog, associating it with an existing dialog using
the 'Target-Dialog' mechanism defined in [RFC4538].
Because there is no explicit SUBSCRIBE request, the tools for
negotiating subscription details are unavailable for REFER
Sparks Expires December 19, 2014 [Page 2]
Internet-Draft REFER Explicit Subscriptions June 2014
subscriptions. This includes negotiating subscription duration and
providing information through Event header field parameters. The use
of the SIP 'Supported' and 'Require' extension mechanisms [RFC3261]
is complicated by the implicit subscription. Avoiding potential
confusion around whether the extension applies to handling the REFER
request itself, or to the messages in the subscription created by the
REFER, or both, requires careful specification in each extension.
Many existing extensions do not provide this clarity.
This document proposes a strawman mechanism to remove the implicit
subscription and replace it with an explicit one. The benefits of
doing so include:
o Allowing REFER to be used within INVITE-created dialogs without
creating dialog reuse.
o Allowing standard subscription parameter negotiation.
o Allowing standard negotiation of SIP extensions.
4. Strawman Mechanism
In this version of the draft, the mechanism is described at a high
level. Future versions (if the group decides to explore this idea
further) will contain a formal specification.
Define an option tag ('explicitsub') for use in the Require:
header field of REFER requests.
Define a header field ('Refer-Events-At') to be included in 200
class REFER responses, containing a URL with GRUU-properties for
which to subscribe to event 'refer'
Modify the REFER specifiation to allow accepting a new SUBSCRIBE
for event 'refer'
The authorization policy for accepting a REFER subscription is based
on possession of the URL for the resource. (Any adversary capable of
obtaining the URL is in a position to see any NOTIFY contents
anyhow). The notifier may accept more than one subscription for the
resource as long as the resource exists. The mechanics called out in
RFC3515 for indicating that the resource no longer exists still
apply.
Sparks Expires December 19, 2014 [Page 3]
Internet-Draft REFER Explicit Subscriptions June 2014
5. Discussion Points
5.1. Backward compatibility
A 3515 Notifier will reject an initial REFER because of the Require:
option, allowing the updated Subscriber to learn that it needs to
retry the REFER allowing for an implicit subsccription.
An updated Notifier receiving a REFER without the option tag can
create an implicit subscription per 3515.
5.2. Should this be a different method?
Instead of using Require:, this could be something like REFERBIS.
The strawman proposes no, on the weak grounds that new option tags
are easier to deploy than new methods.
5.3. Should this use a different event package?
The strawman proposes no. Neither the payload of NOTIFY messages,
nor the meaning of the state being subscribed to changes.
5.4. Could this deprecate RFC4488?
The extension could define that a server not wishing to provide
subscriptions return a URL from the .invalid family in the 'Refer-
Events-At' header field (alternatively, no Refer-Events-At header
field at all). That, along with the use of Require (and not
Supported) from the subscriber simplifies the negotiation flows over
those in [RFC4488] when the client does not know ahead of time if the
server supports the extension. A client not interested in
subscriptions can simply not subscribe.
5.5. Should this tighten down what can appear in a Refer-To header
field?
The strawman proposal is no. As with 3515, a REFER recipient that
doesn't know what to do with a non-SIP URL (for example) can decline
the REFER.
6. Security Considerations
If the group decides to pursue this idea, this section will need to
add detail to the authorization policy mentioned above, and consider
the ramifications of being asked to subscribe to a URL this way
(which will be very similar to the security considerations that apply
to the URI in a Refer-To header field in the first place).
Sparks Expires December 19, 2014 [Page 4]
Internet-Draft REFER Explicit Subscriptions June 2014
7. IANA Considerations
This document has no actions for IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol
(SIP) REFER Method Implicit Subscription", RFC 4488, May
2006.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session
Initiation Protocol (SIP) Call Control - Transfer", BCP
149, RFC 5589, June 2009.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
July 2012.
8.2. Informative References
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007.
Author's Address
Sparks Expires December 19, 2014 [Page 5]
Internet-Draft REFER Explicit Subscriptions June 2014
Robert Sparks
Oracle
7460 Warren Parkway
Suite 300
Frisco, Texas 75034
US
Email: RjS@nostrum.com
Sparks Expires December 19, 2014 [Page 6]