RE: meaning of tel URI in presence data model, was: Re:[Simple]Presence Data Model: Identifying services

[Aki Niemi <aki.niemi at nokia.com>]

On Tue, 2004-10-12 at 11:32, Khartabil Hisham (Nokia-TP-MSW/Helsinki)
wrote:
> > You shouldn't assume that an ENUM query is needed before a tel URL can
> > be used. What if my UA decides to actually dial that number? 
> 
> What do you mean by "dial that number"? How is an INVITE request
> handled when it has a tel-URI in the request-URI besides doing an enum
> lookup?

Dial as in rotating the dial pad ;) 

I might only have an IM and Presence client, with which I use a circuit
switched telephony application. Or alternatively, the presentity might
only have a SIP IM client and use circuit switched telephony for voice.
Using telephone numbers as, well, telephone numbers is a perfectly valid
use case.

Cheers,
Aki

> /Hisham
> 
> > This is the
> > lowest common denominator when it comes to UAs using tel URLs. This is
> > also the reason why I think the only meaning we can give a 
> > service tuple
> > with tel URL as contact is: "Here's a telephone number. You 
> > can dial it
> > to reach me."
> > 
> > Cheers,
> > Aki
> > 
> > > Regards,
> > > Hisham
> > > 
> > > > -----Original Message-----
> > > > From: simple-bounces at ietf.org 
> > > > [mailto:simple-bounces at ietf.org]On Behalf
> > > > Of ext Paul Kyzivat
> > > > Sent: 12.October.2004 02:55
> > > > To: Jonathan Rosenberg
> > > > Cc: Isomaki Markus (Nokia-TP/Espoo); Niemi Aki 
> > (Nokia-NRC/Helsinki);
> > > > SIMPLE WG
> > > > Subject: Re: meaning of tel URI in presence data model, was: Re:
> > > > [Simple]Presence Data Model: Identifying services
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Jonathan Rosenberg wrote:
> > > > > inline.
> > > > > 
> > > > > Paul Kyzivat wrote:
> > > > > 
> > > > > 
> > > > >>>
> > > > >>> The problem is that it could potentially be ANYTHING, 
> > since enum 
> > > > >>> could have a SIP URI, HTTP URI, anything really. Putting 
> > > > the tel URI 
> > > > >>> in the <contact> and interpreting it as name is really 
> > > > equivalent to 
> > > > >>> putting the presentity URI into the <contact>. The 
> > > > presentity URI is 
> > > > >>> already a layer of indirection  - subscribe to it, and it 
> > > > tells you 
> > > > >>> how to reach the user, just like enum does. Why then, 
> > add another 
> > > > >>> layer of indirection?
> > > > >>
> > > > >> We *already* allow further layers of indirection - the 
> > > > contact can be 
> > > > >> a SIP AOR. And I am permitted to register all sorts of 
> > > > URIs to an AOR, 
> > > > >> including http and mailto. So this isn't new.
> > > > > 
> > > > > Yes, but the scope of that indirection is bounded with the 
> > > > SIP URI. At 
> > > > > least it applies to a multimedia communications service of 
> > > > some sort, 
> > > > 
> > > > Well, I think I can register any url that I can put in a enum 
> > > > record, so 
> > > > it isn't much different on that score.
> > > > 
> > > > > and we can include attributes that say something meaningful 
> > > > about what 
> > > > > it means. We can describe methods and extensions and all of 
> > > > the prescaps 
> > > > > stuff that help us say what we mean.
> > > > 
> > > > True.
> > > > 
> > > > > I can't do any of that for tel if you use it as a name. It 
> > > > could be a 
> > > > > mailto URL. Could be http. Could be sip. Could be nntp. 
> > How do you 
> > > > > define useful attributes in that context?
> > > > 
> > > > OK, so there are things that could be present that might not 
> > > > be of much 
> > > > value. It isn't going to matter unless the client that is 
> > > > used to access 
> > > > the tel uri can support those things. And it also isn't going 
> > > > to matter 
> > > > unless those kinds of urls are actually present in the 
> > enum record.
> > > > 
> > > > *If* the enum record has entries for both sip and nntp, 
> > and the tuple 
> > > > advertises voice, and I pick a client that does voice, 
> > then it will 
> > > > presumably chose the sip url because it can't do voice 
> > with nntp. If 
> > > > there only an nntp url, then the presence was wrong. If 
> > the client I 
> > > > choose can do both sip and nntp, then I would expect it would 
> > > > have some 
> > > > controls to cover the case.
> > > > 
> > > > >>> Indeed, how could one usefully put attributes into the 
> > > > tuple when the 
> > > > >>> actual service could be anything?
> > > > 
> > > > Well, it doesn't matter what it *could* contain - it only 
> > > > matters what 
> > > > it *does* contain.
> > > > 
> > > > I presumably put in attributes that are consistent with 
> > > > something in there.
> > > > 
> > > > This is analogous to putting an AOR as a contact in a tuple, 
> > > > when there 
> > > > are registered devices with inconsistent capabilities.
> > > > 
> > > > >> You put the attributes you want to advertise. They should be 
> > > > >> attributes that are realizable via that address.
> > > > > 
> > > > > My point is, those attributes are going to be wildly 
> > > > different for the 
> > > > > http URL that you get out of enum, compared to the sip URL. 
> > > > How can you 
> > > > > characterize the service associated with a name, when 
> > the name can 
> > > > > resolve to any service??
> > > > 
> > > > If it hurts, then don't do it.
> > > > 
> > > > Sure there are nonsense cases. But there are a lot of useful 
> > > > cases too.
> > > > 
> > > > >>>>  From a practical perspective, I think this means that 
> > > > if all I have 
> > > > >>>> is a PSTN phone, then I can consider this contact as one 
> > > > to try. If 
> > > > >>>> I have a sip device that supports tel uris and ENUM and 
> > > > has a pstn 
> > > > >>>> gateway, then I can also consider trying this 
> > contact. The tuple 
> > > > >>>> with this contact could show support for all sorts of 
> > > > media if it 
> > > > >>>> wants, and if my device supports those media then it 
> > > > might try them 
> > > > >>>> as well.
> > > > >>>
> > > > >>> I think this ambiguity is going to cause us problems. 
> > > > Unlike other 
> > > > >>> URI, a tel URI based on this definition pretty much tells 
> > > > you NOTHING.
> > > > 
> > > > It tells you that this thing is reachable from the PSTN. That 
> > > > means it 
> > > > probably can do voice, or maybe fax, or maybe SMS. Hopefully the 
> > > > characteristics/status will sort that out for you. It might 
> > > > also be able 
> > > > to do other stuff if you can support the protocols necessary, 
> > > > but again 
> > > > hopefully the characteristics and status will tell you what the 
> > > > publisher has in mind.
> > > > 
> > > > I think this could be important if you don't want to 
> > expose very much 
> > > > information. With this you only need to expose a single 
> > > > address that can 
> > > > be used in all sorts of contexts.
> > > > 
> > > > > The nice thing about prescaps is that I can say things 
> > about SIP 
> > > > > capabilities. What do service independent capabilities 
> > > > mean? Can you 
> > > > > give an exmaple?
> > > > 
> > > > While we focused on defining capabilities for sip, they 
> > aren't all 
> > > > restricted to sip. Voice has meaning for sip, for h.323, for 
> > > > the pstn, 
> > > > and maybe elsewhere.
> > > > 
> > > > It isn't our problem, but other capabilities can be defined 
> > > > if they make 
> > > > sense.
> > > > 
> > > > What is imortant to me is that this both encompasses the 
> > > > capabilities of 
> > > > sip if this address can be reached via sip, and the same 
> > > > tuple can also 
> > > > work for *some* useful use cases with other protocols.
> > > > 
> > > > >> I certainly don't think there should be any problem 
> > > > because a watcher 
> > > > >> with a PSTN phone makes a PSTN call, while a watcher with 
> > > > a sip phone 
> > > > >> uses enum and then makes a sip call.
> > > > > 
> > > > > That's OK; if we had a way to say, "this is the number you 
> > > > should reach 
> > > > > me at via the pstn", then whether or not the user is 
> > > > reached directly or 
> > > > > via a sip gateway to the pstn is irrelevant. The problem 
> > > > is, tel URI can 
> > > > > mean much more than this.
> > > > 
> > > > This is probably not going to be the address of choice unless 
> > > > access via 
> > > > the pstn is an option. It may also be the option of 
> > choice even for 
> > > > watchers that normally only go to the pstn as a last resort.
> > > > 
> > > > >>> Let me flip it around. I've got a cell phone. Its 
> > > > reachable via the 
> > > > >>> PSTN. What should I put into my presence document to 
> > unambigously 
> > > > >>> tell the world that I'm reachable at this service 
> > through this 
> > > > >>> particular phone number?
> > > > >>
> > > > >> You should put a tel: contact, and also capability 
> > > > descriptions for at 
> > > > >> least voice and whatever else the phone can do 
> > concurrently in a 
> > > > >> session via the tel address.
> > > > > 
> > > > > And so this gets looked up in enum, and you get back an 
> > > > HTTP URI. What 
> > > > > does *that* mean?
> > > > 
> > > > Why would I be getting back an HTTP URI? The presence 
> > > > document indicated 
> > > > voice capability. Assuming I clicked on the presence display 
> > > > to contact 
> > > > you, I would hope it would give me a range of choices of how 
> > > > to contact 
> > > > you, based at least on the intersection of what my device is 
> > > > capable of 
> > > > and what your presence advertised. If I had selected 
> > "call", then I 
> > > > don't imagine the http uri would have been chosen.
> > > > 
> > > > If all you had in your enum record was an http uri then 
> > you shouldn't 
> > > > have published that you have voice at that address.
> > > > 
> > > > > As a meta-point, a lot of the problems we have gotten 
> > into with the 
> > > > > presence work (ala what-is-a-tuple) where due to our 
> > fear of saying 
> > > > > anything concice about what the information being 
> > presented really 
> > > > > means. I am fearful that this is another example of 
> > that problem.
> > > > 
> > > > I just don't see this as a practical problem.
> > > > 
> > > > 	Paul
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Simple mailing list
> > > > Simple at ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/simple
> > > > 
> > 

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple