Re: AD Review: draft-ietf-httpbis-unencoded-digest

Thanks for these suggestions, and for taking the time to read through so
carefully. I've landed most of the PRs Lucas put up, and we can quibble
about wording on the last. :)

-mike


On Thu, Dec 11, 2025 at 4:03 AM Lucas Pardue <lucas@lucaspardue.com> wrote:

> Hi Mike,
>
> Thanks for the detailed review comments! I've used the ietf-comments tool
> to raise these as GitHub issues and I've responded to each one (most times
> with an associated PR). For completeness, I'll put a link to each issue as
> an in line response:
>
> On Wed, Dec 10, 2025, at 20:18, Mike Bishop wrote:
>
> # AD review of draft-ietf-httpbis-unencoded-digest-02
>
> CC @MikeBishop
>
> ## Discuss
>
> ### Section 3, paragraph 6
>
> 2119 keywords can't really be applied to future documents. I presume
> this really is intended to say "This specification does not define any
> Parameters; future extensions might do so."
>
> See https://github.com/httpwg/http-extensions/issues/3350
>
>
> ### Missing "Updates" explanation
>
> This document updates RFC9530, but does not seem to include explanatory
> text
> about this in the abstract.
>
> See https://github.com/httpwg/http-extensions/issues/3351
>
>
> ## Comments
>
> ### Section 1, paragraph 4
> ```
>      A more complex example involves HTTP Range Requests (Section 14 of
>      [HTTP]), where a client fetches multiple partial representations from
>      different origins and "stitches" them back into a whole.
> ```
> I don't see anything in that about different origins, only about separate
> requests for a given resource. If the origins differ, they are not the same
> resource (from HTTP's perspective).
>
> See https://github.com/httpwg/http-extensions/issues/3352
>
>
> ### Section 3, paragraph 3
>
> I assume there was discussion about whether repeating the definition
> here was worthwhile rather than simply saying it's identically structured?
>
> See https://github.com/httpwg/http-extensions/issues/3353
>
>
> ### Section 3, paragraph 13
>
> Please reword to be clear that you don't mean the Security
> Considerations section of the current document. Perhaps "[DIGEST-FIELDS]
> discusses some of the issues...."
>
> See https://github.com/httpwg/http-extensions/issues/3354
>
>
> ### Section 4, paragraph 3
>
> It's difficult to know whether the recipient "ignored" what you sent or
> considered it but made a different choice. Consider being more precise
> here,
> that receiving an Unencoded-Digest which does not conform to the
> Want-Unencoded-Digest you sent is not (MUST NOT be?) treated as an error.
>
> See https://github.com/httpwg/http-extensions/issues/3355
>
>
> ### Section 5, paragraph 2
>
> This is a subtle distinction; thank you for calling it out. A
> content-coding is defined to operate "without loss of information", but
> that
> doesn't necessarily mean byte-for-byte equivalence.
>
> See https://github.com/httpwg/http-extensions/issues/3356
>
>
> ### Section 6, paragraph 12 and paragraph 14
> ```
>      Range: bytes=0-10
> ```
> Since byte ranges are inclusive, this requests 11 bytes...
>
> ```
>      Content-Range: bytes 0-9/44
> ```
> ...but this only returns 10. Sending less than requested is
> [technically valid](
> https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.7-2),
> but probably not what you intended to illustrate here.
>
> See https://github.com/httpwg/http-extensions/issues/3357
>
>
> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> ### Typos
>
> #### Section 5, paragraph 2
> ```
> -    when selecting content coding for use with Unencoded-Digest.
> +    when selecting content codings for use with Unencoded-Digest.
> +                                 +
> ```
>
> #### Section 7, paragraph 2
> ```
> -    substitute various parts of an HTTP message presents several risks,
> -                                                                      ^
> +    substitute various parts of an HTTP message presents several risks;
> +                                                                      ^
> ```
>
> #### Section 8, paragraph 1
> ```
> -    Should this document be adopted and achieve working group consensus,
> ```
> I think we might have gotten there.
>
> These three are collected in
> https://github.com/httpwg/http-extensions/issues/3358
>
>
> ### Grammar/style
>
> #### Section 1, paragraph 2
> ```
> cking is possibly an unacceptable trade off. For a variety of reasons,
> decod
>                                   ^^^^^^^^^
> ```
> When "trade-off" is used as a noun or modifier, it needs to be hyphenated.
> [VERB_NOUN_CONFUSION]
>
> See https://github.com/httpwg/http-extensions/issues/3359
>
> Cheers
> Lucas
>
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF]. You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>
>
>