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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 4 Jul 2000 20:31:29 -0700

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 paramter dog=[email-masked] (rather
than some uninterpreted user name at fish.com).

If the parser determines the end of the user@host:port by searching for a
semicolon then the same thing will occur. This is a valid (as far as I can
see) and simple way for parser to pull out the base URL (until now).

Slightly kludgier but at least syntactically workable would be to
differently quote the meta characters in the tel:. For example a semicolon
in the tel would be written as %%3b. Now the you can diffentiate %3b from
%%3b - ok so its a hack but it should work nicely.

 "Any characters of the _escaped_ `telephone-subscriber' [per RFC2396]
 that do not exist in the character set of `user' MUST be escaped using
 two percentage marks followed by the character hex value. "

For example: 

Unescaped: tel:ABCD;dog="cat litter"?stuff

Escaped: tel:ABCD;dog=%22cat%20litter%22?stuff

would become

sip:ABCD%%3bdog=[email-masked];user=phone

I would rather a kludge that works nicely than changing the characters
allowable in the user part which further complicates the parsing of a sip
URL. Your suggestion would mean you can only parse a URI correctly by
_first_ locating and understanding one of the parameters !!! Right?

Robert.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2000 9:00 AM
> To: 'Gethin Liddell'; Henning Schulzrinne
> Cc: [email-masked]
> Subject: RE: [SIP] SIP URL telephone-subscriber syntax.
> 
> 
> Sorry, brain fart.
> 
> Disregard last email. If the user part is empty - there can't be any
> semicolons. :)
> 
> Where's that coffee pot.
> 
> Robert.
> 
> > -----Original Message-----
> > From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> > Sent: Wednesday, July 05, 2000 8:51 AM
> > To: 'Gethin Liddell'; Henning Schulzrinne
> > Cc: [email-masked]
> > Subject: RE: [SIP] SIP URL telephone-subscriber syntax.
> > 
> > 
> > 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]
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Gethin Liddell <[email-masked]>
Date: Wed, 5 Jul 2000 09:25:14 +0100

> 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 ? hasve been added
to the user bnf), this can only be resolved as 

user = ABCD;dog=cat
host = fish.com

> see) and simple way for parser to pull out the base URL (until now).

do you mean searching for a question mark here?  If you do then i agree
this is a problem.  Slightly modifying your example (whether there is a
user parameter or not does not matter):

sip:ABCD?dog=[email-masked]

is this 

host= "ABCD"    header = "dog=[email-masked]"

or 

user = "ABCD?dog=cat"   host = "fish.com"

> differently quote the meta characters in the tel:.

or remove @ from the list of characters in headers and make it have to
be escaped.

> _first_ locating and understanding one of the parameters !!! Right?

But it is not backwards compatible at all  If an old parser sees %%3b
then it will not correctly parse it anyway.  I don't really like adding
and removing characters from the BNF but I think it is preferable to
adding a new escaping mechanism that will make things fuzzier and more
complicated.

http://www.ubiquity.net