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

Due to the number of minor edits that made several things better, we've just published a 03. We're ready for Last Call now.

Cheers
Lucas



On Thu, Dec 11, 2025, at 14:56, Mike Bishop wrote:
> Thanks, these all look good. Since none of this was particularly large, your discretion whether you'd like to cut a new version before I start Last Call or just have these changes staged for the next time around.
> 
> 
> *From:* Mike West <mkwst@google.com>
> *Sent:* Thursday, December 11, 2025 3:42 AM
> *To:* Lucas Pardue <lucas@lucaspardue.com>
> *Cc:* Mike Bishop <mbishop@evequefou.be>; draft-ietf-httpbis-unencoded-digest@ietf.org <draft-ietf-httpbis-unencoded-digest@ietf.org>; HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* 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
>>