Re: [Simple] Extending <status> for presence

[Paul Kyzivat <[e-mail]>]

Henning Schulzrinne wrote:
> Stepping back a bit, maybe we should ask what kind of questions presence 
> about a person can answer.
> 
> (1) Is the person available for communications and, if so, on what media?
> 
> Here, in general, we only care about the media that are available, not 
> all the media that the user doesn't have right now, since that list is 
> unbounded once you add applications ("No, I'm not available for Doom, 
> Chess, SimCity, ..."). We might conceivably care about how long a media 
> might still be available ("leaving in 15 minutes, better call quickly") 
> or when it might be available again ("meeting ends in 20 minutes").

I generally agree with this, though representing all of this 
information, and making clients that can encode, decode, and utilize it 
in a productive way may be quite an agressive goal.

However I think this category is about the device, not the person. The 
availability of the person is something separate. (more below)

It is definitely necessary to represent media that are not available now 
but that might be available later to get any value out of a status like 
"Out to Lunch". I wrote about this earlier. (What value is there in 
knowing you will be back from lunch soon if I don't know if you are ever 
capable of communicating in the way I require?)

> 
> (2) What is the person doing right now?
> 
> We might want to know not just the start time (how long already), but 
> also how long until anticipated completion.

I guess "Out to Lunch" falls into this category. It doesn't necessarily 
imply unavailability to communicate either. (You may be able to call me 
at my cell phone while I am at lunch if you don't mind listening to me 
chew.)

> 
> Note that many calendar systems (such as RFC 2445 or Yahoo calendar) 
> allow for categories of activities. Some are free-text (but often 
> definable as a list for a particular software), others are pre-defined.

Going that far scares me. Pretty much a guarantee that we will never 
complete this task.

> 
> (3) How is the person feeling right now (calm and relaxed, stressed, 
> hopping mad) - very useful to know for the calling party and easily 
> derived from a real-time blood-pressure input. (:-), if that's needed.)

Does Do Not Disturb fit in here? I think so.

> 
> Obviously, there could be many other pieces of information that might be 
> useful to others, such as location, level of distraction ("watching 
> TV"), etc., but I suspect we all agree that those are beyond the current 
> discussion.

Another one that seems to be important is Active/Inactive - derived from 
observation of behavior rather than explicitly set. So you can send me a 
message but I may not respond, or you can call me but I might not answer.

> 
> Note that you can easily get to the point where you are effectively 
> sending an iCal (or xCal draft-ietf-calsch-many-xcal-02.txt) entry 
> describing the activity. This may be a better, more general solution.


Henning Schulzrinne later wrote:
> Another dimension: availability for communication can probably be 
> classified into three rough classes:
> 
> - available real-time
> - available store-and-forward (message store of some sort, e.g., 
> voicemail or IMs that are stored somewhere for retrieval)
> - not availabl

I'm not sure this is another dimension, or bits and pieces of other 
dimensions. Nor am I sure whether you intend this to describe the device 
or the person.

I think there may be value in describing the person (if any) as 
available/unavailable. This is something like active/inactive but is an 
explicit assertion rather than inferred. (All combinations of the two 
are possible.)

But available-store-and-forward seems different. This can be represented 
many different ways. One way is with a separate tuple representing a 
recorder or voicemail system. This might be a common way to handle it 
for voicemail. It may also be an appropriate solution for IM in some 
cases, such as when you are on vacation, or your normal IM device is 
offline for some other reason. But it may not cover the case where your 
IM device is online but you are away. In this case the device may simply 
accept IM on your behalf - in effect it is acting as the independent 
recording device would, but isn't a separate device.

I don't yet see how to describe this. It is a device that both is and 
isn't an automaton.

	Paul


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