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

From: [email-masked]
Date: Wed, 5 Mar 2003 14:31:27 +0200

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, March 04, 2003 8:11 PM
> 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
> 
> 
> 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."

Never the less, there should be a requirement for a solution to enable this hard state publication. The solution is a different issue.

/Hisham

> 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple