Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments

[Brett Tate <[e-mail]>]

> >> Was that text problematic for you?
> > The proposal continues to mandate that the option-tag only be honored
> > if received within a Require header of REFER.
> >
> > If REFER is received within dialog, mandating that the UAS return a
> > 421 appears to do nothing but require extra messaging for those
> > attempting to use it.  I recommend allowing behavior similar to RFC
> > 3262 so that the option tag can be within Supported of mid-dialog
> > REFER and Require of REFER's 2xx response.
>
> We _specifically_ avoided that design. It takes us into the "I don't
> know if this will create a subscription or not when I send the REFER"
>territory.

If referrer sends a REFER within dialog without using the Require, they know
that it might create a subscription since they don't know if the option-tag
is supported.  The 2xx response can indicate if it did create a subscription
by supplying Require indicating what occurred.

If the desire is to allow RFC 6665 compliant device to send REFER over
dialog during GRUU situation, they would need to use the Require (AFAIK).

I still haven't noticed how the draft avoids RFC 6665 compliant notifier
from needing to supply GRUU Contact within call dialog.


> You have Supported around _before_ you get to sending the REFER
> require to help you avoid discovering lack of support by trying to
> require it if you care about that extra messaging.

If the REFER was sent within dialog, the lack of support/use would be
observed by receiving REFER's 2xx response without Require option-tag.

The referrer can use Require when REFER sent outside of dialog (or within
dialog if desired) if they want to avoid ambiguity during forking situation.

Thanks,
Brett