Change:
with the code (0x10D).  The last byte "0xff" is used to indicate any frame type greater than "0xfe". <ins> 9. HTTP/3 permits extension of the protocol.  Within the limitations described in this section, protocol extensions can be used to provide additional services or alter any aspect of the protocol.  Extensions are effective only within the scope of a single HTTP/3 connection. This applies to the protocol elements defined in this document.  This does not affect the existing options for extending HTTP, such as defining new methods, status codes, or header fields. Extensions are permitted to use new frame types (frames), new settings (settings-parameters), new error codes (errors), or new unidirectional stream types (unidirectional-streams).  Registries are established for managing these extension points: frame types (iana- frames), settings (iana-settings), error codes (iana-error-codes), and stream types (iana-stream-types). Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames and unidirectional streams that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. Extensions that could change the semantics of existing protocol components MUST be negotiated before being used.  For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. In this case, it could also be necessary to coordinate when the revised layout comes into effect. This document doesn't mandate a specific method for negotiating the use of an extension but notes that a setting (settings-parameters) could be used for that purpose.  If both peers set a value that indicates willingness to use the extension, then the extension can be used.  If a setting is used for extension negotiation, the default value MUST be defined in such a fashion that the extension is disabled if the setting is omitted. </ins> 10. The security considerations of HTTP/3 should be comparable to those

Discussion:
no text changes outside the Document Organization section.
Wow, this is a fun diff to review :-)
That's why I pointed out that there are no actual text changes. But if it's easier, you could open and in side-by-side browser windows. :-) I'd like to land this fairly quickly; from some experiments, other HTTP PRs merge into this just fine if they come after, but risk being summarily wiped out if merged before it.
It's fine. The stream usage and request "lifecycle" sections are a bit too far apart, but I don't know that I have a suggestion there.
S 3.2.2. This isn't understandable without knowing what push is or what a PUSH promise is. Am I supposed to get that from 7540? In either case, you should clearly state that a push stream can only be used for a single push promise (this is implied by the formatting). Happy to supply a PR if we can agree on what's wanted?
Yes, as currently written, a push stream corresponds 1:1 with a PUSH_PROMISE. Which is consistent again with 7540 (we had a period where it was not).
Well. A push stream corresponds one-to-one with a push ID. You can duplicate promises using the DUPLICATE_PUSH frame. I think this is what was attempted to be described by the term "promised server push" as abstract from the frames that might get sent. If the language needs to improve to make this clearer then lets do it.
Does address this sufficiently, now that the description of push precedes this section? There's already a back-reference at the end of the paragraph if someone needs more details.
Closing; please reopen if you feel that does not sufficiently address this.
It would be a lot easier to read the spec if the lifecycle (which provides an overview of operation implicitly) came before the packet formats. Happy to provide a PR, but no point if the editors don't want it.
Thanks for the suggestion. I can see this either way. The ordering was intended to follow the HTTP/2 pattern of "framing layer, putting HTTP on the framing layer." The QUIC spec's new layout of successive layers of detail (concepts, then specific mechanisms, then wire format) would suggest putting frame specifics last.

PR not necessary -- it's a straightforward change if we decide to reorder this way.
I just suggested this change the other day, because I had the same issue. In particular, talking about the multiple push frames before introducing what push is is very awkward.
I like this new layout.Thanks Mike, this works for me!