Subject: RE: Status discussion again RE: [Simple] Test message

From: "Adrian Bateman" <[email-masked]>
Date: Sat, 1 Jun 2002 15:37:35 +0100

On 31 May 2002 03:16, Li Hua Tang wrote:
> 
> It's always open, but no driving force for input and output.:) Need 
> inspiration...
> 
> Here is the point. 'Open' status only describes an objective 
> communication possibility. We may need something like 'Eager to chat!'

> or 'I want to be silent.' to describe the user's subjective attitude 
> to communication. One is the capability (open or closed), the other is

> the availability (user's willingness). That's what we have got known 
> from the previous status discussion.
> 
> So can we summary status as below?
> Open
>     - availble  // always ready to chat
>     - away      // temporarily not available
>     - invisible // only available to someone I want to chat
>     - busy      // not ready to chat or no immediately response to
messages
>     - in call   // may ready to chat later
> Closed
>     - unavailable      // disconnect and can't chat
>     - do not disturb   // don't want to receive message but close the
> channel

(Apart from the fact that invisible can't really be a state (visibly
invisible?) so should look just like disconnnected,) I'll try to
reiterate my thoughts on this discussion from a different tack.

Why is it important to try to distill the different IM status values
into a definitive set? I don't believe that the group will reach
consensus on a definitive minimal set because one person's busy is
another's do-not-disturb. Doesn't the benefit come from having a
*reasonably* small and *well-known* vocabulary for IM status values? You
don't even really need to decide which are open and which are closed -
PIDF allows for that already.

Perhaps rather than trying to find the set of status values, attention
might be focussed on the reason for having such a set and the values
might fall out of that discussion?

Regards,

Adrian.

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Jun 2002 22:51:07 -0400

Once again this one has stalled, but I think Adrian has captured the 
essence of why below:

> might fall out of that discussion?

This is the essence of the problem. We don't know *why* we want these 
various status values. Until we know what kinds of things we need to do 
with them, it will be hard to determine what we want to do.

SO, I propose that we focus discussion instead on the things that might 
be done with such inforamtion. Most importantly, they are things that an 
automata would do, since anything else can be handled by the note.

* display icons appropriate to the status

   This would in fact argue for a set of common reasons, such as "on the 
phone" and "in a meeting", irregardless if they don't say anything much 
beyond CLOSED or OPEN in terms of the ability to receive an IM.

* Provide local language versions of the status

   Similar to the above item, it would require a set of common reasons.

* have the secretary automatically connected to the boss in a phone 
call, when the boss becomes available, where the *secretary* defines 
available

This is an interesting one. TO date, our assumption was that 
availability is the decision of the presentity; that it decides whether 
or not it wants to receive calls. THere is an argument to be made that, 
in the case above, for example, the watcher wants to determine what 
availability means, based on "raw" information about the boss - whether 
they are in a call or not, in a meeting or not, and so on. In order for 
that to work, the secretary's application needs detailed information on 
what the boss is doing so that it can make a decision.

I am sure there are others; suggestions welcome, as well as comments on 
the above list. Again, I propose we focus on the usages for the status 
values, rather than on the values themselves.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jun 2002 08:59:15 -0400

> automata would do, since anything else can be handled by the note.

I agree that this is a useful way to progress.

Some time ago I tried, rather unsuccessfully, to make a point about the sorts of statuses that are being proposed. I will try again:

Most of the statuses can be classified into one of two buckets:
- what the presentity is *doing*
  ("on the phone", "in meeting", "on vacation")
- what the presentity is *willing to do*
  ("open"?, "do not disturb"?, "emergency calls only")

Choosing one sort or another seems to be a matter of philosophy. You choose to represent what is being done if you are generating the status automatically and don't know
what the presentity is willing to do, or if you want to put the onus on the caller to decide. You can choose to represent what the presentity is willing to do if the user
is explicitly setting the status, if the user has set policy on how to determine what he is willing to do, and if you want to avoid failed attempts to communicate by
accurately representing willingness.

Automatons can use either sort to display icons, etc. The second sort are beter for caller automatons that automatically place calls, because the automaton has less to
infer. OTOH, if you want to report that sort of status automatically then it will require a complex automaton in the presentity to infer the status from actions.

I suppose we need both sorts, but it would be useful to be mindful of what kind the things we are defining are, and to attempt to make a reasonably complete set of each. 

	Paul