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

[Michael Welzl <michael.welzl@xxxxxxxxxx>]

On Mon, 2008-07-28 at 13:25 -0400, Hector Santos wrote:
> Michael Welzl wrote:
> > Hi all,
> > 
> > 
> > On Sun, 2008-07-27 at 13:35 -0400, Hector Santos wrote:
> > 
> > [snip]
> > 
> > 
> >> IMO, if we can't make this new proposal of a Sender define "expires" 
> >> header consistent with already existing standard practices, then IMO, 
> >> it should be call something else.
> > 
> > To repeat the nice definition that Keith gave us, and which most
> > of us seem to like:
> 
> But is not realistic.

Why?


> What is more realistic is the original intent of the I-D you 
> referenced in which you tried to revive the "Expires" header:
> 
>     http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15
> 
> where it defines Expires as:
> 
>     4. Expires:
> 
>     Syntax: Expires-field = "Expires:" CFWS date-time [CFWS] CRLF
> 
>     The Expires header indicates a date-time, at which this
>     message expires. The field can be used both to limit and to
>     extend the life of a message. User agents and servers which
>     employ automatic purging of old messages MAY let this field
>     influence the purging process. There is no requirement that a
>     user agent must suppress expired messages or make them
>     inaccessible to their owners.

Let's analyze the paragraph:

* sentence 1 is fine with me.

* sentence 2, "can be used both to limit and to extend" seems
  confusing and strange to me.

* sentence 3 is fine with me.

* The last sentence is not strict enough in my opinion. One
  conclusion from this whole discussion that we're having here
  is that the field should only be advisory. Hence I prefer
  the stricter statement that Keith made, even when it's
  unusual to prescribe behavior for user agents:

"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"


> It is quite clear of the intent and the engineerings insights for 
> forth in the Expires header:
> 
>     ... servers which employ automatic purging of old messages
>     MAY let this field influence the purging process.
> 
> You can't ignore this.

ok.

cheers,
Michael