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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 18 Jan 2002 14:53:07 -0600

Robert:

Funny you should bring this up; Christer, James, and I were discussing this
very issue this afternoon here at the SIP 2002 conference.

Anyway, my preference is (2) below; but apparently it has already been
discussed while I was not quite paying attention.  So I guess I loose.

The way we have the tel URL parameters in SIP URIs now does not semantically 
lend 'parameter' status to them; i.e. while parsing them, they will simply
be parsed as strings, not as other-param.  If they were do be parsed
and stored as other-param, a proxy that became LNP aware would
already have parsed and stored them as other-params instead of parsing
the userinfo part anew.

Robert Sparks wrote:
> 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

Regards,
 
- vijay
--
Vijay K. Gurbani    vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Sun, 20 Jan 2002 21:56:21 +0200

Hi,

First, I must also admit that I haven't followed the discussion, and
wasn't aware about the issue until Paris.

Like Vijay, I would vote for (2). 

However, I strongly dissagree that the parameters should be allowed in
the user part, unless they are treated like parameters. By saying that
servers which don't understand the parameters should just treat the
whole user part as a string will cause problems.

For example, assume that a PSTN gateway is able to route the number
"12345" to the PSTN network.

Now, if it receives sip:12345;parm1=[email-masked], and it treats the
user part as a string, it would try to route "12345;parm1=XXX" to the
PSTN network, and that would obviously not work. If it would be able to
separate "parm1=XXX" as parameters, however, it would be able to route
"12345" to the PSTN network - no matter if it understands the parm1
parameter or not.

So, my opinion is that if we don't define parameters in the ABNF they
shall NOT be there.

So, assuming we want to be able to have the parameters in the user part,
the options I can come up with are:

1. We specify that user=phone means the server MUST treat the SIP-URI
user part as a TEL-URL (this is the same as proposal (1)).

2. We define a Require header option-tag, which requires the server to
treat the SIP-URI user part as a TEL-URL.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jan 2002 12:37:56 -0500

> Like Vijay, I would vote for (2). 

I think we need to consider the pros/cons of that. I only vaguely 
remember the email discussion that led to the conclusion to put them in 
the user part. Certainly, collision of params is one part. Another part 
is URI comparison; it becomes harder with them as params, since one 
element that doesn't understand tel would ignore the params, whereas 
they would be needed for comparison of the tel URL itself. Thus, 
equivalency would be different as a sip URL v. a tel URL, which seems wrong.

> whole user part as a string will cause problems.

No, I don't think that is the proposal. If you need to process the URI, 
the user=phone part is there for you do the proper analysis. That has 
always been the case. The issue is that there are elements that will 
need to do blind URI equality comparisons, without otherwise processing 
the URI, and that supporting those is the issue.

> "12345" to the PSTN network - no matter if it understands the parm1

Right - exactly why it shouldn't do this, and instead look at user=phone 
an thus parse the user part as telephone-subscriber, which defiens all 
these params.

> treat the SIP-URI user part as a TEL-URL.

You can't use Require, since you are assuming the context of this is a 
SIP request. They could appear anywhere. The URI must be usable by itself.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 21 Jan 2002 17:40:41 -0600

> equivalency would be different as a sip URL v. a tel URL, which seems wrong.

Namespace collision could be mitigated by the LNP I-D (when it becomes a RFC)
defining a protected namespace for these parameters.

Regarding equivalency being different on a SIP URL vs. a tel URL, isn't that
what we want?  In other words,

   sip:+1-202-533-1234;rn=+1-202-544-0000;npdi=[email-masked];user=phone

and
   tel:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes

will not be treated the same anyway since the scheme (sip:, tel:) does not
match.

On a SIP URL containing a E.164 number, I do not see any problems in URL comp-
arision if the parameters appear at the end (R-URI parameters).  That is,
given a SIP URL:

   sip:[email-masked];user=phone;rn=+1-202-544-0000;npdi=yes

the normal URL matching rules would apply; i.e. the scheme has to match, the
user part has to match, the domain has to match, and the parameters have to
match.  SIP entities that do not know anything about the parameters "npdi"
and "rn" can still match the name of the parameter ("npdi", "rn") and the
octets that appear as the value of these parameters.

Regards,

- vijay

---

From: Sean Olson <[email-masked]>
Date: Tue, 22 Jan 2002 07:41:29 -0800 (PST)

> defining a protected namespace for these parameters.

This doesn't help. The potential collision stems
from using the same parameter name in both
the SIP URL and the "tel" portion of the user part.

> will not be treated the same anyway since the scheme

The problem is that the same parameters would take
on different meanings depending on whether they
were present in a SIP vs. Tel Url. That is, they
would mean something in the tel URL and possibly
mean nothing in the SIP URL.

> octets that appear as the value of these parameters.

My original argument for having these parameters
as part of the user part is that they really do
reflect attributes of the "user" and not of the
SIP URL as a whole. At least the original parameters
did. With the new LNP stuff, this gets a little
trickier.

There is also an argument for allowing the tel: URI
stuff to evolve independently of the SIP URL
specification. (Admittedly this is weaker, but this
is where the namespace collision stuff comes into
play)

> Regards,
> 
> - vijay
> --
> Vijay K. Gurbani   
> vkg@{lucent.com,research.bell-labs.com,acm.org}

/sean

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/