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

Hi John,

Thanks for the review. Responses in-line:

On Tue, May 23, 2023 at 6:05 PM John Scudder via Datatracker <
noreply@ietf.org> wrote:

> John Scudder 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:
> ----------------------------------------------------------------------
>
> I'm balloting NOOBJ largely on the basis that the document appears to be of
> high quality and would probably be clear and usable if only I had the
> necessary
> grounding in HTTP's more abstruse corners to make sense of it. (Thank you
> for
> the references and examples, those got me halfway there, perhaps. The other
> half is the part I'm taking on faith.)
>
> I do have a few nits and questions --
>
> ## COMMENT
>
> ### Section 5, reserved token value
>
> In your description of the Status template field, you have ""reserved" -
> for
> algorithms that use a reserved token value that cannot be expressed in
> Structured Fields". This is a well-formed sentence but I have no idea what
> it
> means. I made a desultory attempt to suss it out by searching the document
> for
> "token" and this was the only occurrence. If people who will actually be
> making
> use of the registry can be expected to make sense of it, then feel free to
> disregard my comment, of course.
>
> ### Section 5, "optionally the key"
>
> A few lines further down you have "Reference(s): pointer(s) to the primary
> document(s) defining the technical details of the algorithm, and
> optionally the
> key". I couldn't work out what "the key" is in this context, that would be
> placed in the registry. The values you've seeded the registry with don't
> provide any examples, so I'm none the wiser for having checked there.
>

Thanks for pointing these out. I agree they could be improved/clarified.
I'll have a think and submit a proposal to the Github repo where this draft
live. I'll update here when that happens.


> ## NITS
>
> ### Section 6.5, e.g.
>
> In "Since it is possible for there to be variation within content coding,
> the
> checksum conveyed by the integrity field cannot be used to provide a proof
> of
> integrity "at rest" unless the whole (e.g., encoded) content is
> persisted.", do
> you actually mean "i.e." and not "e.g."?
>

Probably? :-D

We can change it and can let the RFC editor be the final arbiter.


> ### Appendix A, typo
>
> /entires/1234 should be /entries/1234
>

Thanks, we'll correct that.


Cheers,
Lucas