Explicit Subscriptions for the REFER Method
draft-sparks-sipcore-refer-explicit-subscription-00

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]