The insanity as I see it:
A 2822 header proposal which is essentially is a *user feature
request* for MUA *display rendering* is using the wrong term for the
controlling header, yet at the same time, it attempts to
inconsistently use the wrong control header to eliminate long time
existing server storage automated expiration controls by shifting the
controls to the user with an astounding new twist - a *non-optional*
user permission mandate on the server retention policies - a major
conflictive change in the existing paradigm, a concept that never was
allowed and most likely will never be widely accepted.
IOW, in other to get the display to work, you need to change the
server behavior.
That is just plain nuts!
Bill is right. Call it something else, add classifications to it.
Don't call it "Expires" if you don't want back ends and operators to
to use it in their mail-bots or try to tie it into existing automated
expiration/purging processes. Even if it was user permission
based, systems can get around that by making it default ON - forcing
the user to turn it off.
--
HLS
Chris Haynes wrote:
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
--
HLS