Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean?

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 01:24:15 -0400

responding to Mike, Paul and Henning in one note:

Mike Hammer wrote:

> Jonathan,
> 
> I'm having a sense of deja vu here.  I thought previous discussions 
> led to the conclusion that idle means exactly that, i.e. no activity
>  since some time point, which may or may not be provided, depending
> on whether the idler felt that this would violate privacy.

The question is, what does "no activity" mean.

> 
> The conclusion that one could jump to based on such an indication 
> would be implicit to the type of service, device, or person.  The 
> likelihood of a no answer is conditional and thus requires some 
> intelligence to guess that.  I thought this would be left to humans 
> that have such cognitive skills.

I agree, I'm merely presenting an alternative formulation which I
thought had been proposed by someone at some point. Seems that Henning
also agrees that 'you probably won't get an answer' is not what it
means. Seems like perhaps some consensus on this part at least.

> While lack of user input is the most likely basis, this can be fooled
>  or not depending on what the thing reporting is.  Does a user 
> include automatons?  I would say that is an implementation detail and
>  just leave it at a "no activity since" definition.  I see no reason 
> to constrain this.  My 2 cents from the peanut gallery.

Here is where I disagree. If we don't have a reasonably consistent
definition of what "no activity" means, I don't see how humans or
automata can reasonably combine that information with other presence
data and come to a meaningful conclusion. From some of the discussions
we had, there were quite a few different interpretations of what "no
activity" meant.

Henning wrote:
>> At this moment, I'm inclined to the concrete definition (lack of 
>> user input), and have it be associated with the device, not the 
>> service. I know others have different opinions. Lets sort this out.
>> 
>> 
> 
> 
> I disagree with the 'device, not service'. I can easily detect 
> non-usage for a service and it seems to be as valuable for that 
> service as for some piece of plastic.

OK, I can live with that. My main beef is that it be well defined. I'd
offer up the following initial definitions:

device-idle: The device has received no data input on any of its user
input devices that require active input (including keyboards, mice,
trackballs, but excluding things like microphones and cameras where
there is always "input")

service-idle: For a service which receives input while it is the "focus"
of the user interaction (focus in the user interface sense), there has
been no input. For example, if my IM app is running, but I haven't
selected it on my PC, its idle even though I may be typing into another app.

Fire away.

Paul Kyzivat wrote:
> I think idle makes sense for devices, services, and maybe people as
> well. If we say idle can only be used for devices we will have
> problems when there are services that are capable of reporting their
> own idleness but are unable to determine device idleness.

I can buy device and service. Person is something different. Sure, an
individual can be idle in the sense that they are bored or have nothing
to do. But this would seem to be one value of something like a <mood>
element, as opposed to a separate standalone attribute. Or did you have
something else in mind?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Mike Hammer <[email-masked]>
Date: Fri, 01 Oct 2004 11:22:46 -0400

>trackballs, but excluding things like microphones and cameras where

This seems to assume that a human user is always at the other end.

I was thinking that there might be devices (e.g. a large telescope, or say 
an outdoor web cam at a popular ski resort) that could be on-line (versus 
off-line for maintenance) and could be actively serving one potential 
star-gazer or skier, or perhaps idle and available (possibly for a small 
fee).

There is no human user providing input, but I suppose one could redefine 
the controlling automaton to be the user and the activity of data exchange 
to be the input.  Note that while the camera is always on and capturing 
input, it may or may not be streaming that input to somewhere else, so 
"active input" might have meaning for cameras or microphones.

Note also that being idle in the human user case is giving a clue that 
perhaps, the human is not really there (caveat the cellphone example); but 
for an automaton, that is not the case, instead idle might be a clue that 
the fee was set too high.  So, I am still inclined to be wary about "one 
meaning fits all device types".

So, I guess the definition will work.  It just moves the definition problem 
to defining what is the user, and what is active input for cases where 
user!=human.  Should some "need to define" caution be added for those 
non-human based cases?

Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Oct 2004 12:08:41 -0400

Would a simple definition "no human interaction with the device or 
service for x minutes" not be sufficient?

For a service, 'human interaction' includes a person answering a call, 
placing a call or sending a message. Since all communication services 
are either session- or message-based, this should pretty much capture 
the possibilities.

For a device, it includes any user input, via keyboard, mouse, stylus, 
voice or other HMI device.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 22:44:39 -0400

inline.

> This seems to assume that a human user is always at the other end.

A human user or something like it, yes.

> 
> I was thinking that there might be devices (e.g. a large telescope, or 
> say an outdoor web cam at a popular ski resort) that could be on-line 
> (versus off-line for maintenance) and could be actively serving one 
> potential star-gazer or skier, or perhaps idle and available (possibly 
> for a small fee).

Sure. But these things are not communications services, and are not the 
types of things we are trying to model with presence documents.

> perhaps, the human is not really there (caveat the cellphone example); 

What does "there" refer to in your text above?

> So, I guess the definition will work.  It just moves the definition 
> problem to defining what is the user, and what is active input for cases 
> where user!=human.  Should some "need to define" caution be added for 
> those non-human based cases?

I dont think so. Presence is about communications status of people or 
things that have similar properties to people as they relate to usage of 
communications systems.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 22:40:50 -0400

Henning Schulzrinne wrote:

> For a service, 'human interaction' includes a person answering a
> call, placing a call or sending a message. Since all communication
> services are either session- or message-based, this should pretty
> much capture the possibilities.

To be honest, I don't see the difference between this an "no user input
for X minutes". Is there one?

Henning later wrote:
> Another thought:
> 
> In many cases, it is probably more informative to say "has been
> active as recently as ten minutes ago", i.e., the inverse of idle.
> Even knowing that user Bob sent email or placed a call, both
> services, a short while ago is quite useful - Bob is probably around
> and not asleep.  (Absence of idle is not as informative as the
> recipient doesn't know the idle threshold and idle may not be
> reported at all.)

Interesting. You could solve half of this by just reporting the idle 
threshold as part of the <idle> element. Once you do that, the only 
issue is differentiating lack of an idle indicatiion with active. Seems 
like the same argument could be made for almost any indicator that has 
only a positive indication.

As such, another approach would be to change idle to include both, just 
as <privacy> can indicate either private or public. Both values are 
included. That would look something like

<input>idle</input>
<input>active</input>

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 03 Oct 2004 11:53:52 +0200

> for X minutes". Is there one?

No real difference. The definition is just less input-oriented and more 
service-oriented. Presumably calls placed and messages sent require some 
form of user input. Consider it more like additional examples for services.

> included. That would look something like

I'd choose a different label, e.g., usage, but that's third-order 
nitpicking.

The general problem is that long idle times have very limited predictive 
ability - the probability of reachability dramatically *in*creases after 
15 hours of idle time for most office workers, or, around lunch time, 
after 30 minutes to one hour of idle time.

That would work, but I suspect that without a last-active indication, 
this is all of limited use. The three examples combined (short idle time 
is useful, gone home, lunch) illustrate that idle/active is helpful 
mostly if you know how long this has been active or idle (or you know 
more about the person and her timezone) and requires relatively short 
reporting intervals. Knowing that somebody was active an hour ago, at 
the last NOTIFY, isn't all that helpful.

---

From: Mike Hammer <[email-masked]>
Date: Mon, 04 Oct 2004 13:45:32 -0400

>types of things we are trying to model with presence documents.

I was trying to test out the "or something like it" as an automaton 
operating some type of service, i.e. streaming of video, versus calling a 
human and asking what the slopes look like.  This is a direct substitution, 
so I don't know why it wouldn't apply.

It is at odds with the human-based examples because automatons are always 
expected to be present and active and therefore the interpretation of idle 
may not fit the inferences we apply to humans.

>What does "there" refer to in your text above?

The presumption is that if the device is idle for long periods it may be 
because the user went to lunch, etc.; that is, that he is not *there* by 
the phone or other communication device (which also presumes he would 
answer if he was there).

I don't think one can make any inference about the likelihood of an answer, 
short of attempting communication, without including some knowledge outside 
of what can be indicated in the presence message, such as the personal 
habits of a particular person.

In any case, I agree with the idle since external input to the device approach.

Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Oct 2004 03:44:20 -0400

inline.

Henning Schulzrinne wrote:

>> issue is differentiating lack of an idle indicatiion with active. 
>> Seems like the same argument could be made for almost any indicator 
>> that has only a positive indication.
>>
>> As such, another approach would be to change idle to include both, 
>> just as <privacy> can indicate either private or public. Both values 
>> are included. That would look something like
>>
>> <input>idle</input>
>> <input>active</input>
> 
> 

For the current idle definition, there is a timestamp which includes the 
time it was last active. I think you are saying that, if you want to 
include a positive indication of activity, you need a timestamp at which 
the activity first started as well. That sounds fine to me.

-Jonathan R.