Subject: Re: [Simple] Status summary

From: "Avshalom Houri" <[email-masked]>
Date: Tue, 14 May 2002 18:04:21 +0300

I understood busy as an hint that means that I am busy so please disturb 
me only if it is a urgent issue. So it is Open-Active while DND is 
Closed-Active.

Avshalom

Michael Hammer <[email-masked]>
14/05/2002 17:38
Please respond to Michael Hammer

        To:        Avshalom Houri/Haifa/IBM@IBMIL
        cc:        [email-masked], Henning Schulzrinne <[email-masked]>
        Subject:        Re: [Simple] Status summary

Avshalom,

So what is the difference between a busy and a DND?  Some of this seems to 
boil down to the explicit not available (Busy, DND) and the implicit 
(Away).  So essentially there is:

Closed-permanent (Explicit:  De-registration)
Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
Open-Active      (Implicit:  Actively using)
Open-Inactive    (Implicit:  Away so Maybe).

One last comment:  Since some of this may reveal presence, it may be a 
good idea to recommend a default that must be manually over-ridden to 
allow that type of information to be sent (protect privacy).

Mike

At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:

It seems that there is a place for another state - Do Not Disturb (DND). 
DND means that although I am online messages sent to me will not reach me. 
Thus, the blocking of the messages can be done in the client of the 
originator. 

So the states that we will have are: 
* Free (Available)
* Busy (Open but I am busy)
* DND (Closed for communication) 
* Away, for an
   indeterminate amount of time (used also by automatic away sensed by the 
client)
   short time (set manually)
   long time (set manually) 

Avshalom Houri 
Presence and Instant Messaging Architect 
Lotus Sametime, IBM Software Group 

Henning Schulzrinne <[email-masked]> 
Sent by: [email-masked] 

14/05/2002 03:52 
Please respond to Henning Schulzrinne 
        
        To:        Tony Hansen <[email-masked]> 
        cc:        [email-masked] 
        Subject:        Re: [Simple] Status summary 

> Your "on the phone" is just another version of Busy.

Agreed; the only reason I kept it separate is that a SIP device may know 
this condition specifically. It might be useful to have a two-level 
hierarchy of labels, as in busy.phone and busy.meeting.

> 
> I see the following set:
> 
>     Free (Available)
>     Busy
>     Away, for an
>         indeterminate amount of time
>         short time
>         long time
> 
> Each could also be annotated with additional text.
> 
> Busy means "I'm doing stuff, so may not respond right away. Annotations 
> for Busy would be things such as "On the phone" and "In a meeting".
> 
> The time based settings are purely subjective values, not concrete 
> values. The indeterminate time would be appropriate for use by an idle 
> timer.

It would be nice to be able to provide an explicit time of return. With 
calendar integration, this wouldn't be too hard. Obviously, this would 
be optional.

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

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

---

From: Tony Hansen <[email-masked]>
Date: Tue, 14 May 2002 12:06:13 -0400

All of the statuses that Henning and I proposed were OPEN statuses. That
is, they were all to be used when messages were allowed to be sent.

That is, to our list you'd add CLOSED, which equates to the Offline
status for most services.

Now, Closed but active (your DND/Do Not Disturb) is an interesting
status. I don't think the rfc2778 model supports that. Do we need
annotated CLOSED statuses? Do we need a way of saying "I'm around, but
don't bother me"?

(AT&T's IM Anywhere service once supported the equivalent to annotated
CLOSED statuses. We eventually got rid of the concept.)

	Tony

Avshalom Houri wrote:
 > So what is the difference between a busy and a DND?  Some of this seems
 > to boil down to the explicit not available (Busy, DND) and the implicit
 >   indeterminate amount of time (used also by automatic away sensed by
 > the client)

---

From: "Adrian Bateman" <[email-masked]>
Date: Tue, 14 May 2002 22:36:15 +0100

On 14 May 2002 17:06, Tony Hansen wrote:
> All of the statuses that Henning and I proposed were OPEN statuses. 
> That is, they were all to be used when messages were allowed to be 
> sent.
> 

> don't bother me"?

I don't believe 2778 precludes this. It says that there is a state
CLOSED which refers to the acceptability of instant messages. It doesn't
prevent you from qualifying that with additional status information, in
fact this is explicitly allowed by including other status values from
alternative ranges.

In PIDF, we propose that a basic status is supported providing OPEN and
CLOSED status values. For instant messages this has the meaning
expressed in 2778. It may have a meaning for other communication means,
but we don't specify what those are. We also provide for the concept
(and we're having discussions in IMPP about improving the wording) of a
status value that operates in the same semantic range as basic, but
provides for greater granularity (this appears to be the topic of this
thread). Finally, we allow other status values from ranges unrelated to
the acceptability or otherwise of instant messages.

For the class of status values that operate in a similar fashion to the
basic OPEN and CLOSED but with greater fidelity, we explain that these
values should be included in conjunction with the basic value. This
means that you could specify <basic>open</basic> and
<im:status>away</im:status> or <basic>closed</basic> and
<im:status>away</im:status>. Down-level user agents without knowledge of
whatever namespace im: referred to in this instance would still use the
basic values.

Now, in this context, my suggestion would be to focus on determining an
acceptable range of status values that can be used by user agents for
such things as displaying icons, or whatever, without necessarily having
to decide on whether those values imply open or closed which I've
suggested here before will lead to inevitable conflict. It may be that
user agents will interpret the combination of basic and 'im' status
value in determining what to display but it seems apparent that almost
every popular system has slight differences. Perhaps, therefore,
determining this status range is more about defining an acceptable
limited vocabulary than trying to rationalise the different values.

Regards,

Adrian.