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

[Paul Kyzivat <[e-mail]>]

Jonathan Rosenberg wrote:
> inline.
> 
> Paul Kyzivat wrote:
> 
>> Jonathan Rosenberg wrote:
>>
>>>> Why? There is no particular reason why tel: should mean voice. We 
>>>> don't restrict sip: that way, and http: doesn't say much about what 
>>>> you can do either. (I can use http to exchange html, vxml, xcap, etc.)
>>>>
>>>> AFAIK, tel: is an addressing format and namespace. The following is 
>>>> from  draft-ietf-iptel-rfc2806bis-09:
>>>>
>>>>    The "tel" URI telephone number is not restricted in the type of
>>>>    termination point it refers to.  The termination point can be in the
>>>>    public telephone network, a private telephone network or the
>>>>    Internet. The termination point can be fixed or wireless and address
>>>>    a fixed wired, mobile or nomadic terminal.  The terminal addressed
>>>>    can support any electronic communication service (ECS) including
>>>>    voice, data and fax.
>>>
>>> Sigh... here is another case where the tel URI's confusion about what 
>>> it really is, is getting us into trouble.
>>>
>>> If you think about the tel URI as a urn scheme, whereby resolution to 
>>> an actual set of communication resources is done using a resolution 
>>> service (ala DDDS), then it becomes fairly obvious (to me at least) 
>>> that you would simply never even put that URN into the <contact> of a 
>>> presence document, since it doesnt represent a communications service 
>>> at all. If anything, it's closer to a presentity identifier. Rather, 
>>> you would put the individual service URIs that result from the DDDS 
>>> lookups.
>>>
>>> However, the tel URI is somewhat schizophrenic. Its not a URN, even 
>>> though it can use (but doesnt require) URN-like resolution services 
>>> such as enum. It's like a URN in that it can refer to an abstract 
>>> name and be resolved to a wealth of different URIs of many different 
>>> schemes and services. Its unlike a URN in that it is also used to 
>>> refer to telephone resources, and the implication of the tel URI is 
>>> that "I can dial this from a PSTN phone or enterprise phone and reach 
>>> something". In that aspect, its more like a protocol URI.
>>>
>>> What does this mean for presence? To be honest, in the discussion in 
>>> the data model draft, I have assumed the protocol URI meaning. That 
>>> is, it refers to a PSTN (or private network) circuit endpoint, 
>>> period. That, of course, is a BIG assumption, and something we should 
>>> discuss. I would propose that we keep this assumption and merely 
>>> state it. In such a case, it would not make sense for the recipient 
>>> of a presence document to look up  such a tel URI in enum. Rather, it 
>>> knows its a telephony resource right away and can "dial it".
>>
>> This feels wrong to me.
>>
>> I think it is better viewed as "this CAN be reached via the PSTN, and 
>> MAY also be reachable other ways". At the very least, if I choose to 
>> use this published address, and there are ENUM entries for it, I 
>> should be free to use them (potentially making an e2e sip call).
> 
> 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.

> Indeed, how could one usefully put attributes into the tuple when the 
> actual service could be anything?

You put the attributes you want to advertise. They should be attributes 
that are realizable via that address.

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

Not too far from what a SIP uri tells you. :-)

That is why capabilities are important.

 > What
> to do with it will be interpreted differently by different watchers.

Within the bounds of what the capabilities say. I think this is goodness.

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.

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

	Paul


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