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 10:00, Khartabil Hisham (Nokia-TP-MSW/Helsinki)
wrote:
> I agree that an entity forwarding the SIP INVITE request will most
> likely choose a routable URI like SIP and not a http URI after doing
> an enum lookup. What you can't guarantee is that a routable URI, like
> a sip URI, is available in an enum lookup. A presence publisher (PUA)
> has no means of making that determination unless it performs an enum
> lookup itself before placing the tel-URI in a presence document. Not
> all terminals/UAs can perform enum lookups.

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? 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