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

Hi Rob,

Thank you for your review. Responses in line:

On Tue, May 23, 2023 at 12:38 PM Robert Wilton via Datatracker <
noreply@ietf.org> wrote:

> Robert Wilton 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:
> ----------------------------------------------------------------------
>
> Hi,
>
> Thanks for the this document.
>
> A couple of minor comments, that are you welcome to act on, or ignore, at
> your
> desire:
>
> 1. I'm not an HTTP expert, hence I somewhat struggled with what the
> definition
> of an HTTP representation is, although the examples B.1 - B.3 helped.
> Perhaps
> consider a forward reference to the B.1 - B.3 in section 1 or section 1.2.
>

Martin Duke also raised a comment related to HTTP representations. We just
landed a change in the editor copy to point to Section 8.1 of RFC 9110,
which is a better definition of the term representation data that matters
for the purpose of this document. I think that change probably helps the
most.

Many people will just want to use the simpler Content-Digest. The more
advanced usage of Repr-Digest needs a firmer grasp of core HTTP, In Section
3, which defines the Repr-Digest, we have a forward reference to Appendix A
that provides text intended to help the reader understand the relationship
between representations and digests, this is also noted in the document
structure outline in Section 1.1. I'm glad that Appendix B helped you.
However, overall, I'm happy with the current amount and style of forward
references to Appendix B.


> 2. I noted that the "Code Samples" section is marked as being removed from
> the
> final RFC, but I wondered why, and whether it wouldn't benefit for being
> included as informative (non-normative text).
>

That's a fair point. My memory is a little hazy why we stated this.
Possibly its because we can't be exhaustive in encodings or hashing
algorithms. Possibly because we figured its main utility would be during
spec development.

Roberto Polli - is/was there a strong reason not to include this example
code in the final RFC as an appendix?

Cheers,
Lucas


> Regards,
> Rob
>
>
>
>