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

From: [email-masked]
Date: Tue, 20 Jul 2004 11:04:15 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Jul 2004 09:39:38 -0400

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jul 2004 23:16:32 -0400

inline.

> the service-device distinction seems arbitrary.

For the one device/one service case, if that was the only case, I agree 
the separation has little meaning.

> constrained by the service offering as by the piece of plastic.

There are other benefits.

If my presence server receives information that says that the service 
runs on multiple devices, and it separately learns that one device 
fails, it can know that the service is still available.

 From a watcher perspective, I think it helps in selecting. Lets say I 
have a messaging service which I see runs on a mobile device and a fixed 
device, and a voice service on a fixed device. If I know you are 
traveling, I might be inclined to use the messaging service, since there 
is the possibility you can be reached.

You've missed the third, key case, though:

- A particular device maps to multiple services

Now, this one is really interesting for both watchers and presence 
servers as consumers.

For watchers, it allows you infer important correlation that can help 
you make a choice. Some examples:

* Jon told me to contact him on his cell. I see that his cell has sms 
and voice, but his voice service reports its busy. So I'll send him an 
sms to that phone

* Jon is PTTing with me. The quality stinks. He says, "go circuit". I'd 
like to call him back on the circuit voice on the same device his PTT 
service is on (since I know he's got that).

* Bob and I are talking. I see from his presence doc that he has a 
videophone app on the same PC running his voice softphone app. I want to 
also use video to talk to him. His softphone doesnt do video, so a 
reinvite won't help. His pres doc indicates two video devices - one is 
on his PC as well, another is a hard videophone somewhere else. Since I 
know he's at the PC with the softphone, I contact the videophone on the 
PC too.

I am sure there are many others.

> been vaguely helpful in a single-line, single-purpose world of the 

How is your multi-tasking pocket PC not a device? "device" is not some 
short lived concept. There are always going to be devices. In fact, the 
more powerful they get, the more services can run on them, and the more 
interesting the ability to correlate those services, and extract common 
information, becomes.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2004 14:17:49 -0400

> service is on (since I know he's got that).

All of the above work just as well if service tuples contain device 
id(s) for purposes of correlation, without any separate device state.

> know he's at the PC with the softphone, I contact the videophone on the 

As an example it works, but it seems far fetched. Since a video phone 
should be able to do voice-only calls, why would you want to run both a 
voice-only softphone and a soft-video-phone on the same PC at the same 
time? (Among other problems, they will have to compete for the audio 
resources of the PC, so they can't both be in a call at the same time.)

	Paul