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

Yes, thanks

On Mon, May 22, 2023 at 10:29 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

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