Subject: [Simple] Presence data model: devices

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Jul 2004 21:58:26 -0400

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.

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

(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

---

From: Alex Audu <[email-masked]>
Date: Tue, 20 Jul 2004 11:30:27 -0500

I guess one thing to think about is "can a service map to multiple devices?"

I think it certainly can.  We have seen how telephony service has grown from

being supported on only the black phone, to now being supported on a
multitude
of newer, more versatile devices.  It is not uncommon for Joe to ask a
friend
"can you call me back on my land-line phone? I can't hear you very well on
this
cell phone".

Modes of communication vary. They can include audio/visual (send audio and
receive
video after appropriate translations, send audio and receive audio, send
video and
receive audio, send video and receive video), sensory, and tactile
communication modes.
It is possible but rare that one device can support all these modes;
however it most likely
that the various modes will be supported on different devices optimized for
each mode.
So, I am not sure if we can  dimish the importance of device addressability.

Regards,
Alex.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Jul 2004 12:42:27 -0400

> "can you call me back on my land-line phone? I can't hear you very well on

None of this requires a device abstraction. The caller can only choose 
the mobility modality if

(1) there are two separate service entries (one stationary, one mobile)

or

(2) there is one service entry and the caller uses caller preferences 
that the callee chooses to honor.

Neither requires nor benefits from a device tuple. (Devices tuples 
cannot be contacted directly.)

In many cases, we'll have a single watcher-visible modality that 
encompasses multiple devices. For example, on trips to Europe, I carry 
both my GSM phone (works in both places) and my CDMA phone (works in 
only one, but is cheaper). I want the caller to reach my mobile service, 
but don't necessarily want to have to expose the devices as that's none 
of the caller's business. Thus, I need the ability to declare a mobile 
*service* (which is then routed according to my service preferences to 
one of my phones, e.g., depending on how much an incoming call is going 
to cost me.) [The proposed model allows this, as far as I can tell, so 
no disagreement here.]

> So, I am not sure if we can  dimish the importance of device addressability.

I don't think anybody is arguing that we outlaw one-device service 
tuples if the user wants to publish these.

Only services are addressable in the proposed model. Thus, the presence 
of device tuples does not help or hinder their addressability.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jul 2004 18:30:27 -0400

Thanks for articulating. Responses inline.

Henning Schulzrinne wrote:

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

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

  Locally, we have created virtual multimedia devices that
> IP array microphone). They act exactly like one multimedia device in 

Fine, you can do that too.

> 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
> 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
> violate even that assumption with a bit of forward thinking.)

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

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

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

> reference for that particular service tuple and property.

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

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

> 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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jul 2004 22:57:05 -0400

I think my reply to your initial post covered most of what I would 
otherwise say throughout the thread, but to emphasize here:

Henning Schulzrinne wrote:

> only one, but is cheaper).

Great example. Let me give you a case for something I dont know how to 
do without the notion of a device.

You have two phones, this CDMA and GSM one. Lets say they both work 
(i.e., you are in the U.S). Your presence document indicates a voice 
service and a SIP messaging service on the GSM phone, and an sms service 
on the CDMA phone. Lets say I'm talking to you on your GSM phone, which 
is low on power. While talking, you say, "hey, can you send me a 
message, but send it to me other phone since I am about to run out of 
...." and at that moment, the call ends since power is out. I want to 
send you a message now, but not to the gsm phone. I have no way to know 
which of the two messaging services is accessible on that phone, or 
another phone, without device information.

Indeed, a convenient user interface would show user "henning" with two 
device icons, each a cell phone. Perhaps one has "gsm" inside, and the 
other "cdma" (again, these are DEVICE characteristics). So, if you say 
to someone, "call my gsm", it becomes very easy for me, or anyone else, 
to call it, or PTT it, or sms it, or access any of the other services 
avaialble on it. Without a device concept, I can't do that.

It is true that, in this case, device ID will suffice. However, the 
device has characteristics and status that are independent of the 
services; and placing them into the service causes unneeded repitition 
and lack of clarity about what they apply to. These characteristics ARE 
about the device; putting them into service is artificial.

  I want the caller to reach my mobile service,
> of the caller's business.

Well, thats OK. There is nothing that says you HAVE to report on your 
devices if you don't want to. If you want to just indicate services to 
the watcher thats fine.

  Thus, I need the ability to declare a mobile
> to cost me.) [The proposed model allows this, as far as I can tell, so 

Right.

The point is, the model I am proposing represents what seems to me, to 
be the minimum of the concepts we've been talking about and assuming all 
along.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2004 13:54:00 -0400

Jonathan,

There is one point in here that I want to comment on...

	Paul

> avaialble on it. Without a device concept, I can't do that.

As long as the data model has a many:many relationship between services 
and devices there is going to be a problem deciding what is the best, 
most convenient, user model. Most of the user models of this sort of 
thing are tree oriented one way or another. A many:many model has to be 
unwound using repetition to be displayed as a tree. So either the top 
level view can be devices, with services within and possibly replicated, 
or else the top level can be services, with devices within, possibly 
replicated.

The case you describe, while real, is a fairly obscure one. I think it 
would be sufficient to have the service view, and for each service to 
list the associated device(s).

This need to replicate would be simpler if the device is simply an 
attribute rather than a separate item that has state that also needs to 
be replicated.

(Of course another UI might show services and devices at the same level, 
with cross references between them, but that doesn't sound like a very 
appealing UI.)

	Paul