[Top] [All Lists]

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

2008-07-24 12:03:05

On Thu, 2008-07-24, Chris Eastlund wrote:

Isn't this more of a calendar function than a cleanup function?

If I miss a meeting notice that has an EXPIRES header, I don't
want it deleted, I might want it highlighted so I can apologize for
missing the meeting.  And it would be nice if the MUA would slide
soon-to-expire messages to the top of some priority list.

Maybe it's a personal choice, but I don't want a third party being
able to set a firm date-to-disappear on mail in my inbox.

This explosion of responses to the Expires header field proposal made me
step back to see what the issue might be.

I think that "expires" is not even the right concept here! It is phrased in
such a way that most of us wanted to jump in and make sure that it doesn't
interfere with *our own way* of managing email stores.

I think that what might be needed here is something more positive and
useful. The desire seems to be to allow the sender to categorize a message
based on a datetime and allow a user to choose to do some automatic
processing keyed to that header field.

I suggest something like:

scheduled = "Scheduled:" chron-desc *("," chron-desc)

chron-desc = chron-name ":" date-time

chron-name = "Invitation" |
             "Event" |
             "Vacation" |
             "Deadline" |
             "Warning" |
             "Expires" |

For example, a conference announcement might contain:

Scheduled: Invitation: 1 Aug 2008 17:00 -0400,
 Warning: 1 Sep 2008 17:00 -0400,
 Event: 8 Sep 2008 08:00 -0400,
 Expires: 12 Sep 2008 16:30 -0400

This could indicate that the invitions must be accepted by end of business
1 Aug, papers are due by end of business 1 Sep, the conference starts at 8
am on 8 Sep and is over at 4:30 pm on the 12th. (One might also infer that
the conference will be held in the US Eastern timezone.)

A MUA could be configured to change the color highlighting of the subject
listing for each of these intervals and perhaps archive or delete it when
the conference is over.

One advantage of this is that I doubt that any backend systems will try to
interpret this field and do something unwanted.

Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com>

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