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

[Ivo Sedlacek <[e-mail]>]

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

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



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

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



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.

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



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.

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



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.

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



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?

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



PROPOSED SOLUTION 6:

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

Clarify the need for this requirement or remove it.

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



Kind regards



Ivo Sedlacek