Subject: [Simple] Presence Data Model: Identifying services

From: [email-masked]
Date: Thu, 23 Sep 2004 11:10:21 +0300

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

Of course each of these proprietary services are allowed to define additional status or tuple-level extensions to PIDF. 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 _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. 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?

Regards,
	Markus 

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

---

From: Aki Niemi <[email-masked]>
Date: Wed, 29 Sep 2004 11:13:05 +0300

Hi Markus,

I think the service-features draft is 50% right. As you also point out,
the URI scheme provides rudimentary service classification that in most
cases is sufficient and provides helpful information for the watcher.

But I also don't quite agree with the way service-features uses prescaps
to advertize service capabilities. A super-UA may boast a range of
capabilities leaving the watcher clueless about the actual combinations
of those capabilities that will work. In fact, the more capabilities the
UA boasts, the more useless the information -- the watcher will have to
resort to "trial-and-error", which is anyway the default behavior in the
absence of any prescaps.

Splitting the information into separate tuples, each describing a
specific "service" offered will suffer from the same or worse
"combinatorial explosion" that the draft describes.

I guess I also somewhat agree with Paul's argument that your proposal
merely adds syntax without assigning semantics. Also, XML already has a
fairly clean namespace structure, so the Java-style naming convention
seems superfluous.

In general, there seems at least three orthogonal things a presentity
may want to communicate to the watcher:

i) what communications mean to use?
	* Including what capabilities this medium has
	* In practice, the <contact> + prescaps 
ii) what "application" am I running?
	* This is basically the service-id element
iii) in what state is that application? 
	* Currently not covered
	* Application specific

This in mind, I think we are ultimately talking about extending the
<status> element to express application-specific statuses. After all, I
may have several SIP-based applications that are all in a different
state. For example, I may be in "accepting-new-chess-moves" for my chess
application (running on IM), but in a "please-don't-disturb" mode for
push to talk.

A status extension would implicitly also carry something akin to a
service-id, but instead of just a simple ID, it would have real
meaningful status information as well.

But, I don't know if there is much to standardize here beyond explicitly
mentioning that this is the best extension point for application-id type
features in presence. Seems natural that we should discuss this point in
the data model for presence.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2004 11:48:14 -0400

Aki,

I think you make some good observations here. More inline.

	Paul

Aki Niemi wrote:
> of those capabilities that will work.

Well, ideally the capabilities are orthogonal to one another, so that 
all combinations are possible and meaningful. Certainly callee 
capabilities notation that prescaps is based on assumes that the 
capabilities are orthogonal. If this is not the case then some other 
representation is called for. (E.g. multiple tuples)

 > In fact, the more capabilities the

To some extent this is in the hands of the device implementors. If there 
are lots of complex rules about what can be used with what, then the 
description of the device with inherently either be complex or imprecise.

The obvious answer is: if it hurts, don't do it.

> 	* This is basically the service-id element

I finally start to warm to the concept when it is described this way.

I think we already have *some* notion of this concept of application 
within callerprefs/calleecaps: certainly actor=msg-taker (and maybe 
actor=attendant) are describing a form of application.

Perhaps this should be generalized further. If so, I think it has as 
much value for callerprefs as it does for presence, so I would argue for 
adding it to callee caps first and then bringing it into presence via 
prescaps.

I think it is going to be quite difficult to come up with a clear and 
concise discrimination between what is an application and what is 
communications means. Luckily, if done via prescaps there is no real 
need to make the distinction.

> application (running on IM), but in a "please-don't-disturb" mode for

That seems like kind of a mixed bag for a single tuple. It sounds like a 
valid application for multiple tuples.

(Would I really have have the IM at this address dedicated to chess, 
while the PTT isn't? I don't think so.)

I have a sense that the "applications" that share an address are really 
just part of the means of communication. A "real" application would 
probably utilize all the communication modalities that are available at 
that address - if it didn't, they wouldn't be available.