Subject: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Mar 2007 10:57:32 -0400

There is a debate going on buried in a separate thread that I wanted to 
escalate to a new post and a new thread, so folks who have not noticed 
the other thread can participate.

Since around gruu-06, the registrar will construct a GRUU for an 
endpoint that includes an instance ID in its REGISTER request, even if 
it omitted Supported: gruu (and thus does not itself support GRUU). This 
allows other entities to learn the GRUU through other means, such as 
reg-event, and then direct a request to that UA instance, even if the UA 
instance itself doesn't support GRUU.

A complaint has been raised that this is inconsistent. Should an entity 
use that GRUU, learned by reg-event, the request will be delivered to 
the UA instance, but it will include a non-GRUU in its Contact, and so 
from then on, GRUU-enabled features like transfer won't work since the 
UA doesn't support GRUU. The argument was made that this is effectively 
false advertising since GRUU isn't REALLY supported for this UA.

I disagree with this perspective and believe that the current text in 
gruu-13 is fine. I believe our ability to generate GRUU even if the UA 
doesn't understand GRUU is a feature and not a bug.

I'd like to settle this in the next few days so I can submit gruu-13 and 
we can move on to other pressing issues, like rehashing our debate on 
the viability of sips. Again.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: [email-masked]
Date: Wed, 28 Mar 2007 17:12:11 -0500

From: Jonathan Rosenberg <[email-masked]>

   the UA instance, but
   [the response] will include a non-GRUU in its Contact, and so 

I agree with you and Peter that this is not a bug.

1) This situation causes no additional failures relative to the
   situation where the registrar does not construct a GRUU for the
   non-GRUU-supporting UA.

2) It's not false advertising if the UA making the initial contact is
   paying attention -- the response does not contain "Supported:
   gruu", and the Contact it provides in the response is
   self-evidently not a GRUU (due to the absence of the "gr"
   parameter).

3) Indeed, if the UA making the contact desires a GRUU for the other
   UA, and the Contact in the response is not a GRUU, *the UA already
   has a GRUU for the other UA in hand*.  Being self-evidently a GRUU,
   it can be safely used for all GRUUish needs.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 10:00:48 -0400

Thanks for chiming in Dale.

So, so far I have three folks saying its a feature (myself, Dale, Peter) 
and Michael saying its a bug but he is willing to drop the issue. I'll 
give people another day or so, but unless anyone pipes up I think we can 
close this issue.

There remains the issue on specific text around record-routing, please 
see my other note on the proposed text.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Mar 2007 14:01:08 -0400

> give people another day or so, but unless anyone pipes up I think we can 

Well, it got the way it is because of me, and I stand by it.

	Paul

>>    A complaint has been raised that this is inconsistent. Should an 
>> entity    use that GRUU, learned by reg-event, the request will be 
>> delivered to    the UA instance, but
>>    UA doesn't support GRUU. The argument was made that this is 
>> effectively    false advertising since GRUU isn't REALLY supported for 
>> this UA.
>>