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

[Jonathan Rosenberg <[e-mail]>]

inline.

Paul Kyzivat wrote:

> 
> 
> Aki Niemi wrote:
> 
>> On Thu, 2004-09-23 at 18:46, ext Paul Kyzivat wrote:
>>
>>> I don't find the scheme as clearcut as that. I don't think one should 
>>> assume "tel" indicates telephony. It perhaps does imply reachability 
>>> via various telephony protocols for purpose of voice communications, 
>>> but is not exclusive to that. If the tel: URI can be mapped to a sip 
>>> endpoint and protocol, then non-voice, non-telephony capabilities are 
>>> not excluded.
>>
>>
>> Hmm... If the scheme is that ambiguous, then perhaps its definition
>> needs to improve.
> 
> 
> 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".

Comments?

-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