Re: Tommy Jensen's No Objection on draft-ietf-httpbis-unencoded-digest-04: (with COMMENT)

Hi Tommy,

Thanks for the review. Response in line

On Thu, Apr 2, 2026, at 08:24, Tommy Jensen via Datatracker wrote:
> 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.

While I agree in general with the analysis, in practical terms I don't think normative language particularly helps.

For instance, adding SHOULD begs the question of when is it ok to ignore that and do something different. If it was upgraded to a MUST, then we enter a territory of competing requirement on content-negotiation.

The use of HTTP extensions is looser than people might tend to think. Particularly so for Integrity fields and Integrity Preference fields. They are a general-purpose tool with weak (if any) in-band feature negotiation.

The expectation with RFC 9530, this draft, and to a greater extent the related HTTP Signatures [1] is that an application/profile defines more-specific requirements. For instance, an application that mandates the use of Unencoded-Digest can apply the guidance in Section 5 and itself do the work to decide how strict or lax to be. As a concrete example, the Unencoded-Digest work is motivated by the signature-based integrity work in w3c led by co-author Mike West. I've just opened an issue there [2] to propose that it prohibits the use of such content codings since an incorrect selection will result in the failure of _that_ protocol.

> 
> 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"/

Thanks, we'll be cutting a new draft soon to incorporate the accepted feedback.

Cheers
Lucas


[1] https://httpwg.org/specs/rfc9421.html#rfc.section.1.4
[2] https://github.com/WICG/signature-based-sri/issues/54
> 
> 
> 
>