Subject: [Sip] GRUU text around modification of URI parameters

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

During the Prague IETF, I discussed a change I made in GRUU-12. I had 
combed through Dale Worleys implementing GRUU draft, and extracted two 
items from it which seemed more appropriate in the GRUU spec itself. One 
of them had to do with UA's treating the GRUUs as opaque. COnsequently, 
this text made it into GRUU-12:

   The GRUU learned by the UA in the REGISTER response MUST be treated
    opaquely by the UA.  That is, the UA MUST NOT modify it in any way
    (including adding or removal of URI parameters).

During the meeting, Adam Roach correctly pointed out that these words 
would prohibit UA loose route:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt
from working. That draft meets our charter goal of delivering params to 
a UA by allowing a UA to insert params of its own choosing into the 
GRUU. OOps.

So, I took an action item to look over the URI parameters and make a 
more concrete recommendation on which URI parameters were subject to 
manipulation by a UA. I went through the IANA registry of URI params and 
here is the text I came up with:

<t>
The user and host parts of the GRUU learned by the UA in the REGISTER 
response
MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them
in any way. Furthermore, the UA MUST NOT add or remove URI parameters
relevant for receipt and processing of request at the proxy, including
the transport, lr, maddr, ttl, user, and comp <xref target="RFC3486"/>
parameters.
</t>

This is more or less all of the URI parameters from 3261, excepting 
header field, body, and method params, which I think are inappropriate 
for GRUU anyway. It also omits the URI params registered by RFC 4458 and 
RFC 4240 (the voicemail URI and netann specs). Again I think those make 
no sense here.

I've put the above text into my working -13. Unless someone objects I'll 
consider this issue closed.

Thanks,
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: Thu, 29 Mar 2007 12:57:22 -0500

From: Jonathan Rosenberg <[email-masked]>

   <t>

I'd like to know your interpretation of this issue from a different
perspective.  It seems to me that the baseline situation is that *all*
URI parameters should be treated as opaque unless there is a good
reason to consider them not so.  So instead of enumerating the
parameters that cannot be modified by an agent that is not
authoritative to mint URIs for a domain, enumerate the ones that
*can*.

For instance, the method URI parameter seems acceptable, as it is
well-defined what the implications of changing it are in any
circumstance.  But that isn't an interesting case in the GRUU context,
I don't think.

Indeed, are there any parameters which should be generally modifiable
and are also useful in the GRUU context?

Dale

---

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

At the moment I'd say there are no parameters that are usefully 
modifiable by a client. However I think its easier if the text be 
explicit both ways - saying what you can and cannot modify. I'm fine to 
add a sentence which further notes that the other URI parameters just 
aren't useful to manipulate.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Mar 2007 16:22:01 -0500

Can that sentence say "other already standardized URI parameters" or  
something along those lines?

RjS

On Mar 29, 2007, at 4:10 PM, Jonathan Rosenberg wrote:

> explicit both ways - saying what you can and cannot modify. I'm  
> fine to add a sentence which further notes that the other URI  
> parameters just aren't useful to manipulate.
>
> -Jonathan R.
>
>>    The user and host parts of the GRUU learned by the UA in the  
>> REGISTER    response
>>    This is more or less all of the URI parameters from 3261,  
>> excepting    header field, body, and method params, which I think  
>> are inappropriate    for GRUU anyway. It also omits the URI params  
>> registered by RFC 4458 and    RFC 4240 (the voicemail URI and  
>> netann specs). Again I think those make    no sense here.
>>    I've put the above text into my working -13. Unless someone  
>> objects I'll    consider this issue closed.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Mar 2007 09:16:52 -0400

Well, that won't work once UA-loose-route progresses and we end up with 
standardized URI parameters that it is supposed to modify. So I want to 
be explicit about every parameter known at this time, with general 
guidance on future ones.

-Jonathan R.

Robert Sparks wrote:

>> explicit both ways - saying what you can and cannot modify. I'm  fine 
>> to add a sentence which further notes that the other URI  parameters 
>> just aren't useful to manipulate.
>>
>> -Jonathan R.
>>
>>> registered by RFC 4458 and    RFC 4240 (the voicemail URI and  netann 
>>> specs). Again I think those make    no sense here.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Mar 2007 09:27:25 -0400

Actually, let me clarify here.

None of them are usefully MODIFIABLE. However, a whole bunch are 
usefully added. In particular, the ones defined in RFC 4240 and RFC 
4458. SO imagine a UA that wants to be a voicemail server, so it gets a 
GRUU from its registrar and can add the parameters defined in those two 
RFC to its GRUU, before handing the URI out to someone else.

THis works great, except that the proxy will strip all such parameters 
when the r-uri is translated to the registered contact. Well, thats what 
UA loose route is for, and once that problem is fixed, adding these and 
other parameters makes sense.

So, I updated the text to say this:

<t>
The user and host parts of the GRUU learned by the UA in the REGISTER 
response
MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them
in any way. Furthermore, the UA MUST NOT add, remove or modify URI 
parameters
relevant for receipt and processing of request at the proxy, including
the transport, lr, maddr, ttl, user, and comp <xref target="RFC3486"/>
parameters.  The other parameter defined in RFC 3261 - method, would
not typically be present in a GRUU delivered from a registrar, and a
UA MAY add a method parameter to the GRUU before handing it out to
another entity. Similarly, the parameters defined in RFC 4240 <xref
target="RFC4240"/> and RFC 4458 <xref target="RFC4458"/> are meant for
consumption by the UA. These would not be included in the GRUU
returned by a registrar and MAY be added by a UA wishing to provide
services associated with those parameters. Note, however, that should
another UA dereference the GRUU, the parameters will be lost at the
proxy when the Request-URI is translated into the registered contact,
unless some other means is provided for the attributes to be delivered
to the UA. Mechanisms for such delivery are currently the subject of
future standardization activity <xref
target="I-D.rosenberg-sip-ua-loose-route"/>.
</t>

OK?

-Jonathan R.

Jonathan Rosenberg wrote:

>>    header field, body, and method params, which I think are 
>> inappropriate    for GRUU anyway. It also omits the URI params 
>>    I've put the above text into my working -13. Unless someone objects 
>> I'll    consider this issue closed.
>>

---

From: [email-masked]
Date: Fri, 30 Mar 2007 17:35:50 -0500

What I'm looking for is "default" guidance -- If a device sees a URI
parameter that it doesn't recognize, should the general policy be to
treat it opaquely?  I think that we're getting muddled by not having
an overall philosophy.  Once we do that, the particular deviations
required within GRUU will probably be small, and they will be
"obvious".

Dale