Re: [sipcore] Comments to draft-sparks-sipcore-refer-clarifications-05.txt

[Robert Sparks <[e-mail]>]

On 11/4/14 7:24 AM, Ivo Sedlacek wrote:
>
> Hello,
>
> I reviewed the draft-sparks-sipcore-refer-clarifications-05 and here 
> are my comments:
>
> COMMENT 1:
>
> ------------------
>
> Abstract states "An accepted SIP REFER method creates an implicit 
> subscription using the SIP-Specific Event Notification Framework."
>
> This is only partly true since creation of implicit subscription do 
> not necessarily happen when 
> draft-sparks-sipcore-refer-explicit-subscription is used or when 
> RFC4488 is used (assuming application specific logic ensures that the 
> implicit subscription is not created).
>
> ------------------
>
> PROPOSED SOLUTION 1:
>
> ------------------
>
> State: "An accepted SIP REFER method >>can<< create an implicit 
> subscription using the SIP-Specific Event Notification Framework."
>
> ------------------
>
Hrmm - this is effectively the same feedback you sent earlier on 
sentences like this in the document (but thanks for the cleaner proposed 
text).

My response then (and now) is that accounting for the one case where you 
can ask (but not be guaranteed)
to suppress the subscription doesn't help with the clarity of this document.

I'd like to hear from others in the group.
Do you want to find a way to call out this case, or leave the text as is?
I would prefer to leave the text alone.
If we change it, I don't think this proposal is the right one yet. "Can" 
understates the issue significantly.

> COMMENT 2:
>
> ------------------
>
> Section 2 states "An accepted SIP REFER method creates an implicit 
> subscription using the SIP-Specific Event Notification Framework."
>
> This is only partly true since creation of implicit subscription do 
> not necessarily happen when 
> draft-sparks-sipcore-refer-explicit-subscription is used or when 
> RFC4488 is used (assuming application specific logic ensures that the 
> implicit subscription is not created).
>
> ------------------
>
> PROPOSED SOLUTION 2:
>
> ------------------
>
> State: "An accepted SIP REFER method >>can<< create an implicit 
> subscription using the SIP-Specific Event Notification Framework."
>
> ------------------
>
Same as 1:
>
> COMMENT 3:
>
> ------------------
>
> Section 3 states "
>
>    Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to
>
>    implement and use as the local target in the subscription created by
>
>    the REFER request.
>
> "
>
> In RFC6665, usage of GRUU is mandatory for notifier (">>Notifiers<< 
> MUST implement the Globally Routable User Agent URI (GRUU) extension 
> defined in [RFC5627], and MUST use a GRUU as their local target."), 
> while the statement above could be understood to refer to both 
> subscriber and notifier.
>
> ------------------
>
I think Adam tried to address this in an earlier response. The new 6665 
clarifications draft may address it more strongly.
>
> PROPOSED SOLUTION 3:
>
> ------------------
>
> State: "
>
>    Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to
>
>    implement and use as the local target >>by notifiers<< in the 
> subscription created by
>
>    the REFER request.
>
> "
>
> ------------------
>
> COMMENT 4:
>
> ------------------
>
> Section 3 states "
>
>    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.
>
> "
>
> The UA might be globally reachable without indicating GRUU - this is 
> common today with network conference servers. Requiring GRUU is 
> unnecessary.
>
> ------------------
>
Again, see Adam's 6665 clarifications draft (and please take any 
argument with it to the list under that name as a subject, not this draft).
>
> PROPOSED SOLUTION 4:
>
> ------------------
>
> Make the statement general to state that the UA must provide URI which 
> is a globally reachable in the Contact of INVITE requests.
>
> ------------------
>
> COMMENT 5:
>
> ------------------
>
> Section 4, 1st paragraph and 2nd paragraph provide overlapping 
> information.
>
> In 1st paragraph, there is a statement that if remote UA provided a 
> GRUU as its local target then a user agent sending a REFER request 
> (towards that target) that could result in an  implicit subscription 
> within a dialog is prohibited.
>
> In 2nd paragraph, the same is stated (in positive way) regardless 
> whether the remote UA provided a GRUU as its local target or not.
>
> ------------------
>
> PROPOSED SOLUTION 5:
>
> ------------------
>
> Remove the 1st paragraph of section 4.
>
> ------------------
>
I can almost see the overlap you are talking about, but I don't see 
where that introduces any weakness into the text.
Removing the paragraph is not the right thing to do. The first paragraph 
describes the prohibition, the second talks
about what's left that you can do. The document is less accurate if you 
leave either point out.
>
> COMMENT 6:
>
> ------------------
>
> Section 3 states: "
>
>    A user agent constructing any REFER that can result in an implicit
>
>    subscription MUST populate its Contact header field with a GRUU.
>
> "
>
> In RFC665, there is no such requirement for subscriber. Why do we 
> state such new requirement?
>
> ------------------
>
See Adam's earlier response and the 6665 clarifications draft.
>
> PROPOSED SOLUTION 6:
>
> ------------------
>
> Clarify the need for this requirement or remove it.
>
> ------------------
>
> Kind regards
>
> Ivo Sedlacek
>