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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 5 Jul 2000 19:44:29 -0700

Gethin,
> 
> @ 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
> 

I think you misinterpreted my example (the parameter cat=dog originated as a
tel: prameter not a sip one; however it may be interpreted as a SIP
parameter dog=[email-masked] - that's the ambiguity). 

sip:ABCD;dog=[email-masked];user=phone

 From RFC2543bis (July 2000) the @ is a valid SIP parameter value (see
below). So if the parser doesn't understand the user=phone parameter (or is
not very careful in handling the tel:) then it WILL be misinterpreted!!! See
what I mean about this making the SIP URL parsing complicated and
conditional on the understanding of a parameter value !!!

other-param = pname - pname "=" pvalue (Henning, I assume that is supposed
to be a '|' not a hyphen in the document, right ?).
pname = 1 * paramchar
pvalue = 1 * paramchar
paramchar = param-unreserved | unreserved | escaped
param-unreserved = [ | ] | / | : | @ | & | + | $ 

> > 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).
> 
> 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):
> 

No. I am simply anticipating how some parsers might currently work. 

sip:user@host:port;option1=optionval;etc=etcval

An easy way to retrieve the user@host:port section is to search for the
first semicolon (or end of string or closing angle bracket '>'). Placing a
semicolon in the user part will confuse them.

> 
> > Slightly kludgier but at least syntactically workable would be to
> > differently quote the meta characters in the tel:.
> 
> or remove @ from the list of characters in headers and make it have to
> be escaped.
> 
So we hack/simplify things by removing the @ character from headers so that
we can place the ; in the user part?? Doesn't sound like a good trade off to
me.

> 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.

Ok ok ... I knew I should have suggested an alternate quoting mechanism from
the outset.
The translation may make conversion of the telephone-subscriber ever so
slightly more complicated but at least the complication and changes are
localized to just this area (and not pushed to complicating the whole SIP
URL parsing). 

One of the simplest methods would be to translate the tel: reserved
characters ';' & '?' to two other URI reserved characters (RFC2396) that are
unreserved characters in the SIP user part.

'&', '$' and '/' fulfill these conditions.

So simply translate ; to & and ? to $. 

Something a little more idiot proof is to translate them to something
longer, eg: 
; to /%3b/
? to /%3f/ 

See any problems ? Got any objections or preference ?

Robert.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Jul 2000 00:57:47 -0400

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2000 01:50:40 -0400

> 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: Gethin Liddell <[email-masked]>
Date: Thu, 6 Jul 2000 10:03:03 +0100

> > to the user bnf), this can only be resolved as 

ooops

> From RFC2543bis (July 2000) the @ is a valid SIP parameter value (see

my appologies, you are correct.  i mis-read the bis and thought for
some reason that @ was an invalid parameter char :(

However, my opinion is still that it will be easier to make @ a
reserved character for both parameters and headers than it would to
change the whole escaping mechanism that is currently in use.  

I do see problems with the new method you suggested.  For example, the
suggested characters & and $ are valid in their own right in the tel
url (unless i've read it wrong again :) ) so we would need to translate
or do something with all occurances of them.  The same problem occurs
with `/' being used in the longer escaped string.

-- 
Gethin Liddell
Ubiquity Software Corporation

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