Subject: RE: [Simple] Presence Data Model: Identifying services

From: [email-masked]
Date: Thu, 23 Sep 2004 15:34:08 +0300

Hi Stefan,

Comments back to you inline. 

(Yes, I absolutely agree with you on the usefulness of the Presence Data Model draft and that it should have been the starting point, at least right after PIDF.)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Goeman Stefan
> Sent: 23 September, 2004 14:42
> To: [email-masked]'
> Subject: RE: [Simple] Presence Data Model: Identifying services
> 
> 
> Hello,
> 
> Comments inline
> 
> P.S.: In general, I find the Presence Data model draft a good 
> document. This
> is how things should have started in the first place.
> 
> Greetings,
> Stefan.
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> > Sent: donderdag 23 september 2004 10:10
> > To: [email-masked]
> > Subject: [Simple] Presence Data Model: Identifying services
> > 
> > 
> > Hi all,
> > 
> > I have a comment on Presence Data Model draft about the 
> > identification/characterization of services. (I know this has 
> > been discussed for a while already, but I still think the 
> > current way is somewhat unadequate.)
> > 
> > The current Data Model draft says:
> > 
> >    In this model, services are not explicitly enumerated.  That is,
> >    there is no "service" attribute with values of "ptt" or 
> > "telephony".
> >    Rather, the service is identified in one of two ways.  In 
> > many cases,
> >    the URI scheme is a clear indicator of service.  An "sms" 
> > URI clearly
> >    indicates SMS, and a "tel" URI clearly indicates 
> > telephony.  For some
> >    URIs, there may be many services available, for example, 
> SIP.  For
> >    those services, each service has a set of 
> characteristics, each of
> >    which has a well-defined meaning, such that a system can
> >    unequivocally determine whether or not the service has that
> >    characteristic.  This is discussed in more detail in [5]. 
> > 
> > I agree that the contact URI scheme is the most important 
> > piece of information to distinguish what is the "service". 
> > (There are some gaps here too, since e.g. the URI schemes for 
> > SMS or MMS do not even exist, and there may be other non-IETF 
> > protocols that face the same problem.) However, I'm not 
> > convinced that listing the signaling/media characteristics of 
> > the end-point or service really gives enough information to 
> > the watcher to really determine if it can communicate with 
> > the advertised service/application. 
> > 
> > The refenced draft [5] has a following example:
> > 
> > 5.6 Walkie-talkie
> > 
> >    The walkie-talkie service allows real-time voice communication
> >    between participants.  Only one participant can speak at a 
> > time; that
> >    is, communication is half-duplex.  Typically, 
> participants press a
> >    button to indicate that they are ready to speak, although other
> >    mechanism (e.g.  voice activation) are occasionally used.
> > 
> >    Support for the Walkie-Talkie service can be deduced by 
> > observing the
> >    presence of a contact URI with a scheme of "sip:", 
> associated with
> >    the following minimal set of capabilities: <audio>true</audio>
> >    <duplex>half</duplex> <methods>INVITE,ACK,BYE,CANCEL</methods>
> > 
> > Presumably this is the same as the service sometimes called 
> > Push-to-Talk (PTT, PoC). The concrete problem is that there 
> > are several _non-interworking_ variants of this service, that 
> > still all would match the characteristics listed above, as 
> > the _SIP_ part might still be standard, at least for some 
> > methods etc. But still the communication would fail even if 
> > the tuple looks OK.
> I don't think I understand you here. I would expect that if 
> both end-point
> SIP US support exactly the same methods, the SIP UA should 
> also be able to
> handle those SIP method. Or, to phase it in another way, both 
> end-point
> should be able to communicate with each other only based on 
> using these
> capabilities.
>

To some extent that might be possible, but there might be differences e.g. in floor control etc., which make the service still practically unusable, which means that the presence document shouldn't give the impression that the communication will work. Obviously it is possible to list all those additional characteristics as well (and this might be a good idea too), but for instance if presence of a network game is published, it is easier to _explicitely_ tell what the game is by providing some sort of unique id which would be only meaningful to those similar game clients.  
 
> > (Also if I saw the characteristics above, 
> > I could as well determine that they describe normal VoIP 
> > application running in (very) some old PC with half-duplex 
> > audio drivers, so I claim the service description is hard to 
> > make unambiguous in the first place.)  
> >
> I also have the impression that it will be difficult to determine the
> services merely based on the SIP methods (and ...) supported 
> by the SIP UA.
> It possibly might mean that the SIP-based ptt-service on my 
> mobile phone
> might be mapped onto some communication service on your PC. 
> Then, I wonder
> who will be responsible for such kind of mapping? Only the 
> end terminals, or
> is support from the network, presence server, necessary? And, 
> how will one
> service in one domain be mapped into a service in another 
> domain? I believe
> there are some open issues here. 
>

I think that it is fully OK to describe some rather simple things using characteristics, but in many cases applications are more complex.
    
> > I think the main point of a service tuple is to give the 
> > watcher enough information to know whether he can really 
> > communicate & interoperate with the advertised service. Given 
> > that many services taht are using SIP also have propritary or 
> > non-SIP features, I don't think the current approach is enough. 
> > 
> Do you have an example of a service that uses SIP and also has non
> SIP-features? If your service also uses non-SIP features, you can not
> determine the type of service by only looking at the SIP capabilities
> supported by the SIP UA. Some indication of that non-SIP 
> feature should also
> be present in the presence document. 
> 

True, and since some of those non-SIP features might not be based on (IETF) standards, it might be good to have the possibility for the developers of such applications to have a short cut of saying what the app really is, rather than having to list characteristics. In the end, some applications are really not even meant to work with any other than the exactly same application, for instance some networking games. 

> > Of course each of these proprietary services are allowed to 
> > define additional status or tuple-level extensions to PIDF.
> Yes, you can always extend the PIDF. My comment here is that 
> this might lead
> to an "explosion" of applications or services. It will 
> certainly not help
> interoperability.
>  

And who would standardize such characteristic definitions. It has already taken a couple of years to standardize even "prescaps", which is just a starting point. 

> > However, I would like to have some kind of "service 
> > identifier" as part of the basic framework so that this could 
> > be done in a consistent manner. I think it would help 
> > especially in making of authorization and composition rules 
> > more simple. The current "class" attribute is way too 
> loosely defined.
> > 
> > So the concrete proposal is to include in RPID a "service id" 
> > element that would have a vendor-specific namespace, similar 
> > to e.g. vendor-specific XCAP AUIDs. So for instance the 
> > SIP-based PTT app from vendor xyz.com would have, e.g. 
> > 
> > <service-id>com.xyz.ptt</service-id>
> > 
> > while the PTT app compliant with OMA would have, e.g.
> > 
> > <service-id>com.openmobilealliance.ptt</service-id>
> > 
> In general, I could agree with that approach. However, I 
> don't see a reason
> why the vendor specific SIP-based PTT should be different 
> from the OMA based
> PTT. Simply define one PTT, based on the SIP UA capabilities.
> 

Well, for instance Nokia has a prorietary PTT application, which uses SIP INVITE etc., so users are essentially addressed with sip: URI. However, it has some floor control, media etc. features which make it basically non-interoperable with clients that are not specifically following that proprietary spec. 

OMA PTT is closer to standard IETF SIP. Unless there is some conversion, it does not work with Nokia PTT directly. There should be some way for distinguishing these two in a presence document, so that there won't be confusion. I think the current idea is to do some kind of proprietary PIDF extensions, but in my opinion a standard XML element in RPID to tell this kind of information would be better, also for the purposes of authorization rule making.

> > in _addition_ to describing sip:, half-duplex audio, and the 
> > supported methods. Now:
> > 1.) Watcher having one of those apps could see right away 
> > whether it is possible to communicate
> > 2.) Composer getting PUBLISHes from 2 sources could 
> > immediately know that they are from a similar app
> > 3.) The app could set its authorization rules using the unique id.
> > 
> > The main downside I can see in this approach that if there 
> > are two different proprietary apps that indeed could 
> > communicate at least partially, the watcher might make a 
> > conclusion that communication is not possible baed on 
> > different service-id. However, in this case the watcher still 
> > would have the characteristics visible and could determine 
> > that some interworking could be achieved. 
> Personally, I don't think it is a good idea that an end-user 
> should make
> such decission. If I get a presence document that indicates 
> that another
> person is able to receive some type of communication, I 
> expect that that
> type of communication would actually work when I use it.
> 

Exactly right. If you are an application who does not necessarily aim for interoperability, but still uses sip:, INVITE etc., you should be able to explicitely say so.

> >For this kind of 
> > reasons there should be careful text about when to use 
> > service-id in the first place, and what can be determined from it.
> > 
> > Does someone think that this is an absolutely bad idea? If 
> > so, how would you envision solving the issues discussed above?
> > 
> I think more care should be taken in mapping SIP UA 
> capabilities into actual
> services. That is not so clear to me!
>

The idea is nice, but I don't see a problem in _addition_ defining the application with something like "com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind of profile would have more meaning than the list of characteristics.
 
> 
> > Regards,
> > 	Markus 
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

Markus

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Sep 2004 11:46:53 -0400

I have comments both to Markus' original posting and to the ensuing 
discussion. So I will just insert inline in the latest response I have.

	Paul

[email-masked] wrote:
>>>telephony. 

I don't find the scheme as clearcut as that. I don't think one should 
assume "tel" indicates telephony. It perhaps does imply reachability via 
various telephony protocols for purpose of voice communications, but is 
not exclusive to that. If the tel: URI can be mapped to a sip endpoint 
and protocol, then non-voice, non-telephony capabilities are not excluded.

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.

 >>> For some

I think the goal should be that all of these are at least minimally 
interoperable. I ought to be able to call a PTT contact from a regular 
voice phone and have *something* reasonable happen. (Maybe it is just 
oneway voice, with the non-ptt caller never getting the floor, but that 
may be better than nothing.

I think the real problem in this case is not with the capability 
approach. It is that the 'duplex' capability is underspecified. There is 
no explanation of how a pair of half duplex endpoints (or one 
half-duplex and one full-duplex endpoint) agree on who can talk.

In the case of the 'voice' capability, it is understood that having both 
endpoints support voice isn't enough to support communication. There is 
an SDP negotiation of codecs, etc. that either succeeds or fails. There 
should be something similar for half-duplex.

>>there are some open issues here. 

The intent is that capabilities have common meanings in all domains, so 
they don't need to be mapped. I don't see why there should be any 
binding between services and domains.

In the general case one should assume that there are devices of widely 
varying capabilities in every domain, and that they know best what they 
are capable of. So the device should be the one deciding if a contact 
with and advertised set of capabilties is something it wants to attempt 
communication with.

In some environment where there is an intermediary in front of a device 
that understands the device and acts on its behalf, then I suppose it 
could make these decisions. But I would consider that the odd case.

> I think that it is fully OK to describe some rather simple things using characteristics, but in many cases applications are more complex.

Clearly we have chosen not to describe capabilities if full detail. 
(E.g. we don't publish codec support.) Because of this, there is the 
possibility that we make a wrong decision about ability to communicate 
and it doesn't get discovered until we try.

This is ok when the expected probability of failure is low. (We 
generally expect that there will be some codec in common, or that one 
end or the other will be able to introduce a transcoder.)

>>>non-SIP features, I don't think the current approach is enough. 

In cases where the existing capabilities aren't sufficient to ensure a 
good probability of communication, then we should indeed consider adding 
additional capabilities.

But I continue to object to the notion of "service" as the way to do 
that, because it conveys no semantics about what the capability is that 
it describes.

> True, and since some of those non-SIP features might not be based on (IETF) standards, it might be good to have the possibility for the developers of such applications to have a short cut of saying…

If the intent is to define a closed world, where interoperability is not 
even considered a desirable feature, then I agree. I think that may 
indeed be the case for proprietary games.

But for something like PTT, while it might be in the best interest of 
the maker of a particular PTT solution to keep it closed, I don't think 
it is in the best interest of society or the IETF that this happen. This 
is precisely the forum in which we try to prevent that from happening.

>>to an "explosion" of applications or services. It will 

My point precisely.

>>><service-id>com.openmobilealliance.ptt</service-id>

I am not fond of this solution. Done this way, we have defined an 
element that has no semantics at all, only syntax.

I would rather see vendor specific extensions to PIDF. At least then the 
people that support an extension will understand what it means.

But I would rather see people come forward and do the hard work of 
publicly defining new capabilities so that independent implementations 
can use them in an interoperable way.

> Well, for instance Nokia has a prorietary PTT application, which uses SIP INVITE etc., so users are essentially addressed with sip: URI. However, it has some floor control, media etc. features whic…

This is a problem, not a good thing. I realize it has to happen as part 
of the development process, but the goal should be to get out of it as 
fast as possible.

I would hope that endpoints supporting this would be described as well 
as possible using existing capabilities, and that a reasonable effort be 
made to do something reasonable when some other sip device connects.

If you really can't deal with a regular voice caller at all, then I 
would suggest, as a transitional step, saying that you don't support 
voice, and then advertising some proprietary capability as an 
alternative to voice.

> OMA PTT is closer to standard IETF SIP. Unless there is some conversion, it does not work with Nokia PTT directly. There should be some way for distinguishing these two in a presence document, so t…

See above for what I think you could do for now. The same issues may 
apply to OMA PTT, and a similar solution could be applied to it.

Hopefully somebody will come up with a PTT that can be dealt with more 
gracefully. I think that work should be done on better defining 
half-duplex, so that it can be used in conjunction with voice to 
describe PTT. But it may just turn out to be the wrong thing. Maybe we 
need a "floor-control" capability.

>>>different service-id.

This is my concern as well.

 >>> However, in this case the watcher still

With high probability. There are no guarantees with presence. For 
instance see my mention above of codecs.

> Exactly right. If you are an application who does not necessarily aim for interoperability, but still uses sip:, INVITE etc., you should be able to explicitely say so.

And you can, without a special notion of service.

>>>so, how would you envision solving the issues discussed above?

I still don't buy this.

> The idea is nice, but I don't see a problem in _addition_ defining the application with something like "com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind of profile would have more meani…

I am still opposed to defining an attribute with no semantics.
We have been around this so many times that I am quite certain that it 
will never be possible to get a useful agreement on what "service" means.

If it is introduced, I expect it to have problems like those of the INFO 
method. (The arguments for introducing it seem similar.)

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Fri, 24 Sep 2004 15:37:04 +0300

> and protocol, then non-voice, non-telephony capabilities are not excluded.

Hmm... If the scheme is that ambiguous, then perhaps its definition
needs to improve.

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

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2004 09:59:00 -0400

> Hmm... If the scheme is that ambiguous, then perhaps its definition

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

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.

> publishes a SIP or IM tuple as well as a tel tuple. Is there a reason

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.

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

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Sep 2004 11:27:29 -0400

inline.

[email-masked] wrote:

> (Yes, I absolutely agree with you on the usefulness of the Presence
> Data Model draft and that it should have been the starting point, at
> least right after PIDF.)

Thanks! Obviously I agree its a good thing ;)

> 
> To some extent that might be possible, but there might be differences
> e.g. in floor control etc., which make the service still practically
> unusable, which means that the presence document shouldn't give the
> impression that the communication will work. Obviously it is possible
> to list all those additional characteristics as well (and this might
> be a good idea too), but for instance if presence of a network game
> is published, it is easier to _explicitely_ tell what the game is by
> providing some sort of unique id which would be only meaningful to
> those similar game clients.

I think there are two aspects to this.

Firstly, I think we have a bunch of "SIP endpoints", like your PTT 
phone, which use SIP as a core technology, but don't interoperate with 
any other SIP endpoint. We've designed SIP to *be* interoperable, so if 
its not, its telling me that your protocol really isn't SIP after all. 
In such a case, I would suggest you register a new URI scheme for it, 
for example, ptt:user@domain, to indicate this. I think this is a 
scheme, since the point of a URI is to provide full context required to 
communicate. If sip:user@domain isn't providing that context since there 
are proprietary changes which prevent communication from compliant SIP 
endpoints, the scheme needs to be changed.

That said, there are cases where an endpoint is 100% sip compliant, but 
still it cannot communicate with another endpoint. Assuming proper 
behavior in terms of falling back to baseline usages when extensions 
aren't supported, I can only think of really a small number of reasons 
why this would happen:

1. Endpoints A and B do not support a common codec for the media types 
they have in common,

2. Endpoints A and B do not support a common set of media types

For the specific case of PTT, where "if you don't support this floor 
control technique, the call won't be set up", I put that in the first 
category (cases where its not really SIP). Thats because a SIP endpoint 
should be able to proceed with a call if extensions or features are not 
utilized. If you are not doing that because they are essential to the 
service, then it's something different.

The second case above (no common media or codecs) is solved in part in 
the presence document, where the supported media types are listed. We 
have elected not to include codecs in presence documents, so that case 
cannot be detected.

Of course, a call can always fail even if there are no protocol interop 
problems - I may call you, you insist on video, and since I don't do 
video, you elect not to proceed with the call. That's a **policy** 
problem, and I do not think it is the role of presence to generally 
convey the policies which are required to be in place for a call to 
complete. Perhaps others have different opinions.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Sep 2004 11:37:14 -0400

inline.

Paul Kyzivat wrote:

>>> assume "tel" indicates telephony. It perhaps does imply reachability 
>>> via various telephony protocols for purpose of voice communications, 
>>> but is not exclusive to that. If the tel: URI can be mapped to a sip 
>>> endpoint and protocol, then non-voice, non-telephony capabilities are 
>>> not excluded.
>>
>>

Sigh... here is another case where the tel URI's confusion about what it 
really is, is getting us into trouble.

If you think about the tel URI as a urn scheme, whereby resolution to an 
actual set of communication resources is done using a resolution service 
(ala DDDS), then it becomes fairly obvious (to me at least) that you 
would simply never even put that URN into the <contact> of a presence 
document, since it doesnt represent a communications service at all. If 
anything, it's closer to a presentity identifier. Rather, you would put 
the individual service URIs that result from the DDDS lookups.

However, the tel URI is somewhat schizophrenic. Its not a URN, even 
though it can use (but doesnt require) URN-like resolution services such 
as enum. It's like a URN in that it can refer to an abstract name and be 
resolved to a wealth of different URIs of many different schemes and 
services. Its unlike a URN in that it is also used to refer to telephone 
resources, and the implication of the tel URI is that "I can dial this 
from a PSTN phone or enterprise phone and reach something". In that 
aspect, its more like a protocol URI.

What does this mean for presence? To be honest, in the discussion in the 
data model draft, I have assumed the protocol URI meaning. That is, it 
refers to a PSTN (or private network) circuit endpoint, period. That, of 
course, is a BIG assumption, and something we should discuss. I would 
propose that we keep this assumption and merely state it. In such a 
case, it would not make sense for the recipient of a presence document 
to look up  such a tel URI in enum. Rather, it knows its a telephony 
resource right away and can "dial it".

Comments?

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Fri, 24 Sep 2004 18:54:36 +0300

Inline.

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

>     can support any electronic communication service (ECS) including

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.

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

> 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

---

From: Mike Hammer <[email-masked]>
Date: Fri, 24 Sep 2004 12:32:41 -0400

At 11:37 AM 9/24/2004 -0400, Jonathan Rosenberg wrote:
>>AFAIK, tel: is an addressing format and namespace. The following is 
>>from  draft-ietf-iptel-rfc2806bis-09:
>(ala DDDS), then it becomes fairly obvious (to me at least) that you would 
>simply never even put that URN into the <contact> of a presence document, 
>since it doesnt represent a communications service at all. If anything, 
>it's closer to a presentity identifier. Rather, you would put the 
>individual service URIs that result from the DDDS lookups.
>
>However, the tel URI is somewhat schizophrenic. Its not a URN, even though 
>it can use (but doesnt require) URN-like resolution services such as enum. 
>It's like a URN in that it can refer to an abstract name and be resolved 
>to a wealth of different URIs of many different schemes and services. Its 
>unlike a URN in that it is also used to refer to telephone resources, and 
>the implication of the tel URI is that "I can dial this from a PSTN phone 
>or enterprise phone and reach something". In that aspect, its more like a 
>protocol URI.
>
>propose that we keep this assumption and merely state it. In such a case, 
>it would not make sense for the recipient of a presence document to look 
>up  such a tel URI in enum. Rather, it knows its a telephony resource 
>right away and can "dial it".
>
>Comments?

There was some discussion on one of the mail lists that a parameter was 
needed to indicate that an ENUM dip had already been performed and 
determined that this particular terminal must be reached by going to the 
PSTN, i.e., that it was a circuit endpoint.  That could be one of the 
things that the presence document indicates.

If one were to do an ENUM lookup and receive a list of indications of IP 
endpoints, well, I would have expected that list to have been included in 
the presence for that user in the first place.

I think it much more useful for ENUM to point to a presence address leading 
to richer data with corresponding user controls than the reverse.  So, I 
guess I'm in agreement with Jonathan.

Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2004 15:26:52 -0400

Jonathan Rosenberg wrote:
> 
>> 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.)
>>

This feels wrong to me.

I think it is better viewed as "this CAN be reached via the PSTN, and 
MAY also be reachable other ways". At the very least, if I choose to use 
this published address, and there are ENUM entries for it, I should be 
free to use them (potentially making an e2e sip call).

 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.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2004 15:49:10 -0400

> Which is one of the reasons an explicit smsto URI would be nicer...

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

> appropriate GW in place or a termination point that speaks SIP.

Why not a SIMPLE-SMS gateway?

>>>publishes a SIP or IM tuple as well as a tel tuple. Is there a
>>>reason this would not work?
>>
>>for a variety of reasons. But that doesn't mean we should
>>automatically assume tel: implies voice telephony and only that.
> 

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.

> 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

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

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 24 Sep 2004 16:15:41 -0400

> This feels wrong to me.

Agreed.

> free to use them (potentially making an e2e sip call).

To rephrase slightly: the tel: URI simply says "this is a service that 
is identified by an E.164 number" and adds a level of indirection to 
allow a separate instance to do the binding to one or more instances 
implementing this service, where the binding resolution is performed 
either at the outbound proxy (if used in a SIP device, using any method 
including but not limited to ENUM) or the end system (using ENUM or 
direct dial).

It probably helps if that number is indeed dialable (with number 
translation into a dial string) by a regular, analog phone controlled by 
  some TAPI interface. The usual phone number caveats apply: it may 
whistle at you, it may be an SMS-only number, etc.

I don't see why this level of indirection is problem or requires further 
special-casing within the presence data model.