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

From: [email-masked]
Date: Thu, 23 Sep 2004 22:51:22 +0300

Hi Paul,

Thanks for your comments. 

I guess what we both want to accomplish is this:

Allow the watcher to better understand whether and how it is able to communicate with a "service" or "communication mean" that is advertised by the presentity. 

The current approach is to list as many characteristics and parameters of the service as possible, so that the watcher has as much information as possible. In theory this works well, as long as there is some agreed set of characteristics for each possible service. In practice there are no guarantees, since some essential info, such as codec support, is probably discovered only by trial and error. The concept still works well as long as the probability of a "false positive" is reasonably low.

One idea might be that the presentity should be able to declare some capabilities as mandatory/essential, i.e. saying like "if you don't support at least capabilities A and B, please don't contact me, since there is no value in this from my point of view". An example might be PTT, where the presentity could declare support for "voice", "half-duplex", "INVITE, ..." and floor control "foo", and might insist that even if the watcher supported the same except floor control "bar", the communication should not be attempted. Obviously it would be in the power of the clients and users to decide what to declare as essential and whether to obey those declarations, but at least it would give a hint whether things would work in a reasonable way or not. The ability to declare something as mandatory/essential should apply also to characteristics not understood by the watcher, e.g. if the watcher in the example is a normal VoIP client able to do half-duplex but with no understanding of any type of floor control (except maybe on layer 9 ;-), it could still see that "some feature I don't understand seems to be mandatory, so there is a high probability that the communication will not work". In this way the evil proprietary client could hint "please don't call me even though I'm addressable with SIP unless you know what xyz and zyx are, since if you don't, the outcome may not be anything useful".

Is there any chance of adding this kind of mechanism? I guess it would be some kind of attribute that would apply to all elements describing service characteristics. I believe it should be part of the data model, so that the designers of the proprietary extensions would know how to use it. 

The hard part I see is keeping the standardized characteristics up-to-date and useful. For instance adding "floor control protocol" etc.

Markus

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 23 September, 2004 18:47
> To: Isomaki Markus (Nokia-TP/Espoo)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Presence Data Model: Identifying services
> 
> 
> 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:
> > 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. 
> 
> 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
> >>>   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 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.
> 
> >>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. 
> 
> 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.)
> 
> >>>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. 
> 
> 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.
> 
> >>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. 
> 
> 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.
> 
> >>>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.
> 
> My point precisely.
> 
> > 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>
> 
> 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.
> 
> >>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. 
> 
> 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 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.
> 
> 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.
> 
> >>>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.
> 
> This is my concern as well.
> 
>  >>> 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.
> 
> 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.
> 
> >>>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 still don't buy this.
> 
> >>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.
> 
> 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
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2004 16:34:03 -0400

Markus,

I largely agree with the comments that Jonathan made.

He suggested that the problem at hand is that your PTT isn't really sip 
if it can't interoperate with a regular sip device. That may be a bit 
extreme, but not too far off.

As I suggested in an earlier reply, you could model this by indicating 
that you don't support voice, and instead describe some other capability.

Better yet would be to actually support voice. How hard would it be to 
create a voice:ptt transcoder. Then the situation would be much like a 
codec mismatch. I don't really imagine you would do this right now, but 
that may be the long term path to true interoperability.

More comments below.

	Paul

[email-masked] wrote:
> One idea might be that the presentity should be able to declare some capabilities as mandatory/essential, i.e. saying like "if you don't support at least capabilities A and B, please don't contact me, since there is no value in this from my point of view". An example might be PTT, where the presentity could declare support for "voice", "half-duplex", "INVITE, ..." and floor control "foo", and might insist that even if the watcher supported the same except floor control "bar", the communication should not be attempted. Obviously it would be in the power of the clients and users to decide what to declare as essential and whether to obey those declarations, but at least it would give a hint whether things would work in a reasonable way or not. The ability to declare something as mandatory/essential should apply also to characteristics not understood by the watcher, e.g. if the watcher in the example is a normal VoIP client able to do half-duplex but with no understanding of a
ny type of floor control (except maybe on layer 9 ;-), it could still see that "some feature I don't understand seems to be mandatory, so there is a high probability that the communication will not work". In this way the evil proprietary client could hint "please don't call me even though I'm addressable with SIP unless you know what xyz and zyx are, since if you don't, the outcome may not be anything useful".

I fear where this approach might lead.

I think we will then end up with complex predicates.
(We have more than enough trouble that way with callerprefs, and we 
don't have a comparable description of calleeprefs.)

This would be especially problematic if it meant that the presence UI 
needed to display these constraints. (It would be slightly less bad if 
the subscriber application just applied the constraints to the 
capabilities it knows are available locally in order to filter what is 
displayed.)

> Is there any chance of adding this kind of mechanism? I guess it would be some kind of attribute that would apply to all elements describing service characteristics. I believe it should be part of…

I really hope we don't need to go there.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Sep 2004 09:21:00 -0400

I think this is an overstatement.

To keep it simple, a sip client with only a speaker and microphone can not 
effectively participate in a service which involves a video stream, even to 
be just the receiver.  He can attempt a media negotiation, but it will fail.

Similarly, if the PTT floor control is handled in the RTP / STCP (as some 
of the proposals do), then the SIP is compliant, but the negotiation 
(assuming that the SDP properly represents the details) will fail.

To call this "not SIP" seems very odd.  The SIP would be fully compliant.

Now, one can view the presence properties as a hint, and say "sometimes it 
is not enough information".  In fact, for at least some cases we need to 
say that.
But we should not pretend that the contact URI always properly (much less 
unambiguously) identifies the service.

Yours,
Joel M. Halpern

At 04:34 PM 9/24/2004 -0400, Paul Kyzivat wrote:
>He suggested that the problem at hand is that your PTT isn't really sip if 
>it can't interoperate with a regular sip device. That may be a bit