Recently there has been some offline discussion regarding the impact of RFC 6665 on the use of REFER. Particularly on whether an RFC 6665 compliant UA can send a REFER using a dialog created by another SIP method other than for interoperability with UAs that don't support GRUU and RFC 6665.

RFC 6665 deprecates dialog reuse for subscriptions. REFER can create also create an implicit subscription.

RFC 6665 states:

        .... the dialog reuse technique described in RFC 3265 is now deprecated.

   This dialog-sharing technique has also historically been used as a
   means for targeting an event package at a dialog.  This usage can be
   seen, for example, in certain applications of the REFER method
   [RFC3515].  With the removal of dialog reuse, an alternate (and more
   explicit) means of targeting dialogs needs to be used for this type
   of correlation.  The appropriate means of such targeting is left up
   to the actual event packages.  Candidates include the "Target-Dialog"
   header field [RFC4538], the "Join" header field [RFC3911], and the
   "Replaces" header field [RFC3891], depending on the semantics
   desired.

And

      Further note that the prohibition on reusing dialogs does not
      exempt implicit subscriptions created by the REFER method.  This
      means that implementations complying with this specification are
      required to use the "Target-Dialog" mechanism described in
      [RFC4538] when the remote target is a GRUU.


However RFC 4488 provides a means to request a REFER recipient not to create an implicit subscription through the use of Refer-Sub: false. However the text of RFC 4488 does not require that the REFER recipient not create an implicit subscription since RFC 4488 states:

   If the REFER-Recipient supports the extension and is willing to process the REFER transaction without establishing an implicit subscription, it MUST insert the "Refer-Sub" header field set to "false" in the 2xx response to the REFER-Issuer.

The key words here are "and is WILLING to process the REFER transaction without establishing an implicit subscription" so there is always the possibility that a subscription will be created even if norefersub is supported and Refer-Sub header field is set to FALSE.

However RFC 5057 seems to be in conflict with RFC 4488 in this regard stating:


   Dialogs with multiple usages arise when a usage-creating action
   occurs inside an existing dialog.  Such actions include accepting a
   REFER or SUBSCRIBE issued inside a dialog established with an INVITE
   request.  Multiple REFERs within a dialog create multiple
   subscriptions, each of which is a new dialog usage sharing common
   dialog state.  (Note that any REFER issued utilizing the
   subscription-suppression mechanism specified in [2] creates no new
   usage.)  Similarly, an endpoint in a dialog established with an
   INVITE might subscribe to its peer's Key Press Markup Language (KPML)
   [3] and later issue a REFER, resulting in three dialog usages sharing
   common dialog state.


So the first question is if an RFC 6665 compliant UA indicated either Require: norefersub or knows that the REFER recipient supports norefersub and also indicates Refer-Sub: False in the REFER request  can that REFER request be sent on a dialog created by another Method (in the safe knowledge that no subscription will be created)?

If the answer to the first question is no - an implicit subscription could still be created.

Can some other knowledge that the REFER recipient will not create an implicit subscription - such as the definition in another specification outside of IETF of a feature that mandates that no subscription be created by the REFER recipient and the indication of the support of such a feature by the REFER recipient in a global tree media feature tag has been received by the REFER sender. Does this allow an RFC 6665 UA to send the REFER on a dialog created by another Method?

I have discussed the issue with Adam Roach offline and his view and mine is that RFC 6665 UAs do not send REFER requests sent on a dialog created by another Method except for interoperability with UAs that don't support GRUU and RFC 6665.

What is the view of the rest of the community?

Andrew
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.