- From: Martin Duke via Datatracker <noreply@ietf.org>
- Date: Mon, 22 May 2023 09:02:16 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-digest-headers@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net, mnot@mnot.net
Martin Duke has entered the following ballot position for draft-ietf-httpbis-digest-headers-12: 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-digest-headers/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This HTTP tourist was quite confused by the Repr-Digest field. Section 3.2 of RFC9110 says that a representation "consists of a set of representation metadata and a potentially unbounded stream of representation data". So what exactly is the input to the hash function for Repr-Digest? I was expecting to see some of the metadata fields somehow incorporated in the input, but the appendices seem to indicate that the input is just the full, not-range-limited content, in whatever encoding the sender selects. An unambiguous statement of the Hash algorithm input in each case would be helpful, though maybe it's just because my comfort with the term "representation" is just from having read the definition, rather than working with it.
Received on Monday, 22 May 2023 16:02:22 UTC