Subject: RE: [SIP] Change in SIP URL syntax

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 1 Aug 2000 02:56:12 -0700

Unfortunately Gethin, that's not true as the draft currently stands (July).
'@' doesn't need to be escaped when it appears in a paramter name or value.

Jonathan and Henning were discussing changing the draft in this respect but
I never saw any concrete conclusion reached.

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

> -----Original Message-----
> From: Gethin Liddell [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2000 4:48 PM
> To: Ajay Chitturi; [email-masked]
> Subject: Re: [SIP] Change in SIP URL syntax
> 
> 
> On Tue, 01 Aug 2000, Ajay Chitturi wrote:
> > 
> > Hi,
> > 
> > I noticed the following change in the SIP URL syntax in the latest
> > version of 2543bis
> > 
> > 	Added semicolon and question mark to the list of unreserved
> > characters for the user part of SIP URLs
> > 	to handle tel: URLs properly.
> > 
> 
> there was a long discussion on this a couple of weeks back.  
> i will not
> go over all of the arguments, for and against, yet again, but 
> point you
> in the direction of the archives instead (thread name is: "SIP URL
> telephone-subscriber syntax").  If after reading these, you still
> disagree with the forum's consensus then please raise this issue again
> with your new objections.
> 
> > Wouldn't the change make URL parsing ambiguous ?
> > 
> > For eg. the URL <sip:a;b=c@d> could be parsed in two 
> different ways :
> > (i) host is a and param is b=c@d
> > (ii) user is a;b=c and host is d
> 
> no, this is not ambiguous.  ; is allowed in user so the user is a;b=c 
> this is black and white there is no ambiguity via the greedy parsing
> algorithm.  if you wanted the former, then the url should look like:
> 
> sip:a;b=c%40d
> 
> It is the case that any character that incorrectly changes the
> semantics of URI's MUST be escaped.  that is all that is happening
> here.  It is suggested that @ is always escaped in parameters. even if
> this is not required for example:
> 
> a@b;c@d
> 
> is user "a" host "b" param "c@d" but it is suggested to even make the
> parameter here "c%40d".  mainly because this will make development
> easier :)
> 
> > Am I missing something ?
> > Is there a simple way to parse URL's with this change ?
> 
> perhaps this has made parsing sip url's slightly more difficult but
> this is considered better than double escaping of characters or
> defining new escaping techniques to enable the encapsulation 
> of the tel
> url in the user.
> 
> HTH
> 
> -- 
> 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

---

From: Gethin Liddell <[email-masked]>
Date: Tue, 1 Aug 2000 11:01:29 +0100

> '@' doesn't need to be escaped when it appears in a paramter name or value.

you are correct that @ does not HAVE to be escaped in the majority of
situations (as i said previously), but where it changes the semantics of
the sip url, i.e. changes what is host and what is not, then by
implication it MUST.

> I never saw any concrete conclusion reached.

then we will wait for them to confirm or disagree when they come on-line
later in the day.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 01 Aug 2000 09:31:52 -0400

The current version of the text (to be -01) says

... The set of characters not reserved in the RFC 2806 description
of \header{telephone-subscriber} contains a number of characters in
various syntax elements that need to be escaped when used in SIP URLs,
for example quotation marks (\%22), hash (\%23), colon (\%3a), at-sign
(\%40) and the ``unwise'' characters, i.e., punctuation of \%5b and
above.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 01 Aug 2000 09:31:52 -0400