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

[Chris Haynes <chris@xxxxxxxxxxxxxxxxx>]

On Tuesday, July 22, 2008 at 10:15:06 AM, Michael Welzl wrote:


> So we propose to standardize such a header. We would do this
> by reviving the "Expiry" part of
> http://tools.ietf.org/html/draft-ietf-mailext-new-fields-15
> (we've been in touch with the draft's author, Jacob Palme,
> about this, and he likes the idea).

Many of the responses so far have expressed concern about what UAs might or might not do with this information.  Debating these UA technical options are secondary to two key questions:

1) Would the widespread introduction / use of this header by senders cause any damage to / loss of messages in (unmodified) UAs as currently deployed?


2) Can the semantics of an 'expired' message be agreed and communicated in a clean, simplistic, non-technical way?


The ues of / content of the 'Expiry' part is not a communication between protocol-implementors, it is a communication between message senders and recipients.

Where a UA provides user-configurable facilities to recognise and respond to 'Expiry', its user will have to make decisions about how she wants expired messages to be handled. So she has to know, usually in advance of receiving any specific message, just what an 'expired' message means to her, and so how she wants the UA to handle it for her.

Similarly, the sender has to be aware just how recipients will interpret the 'Expiry' date, and consider whether the recipient behaviour (conditioned by the 'generally-understood' meaning of the value) is what is intended.

It's important to note that we are not talking here about a semantic definition using the special language which satisfies IETF junkies. It has to be one that end-users (senders and recipients) can understand.

Is that possible; can the IETF editorial processes achieve the necessary linguistic clarity and simplicity? 

Chris Haynes