IESG,
TL;DR summary: It may be entirely reasonable to define a message
header field for this purpose, but reusing the old name, even
under the rubric of an update, is not a good idea. There are
other issues with the document. Skip to "Conclusions" below if
necessary.
A very high level observation about this spec:
When the "Expires:" header field has been used at all in recent
years, its semantics have not been well-defined. It was
formally introduced into the IETF world with the MIXER specs
(most recently RFC 2156), but that spec does not give a
definition of its use other than via a somewhat indirect pointer
to the X.400 specs. If I recall, it has appeared in messages
mapped into Internet mail from USENET and Netnews (see RFCs 850
and 1036 as well as the current RFC 5536, the latter cited in
the I-D) since the 1980s. In even more dim memory, I believe
it appeared in some messages gatewayed from versions of the
Defense Messaging System (DMS), even pre-GOSIP (and hence not
X.400-derived) ones, and that fields with similar meanings that
might have been translated into "Expires" or "Expiration-date"
appeared in a few of the proprietary messaging systems of the
1980s and early 1990s. The draft hints at the existence of
those other implementations with "or elsewhere" in the second
paragraph of Section 6.
Pretending (accidentally or intentionally) that the MIXER
definition and the X.400 definition on which it depends and that
any other implementations have the similar (see below) semantics
are the only use to which "Expires:" has been put historically
is just not realistic. Proving that other cases do not exist
falls into the category of proving a universal negative.
In particular, when those other implementations specified what
the field is about and how it is expected to be interpreted at
all --most didn't, at least in documents easily accessible to
the Internet implementer community-- the definitions are not
consistent with each other. "Expires" as "should be discarded",
as "no longer relevant after", as "a new message on this subject
will be available by then and should be consulted instead", as
"becomes toxic after and should not be read", as "should not be
retained even for historical purposes", etc., are all different.
And "loses its validity" (from RFC 2156 and the current
document) could encompass any of those and is not obviously
equivalent to "has no value" (Section 4 of the I-D). As the
document points out about Netnews, syntax and meanings are
similar across those implementations/ uses, but not the same.
Expecting uses of "Expires:" to conform to a new, "updated"
definition is not plausible. Messages lying around in old
archives ("expired" or "lost validity" or not) will not be
updated. Any external systems that use the field and gateway
traffic into the Internet are unlikely to change their
definitions and we can't make them (one of the authors of this
I-D has recently discussed this issue in a closely-related
context [1]).
In addition to that broad issue, there are a number of nit-picky
issues that should probably be fixed if the document is to be
placed on Standards Track. I agree with Barry [2] about the
placement and content of Section 6. It is not entirely clear
to me what Section 3 means unless it is "weird stuff might
appear in the date-time field and your code should not blow up".
If so, wouldn't incorporating the language of the last paragraph
of Section 3.3 of RFC 5322 be more appropriate? A comment about
pre-expired messages (those with dates in the past, perhaps "a
long way in the past") might be in order, perhaps with a SHOULD
NOT. RFC 2156 is the ultimate reference for date-time in this
spec, but it actually never defines it other than in prose about
what might happen (and that prose refers to RFC 822, not 5322).
More important, every single use of date-time in RFC 5322 (and
5322bis and 5321 and 5321bis) is a time-stamp, i.e., a field
that records the date and time at which some event occurred.
The value in the "Expires:" field is (normally) a future
calendar date. The topic of how to handle such dates and the
issues involved has been the focus of active discussion in
SEDATE and, I gather, in CALEXT. Given that the I-D is being
proposed for standardization in Last 2022 rather than, e.g.,
1983 (RFC RFC 850), 1984 (X.400 Red Book), or 1986 (RFC 987),
perhaps the value of that element should be aligned, at least as
an option, with the SEDATE and CALEXT work rather than assuming
that future dates and time stamps are the same thing.
Conclusions:
(1) A new header field, with a new name, one that is carefully
defined as to semantics and intent, would certainly be
appropriate, especially if the authors are aware of
implementations that intend to use this functionality.
Overloading that function by "updating" the definition of a
header field that has been around for 35 or more years (in the
IETF, first as "Expiry-Date:") and used in ways some of which
conform to IETF specifications and some of which do not (or that
conform only through vagueness) is just looking for
incompatibilities where one implementation interprets the field
(or the reasons for supplying it) in different ways than others.
Better to start with a new field name, a clear definition,
possibly an additional clause to identify intent, and some
careful language about obsoleting the "Expires" of RFCs 2156 and
4021.
(2) Section 3, 4, and 5 of the document need careful
reexamination. Issues with Section 3 are discussed above. 4
and 5 do not present clear enough definitions to actually make
the field useful in an interoperable way and appear to create
some contradictions in terminology.
(3) The date-time information should be carefully reexamined
with regard to handing of future dates and times. As a start,
the SEDATE and CALEXT WGs should be asked to review this
specification.
thanks,
john
[1]
https://mailarchive.ietf.org/arch/msg/emailcore/JEgnHty7YBiu7ioj_uKkjJ4sgcM
[2]
https://mailarchive.ietf.org/arch/msg/last-call/J1Zqxjal9xkR5KNbBocNyOfW56U
--On Tuesday, November 29, 2022 06:28 -0800 The IESG
<iesg-secretary@xxxxxxxx> wrote:
>
> The IESG has received a request from an individual submitter
> to consider the following document: - 'Updated Use of the
> Expires Message Header Field' <draft-billon-expires-06.txt>
> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the last-call@xxxxxxxx mailing lists
> by 2022-12-27. Exceptionally, comments may be sent to
> iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document allows broader use of the Expires message
> header field for mail messages. Message creators can then
> indicate when a message sent becomes valueless and can
> safely be deleted, while recipients would use the
> information to delete or ignore these valueless messages.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-billon-expires/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf-announce
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
