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

From: [email-masked]
Date: Mon, 17 Mar 2003 21:43:17 +0200

Hi Jon,

Using the data manipulation work for setting default statuses certainly makes sense. It just isn't completely clear to me that publication of default status necessarily demands it.  

The very simple design of the corresponding dataset class would have exactly three attributes: entry id, presentity URI, and the default presence document. The PUBLISH definitely should be able to handle this much data manipulation. In addition, a single mechanism would save us from having to provision, find, establish an SA, connect to etc. a data manipulation server.

But if the WG consensus leans towards data manipulation, I can certainly live with it. However, I wouldn't want to mandate yet another set of specs to implementing what I feel is a must-have feature for presence.

Some further comments below.

Cheers,
Aki

 > -----Original Message-----
 > From: ext Peterson, Jon [mailto:[email-masked]]
 > Sent: 15 March, 2003 02:44
 > To: 'Ben Campbell'; Sean Olson
 > Cc: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss
 > Krisztian (NRC/Tampere); Simple WG
 > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
 > 
 > 
 > 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.

This is a good point. The simple solution is that a new publication of a default status always replaces the existing one. So after stepping out of the airplane, the user would publish a new set of persistent state, that has the <note> cleared.

Of course finer control over specific pieces of a default status presence document would be nice, but I could live without it.

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

PUBLISHing a CLOSED would not work if it eventually expires (and disappear). Therefore the default status concept is critical in this scenario.
 
 > > > > 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.

I think here we clearly disagree. From my point of view, publishing reachability information shouldn't be limited to (near) real-time communications. Even if email is not a real-time communication medium such as voice or IM, there is a lot of useful information that one can provide to watchers. For example, the fact that a user has an MWI subscription active makes it much more likely that an email reaches the recipient relatively soon - compared to an account that gets read once a week.
 
[snip]
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple