RE: [Simple] Presence data model: devices

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> Sent: 20.July.2004 16:40
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: simple at ietf.org; jdrosen at dynamicsoft.com
> Subject: Re: [Simple] Presence data model: devices
> 
> 
> 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.

A GRUU guarantees where a request will end up. You are making the assumption that tuples for the same service will get merged. I'm not making that assumption. My watchers will see 2 tuples for the same service if they get published by different PUAs. Each tuple will have a GRUU. It will then be helpful to have device characteristics for that service and the GRUU will get you to that device. It does not have to be device-ID as I earlier suggested, the service tuple can describe the device. But if there are many services on that device, then describing those characteristics on one place is sound. Tuple might be one place to do so.

Regards,
Hisham

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