[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Aki Niemi wrote: 
On Tue, 2004-10-12 at 10:00, Khartabil Hisham (Nokia-TP-MSW/Helsinki)
wrote:

I agree that an entity forwarding the SIP INVITE request will most
likely choose a routable URI like SIP and not a http URI after doing
an enum lookup. What you can't guarantee is that a routable URI, like
a sip URI, is available in an enum lookup. A presence publisher (PUA)
has no means of making that determination unless it performs an enum
lookup itself before placing the tel-URI in a presence document. Not
all terminals/UAs can perform enum lookups.



You shouldn't assume that an ENUM query is needed before a tel URL can
be used. What if my UA decides to actually dial that number? This is the
lowest common denominator when it comes to UAs using tel URLs. This is
also the reason why I think the only meaning we can give a service tuple
with tel URL as contact is: "Here's a telephone number. You can dial it
to reach me."

I don't disagree with you. This could indeed happen, and would be valid usage. But that SHOULD only be attempted when the presence status and capabilities are consistent with that usage. (It would be normal that they should be.)

The main advantage is for advertising a superset of what you could achieve that way. For instance you could show audio, video, and IM capabilities with this tel address. The watcher will then know that you can be called from a pstn rotary phone for voice, but that it might be advantageous to use a multimedia UA if one is available. That multimedia UA may be able to use enum, discover a sip address, and establish a multimedia session.

(I get the impression that some people think that a single device should advertise regular telephony (voice only), and video phone (voice + video) as two services. I have never understood that, since one is a superset of the other.)

	Paul

Cheers,
Aki


Regards,
Hisham


-----Original Message-----
From: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org]On Behalf
Of ext Paul Kyzivat
Sent: 12.October.2004 02:55
To: Jonathan Rosenberg
Cc: Isomaki Markus (Nokia-TP/Espoo); Niemi Aki (Nokia-NRC/Helsinki);
SIMPLE WG
Subject: Re: meaning of tel URI in presence data model, was: Re:
[Simple]Presence Data Model: Identifying services




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,

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,

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.


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. 

True.


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?

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.


Indeed, how could one usefully put attributes into the

tuple when the

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.

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

If it hurts, then don't do it.

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


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.

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.


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?

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.


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.

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.

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.


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.

And so this gets looked up in enum, and you get back an

HTTP URI. What

does *that* mean?

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.


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. 

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

	Paul


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple





_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple