Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Michael Welzl <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Organization | University of Innsbruck |
| Message-ID | <[email protected]> |
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