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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

> >>>> 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.
> So, there are two things I think you're trying to talk about. I'm going
> to draw lines around them just to double-check that I'm hearing
> you correctly.
>
> First is the suggestion to change how we're using Supported/Require.
>
> I don't understand yet why you would _want_ to send a REFER
> with Supported: explicitsub and learn later whether the other
> side chose to use an implicit subscription or an explicit subscription,
> signaled in the 200 OK to the REFER.
>
> Essentially, you are positing "I don't care as a client, you choose
> as the server". I don't think we have a need for that, and trying
> to support something like it is what led norefersub to being
> what it is.

That is not my proposal.  If the client cares, they can use Require or not
include option-tag within Supported.  My proposal is that if the client sent
mid-dialog REFER with Supported indicating one or both new option-tags,
there is no reason to mandate returning 421 if the UAS desires to use the
feature.

Why do you want to restrict the functionality so that it can only be used if
option-tag sent within REFER's Require header?  The working group (and RFC
4485) typically discourages the use of Require within requests unless truly
needed.  Depending upon interpretation of RFC 4485's "basic SIP services",
the use of Require is potentially "NOT RECOMMENDED".


> When you are in a dialog, you have the opportunity to see that the
> extension
> is supported before you start preparing your in-dialog refer by watching
> Supported in the transactions earlier in the dialog. If your peer hasn't
> been
> playing nicely and telling you about what it supports, you can probe by
> sending the REFER with the require and see the 421. That is not new
> behavior
> defined by this draft
> - it's basic 3261.

I agree.  However, it isn't basic SIP to restrict option-tag related
functionality to only occur when the request uses the Require header unless
there is truly a need for the restriction.


> Our case here is different from 100rel. The semantic there is that the
> server
> gets to invoke _using_ the extension because it's the thing that knows
> whether the extension is needed. It's been a fundamental point of this
> proposal from the beginning that this is a decision that the client is
> going to
> make.

If they want/have to make the decision, they can use the Require.  If they
don't want/need to decide, they should be able to use Supported within
mid-dialog REFER without requiring the subsequent 421 to occur.


> > 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).
> If I'm reading you correctly, your second comment is that the draft isn't
> clear
> enough that if you are requiring explicitsub (or nosub), the REFER request
> itself isn't bound by the requirements of 3265 since its contact isn't
> used in
> setting up a subscription. I'll go look at the draft between meetings (I'm
> in
> other sessions right now), and see if I can pump that up.

The draft might be adequate from referrer perspective (I didn't perform a
detailed search).  However as indicated below, I haven't noticed how the
draft enables a RFC 6665 compliant notifier from needing to supply GRUU
Contact within call dialog (i.e. as mentioned within
draft-sparks-sipcore-refer-clarifications-05 section 3 last paragraph).


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