Subject: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-00

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 26 Jan 2015 12:55:06 +0000

Hello,

The new version seems nearly OK. I still have one comment, but the rest is fine.

COMMENT:

[I-D.roach-sipcore-6665-clarification] states what the UA does when the UA becomes a notifier. In particular case of REFER, this applies only when the UA accepts a REFER creating an implicit subscription.

Moreover, the text of 3rd paragraph of section 3 duplicates too much of the details given by [I-D.roach-sipcore-6665-clarification].

Thus, I suggest that we change the following statement of section 3:
-----------------
   A UA that will accept a REFER request needs to include a GRUU in the
   Contact header field of all dialog-forming and target-refresh methods
   (such as INVITE) [I-D.roach-sipcore-6665-clarification].  
-----------------
to:
-----------------
   A UA that will become a notifier (e.g. by accepting an REFER request that creates a subscription) needs to include a GRUU in the
   Contact header field of dialog-forming and target-refresh methods as specified in [I-D.roach-sipcore-6665-clarification].  
-----------------

Kind regards

Ivo Sedlacek

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Jan 2015 14:01:16 -0600

Ivo -

Just to be sure, this seems to be a comment on refer-clarifications, not 
(as the subject says) explicit-subscription?

> Thus, I suggest that we change the following statement of section 3:
No, this change is not ok, and the current text is something we ground 
on quite a lot - this proposal risks taking us right back into that 
argument.

Remember that the document is written from the context of what is 
currently standardized, and as currently standardized the sender of the 
REFER has no way to know if the REFER will create a subscription, so it 
must include a GRUU.

The text we added to the introduction acknowledges that 3gpp has a 
private solution that won't create subscriptions as long as they don't 
end up talking to a non-3gpp endpoint, but it _can_ if a non-3gpp 
endpoint is involved. Again, without extension, a standard endpoint has 
to assume that it can become a notifier, and has to provide a GRUU.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Jan 2015 14:18:20 -0600

And I fell into one of the old traps in that old argument. Correction 
inline.

On 1/26/15 2:01 PM, Robert Sparks wrote:
> Ivo -
>
> Just to be sure, this seems to be a comment on refer-clarifications, 
> not (as the subject says) explicit-subscription?
>
>> [I-D.roach-sipcore-6665-clarification] states what the UA does when 
>> the UA becomes a notifier. In particular case of REFER, this applies 
>> only when the UA accepts a REFER creating an implicit subscription.
>>
>> Moreover, the text of 3rd paragraph of section 3 duplicates too much 
>> of the details given by [I-D.roach-sipcore-6665-clarification].
>>
>>     A UA that will become a notifier (e.g. by accepting an REFER 
>> request that creates a subscription) needs to include a GRUU in the
>>     Contact header field of dialog-forming and target-refresh methods 
>> as specified in [I-D.roach-sipcore-6665-clarification].
> currently standardized, and as currently standardized the sender of 
> the REFER has no way to know if the REFER will create a subscription, 
> so it must include a GRUU.
Sorry - that put the argument on the wrong foot, and I apologize again 
for falling into the older trap.

The issue, rather, is that if an agent might accept a REFER that would 
create a subscription at some point in the future, then it needs to 
include a GRUU as the contact of all of its dialog forming requests.

Given that, the issue with your above text is in the "will become" as 
opposed to "might become", because in general, it can't know.
(As we've discussed, with the 3gpp behavior, you can end up accepting an 
in-dialog refer becoming a notifier if you are working with a non-3gpp 
endpoint.)

I could accept the sentence you propose if we change "will become" to 
"can possibly become".
> endpoint is involved. Again, without extension, a standard endpoint 
> has to assume that it can become a notifier, and has to provide a GRUU.
>
> RjS
>> -----------------
>>
>> Kind regards
>>
>> Ivo Sedlacek
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 26 Jan 2015 14:49:31 -0600

On 1/26/15 14:18, Robert Sparks wrote:
>>>     Contact header field of dialog-forming and target-refresh 
>>> methods as specified in [I-D.roach-sipcore-6665-clarification].
>> No, this change is not ok, and the current text is something we 
>> ground on quite a lot - this proposal risks taking us right back into 
>> that argument.
>>
> (As we've discussed, with the 3gpp behavior, you can end up accepting 
> an in-dialog refer becoming a notifier if you are working with a 
> non-3gpp endpoint.)
>

I think that specific change is fine, although we seem to be splitting 
some pretty fine hairs here, and harming clarity in the process.

On the other hand, removing the "such as INVITE" phrase seems highly 
questionable -- I thought this was obvious in RFC 6665, but we later 
learned that people didn't fully connect the dots. It would seem the 
height of folly to repeat this specific mistake.

I believe the following text addresses the issue that Ivo has raised 
without any unnecessary editorial rejiggering: "A UA that might possibly 
become a notifier (e.g. by accepting a REFER request that creates a 
subscription) needs to include a GRUU in the Contact header field of 
dialog-forming and target-refresh methods (such as INVITE) 
[I-D.roach-sipcore-6665-clarification]."

/a

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 27 Jan 2015 08:05:46 +0000

Hello,

> I believe the following text addresses the issue that Ivo has raised without 
> any unnecessary editorial rejiggering: "A UA that might possibly become a 
> notifier (e.g. by accepting a REFER request that creates a
> dialog-forming and target-refresh methods (such as INVITE) [I-D.roach-sipcore-6665-clarification]."

Works for me. Thanks for taking my comments into consideration.

Kind regards

Ivo Sedlacek