Subject: Re: URL user parameter

From: John Hearty <[email-masked]>
Date: Fri, 18 Jun 1999 16:32 -0500 (CDT)

Thanks for the clarification of which URL, but the basic question
to Jonathan still remains.  Perhaps section 2 and 4.3 needs to be 
updated if there is a good reason not to include this.

John

>John, We referred to the URL in the Request-URI not the URL in the
>From/To. 
>
>Shail
>
>John Hearty wrote:
>> 
>> Jonathan,
>> 
>>  In discussions with Cisco personel, we ran into some questions about
>> the user parameter in a URL.  We had supplied some examples using this
>> parameter.  They noted that going into the bakeoff they had included
>> it in their URLs, but most others had not, and you had told them it
>> should not be present, so they removed it.  Section 2 of the RFC clearly
>> allows user=phone for calls from pstn gateways, and only makes mention
>> that "... without this parameter, recipients of SIP URLs MAY interpret
>> the pre- @ part as a phone number if local restrictions on the name
>> space for user name allow it."
>> 
>>  Can you help me understand what recommendations may have been made
>> during the bakeoff regarding this issue?  I am trying to understand
>> if we should be asking for it to be included, and Cisco is concerned
>> about interoperability.  It seems to remove any possible ambiguity
>> about the source of the URL, and I don't understand why recommendations
>> may have been made to remove it.  Is this a misunderstanding?
>> 
>> John Hearty
>> MCI Worldcom

---

From: Sean Olson <[email-masked]>
Date: Sun, 20 Jun 1999 14:43:59 -0500 (CDT)

> From [email-masked]  Sat Jun 19 01:58:36 1999
> Date: Sat, 19 Jun 1999 00:26:30 -0400
> From: Jonathan Rosenberg <[email-masked]>
> Organization: Bell Laboratories
> X-Mailer: Mozilla 4.05 [en] (Win95; U)
> MIME-Version: 1.0
> To: John Hearty <[email-masked]>
> CC: Confctrl <[email-masked]>
> Subject: Re: URL user parameter
> Content-Transfer-Encoding: 7bit
> Sender: [email-masked]
> 
> John Hearty wrote:
> > 
> Now, I admit I don't recall telling the Cisco folks to remove it from
> the Request-URI at the bakeoff. I found no mention of the issue in the
> notes we took at the bakeoff. But, it was a hectic two days and I may
> have said this. There was general confusion about what parameters were
> allowed in the Request-URI. At some point, I think we believed none of
> them should really be permitted. I have recently become less sure about
> that, and think nearly all should be permitted. 
> 
> However, the user param does seem a definite candidate for inclusion in
> the Request-URI. Since its helpful for servers to make routing
> decisions, and these decisions are usually based on the Request-URI and
> not the To field, I believe its reasonable to allow it in the request
> URI. It is certainly not mandatory to do so - i.e., if a UAC dials a
> phone number, it doesn't have to be present. I don't think its absence
> would affect interoperability at all, since interpretation of the user
> portion is always according to local namespace, which can be configured
> in any way desired.
> 

If I recall the SIP bake-off correctly, there was some discussion as to what
parameters a proxy should strip (disallow) in a Request-URI and the consensus(?)
was that only the user parameter was allowed in a Request-URI. This matches
the text in section 4.3. 

Its usage is pretty straightforward and valuable in certain contexts. For
interoperability purposes, the user parameter seems mostly just a hint as 
it is up to the server to interpret the Request-URI. I can't imagine that its
inclusion in the Request-URI would cause that big of a problem in most
implementations as it will almost certainly be included in the To:/From: URIs
as well.

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154