[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
> -----Original Message-----
> From: Niemi Aki (Nokia-NRC/Helsinki)
> Sent: 12.October.2004 11:15
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: ext Paul Kyzivat; Jonathan Rosenberg; Isomaki Markus
> (Nokia-TP/Espoo); SIMPLE WG
> Subject: RE: meaning of tel URI in presence data model, was:
> Re:[Simple]Presence Data Model: Identifying services
>
>
> 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?
What do you mean by "dial that number"? How is an INVITE request handled when it has a tel-URI in the request-URI besides doing an enum lookup?
/Hisham
> 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."
>
> 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