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

From: [email-masked]
Date: Wed, 5 Mar 2003 13:02:20 +0200

Hi,

Some comments inline.

 > -----Original Message-----
 > From: ext Ben Campbell [mailto:[email-masked]]
 > Sent: 04 March, 2003 20:11
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: Sean Olson; Jon Peterson; Isomaki Markus (NRC/Helsinki); Kiss
 > Krisztian (NRC/Tampere); [email-masked]
 > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
 > 
[snip]
 > 
 > 
 > Sorry for jumping late into the conversation, but the problem is, I
 > think, that this approach _assumes_ the compositor supports 
 > a concept of
 > hard state, or default state, or whatever you want to call it. Such
 > support should be a matter of local policy. Some compositors 
 > might fall
 > back to a default state when everything else expires. But an equally
 > valid model is to pass the expiration times on to watchers, and do
 > _nothing_ at expiration time. The semanitic becomes something to the
 > effect of "this is the last I heard, and it is probably 
 > stale, but make
 > your own decision."

Yes, I'm assuming that the composer supports the default state, or fallback status concept. I'm also stating a requirement, that the PUBLISH mechanism should support setting the default status - I'm not saying all composers must support this concept, or support setting the default status with PUBLISH. My point is that the default status is not that different from "live" status, so that we would need to defer the problem to another interface or work item.

I would even argue, that what you say above also makes assumptions about the system. It assumes that watchers understand something about expiration of presence statuses, which they don't by default. Expires of a PUBLISH can't be mapped to the subscriptions of watchers, and a timestamp in a presence document says nothing about expiration.

I'm also a little worried about the duality of Expires in PUBLISH. On one side there's a need to do garbage collection efficiently, and on the other hand, there's a need to publish event state that carries an explicit lifetime. The former fits my interpretation of Expires, but the latter is unclear to me - seems like a new requirement for presence info itself. Sort of like a "Back in 15 minutes" note in a machine-readable form. 

 > My personal opinion is that a presence system has room for 
 > both hard and
 > soft state, and that PUBLISH should be explicitly scoped as 
 > a mechanism
 > for dynamic manipulation of soft state. Hard state manipulation is
 > better left for the data manipulation requirements that have been
 > discussed separately. Setting hard state data is not that 
 > different that
 > establishing buddy list entries, or asserting watcher authorization
 > policy. It doesn't _need_ the dynamicism of PUBLISH.

Publishing this hard state may be as simple as publishing a presentity <note> element. I don't think that being able to publish a <note> that will survive my turning off my PUA devices for a few hours is that unreasonable with PUBLISH. It would seem that the same benefits for using PUBLISH in soft state updates apply here as well. 

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