[Simple] Re: Presence data model: devices

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

Thanks for articulating. Responses inline.

Henning Schulzrinne wrote:

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

Let me try to clarify. As far as a watcher is concerned, "device" is a 
representation of a physically distinct entity that houses services. 
Now, as a presence server or publisher, I can map reality into that view 
anyway I like. If a user has a bluetooth device and a cell phone that it 
would like a watcher to see as separate, it would provide the watcher 
with two devices. If it wants the watcher to see them as one, it would 
provide one.

In that regard, it is a *model* of reality, by trying to map reality 
into a notion of services and 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.

Right. And a presence server could represent them either way.

 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.

Fine, you can do that too.

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

Fair enough. I think a further refinement would be that the device 
concept models those aspects of the device that are shared across 
services. Here are some in that category:

geolocation
on/off status
CPU power
memory
screen capabilities

If something is not shared across services that run on the device, you 
would not include it as part of your device characteristics.


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. 

This is a good point, and that is why I would argue that, by deifnition, 
the device characteristics would be shared across services on that device.


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

And when its no longer true, we can model it as multiple devices.

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

Ah. There is the rub.

How does the composer obtain these "local rules". One of my strong 
motivations in proposing this way of modeling devices has come from 
experiences in building these things, where that whole process of 
correlating together these bits of information from various places is 
hard. Presence sources in the network, such as registrars, HLRs, IP 
PBXs, 802.11 APs and so on, each know a bit of information. Many of them 
know about devices (like the 802.11 ap, which knows about the mac 
address of my device), and some know about services too. Each of these 
has the ability to generate information about some aspect of the user. 
To correlate them together without this headache of provisioning and 
configuration, it would be great if we had a common, well understood way 
to include correlation identifiers.

That way, when the HLR says, "this device is no longer registered", the 
compositor can know that, as a result, a whole bunch of services 
(namely, those which run on the device) are no longer available.

Thus, I continue to maintain that watchers are NOT the only consumers of 
presence documents. PUAs, in form of PC clients, cell phones, HLRs, APs, 
and lots of other things, are also publishers of information, and this 
correlation is a key part of making it work.



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

And how should I correlate the information from the cell phone network 
about the presentity, without such identifiers??

> It is unclear how a watcher would benefit 
> from such decontextualized knowledge.
>
> (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.

Right now, the world talks about devices. Are you saying that people 
don't say, "call my cell"? I say that all the time. My wife says it all 
the time. So do my coworkers. The reality is, that today, I believe that 
the vast majority of people think and talk in terms of devices. I want a 
system that is actually useful and meaningful today. If we deliver 
something that ignores a concept which is so prevalent today, and I 
suspect for years and years to come, I think we are doing the industry a 
disservice.

Even tomorrow, I don't see the notion of device going away. And even if 
it does, fine. The model doesnt require devices to be present.

 As soon
> as a service is available on multiple devices, users are just as likely 
> to say "call me on my 3G service".

Well, when that day arrives some ten years hence, we can happily support 
that by simply electing to NOT include device information in the 
presence documents. The model does not mandate that you always indicate 
all of the information. Indeed, the notion of using a device ID as a 
link was based on the idea that I might often not want to say anything 
about the device, and just ratehr give the user the hint that these 
services were running on the same device, whatever it might be.



 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. 

That is not so.

An implementation could show the user a picture of the devices - say, 
cell phone, PC, work phone. If you select the cell phone icon and hit 
"call" on your display, the implementation would go to the tuple which 
represents the cell phone, find all of the services which run on that 
phone, find the one which understands how to be called, and calls it.

If, however, another implementation wants to render this as a list of 
services, and not even mention the device, it can do that too.


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

Not so. As I say above, from the device, you would obtain the services, 
and then invoke the services. Caller prefs should not be needed in any 
model we come up with.


 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. 

Yes.

I do buy the argument that it might not be useful to have presence 
documents that get published to watchers that include JUST devices, and 
no services. I think I may have even indicated somewhere that this was 
an open question.


> If a service maps 
> to multiple devices, I can't actually call that one piece of plastic.

Sure. That doesnt devalue the notion of a device. Just because some 
services might run on multiple devices, and just because the model 
allows me to represent that, does not mean it is not useful to support 
the ability to "make a call to a device".

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

The device concept is, in fact, a way to represent that information by 
reference.

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

Much of the correlation problems at a presence server, in performing 
composition, motivate the need to talk about devices. I've mentioned 
some of that above.

From a watcher perspective (that is, an end user), I believe that end 
users are very much used to thinking today about devices as their focal 
point. Thats why devices have been part of our discussions over the 
years. The model allows that, and allows for documents to NOT talk about 
devices if they want.


> My basic contention is simplicity: we should have a minimalist data 
> model that cannot be reduced any further.

The concept of device is not new. RPID is full of references to devices. 
The what-is-a-tuple discussions have talked about device, service and 
presentity views for a long time. All I am doing here is trying to put 
some meaning around that. The fact that these concepts have been with us 
all this time tells me that these ARE things people need. However, this 
"what is a tuple" problem has plagued us because these have not been 
properly defined and understood. I don't see how a proposal which tries 
to define them makes things more complicated. If we go forward with what 
we have today (that is, without the model I propose, or some kind of 
similar model), do you believe we will have interoperable systems?

Thanks,
Jonathan R.



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

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