ietf-822
[Top] [All Lists]

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

2008-07-29 02:19:52

On Mon, 2008-07-28 at 23:51 -0400, Hector Santos wrote:
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.

Well put.

Let's settle for 3, but the way it was specified by Keith
is stricter and IMO better:

"Mail Filters MUST NOT consider an expired header field as criteria to 
be considered for deleting the message unless given explicit 
instructions to do so by the recipient"

Semantically, this is not very different from 1) - they MAY do so,
but they MUST NOT do so unless the user allows it. Regarding the
email that I just sent a minute ago, where I agreed to keep the
sentence 1), I now think that this sentence should not be there
because it dilutes what we're saying. That is, if we already say
that servers MUST NOT do so without user permission, it's pointless
to additionally say that they MAY do so.


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 also want #3.


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.

I don't understand that. I have seen wide agreement that we
don't want to specify behavior #1, so why do you call this
more realistic?

Cheers,
Michael

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