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

From: Robert Sparks <[email-masked]>
Date: Thu, 24 Jan 2002 15:51:27 -0500

Nobody has argued with this in a couple of days.

Based on these discussions, I'm planning to proceed with
option 3 (documenting the limitations and suggesting a
way of creating sip URIs from tel URIs that improves the
chances of a case-sensitive blob comparison of the userpart
of a SIP URI producing the same results as tel URL comparison.

RjS

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Tuesday, January 22, 2002 9:41 AM
> To: Vijay K. Gurbani; Jonathan Rosenberg
> Cc: Christer Holmberg; [email-masked]; [email-masked];
> SIP WG List
> Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP
> 
> 
> 
> > > 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.
> > 
> > Namespace collision could be mitigated by the LNP
> > I-D (when it becomes a RFC)
> > 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.
> 
> > 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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}
> > 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
> > 
> 
> /sean
> 
> =====
> Sean Olson <[email-masked]>
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
> 

_______________________________________________
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