Subject: RE: [Simple] Presence data model: devices

From: [email-masked]
Date: Tue, 20 Jul 2004 17:07:30 +0300

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: 20.July.2004 16:40
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Presence data model: devices
> 
> 
> [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Jul 2004 10:54:32 -0400

> A GRUU guarantees where a request will end up. You are making the

Yes, but according to the data model draft, only services have GRUUs. 
Devices don't.

> assumption that tuples for the same service will get merged. I'm not

No, I'm not making this assumption.

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

Indeed, that's what I'm suggesting for the case that a service has a set 
of properties. In any event, we need to be able to describe the set of 
properties (precaps, etc.) for services, which are more than just those 
for pieces of plastic.

> then describing those characteristics on one place is sound. Tuple
> might be one place to do so.

This is simply a matter of saving space by reference. I think there are 
better ways to remove redundancy for space saving, e.g., through 
compression.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jul 2004 14:39:10 -0400

[email-masked] wrote:
> A GRUU guarantees where a request will end up.
 > You are making the assumption that tuples for the same service
 > will get merged.

Henning was enumerating the cases. This one case assumes the service 
forks to multiple devices. If there is indeed to be presence information 
from each of those then yes, presumably it is being merged.

He covered the other cases as well.

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

Then by the terminology we are using here, they are two different 
services, not one.

 > It will then be helpful to have device characteristics for that
 > service and the GRUU will get you to that device.

Because they are separate services, we are back at the degenerate case 
where service = device, and "device characteristics" can be associated 
with the service.

	Paul