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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 22 Jun 2000 02:52:11 -0700

Hi Gethin,

telephone-subscriber can also contain escaped private prefixes - is there
any overlap in the character set that must be escaped for a SIP user field
and those that can be escaped for a private prefix ? I couldn't see any at
first glance - in fact the semi-colon is the only character I could find
that needs to be escaped (if you ignore possibility of quoted string in the
future-extension field).

Robert.

-----Original Message-----
From: Gethin Liddell [mailto:[email-masked]]
Sent: Tuesday, June 20, 2000 7:03 PM
To: Fairlie-Cuninghame, Robert; [email-masked]
Subject: RE: [SIP] SIP URL telephone-subscriber syntax.

On Tue, 20 Jun 2000, Robert wrote:
> RFC2543bis now states that the user part may be a "telephone-subscriber"
as
> defined in RFC2806 ( http://www.ietf.org/rfc/rfc2806.txt
> <http://www.ietf.org/rfc/rfc2806.txt> ). And that this is not discernable
by
> BNF (hence the user=phone parameter).
>  
> So is the following a valid SIP URL:
>  
> sip:0w003585551234567;phone-context=[email-masked];user=phone
>  
> Cheers,
>  
> Robert.

as i understand it this is not legal.  there is a semi-colon
in the user part.  i think that all characters that appear in the
userinfo section have to belong to the character set defined by user

therefore the ; character needs to be escaped as follows:

sip:0w003585551234567%3bphone-context=[email-masked];user=phone

when this is parsed, the %3b should be unescaped back to ; to obtain
the correct meaning.

the bis does not make this clear in section 2 in the bnf.  perhaps some
explanatory text of the semantics of the bis is required within the
explanation of telephone-subscriber to the effect of.

"Any characters of the telephone-subscriber that do not exist in the
character set of `user' MUST be escaped."

HTH

gethin

-- 
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: Thu, 22 Jun 2000 11:01:48 +0100

Hi,

Sorry, not 100% sure what you mean here.

Yes, private-prefix (rfc 2806 - TelURI) does allow characters that will
need to be escaped when printed/sent or what ever because of the
escaping defined in rfc 2396 (Generic URI).  Examples of these
characters are `"', `#',  `<' and `>' because they are used as
delimiters else where. (in fact `%' also cannot exist in its own right
as it is defined as being the escape character delimiter). 

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

as for other characters that need to be escaped?  The tel URI set of
escaped characters will be a subset of the characters that need to be
escaped for the `user' definition.  So as long as the escaping is done
to the more restrictive `user' element, all will be OK.

This property is explaind in the rfc 2543 (and bis) in section 2:

"Note that reserved characters have to be escaped and that the  set of
characters reserved within any given URI component is defined by that
component. In general, a character is reserved if the semantics of the
URI changes if the character is replaced with its escaped US-ASCII
encoding."

As for the future-extension and the quoted string, this could still not
exist in its original format.  i.e. the quotes and any other characters
that are not valid URI characters (as defined in rfc 2396) within the
quotes will have to be escaped.

HTH 

gethin

http://www.ubiquity.net

---

From: "Jose Cherian. P." <[email-masked]>
Date: Thu, 22 Jun 2000 19:42:09 +1000

Hi

I am new to SIP
Is there any open SIP stack available for SIP?

pls help
thanks in advance..

Jose Cherian. P.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 22 Jun 2000 10:20:19 -0500

> Is there any open SIP stack available for SIP?

Jose:

See http://www.cs.columbia.edu/sip/implementations.html for more info.

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
IN Architecture and Internet Software Group
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 03:50:11 -0400

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

-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