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

[Mike Hammer <[e-mail]>]

At 11:37 AM 9/24/2004 -0400, Jonathan Rosenberg wrote:
>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?

There was some discussion on one of the mail lists that a parameter was 
needed to indicate that an ENUM dip had already been performed and 
determined that this particular terminal must be reached by going to the 
PSTN, i.e., that it was a circuit endpoint.  That could be one of the 
things that the presence document indicates.

If one were to do an ENUM lookup and receive a list of indications of IP 
endpoints, well, I would have expected that list to have been included in 
the presence for that user in the first place.

I think it much more useful for ENUM to point to a presence address leading 
to richer data with corresponding user controls than the reverse.  So, I 
guess I'm in agreement with Jonathan.

Mike



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


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