--On Sunday, December 11, 2022 06:57 -0800 Barry Leiba via
Datatracker <noreply@xxxxxxxx> wrote:
> Thanks for addressing my review comments on version 06.
> Nothing more to say here: it's ready to go.
Unfortunately, while the document is greatly improved, it does
not address any of my key concerns. Noting that the following
are largely independent of each other so dismissing one does not
eliminate the need to address the others, a summary is:
(1) The document appears to treat "valueless", "has no value",
"loses its validity", "is [not] wanted", and "expired" as
equivalent. The first two might be, the plain English meanings
of the others are not. Similarly, the final sentence of Section
5 appears to say that "is wanted" and "fraudulent" are opposite
categories. Those differences in meaning interact with what one
might want to do with the "expired" message, including deletion,
warnings, etc.
Recommendation: Either tighten the terminology in the document,
explain the risks associated with alternative interpretations of
what "Expires:" means, or allow for an addition argument that
expresses the intent of whomever or whatever is placing the
field in the document.
(2) As has been extensively discussed recently in SEDATE (and
probably elsewhere), future dates, especially ones that try to
express exact times in other time zones, can be problematic. As
a trivial example, "Using the ABNF from [RFC5322]" is not clear
whether the use of "-0000" is allowed and, if so, whether it has
the semantics in the current version of 5322bis or the current
version of the relevant SEDATE document(s). Those definitions
are different. More important, there have been many issues
discussed there about the exact meaning of a future date and
time if, e.g., the time zone of either the originator or the
recipient is different at that future time from what is was when
the date-time field was specified.
Suggestion: The problem should not be ignored. If nothing else,
the document should either warn about attributing excess
precision to future date-times, should explicitly allow dates
without times and recommend their use, or both.
(3) While "Expires:" has been documented (and standardized) in
the IETF only for X.400 gateways ("MIXER") and Netnews, it has
been used (at least in the past) for other applications. The
fact that certain of us "have never seen" those uses is not a
reliable indication that they have never existed, nor even that
they are are no longer in use, even in communities that do not
participate in the IETF. There are also no guarantees that
those other uses have the same semantics as those this document
proposes (even if the issues in (1) above are ignored).
Preferred suggestion: Header field names are not a scarce
resource. Use a different keyword, the intentions for which and
the associated semantics are clearly spelled out; reference the
definitions of the MIXER and Netnews "Expires:" header field;
and indicate that the new header field is intended to subsume
and replace them.
Or, if there really are reasons to preserve "Expires:" in this
document despite the risks of possible confusion, at least
clearly state those in the document and warn against possible
misinterpretations of intent.
best,
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
