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

On Tue, 2008-07-22 at 11:53 -0400, Nathaniel Borenstein wrote:
> It seems to me that the problem that could derail this idea is the  
> difference between the notions of mandatory and advisory expiration.   
> It's the same problem that has often derailed discussions of  
> "unsending" a message.  It's fairly easy to specify how to send a  
> message that says "I'd like to withdraw that message that I just sent"  
> but impossible to agree that receiving agents should automatically  
> implement that request regardless of the recipient's preferences.   
> (The juiciest messages are the ones most likely to be withdrawn.)
> 
> As long as we are all clear that such expirations/withdrawals are  
> advisory, I don't see any problem with standardizing them.  For  

I'm 100% for "just advisory" - I always thought about
the proposal this way. From the other messages, I get the
impression that nobody's in favor of what you call "mandatory
expiration", and neither am I.


> example, I like the idea that I might configure meeting invitations to  
> automatically move from my inbox to my junk folder (or a special  
> expired folder) if I don't get to them in time, but I'm less happy  
> with the idea of such invitations simply disappearing without a  
> trace.  Others, of course, might prefer the quiet disappearance.  As  
> long as the recipient has control, and the new field simply indicates  
> the sender's desires/intentions, I think it's a great idea.  Moreover,  

This is exactly how I see it. The recommendation should probably
be to mark expired messages somehow by default, with a hint
that the user could be given some means to enable other behavior,
such as silently deleting such emails. Anyhow the spec should
clearly state that silently deleting MUST NOT be the default behavior.


> if we specify a way for one message to specify that a previous one had  
> "expired" we could solve both of these problems (advisory message  
> expiration and advisory message retraction) with a single  
> specification.  I think it's a great idea, but we should manage  
> expectations so that people are aware that these expirations/ 
> retractions can always be ignored.  -- Nathaniel

I'm against that, simply because one message refering to another
one opens up a can of worms that is too large. Let's keep this
small and simple. Anyway I don't see a big benefit from combining
these specs - the "another message has expired" spec could be
developed independently, and perhaps build upon the one that
I'm suggesting here.

Cheers,
Michael