Draft: draft-ietf-quic-http

Commentary: does this address your concerns ? 
 Section 7.2.8 : These frames have no semantics , and can be sent on any open stream when application - layer padding is desired . So I am uncertain if it is acceptable to shoehorn in a reserved frame after a frame that is supposed to be the last and then result in a close of the frame ? Based on what is written I would lean to the interpretation that it is allowed , as the frame sender has decided to not close the stream yet , and thus it is open . If this is correct interpretation than it is up to the editor if they like to clarify more . Else something needs to be done . 
 The best example here is sending a reserved frame after a Request stream is opened by the client . Perhaps it is useful to call that out in section 4.1 . is a bit loose . You ca n't send frames on qpack streams for instance , or as the first bytes on a push stream . Maybe we can rephrase it as , " Can be sent on any stream where frames are permitted to be sent " 
 There are no frames that close the stream , because stream closure is handled by the transport . SETTINGS is special in that it is required to be first , and is covered by : It would hypothetically apply to a future frame type which is required to come at the end of the stream as well , but we have no such frames at this time . ( does impose specific ordering on DATA and HEADERS frames relative to each other , but says nothing about other frame types . ) point is well - taken , and I 'll take that text . 
 does the PR address your issue ? 
 Yes , I think this PR clarifies things a bit and are sufficient to resolve my issue . 
 Labeling this as " editorial " based on
Paragraph (version A):
Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED (errors).  In
particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame is considered invalid.
Paragraph (version B):
Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED (errors).  In
particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame is considered invalid.
Other frame types, especially unknown frame types, might be permitted
subject to their own rules; see extensions.
Paragraph (version A):
Frame types of the format "0x1f * N + 0x21" for non-negative integer
values of N are reserved to exercise the requirement that unknown
types be ignored (extensions).  These frames have no semantics, and
can be sent on any open stream when application-layer padding is
desired.  They MAY also be sent on open streams in connections where
no data is currently being transferred.  Endpoints MUST NOT consider
these frames to have any meaning upon receipt.
Paragraph (version B):
Frame types of the format "0x1f * N + 0x21" for non-negative integer
values of N are reserved to exercise the requirement that unknown
types be ignored (extensions).  These frames have no semantics, and
MAY be sent on any stream where frames are allowed to be sent.  This
enables their use for application-layer padding.  Endpoints MUST NOT
consider these frames to have any meaning upon receipt.