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

From: Ben Campbell <[email-masked]>
Date: 04 Mar 2003 12:10:59 -0600

On Thu, 2003-02-27 at 11:15, [email-masked] wrote:
> Hi,
> 
> Maybe I'm missing something here, but as I see it, in order to do garbage collection, the composer needs to assign PUAs to refresh their publications in certain intervals. The shorter this refresh period is, the more efficient the garbage collection is; the longer the period, the more garbage state will be around.
> 
> Now I agree that a large Expires would seem to accomplish the hard-state publication, but to what value do we draw the line? When will the composer simply accept a long lasting publication, and not reduce the Expires value to its local default to enable efficient garbage collection?
> 
> I think the problem is that the Expires has dual meening in this case. It implies the lifetime of the presence info, as well as the validity period of the publication. Unless we standardize a value for Expires, after which it becomes solely the lifetime of the presence info (to indicate that the state is not to be garbage collected), different systems will behave differently.
> 
> What if we define this explicitly, say Expires=0, or Expires=4294967295 means this is meant to be stored "indefinitely"?
> 

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

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.

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