I guess I have to wonder why this idea is suddenly okay when it's been
rejected numerous times in the past. It's not as if conditions on the
network have changed to be more benign since the idea was last considered.
Keith
On 12/16/22 12:30, Robert Sparks via Datatracker wrote:
Reviewer: Robert Sparks
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-billon-expires-08
Reviewer: Robert Sparks
Review Date: 2022-12-16
IETF LC End Date: 2022-12-27
IESG Telechat date: Not scheduled for a telechat
Summary: Ready for publication as a proposed standard RFC
The last call discussion of this document is surprisingly voluminous, but my
individual opinion is that no further change is needed.
To me the document is clear and at least one implementation exists.
It's interesting to note that as of -08 there are only two non-boilerplate
sentences using BCP 14 keywords:
* Message creators **MUST NOT** include more than one Expires header field in
the message they send. * If there is more than one Expires header field then
message readers **SHOULD** act as if no Expires header field is present.
(unless the software I have that extracts those has a bug).
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
