Subject: Re: [Sip] Propogating URI parameter end to end

From: Eric Burger <[email-masked]>
Date: Mon, 17 May 2004 06:48:02 -0400

How can a proxy POSSIBLY know what the next proxy's requirements will be?
This argument suggests that the proxy MUST retain URI parameters, as the
next proxy MIGHT need them.

What is the harm in keeping the URI parameters?  If it is a security issue
or a local proxy-proxy issue, why not put the URI parameters in the To: URI?

Juha Heinanen said:

Cullen Jennings writes:

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

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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 17 May 2004 08:58:24 -0400

> next proxy MIGHT need them.

They are *uri* parameters - they affect the uri, not the *request*.  So 
any automatic transference of them from one uri to another seems wrong.

If it is the right thing to do for sip uri parameters, then it ought to 
be the right thing to do for tel uri parameters too, as in:

	INVITE tel:12345;phone-context=foo.com
=>
	INVITE sip:[email-masked];phone-context=foo.com

Does that seem right? I don't think so.

Also, what happens when going the other way:

	INVITE sip:[email-masked];xyzzy=mumble
=>
	INVITE tel:+1-321-555-1234;xyzzy=mumble

Another thing: is transference limited to *unknown* parameters, or does 
it apply to parameters that are understood as well? In other contexts 
things are generally not removed just becasue they are understood - they 
are left for others who might also care. But that would lead to nonsense 
like transferring the user=phone parameter.

But transferring only the unknown parameters has similar issues. It 
means that no future uri parameter can be defined unless transferring it 
would cause no harm, since that is what proxies defined according to the 
older specs would do. And of course nobody can rely on the parameters 
being transferred because 3261 compatible proxies don't do that.

Request URI parameters are just not a good place to put information that 
affects the request end-to-end. They are a good place to put information 
that affect one hop.

> or a local proxy-proxy issue, why not put the URI parameters in the To: URI?

Then another class of problems will probably arise - people setting up 
forwarding will want to use parameters in the forwarding address. But 
then they will need to rewrite the To address.

I think a better solution is just to use another header to carry 
parameters to a server. If you want to define a uri containing 
parameters that affect requests generated from that uri, then you can 
use a header parameter:

	<sip:[email-masked]?xyzzy:mumble>

Paul

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 19 May 2004 14:25:15 +0300

> Does that seem right? I don't think so.

the above conversion doesn't make any sense at all.  tel uri parameters
should go before @ sign.  conversion to

 	INVITE sip:[email-masked]

would be ok thought if the proxy somehow knows that 12345 in the given
context maps to [email-masked].

 > 	INVITE tel:+1-321-555-1234;xyzzy=mumble

again, the example is totally bogus, because you cannot put tel uri
params at the of sip uri.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2004 09:24:17 -0400

Juha,

I think you miss my point. Not all uri's are sip uri's. A tel: uri is 
indeed a uri, and it even takes parameters in a syntax similar to that 
used for sip uris. And it doesn't have an @ sign.

Other kinds of uris that might be encountered are pres: and im:.

So it is possible when passing thru a proxy to have a sip uri coming in 
and another kind of uri going out, e.g. sip: in, tel: out, OR tel: in, 
sip: out.

Lets consider another case for a moment: tel: in and tel: out.

  	INVITE tel:12345;phone-context=foo.com
  =>
  	INVITE tel:+1-321-551-2345

in this case we certainly wouldn't say the phone-context parameter 
should be transferred.

How about:

  	INVITE sip:[email-masked];user=dial-string
  =>
  	INVITE sip:[email-masked];user=phone

We don't want the user parameter transferred here.

Of course you can make up examples where transferring parameters is what 
you want, but I don't see a consistent set of rules that always does the 
right thing.

The closest I can come is to say that this should only happen when both 
the input and output urls are sip (or sips), and only for parameters 
that have no meaning to the proxy. But "no meaning to the proxy" 
presents real problems when we start adding features that not all 
proxies support. Yuck!

Also, isn't it a problem if your parameter might be lost because another 
kind of uri is used somewhere along the way?

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 19 May 2004 18:08:57 +0300

> used for sip uris. And it doesn't have an @ sign.

paul, i'm very well aware of that, since i just wrote a piece of code
that translates a tel uri to sip uri and had to read the specs.  

 > >  > 	INVITE sip:[email-masked];phone-context=foo.com

phone-context=foo.com is obviously a tel uri parameter, since it is
included in a tel uri.  according to section 19.1.6 Relating SIP URIs
and tel URLs of rfc 3261, when you convert a tel uri to sip uri, tel uri
params go BEFORE the @ sign.  in your example, phone-context suddenly
became a sip uri parameter, which it isn't and which made your example
syntactically wrong.

 > kind of uri is used somewhere along the way?

i agree with you on the subject matter.  it was just the examples i
criticized.

-- juha