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

[Adam Roach <[e-mail]>]

[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