Re: [Simple] Presence Data Model: Identifying services

[Aki Niemi <[e-mail]>]

Inline.

On Fri, 2004-09-24 at 16:59, ext Paul Kyzivat wrote: 
> > Hmm... If the scheme is that ambiguous, then perhaps its definition
> > needs to improve.
> 
> 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.)

There is a big difference. I can safely assume that for sip:, I am able
to send a SIP request and the other end will understand it; but probably
not an HTTP request, or let's say an SMTP message using that URI.

I admit tel is more problematic, since it is more of a name, really
without a protocol attached to it, and sending a SIP request to it might
actually work (because we've defined what that means). But the inverse
isn't true, since POTS phones don't do IM or anything fancy like that.
That's why I think it's futile to build support for them on top of tel.

BTW, there is also really no way to know whether I can send an SMS to
that telephone number (outside of recognizing it as a mobile number).
Which is one of the reasons an explicit smsto URI would be nicer...

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

Right, but I definitely don't think that IM or voice+IM session are
ECSs. SIP happens to have a linkage in that if I INVITE a tel URI with
appropriate media (e.g., voice or fax), then it may work if there is an
appropriate GW in place or a termination point that speaks SIP.

> >>For instance, it may prove convenient to publish a tel URI for a sip 
> >>endpoint that is capable of both voice and IM. Then calls via the
> PSTN 
> >>will work, calls from a sip audio phone will work, calls from
> another 
> >>voice+im client will have access to voice and IM.
> > 
> > IMO the most obvious solution here is that if the endpoint wants to
> > advertize services other than (or in addition to) telephony, it
> > publishes a SIP or IM tuple as well as a tel tuple. Is there a
> reason
> > this would not work?
> 
> I don't see a problem here, and so I don't feel a need for a solution.
> 
> I agree that other address forms are probably desirable in this case, 
> for a variety of reasons. But that doesn't mean we should
> automatically 
> assume tel: implies voice telephony and only that.

I think we have to assume tel implies some telephony, or ECS service
(whatever that means). If a presentity wants to advertize services
beyond those, then it is only reasonable that those other contacts are
also shown in presence.

> One place where this situation may well come up is when the tel: uri
> is 
> used as the presentity address. (Something that should be ok, and
> makes 
> sense to use if you are a client and that is all you have.) It may be 
> that the user doesn't want to expose device addresses, and so provides
> only the presentity address back as the contact in the tuple(s).

I don't understand what the problem there is. Even if tel URI was
allowed as the entity attribute in PIDF (which it isn't AFAIK) then that
presence document would simply state the status of telephony services,
nothing more.

Cheers,
Aki



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