Re: WG Last Call: draft-ietf-httpbis-unencoded-digest-01 (Ends 2025-11-30)

This looks pretty good.

There is one thing that occurred to me reading this, which might be worth noting.  This depends on having codings that produce exactly one sequence of bytes when decoded.

RFC 9110 says that a content coding transforms the content "without losing the identity of its underlying media type and without loss of information".  I can think of any number of codings that would not always transform back into the same sequence of bytes.

If you are struggling to imagine something, consider a possible json-as-cbor coding scheme.  In this, the JSON infoset is serialized using the (more compact) CBOR encoding.  This is a reversible transform[1] that doesn't change semantics or lose information, but it might not retain things like the spaces between tokens when inverted/decoded (`{"thing":true}` vs `{ "thing": true }` or "\u0009" vs "\t", for instance).  Digests of the restored serialization won't work in that case.

Maybe that's not what RFC 9110 intended and these coding schemes are not permitted.  But that's not what it *says*, unless you take a very specific interpretation of the word "identity".

Nit: It might be worth noting that the gzip encoding in the examples is hex encoded (with added spacing for formatting purposes).

[1] OK, maybe I-JSON, to avoid questions about some of JSON's more extreme quirks.

On Mon, Nov 17, 2025, at 11:55, Mark Nottingham via Datatracker wrote:
> Subject: WG Last Call: draft-ietf-httpbis-unencoded-digest-01 (Ends
> 2025-11-30)
>
> This message starts a 2-week WG Last Call for this document.
>
> Abstract:
>    The Repr-Digest and Content-Digest integrity fields are subject to
>    HTTP content coding considerations.  There are some use cases that
>    benefit from the unambiguous exchange of integrity digests of
>    unencoded representation.  The Unencoded-Digest and Want-Unencoded-
>    Digest fields complement existing integrity fields for this purpose.
>
> File can be retrieved from:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-unencoded-digest/
>
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping
> ietf-http-wg@w3.org in copy. Objections should be motivated and suggestions
> to resolve them are highly appreciated.
>
> Authors, and WG participants in general, are reminded again of the
> Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
> [1]. Appropriate IPR disclosures required for full conformance with the
> provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
> any. Sanctions available for application to violators of IETF IPR Policy can
> be found at [3].
>
> Thank you.
>
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/

Received on Monday, 17 November 2025 02:55:44 UTC