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