Subject: [Simple] characteristics vs status

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2005 00:38:25 -0500

I was reading the presence data model and the latest versions of 
prescaps and rpid on the plane and it got me thinking.

I've been having a bit of a problem about how to represent a device that 
dynamically changes its capabilities. For purposes of discussion I offer 
this one:

A softphone with voice and IM capabilities. It can handle calls that use 
both together, or either one alone. It can also start a call with one 
and add the other to a call later. This phone can also be configured to 
disable one or the other of the media, so that they will be refused if 
offered in a call. (Disabling voice is useful in meetings.)

I have always felt that the proper way to reflect this device in 
presence is to change the prescaps specification of media features 
(<audio>, <message>) according to what is enabled.

However there is a problem with this: when one of the media is disabled, 
there is no obvious way to indicate to a watcher that this device is 
different from a device that only supports the indicated media. This is 
important for someone making a decision about how/when to attempt 
communication. If the watcher's preferred medium is voice, and IM is 
possible but inconvenient, then the watcher who knows that audio is 
possible but disabled might wait for it to become enabled.

One possibility for this is <future-status>. With that, it would be 
possible to say that <message> is available now and <audio> is not, but 
that at a future time both will be available. The problem with this is 
that often it may not be known *when* in the future the change will happen.

Well, reading the description in the presence data model about the 
(fuzzy) distinction between characteristics and status, I have 
difficulty deciding if capabilities are characteristics or status. And 
then it occurred to me that perhaps they should be *both*. Capabilities 
reported as characteristics (directly under <tuple> or <device>) would 
reflect a long term capability. Capabilities reported under <status> 
would reflect more transient state.

So my example device would report <audio> and <message> all the time 
directly under its <tuple>. Then under <status> it would report the 
transient state. It could do this by exception only - inserting an 
element with the value of false for capabilities that had been disabled.

A watcher could render this as follows:
- show an available-audio icon if <audio> is true in the status,
   or if not present in status but true in the tuple.
- show a disabled-audio icon if <audio> is true in the tuple but
   false in the status
- show no audio icon at all otherwise.

Thoughts?

	Paul

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Mar 2005 01:32:26 -0500

Paul,

I think we may be trying to do too much here. Is there a real need for 
this in solutions folks are rolling out in the industry? I dont think 
so. We can probably come up with all kinds of interesting and 
difficult-to-model use cases for the next three years, and still not be 
done with the basic data model and rpid drafts.

The data model draft says that information can be status or 
characteristics, and that the line is blurry. So, you pick one, and that 
is fine. There are no bad consequences to including characteristic 
information that actually changes, or status information that doesn't. I 
think that suffices for the data model and our current efforts.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2005 09:31:01 -0500

Well, I think we are lightyears ahead of what has been implemented, so 
much of what we have already defined could be considered "too much". 
OTOH we are trying to develop capabilities for a *multimedia* presence 
system, which we think is needed even if most of the practical systems 
aren't all the way there yet.

Its not the question of whether to consider the prescaps as 
characteristics or status that is motivating my suggestion. Rather it is 
the need to report both a transient value and a stable value that I see 
and am trying to satisfy. I just thought this might be a fairly natural 
way to get that done.

There are other ways to satisfy the same need. A modification to 
<future-status> (so it doesn't have to specify a particular time in the 
future) is another possibility.

Its of course also possible to do nothing until more of a demand arises.

The basic problem is that I think we will rapidly have devices that have 
these nuances of state to report. If we don't say how to do it, people 
will simply get creative in incompatible ways.

	Paul

Jonathan Rosenberg wrote:
>> I've been having a bit of a problem about how to represent a device 
>> that dynamically changes its capabilities. For purposes of discussion 
>> I offer this one:
>>
>> A softphone with voice and IM capabilities. It can handle calls that 
>> use both together, or either one alone. It can also start a call with 
>> one and add the other to a call later. This phone can also be 
>> configured to disable one or the other of the media, so that they will 
>> be refused if offered in a call. (Disabling voice is useful in meetings.)
>>
>> However there is a problem with this: when one of the media is 
>> disabled, there is no obvious way to indicate to a watcher that this 
>> device is different from a device that only supports the indicated 
>> media. This is important for someone making a decision about how/when 
>> to attempt communication. If the watcher's preferred medium is voice, 
>> and IM is possible but inconvenient, then the watcher who knows that 
>> audio is possible but disabled might wait for it to become enabled.
>>
>> possible to say that <message> is available now and <audio> is not, 
>> but that at a future time both will be available. The problem with 
>> this is that often it may not be known *when* in the future the change 
>> will happen.
>>
>> then it occurred to me that perhaps they should be *both*. 
>> Capabilities reported as characteristics (directly under <tuple> or 
>> <device>) would reflect a long term capability. Capabilities reported 
>> under <status> would reflect more transient state.
>>