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