Subject: RE: [Simple] comments on draft-ietf-simple-rpid (long)

From: [email-masked]
Date: Tue, 2 Mar 2004 09:03:51 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 01.March.2004 17:05
> To: Henning Schulzrinne
> Cc: Paul Kyzivat; Simple WG
> Subject: Re: [Simple] comments on draft-ietf-simple-rpid (long)
> 

> > 
> > 
> > I can't see how a PC or phone could compute these 
> probabilities. This 
> > would require knowing that 10 minutes of absence (the only 
> observable 
> > value), for a particular user, implies that there's a 20% 
> chance that 
> > the user has stepped out. Unless your PC or phone has a 
> user proximity 
> > detector, this seems hard to do.
> > 
> > We do have the contact-type to allow the receiver to guess 
> what this may 
> > mean. I think we discussed this before: in almost all 
> cases, the value 
> > of a long idle time is not all that high (unless you know that the 
> > presentity is either a telemarketer who doesn't exist 
> without a phone or 
> > a compulsive PC user that doesn't take his hands off the 
> keyboard while 
> > in the office), but a short idle time is a good indication 
> that somebody 
> > is likely home, be it a phone or PC.
> > 
> > Thus, my suggestion is to leave this as is and not try to 
> over-interpret 
> > the value.
> 
> I'd really rather not; I think its a mistake to produce an idle 
> attribute that differs substantially from established 
> semantics. This is 
> one of the few pidf extensions that we know is widely used in 
> existing 
> systems, and is a clear requirement for us to provide.
> 
> I would instead propose that we define an attribute like 
> <device-idle> 
> which makes it clear that this refers to the idle time on the 
> DEVICE on 
> which that particular tuple is associated. A natural 
> consequence of this 
> is that it wouldnt make sense for tuples that span devices or are 
> otherwise not associated with a device. I'd also suggest adding text 
> that makes it clear that, in the one case of an IM app on a PC, that 
> this has the commonly understood semantics of idle.

What else is idle? Surely <idle> is not saying that the human is idle, but the device that the human is using has not been used for a while. <device-idle> gains nothing.

For mobile phones, users can ignore the idle indication.

/Hisham

> 
> We may or may not also want idle as you have defined it; I am more 
> agnostic on that point, but would suggest renamining it if it is 
> included, to avoid confusion.
> 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Mar 2004 18:52:00 -0500

inline.

[email-masked] wrote:

> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of ext Jonathan Rosenberg 
>> Sent: 01.March.2004 17:05 To: Henning Schulzrinne Cc: Paul Kyzivat;
>> Simple WG Subject: Re: [Simple] comments on draft-ietf-simple-rpid
>> (long)
>> 
> 

>> attribute that differs substantially from established semantics.
>> This is one of the few pidf extensions that we know is widely used
>> in existing systems, and is a clear requirement for us to provide.
>> 
>> <device-idle> which makes it clear that this refers to the idle
>> time on the DEVICE on which that particular tuple is associated. A
>> natural consequence of this is that it wouldnt make sense for
>> tuples that span devices or are otherwise not associated with a
>> device. I'd also suggest adding text that makes it clear that, in
>> the one case of an IM app on a PC, that this has the commonly
>> understood semantics of idle.
> 
> 
> What else is idle? Surely <idle> is not saying that the human is
> idle, but the device that the human is using has not been used for a
> while. <device-idle> gains nothing.

My interpretation of Hennings current text:

The <idle> records the absolute time and date the communication
    device was last used.

was that "device" was limited to the IM client, for example. In such a 
case, it would mean the last time I sent an IM. I'm not sure why, on 
first read, I came to this conclusion, to be honest.

I think if, the text is clarified as to the scope of device (i.e., the 
"PC" for a typical IM app) that would be fine.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Mar 2004 18:52:00 -0500

inline.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 02 Mar 2004 20:56:25 -0500

> "PC" for a typical IM app) that would be fine.

Probably depends on contact-type:
- presentity: most recent usage for any device for presentity
- device: obvious
- service: the most recent usage across all devices being aggregated 
into one tuple

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 02 Mar 2004 20:56:25 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 14:27:27 -0500

> - service: the most recent usage across all devices being aggregated 

I think that would be a good clarification. As a general rule, many of 
these things make sense in tuples of some types, but not others. 
Wherever possible, we should make that clear.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 14:27:27 -0500

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 Mar 2004 21:16:10 -0500

> Wherever possible, we should make that clear.

Going through the elements, I couldn't find one that could be excluded 
for one of the contact-types. Clearly, some are more likely to be useful 
with some types than others, but given that devices can be in different 
locations and can have different sources of context information and that 
devices can be combined into services, it seems hard (and unnecessary) 
to rule out particular combinations.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 Mar 2004 21:16:10 -0500