Subject: Re: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00

From: Adam Roach <[email-masked]>
Date: Fri, 27 Feb 2015 17:57:27 -0600

On 11/14/14 08:29, Brett Tate wrote:
> I agree with Ivo's comments.
>
> ---
>
> From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
> Sent: Thursday, November 13, 2014 4:16 AM
> To: [email-masked]
> Subject: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00
>
> (a small extension below)
>
> Hello,
>
> I reviewed the draft and here are my comments:
>
> COMMENT 1:
> -------------------------------------------------
> Section 1 states:
> ==============================
>    The second sentence of this paragraph attempted to set context for
>    the normative statement: the reason GRUUs are required in this
>    context is to allow you to send SUBSCRIBE or REFER requests to a
>    specific user agent, with the target of the subscription request
>    being something like an INVITE dialog on that device.  Consequently,
>    the requirement to include a GRUU as a local target applies not just
>    to the local target for SUBSCRIBE-created dialogs, but for *all*
>    dialogs, even those created by INVITE.
> ==============================
>
> UA can have dialogs for which the UA rejects any related out-of-dialog
> REFER request (and any out-of-dialog SUBSCRIBE request).
> Those dialogs are simply not transferrable (and not subscribeable).
> Requiring GRUU for such dialogs is unnecessary.
> -------------------------------------------------
>
> PROPOSED SOLUTION 1:
> -------------------------------------------------
> Restrict the requirement above to only dialogs for which the UA is willing
> to accept an out-of-dialog REFER request (or any out-of-dialog SUBSCRIBE
> request).

Sounds good to me, except that 6665 deprecates in-dialog subscriptions.

So this really reduces to a request to restrict the requirement to use a
GRUU only to those dialogs about which a subscription might be created.
That sounds reasonable, if a bit obscure. I will note that we have to
require such implementations to actually reject subscription requests to
any dialogs that they didn't use a GRUU for a local contact. Otherwise,
they'll trigger the "pre-6665 compatibility mode" behavior of the other
client, and that kind of defeats the purpose of untangling dialogs from
each other (which was a key motivation for publishing RFC 6665 in the
first place).

/a