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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Mar 2003 19:44:02 -0500

I concur with Ben on this point - setting default attributes of compositor
behavior is best left to the data manipulation work.

A little more below.

Jon Peterson
NeuStar, Inc.

---

[snip]
> > --- [email-masked] wrote:

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

I can see why you might want to use PUBLISH for this. It would make sense,
for example, that if a PIDF body in a PUBLISH contains a <presentity>-level
note, that would become the <presentity>-level note used by the compositor,
and that it would not be subject to expiration (unlike the tuples in the
PIDF document, which would expire eventually). I imagine this would be
pretty easy for a compositor to implement - just take the note from the most
recent PUBLISH and use that.

However, when you get off the plane, how do you clear that
<presentity>-level note? Do you have to overwrite it (i.e. PUBLISH new
presence) to clear it? Are there ever cases where you'd want to set or unset
the default without publishing any presence information? I think there are.
This seems more like the data manipulation problem than the publication
problem.

Turning off a phone, btw, will naturally lead to a CLOSED state, if either
the phone PUBLISHes a CLOSED tuple before going offline, or just allows its
tuple(s) to expire.

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

From my perspective, when all presence publications expire the compositor is
left with a <presence> document that contains no tuples - it doesn't need to
have a tuple that says CLOSED, the lack of tuples explains well enough that
nothing is OPEN. The need for some default tuple still isn't clear to me.

If the reference to email above suggests that the default PIDF doc would
contain a mailto URI (either in a default tuple or in some other way), I'm
not sure that presence information should be used to advertise non-real-time
forms of communication. Any communications interface that would always have
a state of OPEN doesn't have presence, IMHO.

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