Re: [Simple] Presence data model: devices

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

hisham.khartabil at nokia.com wrote:

> 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'm arguing that the watcher does not, in general, care how the service 
is provided. The watcher does not get a choice in the matter and is as 
likely to draw wrong conclusions, based on his mental model of what a 
device looks like, than right conclusions.

Currently, many services are indeed tied to a single device in a fairly 
transparent manner. But single-service devices don't benefit from 
dividing service and device description. It's only if multiple services 
share a device (or multiple devices contribute to a service) that there 
is anything of interest.

In the current design, the device model cannot be used to reliably reach 
one device ("call my blue Nokia cell phone") unless each service has 
only one device or there is a service that only reaches that one device. 
If that's the case, the service description itself can describe the 
device. (I doubt that this is useful in practice, but just in case.)


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

The device does not matter here - it's the knowledge of the cost of the 
*service* that matters.  After all, it's not the device that charges you 
money, it's the service that does. It just happens that you are running 
the service on a specific device today. If I run my cell phone PCMCIA 
card on my PC, your assumption is suddenly wrong - calling my PC will 
indeed cost extra. Thus, simply assuming that "PC=free" is exactly the 
kind of implicit assumption that is probably mostly right, but will 
increasingly be dangerously wrong as the traditional device boundaries 
disappear.


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

Again, I don't see how the knowledge of the device helps the *watcher*. 
I care what kind of service I'll be getting, in terms of quality and 
cost, but that depends on the service definition. Indeed, as noted, 
unless you map services to devices one-to-one, you can only guess that 
you'll get one of the N devices making up the service.



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

I don't see how a device ID helps at all. There are two cases, depending 
on the mapping:

- A particular service maps to exactly one device. In that case, the 
properties of the device (speed, display size, media capabilities, etc.) 
are part of the service - for that service at that time, you only get 
those characteristics. Since many of the characteristics are indeed 
determined by the capabilities of the service provider and the service 
plan chosen by the user, not the piece of plastic in the user's pocket, 
the service-device distinction seems arbitrary.

- A particular service maps to multiple devices, forking-style. In that 
case, the only advantage of having device tuples is that it allows you 
to enumerate the possible end points where your call might end up. You 
don't get a choice (although caller preferences might give you input), 
but you might get a hint. This, I believe, is however, much better coded 
as an enumeration of service capabilities as they are as likely to be 
constrained by the service offering as by the piece of plastic.

Any other service constraints ("can't do X and Y at the same time 
because they share one device") rely on dubious assumptions about 
particular instances of plastic.

I do agree that specifying the source and nature of data is a really 
good idea. For example, it might be valuable to provide indications of 
the type of idleness ("no communications", "no user input"), rather than 
having the watcher try to deduce this based on guesses what kind of cell 
phone a cell phone is.

As mobile devices become basically multi-tasking pocket PCs with a 
screen that is as large as PC screens were about five years ago, it 
seems increasingly dubious to rely on classifications that might have 
been vaguely helpful in a single-line, single-purpose world of the 
Motorola StarTAC.




> Regards, Hisham

Henning

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