Re: [Technical Errata Reported] RFC9530 (8890)

Hi Lucas,

Pointing out that nothing requires the digests to be matching is a valid counter-argument, I have to agree :)

When I first read the document, I used the examples to validate my understanding and implementation of the digest. During this process, I stumbled upon the mistake and it took me some time to realize there wasn't an issue with my thinking. I would like to save future readers from a similar experience in whatever way is best suited. If an editorial erratum is the best approach, then let's do that! Is it possible to edit a submitted erratum or should I submit a new one?

Best regards,
Marius Kleidl

On Mon, Apr 27, 2026, at 20:12, Lucas Pardue wrote:
> Hi,
> 
> Thanks for the report Marius, appreciate the effort of checking these things.
> 
> Its unfortunate that there's seems to be an error in an example. This is one of the issues with including so many examples in immutable RFCs.
> 
> That said, I don't think this is a technical errata since it doesnt affect anything wrt the protocol definition. Also if we wanted to get a bit philosophical, these aren't test vectors. There's an argument that there's no requirement that the server in B4 sends a correct representation or calculates a correct digest. A client that received such a response might want to identify a potential problem and retry the upload or phone their tech support :-)
> 
> I won't argue the mistake is deliberate though. We weren't trying to put red herrings in our RFC. 
> 
> Since the actual change to makes seems up for debate, I would switch this to an editorial erratum that is held for document update.
> 
> Cheers
> Lucas
> 
> On Mon, Apr 27, 2026, at 15:53, Marius Kleidl wrote:
>> Hi Roberto,
>> 
>> thank you for the additional context. It makes sense that different compression implementations can produce different output bytes. However, aligning the document with one implementation isn't the purpose of this errata. My main concern is that the SHA-256 and SHA-512 digests in the Repr-Digest header fields don't match the representation in the examples, which should be addressed as this RFC defines these header fields. I hope this helps understand my submission.
>> 
>> Best regards,
>> Marius Kleidl
>> 
>> On Mon, Apr 27, 2026, at 12:28, Roberto Polli wrote:
>>> Hi Marius,
>>> 
>>> On Sat, 25 Apr 2026 at 23:34, RFC Errata System
>>> <rfc-editor@rfc-editor.org> wrote:
>>> >
>>> > The following errata report has been submitted for RFC9530,
>>> > "Digest Fields".
>>> >
>>> > --------------------------------------
>>> > You may review the report below and at:
>>> > https://www.rfc-editor.org/errata/eid8890
>>> >
>>> > --------------------------------------
>>> > Type: Technical
>>> > Reported by: Marius Kleidl <ietf@mariuskleidl.net>
>>> >
>>> > Section: B.4.
>>> >
>>> > Original Text
>>> > -------------
>>> > 8B 08 80 7B 22 68 65 6C 6C 6F
>>> > 22 3A 20 22 77 6F 72 6C 64 22
>>> > 7D 0A 03
>>> >
>>> > Corrected Text
>>> > --------------
>>> > 0B 09 80 7B 22 68 65 6C 6C 6F
>>> > 22 3A 20 22 77 6F 72 6C 64 22
>>> > 7D 0A 03
>>> 
>>> IIRC we used Python's brotli implementation
>>> >>> brotli.compress(b'{"hello":"world"}')
>>> that returns:
>>> 
>>> 0B 08 80 7B 22 ..
>>> 
>>> so probably 8B -> 0B is an actual typo.
>>> 
>>> >
>>> > Notes
>>> > -----
>>> > The Brotli representation provided in the examples in B.4 (Figure 18) and B.6 (Figure 21) aren't valid. Trying to decompress them via Node.js' zlib package and the brotli CLI fails:
>>> >
>>> > ```
>>> > $ node -e "require('zlib').brotliDecompressSync(Buffer.from('8b08807b2268656c6c6f223a2022776f726c64227d0a03','hex'))"
>>> > node:zlib:432
>>> >       throw self[kError];
>>> >       ^
>>> >
>>> > Error: unexpected end of file
>>> >   [...]
>>> >   code: 'Z_BUF_ERROR'
>>> > }
>>> > ```
>>> >
>>> > ```
>>> > $ echo 8b08807b2268656c6c6f223a2022776f726c64227d0a03 | xxd -r -p | brotli -d -c
>>> > corrupt input [con]
>>> > ```
>>> >
>>> > In addition, the SHA-256 over the bytes in the original text is MklYnI/SsUF/5X7enJ2TU+DFjodRObdKLFaPPLe/Kcw=, not d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk= as used by the RFC in the Repr-Digest header field. The SHA-512 digest in Figure 21 is similarly incorrect.
>>> >
>>> 
>>> While I think it's OK to update the examples to match the brotli C
>>> implementation,
>>> I am not sure it's an actual erratum, and I will wait for feedback
>>> by the WG.
>>> 
>>> > The correct text only differs in the first two bytes. With this change, the response content is a valid Brotli compression of `{"hello": "world"}\n`. The SHA-256 and SHA-512 digests in the Repr-Digest header fields then also match the representation's digests.
>>> >
>>> > Instructions:
>>> > -------------
>>> > This erratum is currently posted as "Reported". (If it is spam, it
>>> > will be removed shortly by the RFC Production Center.) Please
>>> > use "Reply All" to discuss whether it should be verified or
>>> > rejected. When a decision is reached, the verifying party
>>> > will log in to change the status and edit the report, if necessary.
>>> >
>>> > --------------------------------------
>>> > RFC9530 (draft-ietf-httpbis-digest-headers-13)
>>> > --------------------------------------
>>> > Title               : Digest Fields
>>> > Publication Date    : February 2024
>>> > Author(s)           : R. Polli, L. Pardue
>>> > Category            : PROPOSED STANDARD
>>> > Source              : HTTP
>>> > Stream              : IETF
>>> > Verifying Party     : IESG
>>> 
>> 
>