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