Explicit Subscriptions for the REFER Method

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 .

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.

REFER as defined by 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 . The SIP-Specific Event Notification framework definition disallows such dialog reuse. Call transfer, as defined in , thus requires sending a REFER request on a new dialog, associating it with an existing dialog using the 'Target-Dialog' mechanism defined in . 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 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.

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.

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.

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.

The strawman proposes no. Neither the payload of NOTIFY messages, nor the meaning of the state being subscribed to changes.

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

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.

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

This document has no actions for IANA.