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).
(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. 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.
Sure it's only a claim that people would use that feature
if it was a standard, but I say that this is worth trying.
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.
a similar question - when should a sender set an expiry date?
When (s)he thinks that it's appropriate. I think it's appropriate
to do so when sending a CFP. If that feature would exist like
I envision, I would visit some of our secretaries and tell them
that it would be appropriate for the talk announcemennts that
they send around. (and there would, of course, be more examples)
I'm not saying it's a bad idea, I'm saying that these issues are hard to
sort out and that's probably why we haven't standardized it yet.
There's really no other way than to try, and for properly
trying this, there's really no other way than to standardize
it. At most, we could try to find a company that already makes
use of the feature in Outlook, but that could be that company's
policy and not tell us much about whether the majority
of people would use it if that feature was generally standardized
and available everywhere.
(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.
Cheers,
Michael