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

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