--On Sunday, December 25, 2022 03:12 -0500 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>...
> Of course none of this is likely to be critical unless Expires
> is actually used to delete messages, which is where many of
> the hazards associated with this proposal lie. And even if
> it is used in that way with the recipient's explicit consent,
> the recipient might be wise to wait some delta-t (say 24-48
> hours) before actually effecting message deletion, to
> accommodate various kinds of inconsistency between clocks and
> time zone interpretations.
Keith,
While I share your concern about deletion, I question whether,
e.g., moving them to a separate folder; color-coding them in a
TOC with some indication the user might rationally construe as
"don't bother reading" or "anything this says is probably wrong
by now" (one, IMO reasonable, reading of "lost validity"); etc.
are, for at least some cases, much better than deletion. Of
course, they are somewhat better because the messages can be
recovered and read but, if the user doesn't know where to look
for them or think to do that,...
And that, of course, raises another issue connected to one that
has been commented on recently. While the IETF does not have a
good history with designing user interfaces and generally tries
to avoid it, designing user behavior -- which the above and
other non-automated uses of message expiration at the receiving
end essentially require if we want constraints on what can be
done automagically is even more of a problem.
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
