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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Sep 2004 17:29:49 -0400

This isn't really an issue with the data model so much as rpid, but its 
used as an example in the data model.

The question is, in the context of the data model, what does <idle> 
mean? Does <idle> apply to a person? To a device? To a service? For each 
case, what does it mean? Does it merely mean, "the likelihood is that 
attempts to reach this service will result in a no-answer", or is it 
something more specific, such as "idle indicates that no user input has 
been provided to this device (service) recently".

The first question is to determine its definition, I think. Once you 
know what it means, you can decide whether it applies to devices, 
services or person. I'm somewhat on the fence here. One argument is that 
you want a concise and measurable definition, so that a PUA can 
concretely say, "this service is idle", and have the recipient of the 
document know what it means. That would argue for something based on 
user input. The problem with that definition is that ultimately, the 
lack of user input is useful because it is an indicator of the real 
quantity of interest - the likelihood that I'll get a "no answer". So, 
why not define it as the data we really want. The problem is that you 
will see vast differences across devices in declaring themselves idle, 
and thus differing interpretations of what to do when you see it in a 
document. Feature or bug? You decide.

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.

[this is the final open issue I am aware of]

Thanks,
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: Wed, 29 Sep 2004 10:44:09 -0400

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 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.

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.

Mike

At 05:29 PM 9/28/2004 -0400, Jonathan Rosenberg wrote:
>The question is, in the context of the data model, what does <idle> mean? 
>Does <idle> apply to a person? To a device? To a service? For each case, 
>what does it mean? Does it merely mean, "the likelihood is that attempts 
>to reach this service will result in a no-answer", or is it something more 
>specific, such as "idle indicates that no user input has been provided to 
>this device (service) recently".
>
>The first question is to determine its definition, I think. Once you know 
>what it means, you can decide whether it applies to devices, services or 
>person. I'm somewhat on the fence here. One argument is that you want a 
>concise and measurable definition, so that a PUA can concretely say, "this 
>service is idle", and have the recipient of the document know what it 
>means. That would argue for something based on user input. The problem 
>with that definition is that ultimately, the lack of user input is useful 
>because it is an indicator of the real quantity of interest - the 
>likelihood that I'll get a "no answer". So, why not define it as the data 
>we really want. The problem is that you will see vast differences across 
>devices in declaring themselves idle, and thus differing interpretations 
>of what to do when you see it in a document. Feature or bug? You decide.
>
>input), and have it be associated with the device, not the service. I know 
>others have different opinions. Lets sort this out.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Sep 2004 11:54:23 -0400

> been provided to this device (service) recently".

The likelihood of reachability is defined by other things besides the 
lack of user input or similar metrics. Calling "likelihood of 
reachability" <idle> seems a bit odd, although lack of usage is clearly 
a factor in gauging such probability.

The RPID draft tries to state this currently.

> quantity of interest - the likelihood that I'll get a "no answer". So, 

But there are lots of reasons for 'no answer'. I might be in a movie 
theater or driving and decide not to answer your call. I might be out of 
coverage area, etc.

In many cases, <idle> is not a terribly good indication of likelihood of 
answer. I make very few calls on my cell phone, i.e., it would be idle 
by any reasonable definition, but it is certainly reachable.

For a person who walks around with an earbud and is exceeding their 
5000-minutes-a-month allotment, idleness may indeed be an indication of 
not being able to be reached.

> document. Feature or bug? You decide.

I think the general approach in RPID has been to provide reasonably 
well-defined input data which is then interpreted, combining multiple 
pieces of information and maybe historical data, to guide communications 
or qualitative reachability. (For example, a smart watcher may correlate 
various factors into a reachability score, based on previous "experiments".)

> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2004 21:08:05 -0400

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.

	Paul

Henning Schulzrinne wrote:
>> mean? Does <idle> apply to a person? To a device? To a service? For 
>> each case, what does it mean? Does it merely mean, "the likelihood is 
>> that attempts to reach this service will result in a no-answer", or is 
>> it something more specific, such as "idle indicates that no user input 
>> has been provided to this device (service) recently".
> 
> 
>> services or person. I'm somewhat on the fence here. One argument is 
>> that you want a concise and measurable definition, so that a PUA can