Subject: [SIP] RE: [Fwd: Aurthorization & Proxy-Authorization URIs]

From: Linden deCarmo <[email-masked]>
Date: Mon, 3 Apr 2000 09:26:35 -0400

Any updates on your communication with the RFC 2617 authors regarding the
use of qoutes with Authorization and Proxy-Authorization headers?

Thanks.

Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:[email-masked]]
> Sent:	Friday, February 25, 2000 7:55 PM
> To:	Jonathan Rosenberg; [email-masked]
> Cc:	[email-masked]
> Subject:	Re: [Fwd: Aurthorization & Proxy-Authorization URIs]
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > ?? I guess the quotes shouldn't be there according to the current BNF,
> > but it might make parsing harder.?
> 
> Since the digest authentication mechanism attempts to follow RFC 2617
> (obviously, 2617 postdates 2543, but it will be the normative reference
> in the next round), request-uri is indeed defined without being a quoted
> string, even though the uri is not a token. (Unless you put an unescaped
> comma into the URI, there shouldn't be delineation problems. But we had
> this discussion in another context, where it became clear that URIs can
> indeed contain commas.) Some parsers allow all parameters to be either
> tokens or quoted strings, since that's easiest and never wrong.
> 
> Unfortunately, RFC 2617 itself is not consistent. In the BNF (3.2.2),
> it's without quotes, in the example (Section 3.5), it shows up *with*
> quotes. I guess we need to contact the RFC 2617 authors to find out what
> people really do and what they intended. Another instance of URIs (in
> WWW-Authenticate) is always with quotes.
> 
> Thus, the confusion is more fundamental.
> 
> > 
> > Subject: Aurthorization & Proxy-Authorization URIs
> > Date: Mon, 21 Feb 2000 14:53:22 -0500
> > From: Linden deCarmo <[email-masked]>
> > To: [email-masked]
> > 
> > The BNF for digest-uri defined by "HTTP Authentication: Basic and Digest
> > Access Authentication" for use in Aurthorization & Proxy-Authorization
> > headers is:
> > 
> > digest-uri       = "uri" "=" digest-uri-value
> > digest-uri-value = request-uri   ; As specified by HTTP/1.1
> > 
> > RFC2543, updates this definition to be:
> > 
> >         2.   The BNF for digest-uri-value is:
> > 
> > digest-uri-value  =  Request-URI ; a defined in Section 4.3
> > 
> > Yet, all the sample call flows for the uri parameters for the
> Aurthorization
> > & Proxy-Authorization headers that I've seen (i.e. SIP Telephony Service
> > Examples With Call Flows)
> > enclose the uri parameter in quotes (i.e. a quoted string) just like the
> > HTTP docs:
> > 
> > uri="sip:xxx.yyyy.com"
> > 
> > Syntacically, I can't see how this is possible.  Am I wrong?  If so,
> could
> > someone point out the relevant section that explains how this is
> possible?
> > 
> > Thank you.
> > 
> > Linden deCarmo
> > Netspeak Corporation
> > 902 Clint Moore Road
> > Suite 104
> > Boca Raton, FL 33487

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Apr 2000 09:51:34 -0400

> use of qoutes with Authorization and Proxy-Authorization headers?

No response whatsoever.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Apr 2000 11:01:36 -0400

> > use of qoutes with Authorization and Proxy-Authorization headers?

I suggest we take a poll at the next bakeoff and see what folks have
implemented. If everyone is using quotes, we can go with that...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Li Li" <[email-masked]>
Date: Mon, 3 Apr 2000 17:34:50 -0400

A simple question on the proxy behavior. How the proxy 
(or the UAC) gets the Request-URI for the INVITE message 
to be sent out?
When the proxy server receives an INVITE, it consults the 
location server to decide where to proxy this request. 
Should the proxy server use the Request-URI (or part of it), 
or should it use the To header to query the location server to 
identify the next hop? If it uses the Rquest-URI, the host portion 
of the Request-URI should mostly be one of the host names on 
the proxy itself. If the proxy uses the To field, possibly the 
Request-URI has already been changed to be quite different from 
To. Then he To doesn't make sense here. Or should it be that 
the proxy first check againt the Request-URI to see if it knows the 
user. If not, resort to the "To" field?

Should section 4.3 in bis be interpreted in this way? If there's
a section in the bis that describes this issue, please give me
a pointer. Thanks...

li li

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Apr 2000 02:32:33 -0400

Li Li wrote:
> identify the next hop?

Yes, the request URI is what a proxy or redirect server should generally
use in order to determine the next hop. 

 If it uses the Rquest-URI, the host portion
> the proxy itself.

Except for the case of a local proxy, in which case the host name in the
request URI is not one of the host names of the proxy itself. In this
case, a proxy should generally forward it to the address in the request
URI.

 If the proxy uses the To field, possibly the
> user. If not, resort to the "To" field?

A proxy will not generally need to look at the To field for general
message routing.

-Jonathan R.

---

From: "Li Li" <[email-masked]>
Date: Tue, 4 Apr 2000 10:04:53 -0400

> case, a proxy should generally forward it to the address in the request

Say if the Request-URI is [email-masked] and foo.com is one of the 
host names of the receiving proxy itself. So the proxy now takes 
"somebody" to do the lookup, as the foo.com does not give any information
about the destination the INVITE should be going, though in the To
header is actually "[email-masked]", which is the destination.
But "somebody" is not unique without the host name and may not tell much 
about where he is. I missed something here? 

li li

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Apr 2000 12:54:44 -0400

> about where he is. I missed something here?

As I said, the To field is not used by the proxy. BellCanada.com is not
the domain of the proxy; it cannot know anything about this name space,
and therefore is not in a position to know anything about
[email-masked].

The proxy uses the request URI. If you are saying that the problem is
that "[email-masked]" is not unique within foo.com (in otherwords,
there are two somebodys), you have mismanaged your own namespace. 

-Jonathan R.

---

From: "Li Li" <[email-masked]>
Date: Tue, 4 Apr 2000 13:48:08 -0400

> there are two somebodys), you have mismanaged your own namespace.

Thanks for pointing/confirming about the unique name space. Then if
there is a "[email-masked]" and a "[email-masked]",
the proxy server needs to configure two names as [email-masked] and
[email-masked] to send the call to different called destinations? So
the proxy server should not serve too many different destination domains
as this would make the name management impossible to give them all different
names in the proxy's domain. Is this right?

li li

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Apr 2000 14:43:44 -0400

Li Li wrote:
> [email-masked] to send the call to different called destinations?

You've lost me. If I call [email-masked] and
[email-masked], those will go to two different proxies (or
possibly the same proxy doing virtual hosting). If those map to
different people, then the outgoing URIs will be different.

> So

No, of course not. Why is this a problem? The proxy is serving many
domains, as you say. To me, this means it handles requests for
domain1.com, domain2.com, etc. You also seem to imply that these are
mapped into a single namespace in the "proxy's domain". I don't follow
that. If it receives a call for [email-masked], it checks its tables
for domain1.com, and finds that this is mapped to [email-masked], and
sends it out to foo.com. Not all incoming request get mapped to foo.com.
For those that do, its up to foo.com to properly manage their namespace.

-Jonathan R.

---

From: "Li Li" <[email-masked]>
Date: Tue, 4 Apr 2000 15:09:37 -0400

> different people, then the outgoing URIs will be different.

I see the problem I have is thst from all the call flow examples in the
call flow draft, the INVITE message always have user@proxydomain in the
Request-URI and the Request-URI changes all the time from proxy to proxy.
For example, if the INVITE goes through proxy ss1.mciworld.com and
ss2.mciworld.com. The Request-URI in the INVITE message is shown as
[email-masked] and then changed to [email-masked].
Should the caller UAC just send in Request-URI [email-masked] to
SS1 proxy. The SS1 does a look up and know that SS2 handles
[email-masked]
and proxy it to SS2? Otherwise, as in the draft, it implies to me
that everyone in the mciworld.com also should have a unique name in the
ss1.mciworldcom.com so that SS1 can handle it.
That leads me to think that when an INVITE is sent to a proxy, it should use
the proxy's host name in the host part of the Request-URI. But as what you
pointed out here, really  the Request-URI should be the destination
user@host
and is sent to the proxy of the destination domain.
Thanks for your help. Very much apprecaited.

li li

---

From: Alan Johnston <[email-masked]>
Date: Tue, 04 Apr 2000 14:43:50 -0500

Li,

I thought your question might have been based on the use of Request-URI in the
Call Flows draft.

I think the Request-URIs in the draft were formulated based on the (mistaken?)
idea that the host portion of the Request-URI should map to the IP address of
the proxy or server (the entity to which the request was sent).

For example, in 3.1.2 on page 25 of draft-ietf-sip-call-flows-00.txt, message F4
has the INVITE Request-URI of [email-masked] but the To header contains
[email-masked] where ss1.wcom.com is the Proxy Server.  

Should the Request-URI instead match the To header in this case?

Alan Johnston
MCI WorldCom

---

From: "Li Li" <[email-masked]>
Date: Tue, 4 Apr 2000 22:07:44 -0400

> I thought your question might have been based on the use of

Yes. Alan, my misunderstanding was exactly resulted from there.
> For example, in 3.1.2 on page 25 of
> draft-ietf-sip-call-flows-00.txt, message F4

Always have the host portion of the Request-URI mapped to the
IP address of the proxy or server may have a problem when there is
a local proxy that handles many (or all) outgoing calls for a caller.
Put Request-URI as [email-masked] in this example may be better,
my own take. Clearer to me. If proxy ss1 only handles calls to users
in wcom.com, things may not be too bad if the INVITE message has
Request-URI with ss1.wcom.com in the host portion. But say if the caller
also wants to call somebody outside of wcom.com but should access through
the
wcom's ss1 proxy for all his services. If in this case the caller UAC gets
all the destinations in the world mapped to a unique [email-masked]
in the Request-URI in the INVITE message, we'd have problems of too many
mappings to handle for ss1.wcom.com. Of course, probably user A can send his
different calls directly to different proxy servers of the destination
carrier's
network, which I don't know if it is the case.

li li