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