Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00

From: [email-masked]
Date: Thu, 13 Mar 2003 09:19:29 +0200

Hi,

One comment below (offering to justify the need for users to modify default statuses).

 > -----Original Message-----
 > From: ext Peterson, Jon [mailto:[email-masked]]
 > Sent: 06 March, 2003 00:48
 > To: Niemi Aki (NMP/Helsinki); [email-masked]
 > Cc: [email-masked]; Isomaki Markus (NRC/Helsinki); 
 > Kiss Krisztian
 > (NRC/Tampere); [email-masked]
 > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00

[snip]

 > The issue of how different it is from "live" status though 
 > is a bit more
 > difficult. A PIDF document can contain 0 tuples. A 
 > compositor might consider
 > this to be the 'base' document it holds for every user. 
 > Sending a tuple-less
 > PIDF document to watchers definitely, in my mind, 
 > communicates that no
 > presence information is currently available for the 
 > presentity. I'm not sure
 > why this default document would need to be modified by users.

I envision two types of publications by users. Publications of type "live" statuses, which in order to be accurate need garbage collection, hence they need to be refreshed by users. Then there are the "default" statuses, which are persistent, and in the absence of any "live" publications, form the presentity's presence document.

I'm mainly interested in two simple use cases. 

1) A user is travelling and boards an airplane. She turns her device off, and would like to publish a note saying that she's on a plane. Having her phone turned off would need to result in a CLOSED status. 

2) A user goes out of radio coverage (or someone steps on her LAN line). The presence status she previously published as OPEN is no longer refreshed and defaults to CLOSED. This is good since now people will email her instead of trying IMs.

Both of these use cases show that "hard state" is really inherent to a usable presence system. The PUBLISH work really should tackle this aspect of presence in order for the SIMPLE based systems to measure up to systems already out there.

Cheers,
Aki 

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

---

From: Sean Olson <[email-masked]>
Date: Thu, 13 Mar 2003 11:07:50 -0800 (PST)

Ok, I'm sold. This makes sense to me for some
systems. Assuming that we have a requirement for 
publication of "hard state", what are the potential 
mechanisms we could use?

--- [email-masked] wrote:
> I envision two types of publications by users.
> Publications of type "live" statuses, which in order
> to be accurate need garbage collection, hence they
> need to be refreshed by users. Then there are the
> "default" statuses, which are persistent, and in the
> absence of any "live" publications, form the
> presentity's presence document.
> 
> 1) A user is travelling and boards an airplane. She
> turns her device off, and would like to publish a
> note saying that she's on a plane. Having her phone
> turned off would need to result in a CLOSED status. 
> 
> 2) A user goes out of radio coverage (or someone
> steps on her LAN line). The presence status she
> previously published as OPEN is no longer refreshed
> and defaults to CLOSED. This is good since now
> people will email her instead of trying IMs.
> 
> Both of these use cases show that "hard state" is
> really inherent to a usable presence system. The
> PUBLISH work really should tackle this aspect of
> presence in order for the SIMPLE based systems to
> measure up to systems already out there.
> 
> Cheers,
> Aki 
> 
> [snip]

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: 13 Mar 2003 13:27:33 -0600

I would like to reiterate my previous comment that setting default
states seems to fit better into the data manipulation work, also in
progress.