Subject: RE: [Sip] Propogating URI parameters end to end

From: [email-masked]
Date: Tue, 11 May 2004 10:30:31 +0300

A new header, or ever better, a body part would be more appropriate, IMO, to propagate peer-to-peer specific indicators.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Paul Kyzivat
> Sent: 11.May.2004 01:10
> To: Manjunath Bangalore
> Cc: [email-masked]; Prabhu, Prashanth
> Subject: Re: [Sip] Propogating URI parameters end to end
> 
> 
> Manjax,
> 
> Yes, this came up regarding the handling of GRUU. As things 
> stand with 
> 3261, you can't expect the parameters to be propagated. Extra 
> requirements were added to the GRUU draft to ensure that the grid 
> parameter is propagated.
> 
> I suppose a change could be made to 3261 to require propagating 
> parameters in general, but it isn't entirely clear that this would 
> always be the right thing to do. It is also not always 
> possible, because 
> the contacts that the proxy translates to needn't be sip 
> URIs. For other 
> kinds there is no guarantee that parameters are supported at 
> all, or if 
> so that propagating sip uri parameters would be the right thing to do.
> 
> This is one of the problems I have with using a uri parameter for 
> referencing uri lists in the exploder drafts.
> 
> I am inclined to leave things as they are - assuming that the 
> parameter 
> must have meaning to the owner of the address it is attached 
> to. If the 
> meaning of one or more parameters extends to propagating them to some 
> derived address then fine, but that isn't a general mechanism.
> 
> 	Paul
> 
> Manjunath Bangalore wrote:
> > Hi,
> > 
> > Consider a case where a  SIP UA initiates a request (Ex: INVITE), 
> > wherein the Request URI contains some user-defined URI 
> parameters that 
> > are to meant to be understood by the eventual UA 
> terminating the request 
> > -  Example:
> > 
> > INVITE [email-masked]; end_user_param=foo
> > 
> > How do we ensure that the user-defined URI parameter 
> accompanying the 
> > Request-URI is propogated to the terminating UA?
> > 
> > With a read of RFC 3261, I see in Sec 16.5, that when the 
> request lands 
> > on the Proxy that is responsible for the domain in the 
> Request-URI,  one 
> > of the ways it can generate a target set is by doing a 
> lookup using a 
> > Location Service, Ex: A SIP Registrar. Before a lookup is done, the 
> > Request-URI is required to be canonicalized, and during 
> this process, 
> > any URI parameters are dropped when contructing an index 
> for the lookup. 
> > While this canonicalization makes sense for the purpose of 
> the location 
> > service lookup, before the INVITE is forwarded to the URI 
> returned by 
> > the Location service, wouldn't it be right to append the 
> original URI 
> > parameters to it,  in order to preserve them.
> > 
> > On a related note, the GRUU draft requires a Proxy in a 
> target domain to 
> > pass the "grid" URI parameter(grid=foo) that is received 
> alongside the 
> > Request-URI.
> > 
> > Unless I am missing something, are there any issues with adding a 
> > statement to RFC 3261, that explicitly states that any URI 
> parameters 
> > present in the Request-URI must be forwarded.
> > 
> > Thanks,
> > -Manjax
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Tue, 11 May 2004 11:59:20 -0700

It's an interesting thing. In the case of the netann draft, and some other
things, we as the WG seem to take the opinion that SIP can do service
invocation and the way to pass parameters to the services is using URL
parameters.  New headers for specific services have been discouraged.
I actually think this is a pretty good idea.

Yet here we have a clear problem with doing service invocation using the
request URI. I don't see any harm of in fixing this. I think I would be in
favor of suggesting that, unless a proxy has a reason to remove parameters
in a retarget, it should leave them alone.

Alternatively, we could take the position that parameters should not be
used, we should get rid of them and use headers instead. But we should pick
one of the other not block both either from happening.

Cullen

On 5/11/04 12:30 AM, "[email-masked]"
<[email-masked]> wrote:

> A new header, or ever better, a body part would be more appropriate, IMO, to
> propagate peer-to-peer specific indicators.
> 
> Regards,
> Hisham
>

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 12 May 2004 08:54:23 +0300

> one of the other not block both either from happening.

request uri is used for the purpose of routing the request.  any
parameters that don't aid for that purpose should not be included in
request uri.  also, as long as all routing related information possibly
needed by the next hop is preserved, proxies should be allowed to
rewrite the whole request uri.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 May 2004 02:22:58 -0400

URI parameters are, by definition, qualifiers for the uri. As such, the 
only thing you can know for certain is that the entity which interprets 
that URI (the one identified by the domain part of the URI) can 
understand and make sense of the URI parameters. If a server translates 
the URI and forwards it somewhere totally different, those parameters 
may not make sense. Its possible that they do make sense to the 
downstream entity, but such a determination is the responsibility of the 
owner of the URI - its part of the location service. Its not something 
the protocol can mandate, unlesss we start defining certain types of 
resources (as we did in the case of gruu).

If you want to convey information to the ultimate recipient, and that 
information makes sense regardless of who or what the ultimate recipient 
is, then that information doesnt belong as a URI parameter, it belongs 
as a header.

In the case of service invocation, I believe that the service invocation 
parmeters are specific to the resource identified in the URI, and so 
using URI parameters makes some sense. This gives people some heartburn, 
since they have this model in their head of having a media server use 
REGISTER to tell a proxy how to route calls to it, and the proxy would 
drop the URI parameters in such a translation.

However, in this case, REGISTER is an entirely inappropriate technique 
for populating the location service. Rather, the proxy should be 
provisioned with a mapping that makes sense for the media server, 
including which URI parameters to retain.

-Jonathan R.

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