[Last-Call] Opsdir last call review of draft-billon-expires-06

[Carlos Pignataro via Datatracker <[e-mail]>]

Reviewer: Carlos Pignataro
Review result: Has Issues

I feel it is very useful to extend the use of the "Expires" header beyond X.400
gateway mapping, and into any email.

I do have a couple of questions/comments, for your consideration:

First, maybe a nit or language nuance, but I note a difference between
"validity" and "value" (or "valid" and "valuable".) Perhaps a misinterpretation
from English-as-a-non-1st-language, but thought I'd mention it:

I find the reference to RFC4021 useful, as
<https://www.rfc-editor.org/rfc/rfc4021.html#section-2.1.50> includes the
textual description of the field and some historical context, whereas RFC2156
doesn't directly. * RFC4021 says: "Time at which a message loses its validity."
* Which aligns with T-REC-F.400-199906-I, B.49: "date and time after which he
considers the IP-message to be invalid."

However, draft-billon-expires-06 includes text like:
* "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." * "Message creators add the header field
along with a relevant date and time when they know that the content of the
message has no value after a given point of time."

A valid message might be valueless, whereas an invalid message can be valuable
-- e.g., depending on the definition of "value". It might seem as redefining
the meaning, changing from "invalid" to "valueless".

S2 of this document does say: "The header field definition and syntax remain
the same as in [RFC4021], the time at which a message loses its validity."

The last sentence of the Introduction seems potentially contradictory to the
advice in Section 5. Deleting is one potential action, but not the only one
when user experience is the goal:
   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.
vs.
   The information provided in the header field is intended to be used
   as a signal that could be used to provide a feature or improved
   experience to the end-user.

S5 says:
   Therefore, no email
   should be silently and automatically deleted solely based on the
   value of the Expires header field.
Is this a "no email should" or a "email SHOULD NOT"?

Organization: Would S6 be more useful as part of the Introduction, which is
quite thin?

And nits:

S2.
OLD:
   If there is more than one Expires header field then message readers
   SHOULD act as if no Expires header field is present.
NEW:
   If there is more than one Expires header, field then message readers
   SHOULD act as if no Expires header field is present.

S5:
OLD:
5.  Advice to Message Readers (Mailbox providers, Webmails and MUAs)
NEW:
5.  Advice to Message Readers (Mailbox Providers, Webmails, and MUAs)

Many thanks for reading thus far!

I hope these are useful and clear.

Carlos Pignataro.