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

[Robert Sparks <[e-mail]>]

Replying to the other section of this mail (and snipping the part I just 
replied to):

On 11/14/14 8:00 AM, Brett Tate wrote:
> Hi,
<snip/>
>> This is confused, or I'm not following what you're looking for yet.
> Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the
> following.
>
> "A UA that will accept a REFER request needs to include a GRUU in the
>   Contact header field of all INVITE requests.  This ensures that out-
>   of-dialog REFER requests corresponding to any resulting INVITE
>   dialogs arrive at this UA.  Future extensions (such as
>   [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this
>   requirement by defining a REFER request that cannot create an
>   implicit subscription."
>
> If something within draft-sparks-sipcore-refer-explicit-subscription allows
> a RFC 6665 compliant notifier to not supply a GRUU Contact within call's
> dialog, please clearly indicate it.  For instance if the following is true,
> indicate that the notifier is not required to supply a GRUU Contact if
> notifier supports 'nosub' (even if referrer does not support 'nosub').
Ah - ok - I think I understand, and I think I can build clearer text.

Nothing in draft-sparks-sipcore-refer-explicit-subscription will allow
an RFC 6665 compliant notifier to not supply a GRUU Contact withing a call's
dialog. What it does do is allow that endpoint to avoid becoming an RFC6665
notifier in the context of this dialog.

The statement about relaxing needs to make it clear that since the REFER
request cannot create an implicit subscription, accepting it doesn't 
make you
a notifier. In fact, SIP events is not involved at all, so none of 
requirements
in 6665 don't come to bear. I'll work on building words that makes that 
more obvious.

>
> Thanks,
> Brett