Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15

On Wed, 2008-07-30 at 04:07 -0400, Hector Santos wrote:
> The insanity as I see it:
> 
> A 2822 header proposal which is essentially is a *user feature 
> request* for MUA  *display rendering* is using the wrong term for the 

"display rendering" is given as a possible example. It could
also mean moving into a different folder or even deletion,
if explicitly allowed by the user.


> controlling header, yet at the same time, it attempts to 
> inconsistently use the wrong control header to eliminate long time 
> existing server storage automated expiration controls by shifting the 
> controls to the user with an astounding new twist - a *non-optional* 
> user permission mandate on the server retention policies - a major 
> conflictive change in the existing paradigm, a concept that never was 
> allowed and most likely will never be widely accepted.
> 
> IOW, in other to get the display to work, you need to change the 
> server behavior.
> 
> That is just plain nuts!
> 
> Bill is right. Call it something else, add classifications to it.
> Don't call it "Expires" if you don't want back ends and operators to 
> to use it in their mail-bots or try to tie it into existing automated 
>   expiration/purging processes.   Even if it was user permission 
> based, systems can get around that by making it default ON - forcing 
> the user to turn it off.

I'm against suggesting anything in the direction of the behavior
you describe above, but still could live with renaming it
(although I would against it, right now ... well, there seem
to be pro's and con's, as with any engineering problem)

Cheers,
Michael