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
(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
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?