Subject: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter

From: [email-masked]
Date: Thu, 31 Aug 2006 22:20:19 -0400

From: "Vijay K. Gurbani" <[email-masked]>

   [email-masked] wrote:
   > It would help a lot if we had a standardized terminology, but RFC 3261
   > didn't establish one.  At my company, we've used these terms:
   > 
   > 	Contact:  <[email-masked];bar=1?Baz=2>;quux=3
   > 
   > "bar" is a "URI parameter"
   > "Baz" is a "header parameter"
   > "quuz" is a "field parameter"

   RFC 3261 does try to use the same terminology, except that
   the use of "header" is overloaded.  For instance, what you
   refer to as a "field parameter" above is actually termed
   as a "header parameter" in RFC 3261 in a very consistent
   manner.  In fact, Section 20.10 attempts to make a distinction
   between a URI parameter and a header parameter.

You're right, and I'd not spotted that.  Though a quick search showed
a couple of uses of "header parameter" where they must have meant
"header field":  page 122, line 21; and page 157, end of section
19.1.5.

   Unfortunately, rfc3261 also calls the construct "?Baz=2" as a
   header.  That is what I think is problematic, since "Contact"
   is a header as well.

RFC 3261 is consistent in calling those things "header fields".  I
don't understand why, as they're called "headers" in HTTP and SMTP,
which is where the concept is taken from.  Anybody have the background
on that?

It's unfortunate that 3261 didn't include a glossary of such syntactic
terms.

Dale

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Sep 2006 09:39:44 -0400

I think this is reasonable. Note that this would break backwards 
compatibility of this version of the spec with all previous versions. 
Generally IETF does not guarantee backwards compatibility when a 
document is still in I-D version (and indeed not for revisions of an RFC 
either...). This spec has been around a while though so I want to make 
sure people are OK with it. I don't think its been widely implemented 
yet though, as SBCs have mostly filled this need so far.

I would suggest:

;gr be the URI parameter which signals that the URI is a GRUU, analagous 
to ;lr.

;gruu be the Contact header field parameter which conveys the gruu 
assigned to you in the REGISTER response.

So, a REGISTER resposne would look like in part:

SIP/2.0 200 OK
Contact: <sip:10.0.1.1>;gruu="sip:[email-masked];gr;opaque=asdasdasd"

Thanks,
Jonathan R.

Cullen Jennings wrote:

> 
> On Aug 21, 2006, at 1:26 PM, Robert Sparks wrote:
> 
>> Right now, the mechanism is creating a header parameter and a URI  
>> parameter with the same name : "gruu".
>>
>> Thinking about this from the perspective of debugging things in a  
>> lab, or worse, over VoIP or an IM, I envision
>> many, many conversations that will take this form:
>>
>> A: I see the problem - it's in the gruu parameter.
>> B: Ok - I'll change that
>> (retry)
>> A: It's still broken - I don't see what you... Oh wait - I didn't  
>> mean _that_ gruu parameter, go
>>      change the other one.
>> B: Oh crud - was it the header parameter or the URI parameter? (and  
>> which one of those is outside
>>      the <>'s? I can never keep that straight...)
>>
>> For the sake of sanity (at least mine), could we please reconsider  
>> giving these things different names?
> 
> 
> Add my plea for consideration to Robert's - implementors are confused  
> enough about the difference between header parameters and uri  
> parameters without us adding to the confusion.
> 
> It's not like gruu is such an intuitively descriptive acronym that  
> nothing else could make sense, we could have gruu and groovy :-)
> 
> 

-- 
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

---

From: [email-masked]
Date: Tue, 19 Sep 2006 10:51:46 -0400

From: Jonathan Rosenberg <[email-masked]>

   I would suggest:

   SIP/2.0 200 OK

This seems reasonable to me, as it avoids the confusion as previously
mentioned, and makes the URI shorter.

In re backward compatibility, the only loss is that an implementation
that looks for "gruu" on URIs will be unable to detect that the new
GRUUs are GRUUs.  But it's not clear that any implementation does that
yet.

Dale