[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
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".