(adding the last call list back in because standardization has
been suggested for this header field)
--On Tuesday, December 13, 2022 06:45 -0800 Dave Crocker
<dhc@xxxxxxxxxxxx> wrote:
> On 12/2/2022 12:02 PM, Keith Moore wrote:
>> an MUA may present the message in such a way as to reflect
>> the message's decreased relevance.
>
> This is MUA guidance. Within a specification, it implies
> guidance to show this information and to distinguish it.
> This is UI/UX design guidance and, again, the IETF generally
> shouldn't do it, because the IETF generally isn't skilled at
> such issues.
>
> Also, strictly in terms of specification language, it is in
> the style of normative guidance (lack of caps notwithstanding)
> and implies that the MUA's choices about showing increased or
> decreased relevance otherwise has been restricted.
>
>
> So...
>
> The Expires message header field indicates a date-time after
> which the author of the message believes that the message no
> longer has primary relevance to its intended recipient(s).
> This field SHOULD NOT be interpreted by intermediate systems
> (such as relaying MTAs or delivery agents) and SHOULD NOT be
> used to trigger automatic deletion of the message.
>
> This is simpler, cleaner, and better-scoped.
Dave,
While I am not sure what the "primary" in "primary relevance"
means, this strikes as much closer to what we are looking for
(and what is, or ought to be intended) than terms such as "loses
validity". It also makes it clear that the header is an
expression of author/sender intent rather than some external,
and presumably well-defined, property like "validity" or "value".
However, while one of the things we have consistently agreed
about for the last several decades is that the IETF should stay
out of the MUA guidance (and UI/UX design business more
generally) -- a principle that I see as having been violated
many times in recent years -- it seems to me that a key element
of maintaining that boundary is not putting UA/UI/UX designers
in the position of having to guess what was intended and how to
act on it. Your text and Keith's seem to be moving us a few
steps away from that problem. By contrast,
draft-billon-expires-08, in continuing to talk vaguely about
"improved experience" and what systems "might" do seems to be
deep into it independent of this particular fix.
> However... on reflection, the SHOULD NOT restriction strikes
> me as excessive. To the extent there should be language
> pertaining to automated actions, I'd instead suggest adding
> non-normative language about the issues concerning taking
> automated actions upon expiry.
Mixed feelings but tend to agree, especially if the conditions
that might be used to determine actions continue to be vague.
This is a deliberate exaggeration but, to the extent to which
the document effectively says "'expires' means whatever you
think it means, as does 'message validity', and, if the
date-time is in the future, you get to interpret it in whatever
way occurs to you", it is not at all clear to me what a
receiving MUA author is expected to do (or its authors to design
for) unless we intend to supply the requisite crystal balls,
tarot cards, or equivalent.
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
