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

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.

>> (otoh, the vast majority of calls for papers that I receive - for past 
>> or future events - are useless to me.  somehow conference organizers 
>> just Don't Get that they are spammers too)
> 
> I'm sure that some of them would, if we would make it easy for
> them to let their emails automatically disappear once they
> become pointless. 

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

> But "making it easy" means that this has to be a visible and obvious feature in most email clients,
> which IMO means that it has to be a standard first. Outlook
> shows that people don't generally use that feature much as
> long as it's not a standard.

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.

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.


>> 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.


>> (and regardless of how we define a message's expiry date, getting users 
>> to understand how to use such things consistently is even harder.)
> 
> 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.

Keith