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

[Ivo Sedlacek <[e-mail]>]

Hello Robert,

please see below.



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.


[Ivo]
The document needs to be correct as well as clear.

Omitting the one case results to incorrect document.

To me, your statement ".... doesn't help with the clarity of this document." is comparable with a judge stating to an accused: "There is one possibility that you are innocent. However, describing it in judgement doesn't help with the clarity of the judgement. So, I declare you guilty instead.".


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:


[Ivo]

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.

[Ivo]
"The new 6665 clarifications draft may address it more strongly." seems to suggest that the comment above is actually correct, i.e. RFC665 does not contain such statement, and new 6665 clarifications draft  is necessary to make it.




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

[Ivo]
Well, this draft states this requirement and therefore it can be questioned.

Yes, the same comments can be raised against the "6665 clarifications draft" but that does not make this document correct.




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.

[Ivo]
The text is inconsistent.

The reader will wonder why:
- the 1st paragraph prohibits dialog reuse if the remote UE provided GRUU; and
- the 2nd paragraph requires out-of-dialog REFER regardless of whether the remote UE provided GRUU.





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.

[Ivo] Again, this document refers to RFC6665 and RFC6665 does not state it.



PROPOSED SOLUTION 6:

------------------

Clarify the need for this requirement or remove it.

------------------



Kind regards



Ivo Sedlacek