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

From: Goeman Stefan <[email-masked]>
Date: Fri, 24 Sep 2004 16:31:07 +0200

Hello,

Comments inline.

Greetings,
Stefan.

> > On second thought, I realized that there is one problem:
> > How will this work together with the Authorization rules.
> 
> I think you are imagining a problem here. I don't think it makes much 
> sense for the client to determine authorization, beyond simply being 
> authorized to subscribe to presence. If the PS gives you the 
> info, just 
> display it. The PS can filter out what it thinks you should 
> not see or do.
>
I think we are talking about different things here. I was taking about me as
presentity managing and editing my own authorization rules. Since my
presence information is also "my property" I would expect that I would be
able to play the role of a rule maker. Clearly, you have to edit your rules
somehow, via some device.
 
> In any case there is no good way for a client to determine if it is 
> permitted to do something, short of trying to do it.
> 
> 	Paul
> 
>  > Here, again, you
> > have to present the authorization rules in a meaningful 
> manner (via some
> > front end user interface). If I am correct, the idea is to 
> retrieve the
> > authorization rules via XCAP from the policy server, make 
> some changes and
> > provide the changes back to the policy server via XCAP.  
> Yet, the policy
> > server is not aware of any services like IM, voice call, 
> ... . So, again,
> > the device should make this mapping. This works well if you 
> only use one
> > device. But, if you use more than one device, with 
> different capabilities
> > and services, it does not work anymore. A device can't say something
> > meaningful over a service it does not support. 
> Consequently, you can not
> > edit every aspect of the authorization rules on your 
> device. I think this is
> > problematic, and I don't see a good solution right know.
> > 
> > Greetings,
> > Stefan. 
> > 
> > 
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:[email-masked]] 
> >>Sent: donderdag 23 september 2004 17:47
> >>To: [email-masked]
> >>Cc: Goeman Stefan; [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
> > 
> 

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

---

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

> somehow, via some device.

Oh, sorry. Yes, the presentity does have to manage rules for what will 
be provided to subscribers. There is already much work on that.

	Paul