[Simple] Presence data model: devices

[Henning Schulzrinne <hgs at cs.columbia.edu>]

Let me try to formulate my concerns about devices somewhat less 
flippantly than in my earlier rush mail. I'm probably missing pieces, 
but we need to start somewhere. A fair treatment would probably require 
another draft...

I have the following concerns:

(1) Devices in the data model draft don't correspond exactly to the 
physical model that naive users have of a device. The data model states, 
for example, that

   ... it is perfectly
   acceptable to use this model to talk about that PC as being composed
   of two separate devices.

There does not appear to be any clear-cut rule that would allow a 
presentity or watcher to decide whether a single physical device 
consists of one or more logical or virtual devices. Personal-area 
network devices such as assemblies of BlueTooth gadgets pose similar 
problems, as both a view as a single device or as individual devices are 
reasonable. Locally, we have created virtual multimedia devices that 
consist of multiple pieces of plastic (a projector, a speakerphone, an 
IP array microphone). They act exactly like one multimedia device in 
most senses.

(2) Devices have ill-defined properties that are implied, but not 
stated, to the watcher.

The only architectural motivational paragraph that I could find is in 
Section 4: "Furthermore, the concept of device adds the ability to 
correlate services together.  The device models the underlying platform 
that supports all of the services on the phone.  Its state therefore 
impacts all services."

However, the types of states that are shared are implicit, not explicit. 
Clearly, devices do not share *all* states across services. For every 
possible state, there are plausible exceptions where services on the 
device do *not* share that state. I gave a few examples, but the burden 
is on the device proponent to prove that the watcher can unambiguously 
determine which states are indeed shared and why such knowledge is 
useful to the watcher. The likely case is that some states for some 
services are shared for some devices, while others are not.  (I'm 
guessing that any reasonable device will have one shared location state, 
at least at GPS resolution, but the example above shows that you can 
violate even that assumption with a bit of forward thinking.)

I agree that state inference models are useful - the draft alludes to 
that. However, many of these are probably best expressed as either local 
rules at the composer, based on local knowledge available to the 
composer, or as heuristics ("if my two mobile devices report two 
different locations, pick my Brand X cell phone since I carry that to 
job sites"; "if my cell phone service is reporting me as talking, mark 
presentity status as busy"). It is unclear how a watcher would benefit 
from such decontextualized knowledge.

(3) Some of the motivating assumptions are short-term or debatable.

   For many users, devices represent the ability
   to communicate, not services.  Frequently, users my statements like,
   "call me on my cell phone" ...

It is debatable that users actually want to refer to a device, even 
though the current service=device abstraction encourages that. As soon 
as a service is available on multiple devices, users are just as likely 
to say "call me on my 3G service". Since a device in this model is not 
reachable itself (it only has a URN that does not resolve), this device 
notion can't actually be implemented by a user - the device tuple cannot 
be used to actually call the device. Thus, there is no functionality 
gain and the user still has to use a service tuple, with caller prefs or 
an explicitly labeled service, to do anything of use. If you want to 
call the Nokia-made blue cell phone of mine, there has to be a service 
tuple, with URI, that maps one-to-one to that device. If a service maps 
to multiple devices, I can't actually call that one piece of plastic.

My proposal is simple: remove the notion of devices from the data model. 
If there is a need to allow one-to-many references (e.g., one service 
found at multiple locations due to uncertainties in where the presentity 
is), we should have appropriate means to express this by value or by 
reference for that particular service tuple and property.

I would like to see examples of services that significantly benefit from 
adding devices and that cannot be similarly expressed by the 
summarization model across service instances. (= a property that is 
shared by all instances of a service or there there is at least one 
instance that can be selected is shown.)

My basic contention is simplicity: we should have a minimalist data 
model that cannot be reduced any further.

Henning


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple