Last Call Review of draft-billon-expires-06
review-billon-expires-06-artart-lc-leiba-2022-11-29-00

Thanks for this; I think it's useful to expand the use of "Expires" beyond just
am X.400 mapping field.

My main comment is that the Introduction is jarringly terse, leading me to
derive the content of Section 6 on my own before I even read further (and,
thus, before I found and read Section 6).  I strongly recommend reorganizing
this by moving the content of Section 6 into Section 1 and re-wording it a bit
to make it a proper introduction.  Something like:

   1. Introduction

   [RFC2156] defines a mapping of header fields between X.400 and
   RFC822/MIME.  One of the mapped fields is the “Expires” header
   field, which provides a date and time at which a message is
   considered to lose its validity.

   This document extends the use of the “Expires” header field to
   Internet email in general, whether the message comes from an X.400
   gateway or elsewhere.

   The date and time of expiration can be used by the mailbox provider
   or the MUA to indicate to the user that certain messages could be
   deleted, in an attempt to unclutter the user's mailbox and spare
   storage resources.

   Netnews articles [RFC5536] have an Expires header with a similar,
   slightly more strict syntax and similar meaning.

Note that I don't think it's necessary to mention RFC 4021 at all.

I would also change the citation to 4021 in Section 2:
OLD
   The header field definition and syntax remain the same as in
   [RFC4021], the time at which a message loses its validity.
NEW
   The header field definition and syntax remain the same as in
   [RFC2156] Sections 2.3.1.2 and 5.3.4: the time at which a
   message loses its validity.

...and then remove the informative reference to 4021.

There's a typo in Section 5:
OLD
   and could allow users to control over the actions to take
NEW
   and could allow users control over the actions to take