Re: EXPIRE

On Thu, 23 Jul 1998, Lyndon Nerenberg wrote:
> And for those exact reasons I oppose including EXPIRE. At best the information 
> it provides is of marginal utility, and in practice, any incorrect/invalid 
> data returned by EXPIRE will most likely result in lost mail. The only way I 
> will support EXPIRE is if the protocol spec *requires* the server to enforce 
> the value it advertised to a client (i.e. if on day n you say EXPIRE 30, and
> on day n+1 you say EXPIRE 2, any operations I performed on day n must continue
> to work within the constraints of the EXPIRE 30 information you gave me). If 
> you cannot guarantee the semantics of operations based on EXPIRE data it 
> doesn't belong in the protocol.

A sysadmin can always change policy regardless of what any standard says.
I really wish you had complained during the past year this proposal has
been refined.  It's really frustrating to get lots of review on a
proposal, get it near complete, then go back to the drawing board as
complaints spring out of the woodwork.

If we want to ratchet down one level of complexity from EXPIRE, the next
would be an "AUTODELE" capability which indicates that RETR and/or TOP
cause an implicit DELE.

		- Chris