On Wed, 2008-07-23 at 10:19 +0100, Chris Haynes wrote:
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?
Surely not: for these UAs, it's just a new, so far unknown,
header, and such headers are generally ignored AFAIK.
2) Can the semantics of an 'expired' message be agreed and communicated in a
clean, simplistic, non-technical way?
Yes, because these semantics aren't very complicated.
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?
I say yes, if we make an effort to be clear and simple here,
because the "Expiry" concept is really a simple one.