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

From: [email-masked]
Date: Wed, 15 Jan 2003 14:22:55 +0200

Just thought to mention that Yahoo actually tells you how long someone has been idle for in hours, mins and seconds. This information, I am assuming, is calculated at the server, not publisher. A similar thing could be done for "out to lunch", using SIMPLE of course. Is there a for the publisher (PUA) to keep publishing presence only to update a time that can be calculated by the server? Perhaps not.

Regards,
Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, January 14, 2003 8:38 PM
> To: Adam Roach
> Cc: [email-masked]
> Subject: Re: [Simple] Extending <status> for presence
> 
> 
> Adam - comments below.
> 
> 	Paul
> 
> Adam Roach wrote:
> > 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".
> 
> 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.
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2003 10:44:46 -0500

Hisham,

PIDF already provides similar information - it provides the <timestamp> 
element in each <tuple>, giving the time the status last changed.

The limitation is that this pertains to the tuple as a whole, not 
individual elements within the tuple. This is probably good enough for 
some purposes, but maybe not all. Going beyond this would require 
timestamping individual status values. Hopefully that isn't necessary.

So, I suppose we can attach a duration to some status value and measure 
its expiration relative to the timestamp of the tuple. Potentially this 
gives a way to say *why* I am in the presence state I am in, and when 
that state is likely to change.

Other status values may indicate *what* I am willing/able to do in the 
current state, such as receive IM messages and save them for later 
display. But is that enough?

I think the presence client also may need some hint of how presence 
state may change in the future. For example:

Suppose my presence status is as above - I'm out to lunch, and accepting 
IM for later viewing. It also either doesn't mention voice, or 
explicitly indicates that voice is not currently accepted.

You need to contact me, but don't need to do so live - you would be 
happy to leave me a message. All you have is your fancy new wireless sip 
phone with IM and presence support. You can see my presence, and know 
that I should be done with lunch in 5 minutes. You can either wait 5 
minutes and make a voice call to me, or you can send me an IM right now. 
But entering the IM on the phone keypad is a pain you would prefer to avoid.

Your choice of which to do depends on knowing whether I will be 
accepting voice calls when I get back from lunch. (If I don't have any 
voice capability you might as well start thumbing in that IM message 
now.) How can you tell that? There seems to be some need to describe 
capabilities that aren't currently available but that may be when status 
changes.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 06:49:18 -0500

inline.

> timestamping individual status values. Hopefully that isn't necessary.

I think it may be.

Lets say we have three status types - basic, "activity", which includes 
out-to-lucnh, in-a-meeting and so on, and the caller prefs things. The 
timestamp on the tuple indicates the last time anything changed. Lets 
say I go into a meeting, and so I change my "activity" to "in a 
meeting". Then, an hour into the meeting, things begin to get fierce, so 
I change my basic status to CLOSED. Activity remains as "in a meeting". 
WHen I change basic status to closed, the timestamp changes too.

I think it would be very useful to know when I set JUST the activity 
status to "in a meeting". Perhaps this need is specific to this activity 
status, and less important for things like basic or the caller prefs 
stuff. But I do see a need for multiple timestamps.

-Jonathan R.

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

---

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

Jonathan,

Wouldn't the tuple describing the activity ("in a meeting"), have to be
different from the OPEN/CLOSED tuple (which I assume is associated with some
device), and therefore have different timestamps?

If OPEN/CLOSED is associated with the tuple, then we're back to the question
of "What does that mean?"...

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 14:41:01 -0500

Lets separate these things out here. Forget about OPEN/CLOSED. Lets 
assume I have a status for geolocation. That geoloc changes often, so 
there is an updated presence doc and an updated tuple timestamp. But, 
I've been in the meeting for some time. I'd like to convey how long.

-Jonathan R.

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 16 Jan 2003 13:24:39 -0700

There are quite a few ways that this could play out.   Here's one:

Assumptions:
- I don't have any fancy electronics implanted so the geoloc comes from my
cell phone.
- We've defined a type of tuple to describe the presence, location, etc.
information of cell-phones.
- We've defined a type of tuple to describe the presentity

Tuple 1:
- Tuple type: cell-phone
- Address: my cellphone #
- Status: Open <- open/closed doesn't make sense for cell-phone, see next
example.
- Location: x,y,z
Tuple 2:
- Tuple type: presentity
- Activity: in meeting

If I want to extend this example, to make it more interesting I could do
this:

(Additional assumption that I've defined a tuple that describes the presence
of a deskop PC.)

Tuple 1:
- Tuple type: cell-phone
- Address: my cellphone #
- Voice Status: on circuit switched data call
- Call Waiting: available
- SMS Status: accepting
- Location: x,y,z
- Incoming Voice: cannot take  <- indicating DND status for the device/media
type
- Incoming SMS: will take

Tuple 2:
- Tuple type: desktop PC
- Interaction status: Idle 3456 seconds
- IM status: not accepting
- Email address: [email-masked]
- Email status: accepting

Tuple 3:
- Tuple type: presentity
- Activity: in meeting
- Mood: bored out of my head
- Body Temp: 36.6C

I think this covers Henning's dimensions.  I'm not sure about the
store-and-forward.  What does it really mean?  It means that the user is not
there to read the message immediately.  Then it is redundant, as I could
determine that from the status of the device, i.e. is the user currently
using the device.  That is closed is "not available", open is "available",
and open and idle, is "store-and-forward".

Thanos
---
Thanos Diacakis
Openwave Systems

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Thanos Diacakis" <[email-masked]>
Cc: "Paul Kyzivat" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, January 16, 2003 12:41 PM
Subject: Re: [Simple] Extending <status> for presence

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 16:49:39 -0500

Jonathan Rosenberg wrote:
> 
>> PIDF already provides similar information - it provides the 
>> <timestamp> element in each <tuple>, giving the time the status last 
>> changed.
>>

I remain open minded about this. Maybe, as you suggest, *some* status 
values will require timestamps. Right now it certainly seems like 
overkill to put a timestamp on every status value.

It may also turn out that the cases that matter can be represented as 
multiple tuples. For instance the basic activity things like "out to 
lunch" can perhaps live in a separate tuple from device specific stuff. 
If so, a tuple timestamp may be enough.

	Paul

---

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

> lunch" can perhaps live in a separate tuple from device specific stuff. 

I think that will be a good start, because qualifiers like out to
lunch don't qualify a device, they do however, qualify the person (I
will stop using the word 'presentity' in this context since it can
represent a bot.  My usage of it thus far has been meant to represent a
user).

- 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