Subject: [Simple] Comment to data model and RPID regarding <device> element

From: Aki Niemi <[email-masked]>
Date: Fri, 11 Mar 2005 00:26:33 +0200

All,

The definition of <device> in the presence data model states that rather 
than have a token identifier that defines what type of device the 
<device> element is describing, this information *could* be reduced from 
device characteristics, such as CPU speed, memory size and screen size.

I believe this design has been motivated by the fear of a combinatorial 
explosion. I.e., there could potentially be a very large number of 
device types, ranging from the mobile phone duct-taped to a laptop to a 
cray supercomputer.

However, I also believe this design is broken. Especially for a device, 
it is extremely difficult to reduce a meaningful representation that is 
reasonably accurate out of these limited characteristics. For example, a 
2,4GHz CPU today could mean a desktop computer, but in not-so-distant 
future, most mobile phones will have CPUs in that class.

I also tried to imagine how many device types there could be and I 
arrived at a list that was not that excessive at all:

laptop
desktop
mobile phone
PDA
HTPC or media PC
blackphone

So my proposal is to add a new element under <device> in RPID called 
<type> with at least the set of registered types above. In addition, 
there would be an "other" type, and a <note> element that either gives 
further information about the device type, or in the case of the "other" 
type, could indicate that indeed this is a PDA duct-taped to a laptop.

Opinions?

Cheers,
Aki

P.S. Apologies for contributing to feature creep at this point in the 
game...

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

---

From: David R Oran <[email-masked]>
Date: Thu, 10 Mar 2005 18:15:11 -0500

> arrived at a list that was not that excessive at all:
Could I get one for "hemorrhoid swelling monitor"?
How about one for "parole enforcement responder"
I could also use one for "HD Set-top box"

In fact, I could continue until I exceed the moderator-enforced limit 
on message lengths to this alias.
Or, we could argue about the ego-size of devices that get real 
registrations versus those that are stuck with "other".

I just don't get the usage scenario where device-type is useful for 
much of anything.

Dave.

> further information about the device type, or in the case of the 
> "other" type, could indicate that indeed this is a PDA duct-taped to a 
> laptop.
>
> Opinions?
>
> Cheers,
> Aki
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Aki Niemi <[email-masked]>
Date: Fri, 11 Mar 2005 01:29:47 +0200

ext David R Oran wrote:
> In fact, I could continue until I exceed the moderator-enforced limit on 
> message lengths to this alias.
> I just don't get the usage scenario where device-type is useful for much 
> of anything.

I could cite real-world systems, where such a feature is already 
present. A buddy shows a little mobile-phone icon, if they're using the 
IM client on a mobile. Also, the data model already talks about the 
users' need of being able to address devices, like "call me on my mobile 
phone". The heuristics for deriving that info out of things like CPU 
speed are not robust at all.

What you say above is of course true, but then again we've already 
manage to come up with a reasonable set of moods or activities in RPID. 
And I quickly searched bestbuy.com: at least they didn't seem to carry a 
hemorrhoid swelling monitor. Which was expected, since it did sound like 
a niche product. ;-)

Cheers,
Aki

---

From: David R Oran <[email-masked]>
Date: Fri, 11 Mar 2005 09:52:19 -0500

> present. A buddy shows a little mobile-phone icon, if they're using 
> the IM client on a mobile. Also, the data model already talks about 
> the users' need of being able to address devices, like "call me on my 
> mobile phone". The heuristics for deriving that info out of things 
> like CPU speed are not robust at all.
>
But this example is covered by other characteristics, notably, the 
"mobile" property. I agree that it's useful for the presence system to 
know the difference between a home phone, a mobile phone, or an office 
phone. What's not useful is to try to encode those things in a "device 
type".

Riddle me this one - do I PUBLISH from my Treo as a "mobile phone" or a 
"PDA", or do we have a device type which is "combined PDA and mobile 
phone", and go over the edge to combinatorial explosion.

If we need a characteristic because it's useful, then I'm all for it. I 
just don't thins dev ice type is one of those.

Cheers, Dave.

> manage to come up with a reasonable set of moods or activities in 
> RPID. And I quickly searched bestbuy.com: at least they didn't seem to 
> carry a hemorrhoid swelling monitor. Which was expected, since it did 
> sound like a niche product. ;-)
>
> Cheers,
> Aki
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Aki Niemi <[email-masked]>
Date: Fri, 11 Mar 2005 17:14:26 +0200

> phone", and go over the edge to combinatorial explosion.

This would be entirely up to the UA; it could indicate a device type of 
"PDA" and include the "mobile" prescaps in its service description. You 
would still use e.g. prescaps to indicate the capabilities, and the 
device type would merely mirror whatever was on the sales package of the 
device.

The point is that if you don't have a handle enumeration on the type of 
the device, then a big part of the benefit in being able to represent 
devices goes away and <device> becomes merely an abstract container for 
a set of services.

My use case is one where I want to be able to render some eye-candy to 
the user depending on what type of device(s) the presentity is using. 
The RPID/CIPID has the watcher-given icon that *could* be used, but then 
the watcher no longer has a say in what gets displayed.

What the data model currently has is IMHO merely hand-waiving, as the 
characteristics (CPU, memory, screen) are not constant over time, and if 
you gear your implementation towards today's devices, then next year it 
would seem all of your buddies are using a PC instead of a Treo.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Mar 2005 10:24:06 -0500

I'm with Dave. If CPU, screen and memory are not sufficient, we should 
define the other characteristics that matter. 'mobile' has been 
proposed. From a user perspective what matters is
- size of display (including 'none')
- ease of text entry (12-digit vs. Treo-style vs. real keyboard)

I don't know why I would need to make a distinction between a Treo 
PDA+cellphone, one of those micro clamshell laptops or a Sony PSP - or 
how any such distinction remains meaningful over time.

Aki Niemi wrote:
>> Riddle me this one - do I PUBLISH from my Treo as a "mobile phone" or 
>> a "PDA", or do we have a device type which is "combined PDA and mobile

---

From: Aki Niemi <[email-masked]>
Date: Fri, 11 Mar 2005 17:38:03 +0200

Another point. I'm pretty sure at least most mobile phone manufacturers 
will be reluctant to advertice the phone's CPU speed. And which CPU is 
that anyway? Also, s PS2 might advertize some 200MHz and 32MB of memory, 
and that still doesn't mean that the device is a PC from the eighties.

Having said that though, if the consensus is against enumeration of 
labels for devices, then at least we should add the characteristic 
markup to RPID.

Cheers,
Aki

ext Henning Schulzrinne wrote:
>>>> the users' need of being able to address devices, like "call me on 
>>>> my mobile phone". The heuristics for deriving that info out of 
>>>> things like CPU speed are not robust at all.
>>>>
>>> "mobile" property. I agree that it's useful for the presence system 
>>> to know the difference between a home phone, a mobile phone, or an 
>>> office phone. What's not useful is to try to encode those things in a 
>>> "device type".
>>>
>>> a "PDA", or do we have a device type which is "combined PDA and 
>>> mobile phone", and go over the edge to combinatorial explosion.
>>
>>
>>
>> This would be entirely up to the UA; it could indicate a device type 
>> of "PDA" and include the "mobile" prescaps in its service description. 
>> You would still use e.g. prescaps to indicate the capabilities, and 
>> the device type would merely mirror whatever was on the sales package 
>> of the device.
>>
>> The point is that if you don't have a handle enumeration on the type 
>> of the device, then a big part of the benefit in being able to 
>> represent devices goes away and <device> becomes merely an abstract 
>> container for a set of services.
>>
>> The RPID/CIPID has the watcher-given icon that *could* be used, but 
>> then the watcher no longer has a say in what gets displayed.
>>
>> characteristics (CPU, memory, screen) are not constant over time, and 
>> if you gear your implementation towards today's devices, then next 
>> year it would seem all of your buddies are using a PC instead of a Treo.
>>
>> Cheers,
>> Aki
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Mar 2005 10:46:09 -0500

I agree that CPU MHz counts (and memory) are meaningless - and getting 
increasingly so. Even Intel and AMD have stopped advertising GHz. In 
about a year or two, almost all CPUs will be between 1 and 4 GHz, where 
architecture, such as multiple cores, matters far more than GHz.

In first approximation, screen sizes reflect the type of applications 
that the system designer had in mind, and presumably put a corresponding 
CPU in the box.

Thus, suggestion: only encode user-interface capabilities.

Aki Niemi wrote:
>>>> office phone. What's not useful is to try to encode those things in 
>>>> a "device type".
>>>>
>>>> Riddle me this one - do I PUBLISH from my Treo as a "mobile phone" 
>>>> or a "PDA", or do we have a device type which is "combined PDA and 
>>> of "PDA" and include the "mobile" prescaps in its service 
>>> description. You would still use e.g. prescaps to indicate the 
>>> capabilities, and the device type would merely mirror whatever was on 
>>> the sales package of the device.
>>>
>>> My use case is one where I want to be able to render some eye-candy 
>>> to the user depending on what type of device(s) the presentity is 
>>> using. The RPID/CIPID has the watcher-given icon that *could* be 
>>> used, but then the watcher no longer has a say in what gets displayed.
>>>