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

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