ietf-822
[Top] [All Lists]

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

2008-07-30 08:31:45

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

<Prev in Thread] Current Thread [Next in Thread>