Re: [Simple] Presence data model: devices

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

inline.

Henning Schulzrinne wrote:


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

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

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

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.


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

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