Subject: RE: [Simple] Extending <status> for presence

From: Adam Roach <[email-masked]>
Date: Mon, 13 Jan 2003 17:11:47 -0600

> From: Jonathan Rosenberg [mailto:[email-masked]]
> 
> The fatal assumption here is that, whenever presence changes in a way 
> which may affect call routing, it is also possible at that time to 
> upload a new CPL. I see several problems here...

Yep. Good points.

Given that, it makes sense at some level that we want
machine-readable presence information that conveys more than
just "OPEN" and "CLOSED". Vijay's list seems like a reasonable
starting point. (For the sake of finer grained control, I'd like
something more along the lines of "Available/Away/Busy", where
"Busy" further has a "priority" parameter or similar that indicates
the interruptability of the user).

Henning proposes that this is one of two axes that need to be
nailed down -- that of reachability. The second he identifies
is cause. I would argue that cause is inherently human
consumable, and should be a free-form non-machine-interpreted
string.

So, how do we end up triggering different behavior for
"Out to Lunch" versus "On Vacation?" I think it would be
useful to explore what the *parameters* are that make
these situations different, as opposed to inferring
semantics from the meanings of the actual phrases.

In this particular case, the fundamental difference is the
period of time for which a user will be gone. So, that
would point to adding an optional "duration" parameter to
"away" (and "busy") that would be used to indicate --
at least, on an order of magnitude, how long the condition
is expected to continue. I wouldn't expect to include,
say, an actual number of seconds, as much as, for example,
knowing the unit of time that would be appropriate. Literally,
you would communicate the difference between "Out to Lunch"
and "On Vacation" as "duration=minutes" versus "duration=days".

I'm reasonably certain that, with a minor effort, we could flesh
out additional parameters to apply to the basic "Available/Away/Busy"
statuses that would be sufficient to convey a suitably rich set
of statuses. 

Comments on whether this is a direction the group would
be interested in exploring?

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jan 2003 13:37:50 -0500

Adam - comments below.

	Paul

> and "On Vacation" as "duration=minutes" versus "duration=days".

There is a fundamental problem with simply attaching a duration - when 
does it begin? You need to know when the state began that the duration 
applied to, for it to mean anything.

For instance, "Out to Lunch" might be intended to imply being gone for 
the duration of a lunch (lets say an hour). If you leave at 12 and set 
this status, and I log on and notice your state at 12:55, do I know you 
are probably about to return, or do I think you will be gone for another 
hour?

If we want to attempt to do this at all, then I think we need to specify 
the absolute time interval that the status applies to, or at least the 
time it will cease to apply. UIs can be responsible for providing 
shortcuts and configuration to make it simple to set statuses that 
encode the proper values. So you could presumably still select an "Out 
to Lunch" status from your UI, and it could figure out to say you will 
be unavailable for the next hour.

---

From: "Adam Roach" <[email-masked]>
Date: Wed, 15 Jan 2003 17:44:19 -0600

> be unavailable for the next hour.

You make a good point, but I fear you may have missed mine.

I don't want to get hung up on the exact details of the two parameters
I propose. What I'd like to have is a short meta-conversation about
whether this is the *sort* of thing we'd like to do.

To reiterate my primary question: does anyone else see value to
attempting to define explicit parameters associated with
presence states instead of attempting to imply (or proscribe)
semantics for pre-defined settings like "out to lunch" or
"on vacation"?

/a

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 09:07:52 -0600

> semantics for pre-defined settings like "out to lunch" or

Yes, most definitely.  What you write implicitly refers to the status
of the presentity itself, which is what I have been arguing for all
along.  It is the presentity that is "Out to lunch", "Away" or
"On vacation", not the devices.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 16 Jan 2003 11:05:56 -0700

> "On vacation", not the devices.

The presenity can be "out to lunch" or "on vacation", but it CANNOT be
"Away".  "Away" means object A is geographically separated from object B.  A
presentity needs to be "Away" from *SOMETHING*.  In the context that we
usually use "Away", we refer to the separation between Presenity and Device.

Thanos
---
Thanos Diacakis
Openwave Systems
[email-masked]
+1-303 385 6705