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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Oct 2004 23:24:41 -0400

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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Oct 2004 10:33:51 -0400

Jonathan Rosenberg wrote:
>>> 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 
>>> 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.
>>
>> 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).
> 

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.

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

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.

> the world that I'm reachable at this service through this particular 

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

---

From: "Jimmy Chen" <[email-masked]>
Date: Thu, 7 Oct 2004 18:13:22 +0800

Hi:

I had saw example from XCAP (draft-ietf-simple-xcap-03, P.21).
   <?xml version="1.0"?>
      <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
                   version="0" state="full">
        <watcher-list resource="sip:[email-masked]"
package="presence">
          <watcher status="active"
                   id="8ajksjda7s"
                   duration-subscribed="509"
                   event="approved" >sip:[email-masked]</watcher>
          <watcher status="pending"
                   id="hh8juja87s997-ass7"
                   display-name="Mr. Subscriber"
                   event="subscribe">sip:[email-masked]</watcher>
        </watcher-list>
      </watcherinfo>

So, I would like to know is there any plan to work out an application usage
for "Watcher-List". Or, there is no need for such usage.

Thanks for your kindly answers.
Jimmy Chen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Oct 2004 17:06:02 -0400

inline.

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

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?

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

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

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?

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

> least voice and whatever else the phone can do concurrently in a session 

And so this gets looked up in enum, and you get back an HTTP URI. What 
does *that* mean?

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.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Oct 2004 19:54:58 -0400

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, 

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.

> stuff that help us say what we mean.

True.

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

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

If it hurts, then don't do it.

Sure there are nonsense cases. But there are a lot of useful cases too.

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

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.

> capabilities. What do service independent capabilities mean? Can you 

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.

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

>>> 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?
>>
>> least voice and whatever else the phone can do concurrently in a 
>> session via the tel address.
> 

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.

> means. I am fearful that this is another example of that problem.

I just don't see this as a practical problem.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Oct 2004 20:22:28 -0400

> stuff that help us say what we mean.

Nothing prevents a SIP redirect server from returning a mailto Contact, 
for example, so there doesn't seem a fundamental difference except of 
how the indirection occurs, whether by DNS or SIP. Even the SDP could 
contain some kind of chess application sharing protocol, which is hardly 
more meaningful than mailto to somebody that only expects audio.

> define useful attributes in that context?

Couldn't you do this with prescaps in the presence document?

> characterize the service associated with a name, when the name can 

I don't see the difference. Both URLs can be described using prescaps. 
For both, you can get redirected to any resource whatsoever, including 
HTTP and email. In both cases, what's advertised in prescaps may or may 
not correspond to what's actually available.

> capabilities. What do service independent capabilities mean? Can you 

Are you suggesting that prescaps only be used for SIP URIs? Why couldn't 
they be used for tel and h323 URIs, to give two obvious examples? 
(Clearly, you couldn't use them there to restrict service, but only to 
describe service. That's a somewhat different problem, which has more to 
do with the limitations of H.323 than URI schemes.)

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Oct 2004 00:08:54 -0400

There is no need for an application usage. The XML is from the schema
defined in RFC 3858, and is used here merely to demonstrate the usage of
selectors.

-Jonathan R.