HTTP Datagrams and the Capsule Protocol
draft-ietf-masque-h3-datagram-11

Thank you for the work on this document.

Thanks to Claudio Allocchio for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/AS1MJFEisY2AkSIpisq3KI0B5BI/.

Francesca

Why might an implementer not do what the SHOULDs say in Section 3.2?  I guess I'm wondering why, in a new thing, one would give someone a reason to produce an implementation that is intentionally not forward-compatible.  Otherwise, nice work; I like to complain about SHOULD a lot lately, and this document did an above average job of using it.

I believe Sections 5.1 through 5.3 should refer to these registries as sub-registries of the main "Hypertext Transfer Protocol version 3 (HTTP/3)" registry.

Also, I don't think the MUSTs in Section 5.4 are appropriate when describing IANA actions.  I suggest "will not" instead of "MUST NOT".

Thank you to David Mandelberg for the SECDIR review.

** Section 4.  Consider adding the following clarification:

NEW
HTTP Datagrams and the Capsule Protocol are building blocks for HTTP extensions to define new behaviors or features and do not constitute an independent protocol.  Any extension adopting them will need to perform an appropriate security analysis which considers the impact of these features in the context of a complete protocol.

# Éric Vyncke, INT AD, comments for draft-ietf-masque-h3-datagram-10
CC @evyncke

Thank you for the work put into this document. It is short, easy to read, and will be useful.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Chris Wood for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. 

I hope that this helps to improve the document,

Regards,

-éric

## COMMENTS

### Abstract

s/This document describes HTTP Datagrams/This document specifies HTTP Datagrams and the Capsule Protocol/ ?

### Section 1
For consistency with other reasons, should a reference be added to `unreliable version of the CONNECT method` ?

### Section 2
```
   HTTP extensions can
   override these requirements by defining a negotiation mechanism and
   semantics for HTTP Datagrams.
```
s/can/MAY/ ? (but I am not a native English speaker) I also noticed that 'MAY' is used at the end of section 2.1.

### Section 2.2

I wonder whether this small section is useful. The text should rather go into the intro of section 3.

### Section 3.4

While I am not too familiar with HTTP & QUIC, I wonder when reading `Endpoints indicate that the Capsule Protocol is in use on a data stream by sending a Capsule-Protocol header field with a true value.` Until now, the Capsule Header is not yet defined even less how to send a true value (or did I misread part of the I-D)

### Section 3.5
```
Since QUIC DATAGRAM frames are required to fit within a QUIC packet,
   implementations that reencode DATAGRAM capsules into QUIC DATAGRAM
   frames might be tempted to accumulate the entire capsule before
   reencoding it.  This can cause flow control problems; see
   Section 3.2.
```
The problem is clear, but what is the recommendation for implementers ?

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

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

# GEN AD review of draft-ietf-masque-h3-datagram-10

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/diaocJcywSJa1ENAlJvPf3z2R70).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `natively`; alternatives might be `built-in`, `fundamental`,
   `ingrained`, `intrinsic`, `original`

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

### Grammar/style

#### Section 2.1, paragraph 8
```
eived with a value that is neither 0 or 1, the receiver MUST terminate the c
                                     ^^
```
Use "nor" with neither.

#### Section 3.2, paragraph 16
```
ied to be self-consistent. If the receive side of a stream carrying capsules
                                  ^^^^^^^
```
Did you mean the noun "reception" (= the act of receiving) or "receipt" (=
invoice)? Or use "receive-side"?

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