Wording exists that says implementations MUST process this flag for all frames whose stream identifier field is not 0x0.
Can we insert wording that states that the flag MUST be left unset (0) when sending frames who stream identifier is 0x0 (for example SETTINGS, GOAWAY, or PING)? Also SETTINGS has text to indicate that the FINAL flag should be ignored -- should this be added to PING and GOAWAY as well?
What about RST_STREAM frames? Should we insert wording that the flag MUST be set?
And finally what about WINDOW_UPDATE?
The text was updated successfully, but these errors were encountered:
Yes, we should say that FINAL MUST NOT be set for frames on stream 0. The special text on SETTINGS can be removed. No point in duplicating this sort of advice.
I don't see a strong reason either way for RST_STREAM. The stream is going to end up terminated either way. Perhaps we can pick one.
I can see how WINDOW_UPDATE (and even PRIORITY) could be a problem. We should discuss that further (I'll raise another issue to track those two, because it's worth making the problem statement really clear).
This should be addressed by the state machine (and accompanying description) along with the changes in #130. Once the layering branch is in, this should be good to close.
Wording exists that says implementations MUST process this flag for all frames whose stream identifier field is not 0x0.
Can we insert wording that states that the flag MUST be left unset (0) when sending frames who stream identifier is 0x0 (for example SETTINGS, GOAWAY, or PING)? Also SETTINGS has text to indicate that the FINAL flag should be ignored -- should this be added to PING and GOAWAY as well?
What about RST_STREAM frames? Should we insert wording that the flag MUST be set?
And finally what about WINDOW_UPDATE?
The text was updated successfully, but these errors were encountered: