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

# 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."

### Missing "Updates" explanation

This document updates RFC9530, but does not seem to include explanatory text
about this in the abstract.

## 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).

### 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?

### 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...."

### 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.

### 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.

### 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.

## 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.

### 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]

## 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