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