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

From: [email-masked]
Date: Tue, 12 Oct 2004 11:32:33 +0300

> -----Original Message-----
> From: Niemi Aki (Nokia-NRC/Helsinki) 
> Sent: 12.October.2004 11:15
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: ext Paul Kyzivat; Jonathan Rosenberg; Isomaki Markus
> (Nokia-TP/Espoo); SIMPLE WG
> Subject: RE: meaning of tel URI in presence data model, was:
> Re:[Simple]Presence Data Model: Identifying services
> 
> 
> 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? 

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?

/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: [email-masked] 
> > > [mailto:[email-masked]]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
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/simple
> > > 
> 

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

---

From: Aki Niemi <[email-masked]>
Date: Tue, 12 Oct 2004 12:13:05 +0300

On Tue, 2004-10-12 at 11:32, Khartabil Hisham (Nokia-TP-MSW/Helsinki)
wrote:
> 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