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

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<mailto: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