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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Conventions and Definitions
• 2. Status
• 3. Introduction
• 4. Strawman Mechanism
• 5. Discussion Points
• 5.1. Backward compatibility
• 5.2. Should this be a different method?
• 5.3. Should this use a different event package?
• 5.4. Could this deprecate RFC4488?
• 5.5. Should this tighten down what can appear in a Refer-To header field?
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

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 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:

• Allowing REFER to be used within INVITE-created dialogs without creating dialog reuse.
• Allowing standard subscription parameter negotiation.
• 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.

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).

7. IANA Considerations

This document has no actions for IANA.

8. References

8.1. Normative References

8.2. Informative References

Author's Address