Re: Comment on draft-roach-sipcore-rfc3265bis-00

Elwell, John wrote:
> I found little to comment on, apart from the following:
>
> In 4.5.1:
> "Notifiers MUST implement the GRUU extension defined in
>    [I-D.ietf-sip-gruu], and MUST use a GRUU as their local target."
>
> 1. Is this just for a SUBSCRIBE-initiated dialog or for any dialog?
>   

The intention is that any UA capable of sending a NOTIFY message in any 
context will use a GRUU for all dialogs. This mechanism is to be used 
instead of dialog re-use. The most common case of dialog re-use right 
now is sending a SUBSCRIBE down an existing dialog that was initially 
established by an INVITE. So, for current use cases, using GRUU in 
INVITE dialogs is the most important thing. For future-proofing, we need 
to require GRUU for all dialogs.

> 2. Should this be package-dependent? For example, there may be some
> event packages for which there is no need for subscribing to a resource
> on the same device.
>   

I think it's likely to be too difficult to guess, ahead of time, which 
packages will never need to target the same device as another dialog. 
It's far too easy to envision a circumstance in which we say, "I can't 
think of any reason someone would need to target a specific device for 
package foo," only to discover a really clever usage several years later 
that we have accidentally precluded.

> 3. What if the registrar doesn't support GRUU, and therefore the
> notifier is unable to obtain a GRUU?
>   

Note, first of all, that this constraint is placed on notifiers, and not 
on subscribers. For the vast majority of notifiers, a self-made GRUU 
(which requires no registrar support) is appropriate.

However, your point is taken, and we should discuss circumstances in 
which registering clients that send NOTIFY messages request a GRUU from 
their registrar, yet receive none. Because of the true interoperability 
nightmare that has resulted from dialog sharing, my suggestion would be 
to disable notifier functionality on those endpoints under such 
circumstances (perhaps with an implementation option to fall back to 
3265 behavior for the truly masochistic).

> And by the way, in appendix C I didn't see a mention of changes relating
> to the use of GRUU.
>   

Sorry about that. My intention was to include that as part of C.1.21, 
but I left it out.

/a
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip