Subject: [Sip] Issues with telephone-subscriber appearing in a SIP URI.

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Jan 2002 10:56:19 -0500

A SIP URI can contain a rfc2806(tel URL) telephone-subscriber
in the userpart of the URI. Previous discussions have made it
clear that tel-url parameters are placed in the userpart of
their sip counterparts. There has been some discussion in the
past on how this interacts with URI equality. To summarize -

These tel URIs are equivalent:
tel:+122;parm1=val1;parm2=val2
tel:+122;parm1=VAL1;PARM2=val2
tel:+122;parm2=val2;parm1=val1

But no two of these SIP URIs are equivalent:

sip:+122;parm1=val;parm2=[email-masked];user=phone
sip:+122;parm1=VAL1;PARM2=[email-masked];user=phone
sip:+122;parm2=val2;parm1=[email-masked];user=phone

because the userpart of SIP URIs is compared case-sensitive.

A few ways of addressing this have been kicked around. To
summarize:

1) Mandate that ;user=phone appears if and only if the
   userpart of a SIP URI is formed as a telephone-subscriber.
   This would, in my opinon, be a very bad thing to do. It
   effectively makes parsing tel: URLs mandatory (except for
   the "tel:" string) and would force every SIP element to
   look for and parse the user parameter before it could even
   begin to look at the userpart. There are many SIP elements
   that are never going to care, and should be treating the
   userpart as an opaque string.

2) Move the tel URI parameters off into the SIP URI parameter
   space. This has been discussed and refused before on the
   SIP lists. Among other things, you get into problems with
   collisions in the parameter name space.

3) Accept and document the limitation.
   This is the approach the group has been leaning towards.
   To make things better, I would like to add to this that 
   we suggest a canonical form for the userpart of a SIP URI
   when it is a telephone-subscriber. Specifically, such userparts
   SHOULD be formed folded to lower-case, with the parameters
   ordered lexically by parameter name. Only elements that create
   such URIs need to know how to do this - all other elements can
   continue to treat the userpart as a blob.

Comments? In absence of contrary discussion, I will reflect 3)
in bis-06.

RjS

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Fri, 18 Jan 2002 12:17:00 EST

>  tel:+122;parm2=val2;parm1=val1
There seems to continue to be confusion about the tel: url and its possible 
forms and uses. I still believe that there needs to be some specific rules. 
One of those should be that the "+" symbol, as the first character after 
"tel:" always means that it is following by a complete E.164 number, and 
never anything else. That means that the above examples are incorrect. +122 
is not a legitimate E.164 number. If the above is intended to reflect a 
legitimate example of something else where the tel: url contains only part of 
the E.164 number, then a real example should be used. "122" would never make 
sense because it includes only the first two digits of the three digit area 
code in the North American Numbering plan. There is no imaginable case in 
which this would be done.

Mike Pierce