Subject: RE: [SIP] SIP URL telephone-subscriber syntax.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 2 Jul 2000 18:41:40 -0700

Hi Henning,

> ; are used all over in the tel URL to delineate parameters, so I'm not
> sure I understand your point here.
> 
> > [Henning, in your example you wrote 
> %3bContext1%40Context2%22 and inferred
> > that this referred to ";Context1@Context2". Did you really 
> mean that the
> > context is ";Context1@Context2\"" or is the escaped string 
> incorrect?]
> 
> Yes, this is a valid, if somewhat unlikely, context name.
> 
The private-prefix is defined as (from RFC2806)

private-prefix        = (%x21-22 / %x24-27 / %x2C / %x2F / %x3A /
                        %x3C-40 / %x45-4F / %x51-56 / %x58-60 /
                        %x65-6F / %x71-76 / %x78-7E)
                        *(%x21-3A / %x3C-7E)
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]

Thus the semicolon (%x3b) is not allowed (assuming we are not using
recursive escaping). However semicolons are allowed in the quoted-string
token (see below). The quoting I believe is sufficient to differentiate
between a semicolon delineating parameters and a future-extension parameter
value.

future-extension      = ";" 1*(token-char) ["=" ((1*(token-char)
                        ["?" 1*(token-char)]) / quoted-string )]
                        ; See section 2.5.11 and [RFC2543]
token-char            = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                        / %x41-5A / %x5E-7A / %x7C / %x7E)
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]
                        ; See sections 1.2 and 2.5.11
quoted-string         = %x22 *( "\" CHAR / (%x20-21 / %x23-7E
                        / %x80-FF )) %x22 

Cheers,

Robert.

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

---

From: Gethin Liddell <[email-masked]>
Date: Mon, 3 Jul 2000 10:40:51 +0100

Hi,

i see this thread has taken off whilst I've been on holiday :) but
here's my pennies worth anyway:

#1  Private-prefix, semi-colons, recursion and Henning's example:

Robert is correct that semi-colons are not allowed in the
private-prefix part of the TEL URI.  So Henning's example of 

sip:+12345%3bphone-context=[email-masked];user=phone

is invalid because the phone-context=%3bContext1%40Context2%22 will be
un-escaped to phone-context=;Context1@Context2" So although the escaped
version is not syntactically invalid, the un-escaped is grammatically invalid.

However, ignoring this, i think this is a very important point being
made by Henning here.  Take the case where we have the TEL URI with two
future-extension parameters a=b@c and d=;e.  Now for this to be a
valid TEL URI, it MUST be written as:

TEL:+1234;a=b@c;d=%3be

We now have to convert this to sip and we have the problem.

Do we allow semi-colon's in userinfo:

(1) ------- sip:+1234;a=b%40c;d=%3be@host

or do we escape the semi-colon's:

(2) ------- sip:+1234%3ba=b%40c%3bd=%3be@host

Well straight away, (2) is incorrect because this will be un-escaped to 

+1234;a=b@c;d=;e

which is evidently different to what we started with  So (2) should be
double escaped to read:

(3) ------- sip:+1234%3ba=b%40c%3bd=%253be@host

So which is best? Well, I can't help but feel that adding `;' to user
is a bit of a hack.  Would we not need to add `?' as well because of
exactly the same arguments for `;'  I personally am split between the
two. Are there any other arguments that we haven't thought about?  Is
the double escaping method not more generic?  OK, it's more difficult
to read but a computer doesn't worry abut that!  However, that means we
would have to escape the `%' in `d=%3be' again.  Does the escaping of
the `@' not complicated things and thus require that the `%3b' be
escaped to `%253b' anyway?

#2 Quoted Strings in URIs.
I really do not like quoted strings in URIs.  For the main reason that
the quote character is defined invalid in the Generic URI RFC 2396
(Section 2.4 and 2.4.3).  It is explicitly defined in the said rfc that
the quote character is invalid because it is used as a delimiter else
where (along with other characters). Any time a quoted string is
required, the quotes would have to be escaped to be valid.  This would
also mean that a lot of internal data would have to be escaped.

For example if we have a simple URI as follows:

myURI:abcdef;token="quoted string"

Then this could only be used as 

myURI:asbcef;token=%22quoted%20string%22

note the space MUST be escaped as well.

Why do i mention this?  Because it worries me when i see emails saying:

> between a semicolon delineating parameters and a future-extension parameter

Even though the semi colon is allowed in the quoted string, it would
still have to be escaped a long with all the other reserved or invalid 
characters.  If this was not the case, it would be impossible to parse
an Unknown URI as an opaque string because you would not know where it
starts or stops or what the characters actually mean within the escaped
string.

I actually contacted the author of the TEL URI over this fact and
informed him that we had agreed to remove the escaped-string from the
future-extension of the Sip URL and asked him what his thoughts were.

Here was the reply:

> Oh well... It seems that I weeded out all non-allowed chars from
> <token-char> in my BNF but forgot about <quoted-string>... I think I trusted
> RFC 2543 too much. 

Now whether this means that quoted string has now been removed from TEL
URI I'm not sure.  Either way it is a mute point point because if a
quoted string is to be used then it would have to be escaped into an
opaque string anyway.  This could and probably would look very messy.

I think I've covered everything ;)

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Jul 2000 11:48:09 -0400

> escaped to `%253b' anyway?

My main concern with double escaping is that it's difficult to get right
across different software versions. The software has to keep track of
what state of escaping various pieces of string are in, how they have
been passed along by other pieces (such as external cgi scripts) and so
on. I don't even want to think about what this means for comparisons.
Single-level escaping is already a pain.

There is another, smaller problem (I hope I didn't misread the hex
listing this time...): The colon (:, 3a) is legal in private-prefix.
However, this is also used in the user:password separator, as in 

sip:alice:[email-masked]
and
sip:1234;phone-context=:mycontext

This can be solved by escaping the ":" (which is probably a good idea
anyway since it's an RFC 2396 "reserved" character - I'm surprised this
is legit at all).

Therefore, I'd suggest that either all tel URL "meta" characters (? and
semicolon, I believe) are valid in the user part or that these parts are
"exported" to the end of the SIP URL. The latter idea is ugly, but at
least syntactically workable. My preference is to allow ; and ? in
user-info, but none of the three solutions is blessed by aesthetics, so
I'm largely agnostic as long as somebody can produce a simple,
unambiguous description of the mechanism.

> I think I've covered everything ;)

Yes, the topic of quoted strings in SIP URLs was discussed on this list
a while ago and there was agreement to remove this "feature" from SIP
URLs. It shouldn't have been there to begin with. I would suggest that
tel URLs take the same approach before the spec moves from Proposed to
Draft Standard. (As long as we keep people from using the feature, this
is not too onerous in terms of backward compatibility.) Mixing two
quoting mechanisms (quotation marks and %xx) is a recipe for confusion.

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

---

From: Gethin Liddell <[email-masked]>
Date: Tue, 4 Jul 2000 13:33:18 +0100

> unambiguous description of the mechanism.

OK, I can see no problem with allowing `;' and `?' in the user part.
All other invalid characters have to be escaped.

This only actually works however, because `;' and `?' are delimiters
within telephone-subscriber but not within userinfo.  If, for example,
`:' had an actual meaning within telephone-subscriber (as it does
in userinfo) then we would be in with a problem.

Note, i'm not complaining, just noting that i think we got of lightly :)

As for the description, are there any arguments/problems/discrepencies
with the following:

#1) Amend user in the bnf 
user = *( unreserved | escaped | &  |  =  |  +  |  $  |  ,  |  ;  |  ? )

#2) Add text to the effect of the following in section 2 under the
telephone-subscriber part:

"Any characters of the un-escaped `telephone-subscriber' that do not
exist in the character set of `user' MUST be escaped.  Because the
`telephone-subscriber' reserved characters set is a subset of the `user'
reserved characters set, a correct `telephone-subscriber' syntax is
maintained."

I think that suffices, if a bit flowery :)

http://www.ubiquity.net

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Jul 2000 15:50:39 -0400

Modified spec roughly accordingly. Note that RFC 2806 has a mistake in
that % can never appear as itself. Same for %22 (") and %23 (#), %3c (<)
and %3e (>), according to RFC 2396. I would suggest this be fixed in
RFC2806bis. Also, the tel: URL allows various characters that RFC 2396
declares "unwise" and thus MUST be escaped.

[Note that any character can be used if escaped, so characters only need
to be listed explicitly if they are safe if used by themself, without
escaping. 2806 seems to not follow this convention.]
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs