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" |
chron-extension-name
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.
Wow, for I minute I thought I was confused and reading the CALSIFY WG list.
Anyway, we already have a well defined format for specifying events,
invitations, and so on: iCalendar. (OK, it does need a little work,
which is why CALSIFY exists. But the basic format is done.) Quite a lot
of effort was expended to get agreement on this stuff. I see no point
in repeating any or all of that effort in a separate context.
But even if there was justification for additional work on calendaring that
isn't already being done somewhere else, it's a completely separate problem
from message expiration. Message expiration is just about saying when, in the
opinion of the sender, the content of a given message - whatever it happens to
be - is no longer going to be useful. The semantics don't extend to inferring
that a message with an expiration date necessarily describes some sort of event
and that the expiration time is somehow related to the time of the event.
When you get down to it this is really about being able to manage
ever-increasing amounts of email a litte more easily. If we try and take it
further than that we'll lose focus and likely derail the entire proposal.
Ned