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

[Jonathan Rosenberg <[e-mail]>]

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?

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


> 
>  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. What 
to do with it will be interpreted differently by different watchers.

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?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com


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