Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-clarifications-04.txt

From: Adam Roach <[email-masked]>
Date: Tue, 21 Oct 2014 12:00:01 -0500

[as participant]

On 8/19/14 07:13, OKUMURA Shinji wrote:
> If the 6665 compliant UAS supports REFER, then
>   1) In a dialog created by INVITE, a local Contact of the UAS MUST be GRUU.

This is actually a clarification for RFC 6665, not REFER. I still owe 
the WG a draft clarifying exactly this point, and apologize for being 
rather deeply behind on coming up with this.

>   2) If the UAS supports a scenario for a transfer, then it SHOULD support tdialog.

This is a good point; I believe it should be couched in terms of 
pointing out that both referers and referees compliant with 6665 are 
bound by section 6.5 of RFC 6665, and that the appropriate mechanism for 
REFER is RFC 4538. (RFC 6665 implies that it expects event packages to 
call this out explicitly, so I think that including it in the 
clarifications document would be good form)

>   3) When the UAS receives REFER within the dialog, if referer supports tdialog,
>      then the UAS MAY respond by 3xx "Extension Required" with "Required: tdialog" and "Contact: GRUUofReferee",
>      else the UAS MAY accept the REFER.

It looks like you're trying to add behavior to RFC6665 referees to force 
pre-RFC6665 referers that support tdialog (but have elected not to use 
it) to use it. I'm not sure this adds much value -- the prospect that a 
client would know how to do this but decide not to seem kind of slim -- 
but I don't really see any harm.

>   4) When the UAS receives REFER out of the dialog, UAS MAY accept the REFER.

I'm not sure this needs to be said. I think it's reasonable to assume 
that it would accept the REFER, subject to its local policy. Adding 
words to reiterate obvious behavior makes the document longer, and 
therefore worse.

>   1) If a UAS's local Contact inside an existing dialog is gruu, then the 6665 compliant UAC MUST use REFER out of dialog.

There's been a lot of discussion around this wording, and the desire 
seems to be to leave the door open for the explicit subscription 
mechanism that Robert is also working on. The resulting text is the 
first sentence of section 4. It basically says the same thing as you're 
proposing, except that it doesn't need to be updated by the explicit 
subscription mechanism.

>   2) If the UAC supports a scenario for a transfer, then it SHOULD support tdialog.

This is covered by (2), above.

>   3) If a UAS does not support both of gruu and tdialog, then the 6665 compliant UAC MAY use REFER within dialog.

I think this is covered adequately in the final paragraph of section 4.

>   4) If a UAC received 3xx "Extension Required" response for REFER that contains "Required: tdialog",
>      then UAS MAY send REFER out of dialog. The REFER request SHOULD contain "Targer-Dialog" header.

This seems to be trying to impose requirements on legacy, already 
deployed clients. I'm not sure how it provides any value without the use 
of a time machine.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2014 14:08:48 -0400

I'd like some clarity on what "must use a gruu" means.
Does this mean the contact must have a "gr" parameter, or only that it 
must be globally routable? (Note that 3261 has always required contact 
URIs to be globally routable.) The key difference is that with a "gr" 
parameter the other end can verify that the uri has been asserted to be 
globally routable.

	Thanks,
	Paul

On 10/21/14 1:00 PM, Adam Roach wrote:
>>      then the UAS MAY respond by 3xx "Extension Required" with
>> "Required: tdialog" and "Contact: GRUUofReferee",
>>   1) If a UAS's local Contact inside an existing dialog is gruu, then
>> the 6665 compliant UAC MUST use REFER out of dialog.
>
>>   3) If a UAS does not support both of gruu and tdialog, then the 6665
>> compliant UAC MAY use REFER within dialog.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Oct 2014 09:01:57 -0500

On 10/21/14 13:08, Paul Kyzivat wrote:
> parameter the other end can verify that the uri has been asserted to 
> be globally routable.

I'm using GRUU as a shorthand for "the mechanism described in RFC5627" 
because it's easier to type. I think applying the term "GRUU" to other 
kinds of URIs, regardless of their routing properties, is going to muddy 
the waters, and make it nearly impossible to talk about the RFC5627 
mechanism.

In any case, the global routability of Contacts hasn't been true in a 
formal sense since the introduction of RFC3327, and hasn't been true in 
a practical sense since the introduction of NATs. We can't rely on it 
being true; and, in fact, it's going to be false in the vast majority of 
cases unless RFC5627 is employed.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Oct 2014 10:45:31 -0400

> cases unless RFC5627 is employed.

My concern is not with generic user endpoints, but with servers managed 
by enterprises or service providers. For instance a conference focus. 
These may have well known URIs, but they don't get them via registration.

RFC5627 does cover these - they are called self-made GRUUs. It does call 
for these to be marked with a "gr" parameter.

So then in practice, the requirement is that the contact have a "gr" 
parameter, and conform to RFC5627 for use of that.

	Thanks,
	Paul