Change:
These are some minor editorial things that should be considered to be addressed: Section 4.1: "A server MAY send one or more PUSHPROMISE frames (Section 7.2.5) before, after, or interleaved with the frames of a response message. These PUSHPROMISE frames are not part of the response; see Section 4.4 for more details. These frames are not permitted in pushed responses; a pushed response that includes PUSHPROMISE frames MUST be treated as a connection error of type H3FRAMEUNEXPECTED." Especially the third sentence was hard to parse. Took me a while to realize that it tries to express that PUSHPROMISE frames are not allowed in pushed responses. I think it is primarily a language thing. However, isn't this dependent on stream type. So PUSHPROMISE are allowed on the client-initiated bi-directional stream but not on the server-initiated unidirectional stream. Section 4.1.1: "For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at URL" To avoid more confusion like the one I had in IETF last call. Can you add an Editors note (to be removed before RFC publication) that this registry does not yet exist, and is dependent on approval of [SEMANTICS]? Section 7.2.4.1: "SETTINGSMAXFIELDSECTION_SIZE (0x6): The default value is unlimited. See Section 4.1.1 for usage." As the actual discussion of usage of this setting is in Section 4.1.1.3 wouldn't that be better to reference?
I'll take a look at cleaning it up, but I'm hesitant to simply say "can't be used on unidirectional streams" because an extension might create a unidirectional stream that does allow PUSH_PROMISE frames for whatever reason. Maybe specifically stating that they can't be sent on Push Streams would work? Good suggestion. Good suggestion; probably we moved this text to subsections after the reference was written.
My personal view has been that PUSHPROMISE is part of a request message. And so it has to abide by the rules there. Any attempt to change that requires a semantic extension to H3. Which is what URL precisely does in order to allow PUSHPROMISE on a new stream type.

Discussion:
A server MAY send one or more PUSH_PROMISE frames (frame-push- promise) before, after, or interleaved with the frames of a response message.  These PUSH_PROMISE frames are not part of the response; see <del> server-push for more details.  These frames are not permitted in pushed responses; a pushed response that includes PUSH_PROMISE frames </del> <ins> server-push for more details.  PUSH_PROMISE frames are not permitted on push streams; a pushed response that includes PUSH_PROMISE frames </ins> MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. Frames of unknown types (extensions), including reserved frames

"Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <https://www.iana.org/assignments/http-fields/>. <ins> *Note:* This registry will not exist until SEMANTICS is approved. *RFC Editor*, please remove this note prior to publication. </ins> As in previous versions of HTTP, field names are strings containing a subset of ASCII characters that are compared in a case-insensitive fashion.  Properties of HTTP field names and values are discussed in

The following settings are defined in HTTP/3: <del> The default value is unlimited.  See header-formatting for usage. </del> <ins> The default value is unlimited.  See header-size-constraints for usage. </ins> Setting identifiers of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that