[Top] [All Lists]

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

2008-07-22 08:37:53

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.


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