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

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 01 Jul 2000 13:24:15 -0400

Jonathan Rosenberg wrote:
> 
> Gethin Liddell wrote:
> >
> > However, as far as the Tel URI rfc (2806) is concerend, the character @
> > (for example) will not have to be escaped.  This, of course, will not be
> > valid in the sipurl as it is used to separate the `userinfo' and
> > `hostinfo' elements and will need to be escaped.
> >
> > For example, if the phone-context is actually stored as:
> >
> > "Context1@Context2"
> >
> > then the tel url will have to look like:
> >
> > tel:+12345;phone-context=%22Context1@Context2%22
> >
> > however, it would NOT be valid to just enter this as a sip url as
> > follows:
> >
> > sip:+12345;phone-context=%22Context1@[email-masked];user=phone
> >
> > for the obvious problem of the @. this would need to be translated to:
> >
> > sip:+12345;phone-context=[email-masked];user=phone
> 
> Hmm. I wonder if the actual translation would be:
> 
> sip:+12345;phone-context=[email-masked];user=phone
> 
> The difference is that here, I have treated the subscriber portion of
> the tel URL as an opaque entity. When placing this into the user portion
> of the SIP URL, I need to escape code reserved characters AND the %
> itself. Effectively, I re-encoded the string, so that the two % signs
> already there are treated as normal %, and thus escape encoded as %25.
> 
> Which way to do it depends on whether you assume that the SIP entity has
> knowledge of the structure of the tel URL subscriber syntax, in which
> case it would know that this would have already had its % url-encoded,
> and thus there is no need to redo that encoding, or whether it is
> treated as a random username that happens to have some bad characters in
> it.
> 
> I tend to think the right answer is probably what Gethin has suggested.
> In either case we should clarify this in the spec.
> 

I don't think you want recursive escaping if you can help it, as it
becomes difficult to make sure the right number of translations happen.
Thus, the % should not be escaped, in my opinion. This is already
implied in the BNF syntax for the 'user' part. However, the semicolon
appears to be in the "needs to be escaped" category, which is annoying,
since it is a syntactically important character. Escaping should only be
used for characters that are opaque to the parsing of the URL, such as
parameter values. Thus, in the slightly modified example from above,

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

would really have to be written as 

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

which is rather confusing since the two %3b's mean very different things
- the first is needed to understand the tel URL, the second is just a
random character in a "context" parameter value (";Context1@Context2").

There seem to be only two solutions:

- allow ; parameters in the user part. This probably works, although it
means that a parser won't know whether this is a user parameter or
generic parameter in a @-less URL until the end. It's probably too late
to require a '@' in all URLs, even if the user part is empty.

- double-escaping rules; seems to me a recipe for perpetual confusion
and unlikely to be implemented correctly. Basically, URLs should be
split along delimiters and then un-escaped for each part. That's it.

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

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 4 Jul 2000 17:50:58 -0700

You will also have to require that the user part cannot be empty if the user
part contains semicolons or question marks.

sip:ACDC;dog=cat 
sip:ACDC;dog=cat@ACDC;user=phone

Robert.

> -----Original Message-----
> From: Gethin Liddell [mailto:[email-masked]]
> Sent: Tuesday, July 04, 2000 8:33 PM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: Re: [SIP] SIP URL telephone-subscriber syntax.
> 
> 
> On Mon, 03 Jul 2000, Henning Schulzrinne wrote:
> > 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.
> > 
> 
> 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 :)
> 
>  -- 
> Gethin Liddell
> Ubiquity Software Corporation
> 
http://www.ubiquity.net
mailto:[email-masked]

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 4 Jul 2000 17:59:47 -0700

Sorry, brain fart.

Disregard last email. If the user part is empty - there can't be any
semicolons. :)

Where's that coffee pot.

Robert.

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2000 8:51 AM
> To: 'Gethin Liddell'; Henning Schulzrinne
> Subject: RE: [SIP] SIP URL telephone-subscriber syntax.
> 
>

---

From: Peter Kjellerstedt <[email-masked]>
Date: Wed, 5 Jul 2000 11:52:03 +0200

> Sent: 05 July 2000 10:25
> To: Fairlie-Cuninghame, Robert; Henning Schulzrinne
> On Wed, 05 Jul 2000, Fairlie-Cuninghame, Robert wrote:
> > The point I was really trying to make is that allowing semicolons
> > and question marks in the user part will cause problems with
> > existing server parsers that treat the semicolon as a delimiter
> > to the user@host:port part or don't support the user=phone parameter.
> > 
> > For instance, if the parser doesn't support user=phone:
> > 
> > sip:ABCD;dog=[email-masked];user=phone
> > 
> > will be treated as hostname ABCD with a parameter dog=[email-masked]
> > (rather than some uninterpreted user name at fish.com).
> 
> @ is not allowed in parameters.  Therefore it would be possible to
> delimit the userinfo first by looking for @ and then parsing the host
> afterwards so in the case above (assuming the ; and ? have been added
> to the user bnf), this can only be resolved as 
> 
> user = ABCD;dog=cat
> host = fish.com

Only that this (if I am not mistaken) would make it impossible
to make an lalr(1) parser for SIP, which (albeit not as easily
as I had hoped for) is possible with the current grammar...

//Peter

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 6 Jul 2000 00:11:06 -0700

If this is the route you want to take (allowing semicolons in the user
part), you will definitely need to add this to the SIP Torture Tests. IMO
this will be one of those things that will be often implemented incorrectly
in lesser SIP parsers. This in itself limits the usefulness of
telephone-subscriber for widespread interoperability. Personally, I'd rather
do something a little esoteric (which requires some extra processing on
telephone-subscriber capable systems) but be guaranteed that dumb SIP
parsers won't have a problem with it. Obviously you can't keep the protocol
restricted to the lowest implementations but in my mind it would be good if
we could avoid this URL parsing complication somehow.

Robert.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, July 06, 2000 1:51 PM
> To: Henning Schulzrinne
> Cc: Fairlie-Cuninghame, Robert; 'Gethin Liddell';
> [email-masked]
> Henning Schulzrinne wrote:
> > 
> > Simple solution: any @ should be reserved (and thus needs 
> to be escaped)
> > since it is syntactically significant in SIP URLs. (@ has 
> no syntactic
> > significance in RFC 2806 and thus this transformation is harmless.)
> > Translating tel: URL delimiters into something else is 
> really, really
> > ugly and just cascades the problem.
> 
> I agree. I'd rather escape @ within parameters if present. I 
> doubt there
> are any current uses for @ within parameters, but we do have uses for
> semicolons and other things in the user part, in order to support tel
> URL syntax, which is quite important.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
>

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 10 Jul 2000 10:11:20 -0700

Hi Henning,

> I'm disappointed that Nuera decides to go against community consensus
> and the spec [assuming it does not agree with your position at the
> moment]. I hope that you are not representing the official position of
> Nuera.

<Grin> Looks like I should put one of those "My opinions are not necessarily
those of my employers" disclaimers at the bottom of my emails. 
I am only the janitor here <joke>.

Come one, there is no "community" consensus here yet (let alone a published
"spec" as you say) and that what is being proposed is something that is
_not_ backward compatible (and you don't need a bakeoff to see it). Doesn't
that count for anything? What about the cries for backward compatibility
over elegance? I would say this is a prime example.

My only goal is to get a usable telephone-subscriber syntax where there are
no fears that someone using plain old RFC2543 (or an earlier bis version)
will not reject the message because of the semicolon in the user part (which
is a definite concern in my mind).

Robert.

My opinions are not those of the company owning the domain www.nuera.com.

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 10 Jul 2000 09:28:22 -0700

At 06:43 AM 7/10/00 -0700, Fairlie-Cuninghame, Robert wrote:
>I am glad you have so much faith in everybodys' SIP parsers (both existing
>and future implementations) being able to handle a semicolon in the user
>part. I, however, am a little more sceptical. Telephone-subscriber is an
>important feature for parties concerned but IMO it will only be interpreted
>by a small proportion of the UA's & proxy out there.
>
>Frankly, I would prefer that we used recursive escaping of the tel: over
>your solution. It might be a little more difficult to implement but at least
>you are not risking interopability with older or simpler SIP parsers. As I
>said previously (and John reiterated yesterday in another stream) backward
>compatiability is more important than elegance!! I personally will recommend
>our gateway does not implement telephone subscriber (as written) because it
>risks interoperability with many existing UA's (IMO).

Please take a step back and look at SIP in a larger case context. How can 
we worry about backwards compatibility with something that doesn't yet 
exist? There is more to SIP's future than what early adopter engineers have 
to deal with.

Isn't it worth a small amount of hassle to provide a good working long 
lasting protocol?