[Top] [All Lists]

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

2008-07-30 01:31:21

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.


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.


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 

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.

- 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


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