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

[Michael Welzl <michael.welzl@xxxxxxxxxx>]

On Tue, 2008-07-22 at 11:04 -0400, Keith Moore wrote:
> Michael Welzl wrote:
> > On Tue, 2008-07-22 at 09:17 -0400, Keith Moore wrote:
> >> here's my question - what should _really_ happen when a message "expires"?
> >>
> >> I keep most incoming messages for archival purposes.  So I wouldn't want 
> >> my message store to delete them on my behalf - certainly not without my 
> >> explicit consent.  What is "pointless" to you might not be pointless to 
> >> me - even an announcement about a talk that happened before I got the 
> >> announcement is useful information to me - it tells me that the talk 
> >> happened, and there might be a video of it on youtube.
> > 
> > That's what we have filters for! You could let your client
> > move the email to some subfolder, mark it somehow (light
> > grey in the list, whatever - up to your client), or just
> > delete it (like I would).
> 
> I'd love to believe that mail clients will be that flexible.  But I also 
> have to consider that most mail clients today are still fairly primitive 
> as to what they can do with existing headers.   My guess is that if 
> expiry-date / expires is implemented at all, it will generally be 
> implemented in the simplest possible way - e.g. by deleting the message 
> silently.

That would be a stupid default behavior, and we could explicitly
recommend not to do this by default in the draft.


> I wonder if anyone believes that any email he sends ever becomes 
> pointless. :)

I believe in this. Again, talk (or, more general, event)
announcements and CFPs are nice examples IMO. They are
clearly bound to a date.


> Let me repeat that I'm not opposed to standardizing this.  But it's not 
> clear to me that it would become a visible and obvious feature in MUAs 
> even if it were standardized.

but standardization seems to be the only way to give this a try.


> After over 30+ years of email, MUA user interfaces still suck.  Granted, 
> it's a difficult problem.   When significant numbers of users still have 
> trouble dealing with the difference between reply / reply-all and 
> remembering to make a conscious decision about which to use in any 
> particular situation, I have little faith that they'll deal well with 
> relatively subtle things like expiration dates in either outgoing or 
> incoming mail.

Let MUA GUIs somehow mark expired emails by default then, by showing
them in light grey or something like that.


> >> the most I might want to do with an expiry date is
> >> - for my MUA to optionally hide expired messages from me when displaying 
> >> lists of messages (say in a folder)
> >> - for my MUA to not notify me that I have new mail when an expired 
> >> message arrives.
> > 
> > Good ideas IMO. Surely the standard shouldn't prescribe
> > what exactly to do - these are things that your client
> > could do for you, or let you choose to do.
> 
> The problem is similar to that with the reply-to field.  In both cases 
> there's a conflict between the sender's expectation of what a recipient 
> _should_ do with the message, and with what the recipient actually wants 
> to do with the message.  The desire/need to avoid overly complex user 
> interfaces mudddies the waters even more.

I don't see a conflict in the "expired" semantics.


> > Simplicity is key. I propose to standardize only that one
> > thing, with the semantics being "it becomes useless after
> > that date". That really should be simple enough.
> 
> One problem with that definition is that the message is NOT useless 
> after that date.

Sorry, you're right, let me try to rephrase that:
"it becomes less important after that date because it is somehow
bound to it".

Cheers,
Michael