Subject: [SIP] Problem with the syntax of URI extension parameters

From: Jonathan Lennox <[email-masked]>
Date: Tue, 2 May 2000 18:03:14 -0400 (EDT)

RFC 2543 (and the current bis draft) defines the BNF for SIP URLs' extension
parameters as follows:

  other-param     = ( token | ( token "=" ( token | quoted-string )))

The problem with this is that RFC 2396 (URI Generic Syntax) specifically
excludes quote marks from URIs, since they're a common URI delimeter in text
documents and protocol fields.  What's more, both the "token" and
"quoted-string" syntax elements come from a very different part of the SIP
BNF; and no other URI syntax, as far as I know, uses anything like them.

I think it'd be much more in the spirit of the generic URI syntax to have 
other-param be defined like this:

  other-param     = pname | pname "=" pvalue
  pname           = 1*paramchar
  pvalue          = 1*paramchar
  paramchar       = param-reserved | unreserved | escaped
  param-reserved  = "/" | "?" | ":" | "@" | "&" | "+" | "$" | ","

That is, special characters get %-escaped rather than quoted.
"param-reserved" above is the same as the general "reserved" with ";" and
"=", the parameter delimiters, omitted.

This would, however, be an incompatible change to the SIP spec.  What would
people (especially the spec authors) think about this?

-- 
Jonathan Lennox
[email-masked]

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

---

From: Igor Slepchin <[email-masked]>
Date: Tue, 02 May 2000 23:03:28 -0400

You would probably want to exclude "?" and "," from param-reserved: "?"
-  to eliminate the ambiguity with "?" that separates parameters from
headers, "," - because URLs are allowed in certain headers and allowing
commas in SIP URLs will make parsing those headers sometime impossible.

Another observation: to be as backward compatible as possible the
characters allowed in param-reserved should be a subset of those allowed
in token. The intersection of reserved from RFC2396 and token from
RFC2543 leaves us with the following

param-reserved = "+"

Also, note that unreserved in RFC2396 allows "(" and ")", while token
does not. On the other hand, I don't think that many implementations
will get broken if those extra characters are allowed.

---
Igor Slepchin

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 02 May 2000 23:35:42 -0400

> -  to eliminate the ambiguity with "?" that separates parameters from

Done.

> commas in SIP URLs will make parsing those headers sometime impossible.

As far as I know, all headers where URLs are allowed mandate the use of
<> for URLs with commas or other "bad" characters. Any we missed?
(Probably still a good idea to make it reserved; the pain is small
compared to the confusion avoided.)

> RFC2543 leaves us with the following

Anybody object to this most restrictive coding? The only slight problem
with being restrictive is that it makes hand-coding HTML pages with SIP
URLs more painful. On the other hand, we haven't really defined any
parameters likely to see $ or @. However, removing : doesn't work well,
since we allow it in IPv6 numerical addresses in the maddr parameter.
Would seem strange to force escaping here.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 May 2000 01:01:38 -0400

> compared to the confusion avoided.)

I agree the , should be escaped to avoid confusion.

-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: Rohan Mahy <[email-masked]>
Date: Wed, 03 May 2000 12:13:39 -0700

So in which contexts do i need to escape the <"> in this parameter?
      ?Request-Contact=*;mobility="mobile"

(obviously when the sip:URL is encoded in HTML)

thanks,
-rohan