Subject: RE: [Simple] tel URIs in common policy

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 12 Aug 2005 08:22:03 -0400

Paul,

Didn't one of the tel: drafts suggest that you could go from tel: to
sip: format AND Vice Versa?

If that is not published yet, then it might need updating to say that
you can go from tel: to sip: but only the domain can go in the reverse
direction.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Wednesday, August 10, 2005 4:02 PM
> To: Brian Rosen
> Cc: 'ext Henning Schulzrinne'; 'Aki Niemi'; [email-masked]
> Subject: Re: [Simple] tel URIs in common policy
> 
> Brian,
> 
> Brian Rosen wrote:
> > Paul
> > 
> > Not sure yet what I think of the basic idea, but
> >    sip:[email-masked];user=phone
> > should be equivalent to
> >    tel:+1-232-1234
> 
> Well, I am suggesting that, when the purpose is identifying a 
> caller for purposes of authorization.
> 
> According to 3261, only someone responsible for the foo.com 
> domain can decide that these are equivalent. If you are not 
> responsible for that domain then you are not permitted to 
> conclude they are equivalent. So I am in some sense 
> advocating violating 3261 in this case.
> 
> Unless we plan to change 3261, or look the other way while 
> people violate it, this is a fundamental problem with using 
> sip;user=phone address forms.
> 
> > So I think you CAN convert it to "enum" form.
> 
> According to sip routing rules, if you are not responsible 
> for the foo.com domain, you *definitely* can't do this to 
> route the sip address! 
> You must simply route it based on the domain name.
> 
> I see this as a key difference between the two forms. With 
> the tel form, anybody can just go to the PSTN, or use enum to 
> find possible ways of reaching it. With the sip form, you can 
> only reach the address via sip.
> 
> > You might have more problems with
> >    sip:[email-masked]
> > 
> > That may be equivalent to
> >    tel:1234;phone-context=foo.com
> > but you don't know that a priori.
> 
> There is certainly nothing written down anywhere that would 
> lead you to believe you could do that. If it can be done, it 
> is only on a domain-specific basis, and so can only be done 
> by someone responsible for the domain.
> 
> 	Paul
> 
> > Brian
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Paul Kyzivat
> > Sent: Wednesday, August 10, 2005 2:19 PM
> > To: Aki Niemi
> > Cc: [email-masked]; ext Henning Schulzrinne
> > Subject: Re: [Simple] tel URIs in common policy
> > 
> > Aki,
> > 
> > 
> > 
> > Aki Niemi wrote:
> > 
> >>Hi,
> >>
> >>I kind of grew fond of the idea Cullen and I came up with 
> in a private 
> >>conversation, namely treating telephone numbers as domains 
> similar to 
> >>when issuing a DNS ENUM query.
> >>
> >>In essence, to match +1-232-555-1234, you'd have an identity 
> >>conditions such as:
> >>
> >><many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />
> > 
> > 
> > Then what do you do with sip:[email-masked];user=phone ?
> > 
> > I don't think you can convert it to:
> > 
> >     4.3.2.1.5.5.5.2.3.2.1.foo.com
> > 
> > and if you could then it it wouldn't match the e164.arpa form.
> > 
> > 
> >>This has an interesting additional property of being able to match 
> >>based on country code, area code, etc. For example, to match all 
> >>Finnish telephone numbers, you'd have:
> >>
> >><many domain="8.5.3.e164.arpa" />
> > 
> > 
> > It only does if you declare that a domain matches anything 
> it is the 
> > tail of. You may sometimes want that, but I don't think you 
> do in general.
> > 
> > 	Paul
> > 
> > 
> >>Not being an expert on ENUM or E.164 in general, I suspect this is 
> >>horribly broken, but it pleases the aesthethic eye.
> >>
> >>Cheers,
> >>Aki
> >>
> >>ext Henning Schulzrinne wrote:
> >>
> >>
> >>>In a side conversation, Hannes suggested a solution to the tel URI 
> >>>problem we discussed during the WG meeting, akin to what's done in 
> >>>the geopriv coordinate system parameter, namely to have a 
> parameter 
> >>>that identifies the scheme, as in
> >>>
> >>><one scheme="tel" id="+1-212-555-1234"/>
> >>>
> >>>or
> >>>
> >>><one scheme="sip" id="[email-masked]"/>
> >>>
> >>>if you really only want to match SIP identity 
> sip:[email-masked].
> >>>
> >>>The default with no scheme parameter is "matches any 
> user@domain scheme".
> >>>
> >>>In order to complete finishing the section of the spec, I'd value 
> >>>quick feedback on the idea.
> >>>
> >>>Henning
> >>>
> >>>_______________________________________________
> >>>Simple mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>
> >>_______________________________________________
> >>Simple mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/simple
> >>
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2005 09:41:44 -0400

> sip: format AND Vice Versa?

I don't know of any that did the visa versa in the sense we are talking 
about here.

What I do recall is that the semantics of sip;user=phone were tightened 
up a bit. It used to be the case that when you convert from tel to sip 
you embed the tel content in the user part and add user=phone. But there 
was then no requirement that a sip uri with the user=phone parameter had 
to obey the tel syntax in its user part. So something like 
"sip:[email-masked];user=phone" was as far as the spec went.

I believe that was tightened up (though I don't recall in what draft 
that was done), so that if the user=phone parameter is present then it 
is at least syntactically equivalent to a tel. But AFAIK that still did 
not give the anyone except the owner of the domain the right to actually 
make the translation.

The creator of the URI may need for it to stay as is for a variety of 
good reasons:
- it might be a sips URI to guarantee all calls have secure signaling.
   (there is no tels URI.)
- there may be a requirement to use sip signaling so that sip features
   like MESSAGE, alternative media, etc. can be used.
- even if the actual target is in the PSTN, the recipient may want to
   control where the hop-off to the PSTN occurs.
- (I'm sure there are more)

So, if I hand you a sip URI (say 
sips:[email-masked];user=phone), I should have an 
expectation that you will use that to contact me via SIP, not some other 
way.

If I put that address in my From address when I call you, and your phone 
simply displays the phone number, then you will not be aware that I 
should only be contacted via SIP. You may attempt to contact me via the 
PSTN directly. Or if you have a sip phone, you may try to reach me using 
either tel:+1-555-123-4567 or sip:[email-masked];user=phone, 
and those may eventually go to the PSTN. So you have violated my intent 
in using that address.

If I want to give you those options then I can explicitly give you the 
tel form of my address.

	Paul

> you can go from tel: to sip: but only the domain can go in the reverse

You can go from tel to sip for a domain where you are permitted to 
construct URIs. You can't just use some arbitrary domain name. And you 
can go the other way iff you are responsible for the domain too. So 
there is symmetry. And the condition may be a bit weaker than 
"responsible for the domain". You can probably safely do it if you are 
aware of the policies of the domain around address processing and that 
it processes these forms suitably. But you can't do it for a domain you 
know nothing about.

	Paul