HTTP-31: Sending Reserved Frames prior to stream close

[gloinul]

Section 7.2.8: https://www.ietf.org/archive/id/draft-ietf-quic-http-31.html#name-reserved-frame-types

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.

[LPardue]

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.

can be sent on any open stream is a bit loose. You can'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"

[MikeBishop]

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 this text:

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. However, where a known frame type is required to be in a specific location, such as the SETTINGS frame as the first frame of the control stream (see Section 6.2.1), an unknown frame type does not satisfy that requirement and SHOULD be treated as an error.

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. (This text does impose specific ordering on DATA and HEADERS frames relative to each other, but says nothing about other frame types.)

@LPardue's point is well-taken, and I'll take that text.

[larseggert]

@gloinul does the PR address your issue?

[gloinul]

Yes, I think this PR clarifies things a bit and are sufficient to resolve my issue.

[larseggert]

Labeling this as "editorial" based on #4235