Re: Martin Duke's No Objection on draft-ietf-httpbis-digest-headers-12: (with COMMENT)

Hi Martin,

Thank you for your review. Response in line:

On Mon, May 22, 2023 at 5:02 PM Martin Duke via Datatracker <
noreply@ietf.org> wrote:

> 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.
>

Representations are a bit head-scratchy overall sometimes but I think I
know what might be contributing to it in this document.

Section 3 defines Repr-Digest with the statement (note the use of term
"representation data")

> The Repr-Digest HTTP field can be used in requests and responses to
communicate digests that are calculated using a hashing algorithm applied
to the entire selected representation data (see Section 8.1
<https://rfc-editor.org/rfc/rfc9110#section-8.1> of [HTTP
<https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html#RFC9110>
]).

where Section 8.1 of HTTP says

> The representation data associated with an HTTP message is either
provided as the content of the message or referred to by the message
semantics and the target URI. The representation data is in a format and
encoding defined by the representation metadata header fields. The data
type of the representation data is determined via the header fields
Content-Type <https://www.rfc-editor.org/rfc/rfc9110#field.content-type>
and Content-Encoding
<https://www.rfc-editor.org/rfc/rfc9110#field.content-encoding>. ...

However, in a few other places in our document, we link to RFC 9110 Section
3.2, which is a more high-level description of Representations and I
suspect the source of the ambiguity you observe. I think most of those
links could instead point to Section 8.1. IMO the text there satisfies your
request for an unambiguous statement. Would this change work to address
your COMMENT?

Cheers
Lucas