Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The FINAL Flag #103

Closed
jpinner opened this issue May 28, 2013 · 3 comments
Closed

The FINAL Flag #103

jpinner opened this issue May 28, 2013 · 3 comments

Comments

@jpinner
Copy link

@jpinner jpinner commented May 28, 2013

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?

@martinthomson
Copy link
Collaborator

@martinthomson martinthomson commented May 29, 2013

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).

@mnot
Copy link
Member

@mnot mnot commented Jun 13, 2013

Based upon Martin's slide deck and Jeff's paint, created a new TF for re-organising the draft.

@martinthomson
Copy link
Collaborator

@martinthomson martinthomson commented Jun 25, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants