Thank you for this clear and concise document. 

In section 6, one minor suggestion is to update the description of the response in the second example. 

OLD
The server responds with a 206 (Partial Content) response using GZIP content coding, it has three different Integrity fields.

NEW
The server responds with a 206 (Partial Content) response using GZIP content coding and containing three different Integrity fields.

I ballot no objection.

* My only comment is that I do not like the mixture of [RFC1234] and [LIST] names for references.  I prefer to that you select one style or the other.

Thanks to Rifaat Shekh-Yusef for their secdir reviews.

Please note that while I am balloting 'no obj', I do feel like some minor tweaks make sense.  I am happy to have a conversation (in avoidance of the 'd' word).

Section 7, para 2:  I expected a 'SHOULD NOT' use an Unencoded-Digest in this circumstance.

Section 7, para 2:  I'm not sure I would call the inference of 'details about the unencrypted content with out decrypting it' a 'side channel' per se. Most commonly, we talk about side channels leaking key, not leaking plain text.  With no loss of clarity, I would suggest merely deleting this sentence:  'This could be used as a side channel'.  Notes:  I would hope that any digest algorithm used in this capacity was strong enough to obscure whatever structure was in the plain text.  I would also hope that in this circumstance, an Unencoded-Digest field would not be utilized.

Thanks for the work done in this document, while simple it seems useful.

BUT, please add a normative reference to RFC 8792.

Cosmetic nit: s/This includes the rule*s*: LF (line feed)/This includes the rules: LF (line feed)*.*/ (or something bigger is missing).

Regards

-éric

Thanks for addressing my DISCUSS comments.

Hi Lucas and Mike, 

Thank you for the effort put into this specification.

The text includes adequate provisions for local policies to better control the handling of the digests.

Please find below some few comments: 

# Broken link

CURRENT:
   Source for this draft and an issue tracker can be found at
   https://github.com/httpwg/http-extensions/labels/unecoded-digest.

# Update definitions, not terms

OLD:
   This document updates the terms "Integrity fields" and "Integrity
   preference fields" defined in RFC 9530.


NEW:
   This document updates the definitions of terms "Integrity fields" and "Integrity preference
   fields" defined in RFC 9530.


OLD:
   This document updates the term "Integrity fields" defined in
   [DIGEST-FIELDS] to also include the Unencoded-Digest field,

NEW:
   This document updates the definition of term "Integrity fields" defined in
   [DIGEST-FIELDS] to also include the Unencoded-Digest field,

# Folding

CURRENT:
   This document uses the line folding strategies described in
   [FOLDING].

This is used only for examples. I would move [FOLDING] from Normative to Informative.

# Ease future referencing to the updated definitions

Maybe consider adding entries in Section 2:

NEW:
 "Integrity fields" is the collective term for Content-Digest, Repr-Digest, and Unencoded-Digest.

 "Integrity preference fields" is the collective term for Want-Repr-Digest, Want-Content-Digest, and Want-Unencoded-Digest.

# Section 3

CURRENT:
   A sender MAY send a digest if it
   knows the recipient will ignore it.

Consider adding an example to illustrate how it knows that.

# Section 4

## Maybe

OLD: must be in the range 0 to 10 inclusive. 

NEW: MUST be in the range 0 to 10 inclusive. 

## Examples of valid values

OLD:
  Examples:

NEW:
  Examples of valid Want-Unencoded-Digest values are:

Cheers,
Med

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