RE: [Simple] Presence data model: devices

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: simple-bounces at ietf.org 
> [mailto:simple-bounces at ietf.org]On Behalf
> Of ext Henning Schulzrinne
> Sent: 20.July.2004 04:58
> To: Simple WG; Jonathan Rosenberg
> Subject: [Simple] Presence data model: devices
> 
> 
> 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.

Just thinking aloud here. If we state that a device is the equipment used by a service, then it can be a virual device or one physical device, depending on the service and the combination of equipment that are needed for the service to be usable.

So, for example, I'm using bluetooth to connect my mobile phone to my PC that is connected to the internet, I therefore have email on my mobile. The device that represents the email service would not be the mobile phone alone, but the combination of the mobile phone and the PC. Otherwise the service is not available.

But the question is, do watchers care? they might. It is a little misleading to represent the above service to be email on a mobile phone. So in actual fact, I need a 3rd "device" that represents the combination of a mobile phone and a PC. Does that need a tuple of its own? I don't know, and I guess this is what Henning is arguing against.

I believe it is useful for watchers to know the device the service is available on. For example, I will only make voice calls to you if you have voice on you PC since calling to you on your mobile phone will cost me extra.

I'm not sure yet if a tuple is needed, or if a device-id is sufficient enough. In either case, something (characteristics) is needed to identify that device as a PC, mobile, or a combination and therefore will enable better GUI representation of that device (like an icon rendered locally).


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

I might agree that if a device state changes, then the presence state of those services affected should change, and therefore no presence state of a device is ever published, but rather those states of the services are. I see this as local to the publisher though, and not the compositor.

If we agree that a tuple represents the presence state of something, then I can buy that a device tuple is not needed. But again, a device ID and characteristics mapped to a service is needed.

Regards,
Hisham

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

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