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

Chris Haynes wrote:

> IMHO there can only be two possible 'meanings' attached to the header.
> 
> If it is intended to be received and understood by the 
 > mail transportation system I contend that the only possible>
 > semantic can be:
> 
> 1) "After the given date the mail system MAY discard this message." 
> 
> The only other possible use of the 'Expires' header (so far as an 
 > RFC822 group is concerned) is as a transparent communication
 > between originator and recipient. In this case:
> 
> 2A) The mail transportation system MUST transport the header 
 >     without modification and,
> 2B) MUST NOT pay any attention to its presence or absence.
> 
> It's my assertion that, with the architecture of today's mail systems, 
 > these are the only two possible semantics we can discuss here.

 > Debate...

In my view, the conflictive issues are:

1) Servers which employ automatic purging of old messages
    MAY let this field influence the purging process.

or

2) Servers which employ automatic purging of old messages
    MUST NOT let this field influence the purging process.

or

3) Servers which employ automatic purging of old messages
    SHOULD NOT let this field influence the purging process
    without USER PERMISSION.

The key point is the acknowledgment for the existence of a long time 
related practices that don't depend on any external expiration field 
and how a new proposed expiration related field relates to it, change 
it or alter the long time practice.

Keith wants #3 at the very least. I hope I am not mis-characterizing 
Keith when I say he has long expressed a legitimate concern for false 
positives and mailers not reaching their users.

I understand it, but #1 is more realistic. I deem a EXPIRES header 
defined by a SENDER to have an exact intent thus a zero false positive 
result. #3 would be nice for servers to begin offering the option. I 
am only pointing out that #1 is already in play and it will very hard 
to convinced backends to change these automatic practices in place. So 
you can't hold them to it.  But for me, for our system, #3 would be a 
compromise IMV.  It may not be for the next system.

-- 
HLS