[Top] [All Lists]

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

2008-07-23 02:51:42

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 

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


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