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

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 4 Nov 2014 13:24:23 +0000

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 06 Nov 2014 14:19:00 -0600

On 11/4/14 7:24 AM, Ivo Sedlacek wrote:
> 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:
> 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.
> 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:
>
> ------------------
>
> 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:
>
> ------------------
>
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:
See Adam's earlier response and the 6665 clarifications draft.

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 12 Nov 2014 15:25:35 +0000

Hello Robert,

please see below.

COMMENT 1:

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

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

PROPOSED SOLUTION 1:

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

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

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

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

PROPOSED SOLUTION 2:

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

------------------
Same as 1:

[Ivo]

Same as 1:

COMMENT 3:

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

Section 3 states "

   the REFER request.

"

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

   the REFER request.

"

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

COMMENT 4:

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

Section 3 states "

   implicit subscription.

"

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

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

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

COMMENT 5:

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

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

PROPOSED SOLUTION 5:

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

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

"

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

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

PROPOSED SOLUTION 6:

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

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

Kind regards

Ivo Sedlacek