ietf-822
[Top] [All Lists]

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

2008-07-23 02:47:49


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

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