On Wednesday, July 30, 2008 at 4:19:14 AM, Keith Moore wrote:
IMHO, we're better off without a standard Expires header than with one
that would have the effect (intended or otherwise) of having such
messages be deleted without recipients' consent.
Keith
I argued yesterday that the _only_ possible semantic (relevant to an 822
discussion) is :
"After the given date the mail system MAY discard this message."
This would be the Originator giving permission for the message to be deleted
(without the recipient's knowledge or permission)- which would, I opine, be a
technically-possible feature to add to an RFC.
So far I've been arguing from a strictly logical / architectural point of view.
Let me now express a personal engineering judgement:
I think any kind of message deletion without the control or consent of the
recipient would be a very bad idea.
Consider this use case (based around Michael Welzl's original post):
a) Someone books a meeting and circulates the agenda to the invitees,
b) The departmental administrator is copied on the invite, so she can book the
room,
c) That invitation has a 'Expires' header - set at the time of the meeting
d) The adminstator's mail system notices that it has the originator's
'permission' to delete the message and does so the next morning.
However:
- The administrator wanted to keep that e-mail as a record of the room usage,
for charging purposes and room utilisation analysis,
- The secretary of the meeting needed that eMail to help write up the minutes.
In other words, the message has a meaning and validity for some recipients
beyond the knowledge or expectations of the originator.
Decisions by the originator about the time the message is 'relevant' may be
made in ignorance of the significance and validity of the contained information
for all recipients.
In my view:
1) To introduce the Expires header with a semantic which permits the mail
system to silently discard messages (wherever the message is at that time)
would be bad requirements engineering,
2) The only possible role for such a header would be as a 'hint' to recipients,
who may opt to give their user agent permission to delete messages (probably
selectively - based on sender, topic, etc). But such a 'hint' (and its
implementation) should not be discussed and defined at the 822 architectural
layer - it does not belong here.
So, FWIW, I think it is a bad idea to consider it in an 822 forum - whatever
semantic is attached to it.
Chris Haynes