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

From: [email-masked]
Date: Thu, 27 Feb 2003 19:15:03 +0200

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

Cheers,
Aki

 > -----Original Message-----
 > From: ext Sean Olson [mailto:[email-masked]]
 > Sent: 27 February, 2003 18:37
 > To: Niemi Aki (NMP/Helsinki); [email-masked]; 
 > Isomaki Markus
 > (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); [email-masked]
 > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
 > 
 > 
 > 
 > 
 > > A suitably large Expires value would probably not
 > > work with any composer that wishes to do garbage
 > > collection in a reasonable way. It would instead
 > > lower the value to one that conforms with its local
 > > policy.
 > 
 > This I don't quite understand. Either the composer
 > is going to authorize you to store state for a 
 > long time or its not. Why would the composer be
 > more willing to store hard-state vs. state that
 > lasts a very long time?
 > 
 > > So instead, what if we define the semantics of a
 > > PUBLISH without an Expires header to accomplish
 > > this? In other words, a PUBLISH without an Expires
 > > header wouldn't expire, and would instead "initiate
 > > the composer" with a default status.
 > 
 > I would prefer that a PUBLISH without an Expires
 > header be reserved to mean that the client wishes
 > the server to choose an expiration value for the
 > publication. 
 > 
 > > 
 > > Cheers,
 > > Aki
 > > 
 > 
 > 
 > __________________________________________________
 > Do you Yahoo!?
 > Yahoo! Tax Center - forms, calculators, tips, more
 > http://taxes.yahoo.com/
 > 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple