Subject: Re: [SIP] URI's in SIP messages

From: Sean Olson <[email-masked]>
Date: Mon, 8 May 2000 14:32:42 -0500 (CDT)

> The current SIP BNF allows the general form of URI (or URI-reference?) to
> be used in the request line and various headers. Observations and
> questions:
> 
> 1. A valid form of URI (RFC 2396)is the empty sequence since:
> 
> URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
> 
> This would permit the request line and various headers (To, From,
> Contact. ..) without an address specification which doesn't seem to make
> much sense. RFC 2396 specifies that the empty sequence URI refers to the
> start of the current document; is there any corresponding abstraction for
> SIP transcations?

No. Please god no. Obviously RFC2396 specifies a much wider and more abstract form
of URI than is commonly used in SIP. Not everything in 2396 is appropriate for 
every URI scheme. They are a set of guidelines that work more or less for the most
common URI schemes in use today: http, ftp, telnet, mailto (with some quirks), etc.

The Request-URI and Contact: URIs have different requirements for parsing than the
To/From URIs. For example, a proxy can to a degree treat the To:/From: URIs 
as opaque strings but MUST understand the syntax/semantics of the Request-URI.
This doesn't prevent you from doing rigorous parsing everywhere, but keep in 
mind that it doesn't necessarily need to be done everywhere.

> 
> 2. The relative URI references a resource relative to a base URI of a
> hierarchial scheme. So a similar question: is this a useful concept for
> SIP sessions?
>

The only contexts where I would think this might be useful would be in
1) The headers parameter of a SIP URI (for the From: and possibly To: headers)
2) A SIP "cookie" similar to an HTTP-cookie. This hasn't really been investigated
   much but would be interesting.

In other words, I don't think it is generally useful in the usual places in a SIP
message (To/From/Contact/Request-URI). But it is potentially useful at the user interface
level or as part of some service logic.

> 3. Finally RFC 2396 states (my emphasis):
>   "When a URI reference is used to perform a retrieval action on the
>    identified resource, the optional fragment identifier, separated from
>    the URI by a crosshatch ("#") character, consists of additional
>    reference information to be interpreted by the user agent after the
>    retrieval action has been successfully completed.  As such, it is not
>    part of a URI, but is often used in conjunction with a URI."
>

True, but this treated in very different ways by different web browsers. Some
treat it as part of the URI, others use it for "post-processing". 
It's not really used in a standard way for SIP, but as stated above it really is up
to the UserAgent's interpretation. THIS IS A GOOD THING.

> 
> So this very general URI seems to have a number of properties which don't
> seem to be relevant when used in place of a SIP URL. Since generality
> often has a price either in implementation or specification, i.e., lots
> of semantic constraints, does it make sense to restrict the syntactic
> form of URI used in place of a SIP URL, e.g., to the absolute-URI form?
> 

Well, if you really want to dig into this, the SIP URI as specified in 2543 is
actually a much different beast. Technically the entire SIP URL according to 2396
falls under the "opaque_part" category of absolute URIs. What does this mean? It means
that the syntax AND semantics of a SIP URI are NOT defined in 2396 at all but left
to the definition in 2543. So from this perspective, much of 2396 does not apply to sip:
URIs. I don't know if this was the intention of the SIP authors or not. From a common
sense perspective, however, a SIP URI has all the properties of the URLs as defined
in 2396: it is a transcribable uniform resouce identifier :)  

I see no benefit in restricting the syntax of a SIP URI. If you "ignore" the fact that
the SIP URI should be treated as opaque, you can parse the SIP URI just like an 
http, ftp, telnet, etc. URI. In this sense, it would actually place more of a burden
on an implementation to prescribe special syntax restrictions on a SIP URI. Furthermore,
I'd prefer to leave open the possibility for future SIP extensions which might need 
something like a relative SIP URI.

> Rick Workman
> Nortel Networks
> Ottawa

--
Sean Olson <[email-masked]>
Ericsson Inc.

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

---

From: "Rick Workman" <[email-masked]>
Date: Mon, 08 May 2000 18:07:38 -0400

> common URI schemes in use today: http, ftp, telnet, mailto (with some quirks), etc.

Be that as it may, they're guidelines which are now an integral part of the SIP BNF.

> mind that it doesn't necessarily need to be done everywhere.

Agreed, but at some point in a session the To:/From: URI's can quite possibly be put in a
Request_URI for a subsequent transaction that proxies will have to worry about.

> level or as part of some service logic.

As part of a SIP message? I guess I can think of many examples where you want to map user
friendly "addresses" to URI's in SIP messages, but that's out of scope for this discussion.

> to the UserAgent's interpretation. THIS IS A GOOD THING.

I'm not arguing the merits of the URI syntax, just how it's used in SIP messages.

> something like a relative SIP URI.

Since the URI's we're discussing can end up as Request-URI's, I think the current syntax is
just too general. At the very least, insisting that the scheme be present doesn't seem
unreasonable. And I guess I can't quite grasp the notion of a relative URL in this context,
so maybe a clarifying example would help.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 May 2000 18:32:40 -0400

> Be that as it may, they're guidelines which are now an integral part

Actually, this doesn't seem to be the case. The BNF for request URI, for
example, is never defined in RFC2543! It says in section 4.3 thats its
either a SIP URI or general URI. The BNF for addr-spec (used in To,
From, Contact) is defined as SIP-URL or URI, but I also never found the
BNF for URI. Even rfc2396 doesn't define "URI", but rather absoluteURI,
relativeURI or URI-reference. 

I believe what URI really means in the SIP context is absoluteURI. That
is, there must always be a scheme, followed by a colon. I believe this
eliminates many of the ambiguities people have been raising. I'm not a
big fan of relative URIs within HTTP itself (as opposed to within HTML,
where the browser computes the absolute URI and puts that in the HTTP
request); in general, I believe URIs sent on the wire should be globally
resolvable. HTTP ran into all sorts of problems, as I recall, since URIs
were not always absolute, and thus servers that supported many domains
got confused when they received things like GET index.html HTTP/1.0.

> As part of a SIP message? I guess I can think of many examples where
> you want to map user friendly "addresses" to URI's in SIP messages,
> but that's out of scope for this discussion.

I really don't see the use of relative URIs within SIP itself.

> I'm not arguing the merits of the URI syntax, just how it's used in

Again, if we say that URI = absoluteURI, this problem goes away also.

-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: "Rick Workman" <[email-masked]>
Date: Thu, 11 May 2000 09:07:43 -0400

Jonathan,

I think I was trying to make the same point; perhaps I wasn't direct enough.
I do think that most people, perhaps erroneously, equate URI to
URI-reference with respect to BNF. And the one place that I know about that
has something close to a complete SIP BNF:

<http://www.cs.columbia.edu/~hgs/sip/SIPgrammar.html>

actually links URI (and Request-URI for that matter) to a rule called
URI-reference but is defined as:

URI-reference = ([ absoluteURI | relativeURI] [ "#" fragment]) | (sip-url)

So I think some clarification in this area would be helpful.

Rick

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 May 2000 14:06:56 -0400

Rick Workman wrote:
> 
> Jonathan,
> 
> I think I was trying to make the same point; perhaps I wasn't direct
> enough. I do think that most people, perhaps erroneously, equate URI
> to URI-reference with respect to BNF. And the one place that I know
> about that has something close to a complete SIP BNF:
> 

Right; I'm basically saying I believe this grammar to be wrong. URI
should be absoluteURI.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 May 2000 03:35:40 -0400

> got confused when they received things like GET index.html HTTP/1.0.

There are two kinds of relative URLs: omitting the host part (which is
what got HTTP/1.0 into trouble) and relative URLs that are relative to
the current file system location (as in ../../foo.html).  The first is
not helpful, the second not applicable.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 May 2000 15:33:28 -0400

> Right; I'm basically saying I believe this grammar to be wrong. URI

Changed to:

Request-Line & = & Method SP Request-URI SP SIP-Version CRLF\\ 
Request-URI  & = & SIP-URI $|$ absoluteURI

where absoluteURI has been defined in RFC 2396.

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

---

From: "Rick Workman" <[email-masked]>
Date: Thu, 18 May 2000 16:28:16 -0400

Henning,

I assume this also applies to "addr-spec" in [6.15]. Also SIP-URI
currently called SIP-URL [2]; doesn't matter as long as it's consistant.

Rick