Re: [Simple] Presence Data Model: Identifying services

[Paul Kyzivat <[e-mail]>]

Aki Niemi wrote:
> 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...

Well, you could advertise support for it in your presence document. :-)

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

Why not a SIMPLE-SMS gateway?

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

I think it is reasonable to assume that a tel: address is reachable via 
the PSTN, and hence presumably supports some media usable in that way. 
But it may also support other media when accessed via a protocol (like 
SIP) that supports them.

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

I'm not sure.

The PIDF xml schema says that it can be anyURL. The description of the 
<presence> element says: "The value of the 'entity' attribute is the 
'pres' URL of the PRESENTITY publishing this presence document." But 
AFAIK "is" isn't normative, so the schema takes precedence. I know use 
of sip: urls is common, so I see no reason why tel: couldn't also be used.

Of course there would be the issue of discovering the presence server 
when using a tel: uri as a presentity address. If I know how to use sip 
for presence, then an enum mapping from the tel address to a sip address 
would do the trick. But then I suppose the PS would use the sip address 
as the entity.

 > then that
> presence document would simply state the status of telephony services,
> nothing more.

Why? It can describe everything that is available. And it can use the 
tel address in the tuples if it likes.

	Paul


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