- From: Tommy Jensen via Datatracker <noreply@ietf.org>
- Date: Thu, 02 Apr 2026 00:24:05 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-unencoded-digest@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net
Tommy Jensen has entered the following ballot position for
draft-ietf-httpbis-unencoded-digest-04: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-unencoded-digest/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
In Section 5:
> original unencoded representation. In order to avoid unintended
> validation failures, care is advised when selecting content codings
> for use with Unencoded-Digest; that said, most registered content
> codings do provide byte-for-byte equivalence and are appropriate.
The important bit is that this consideration is surfaced to the reader (which
this section does). However, Section 5 seems to go out of its way to politely
permit the implementor to shoot themselves in the foot if they so choose after
carefully explaining why they shouldn't. I suggest adding a normative SHOULD
here ("When selecting content codings, implementations SHOULD use those with
byte-to-byte equivalence to avoid...") seeing as how this is exactly a
situation where the implementor has a choice and the authors wish to explain
why there's a more correct choice that otherwise has negative consequences.
I support the other normative commentary from the COMMENT sections from Mahesh
and Deb. Like Deb, I don't think a DISCUSS is warranted, but I am hoping the
next revision addressing Mahesh's DISCUSS will also significantly clean up the
approach to normative requirements in what otherwise looks like a solid
document.
Minor nit in Section 6: s/"following by an LF"/"followed by an LF"/
Received on Thursday, 2 April 2026 07:24:20 UTC