- From: Martin Thomson <mt@lowentropy.net>
- Date: Sat, 13 Nov 2021 00:58:05 +1100
- To: ietf-http-wg@w3.org
Recall that this is a bis document. We have a narrow scope for changes and so not everything here is new. With that in mind, we should try to fix the issues you have identified. I've opened a few pull requests. I've trimmed your text where I think that it isn't necessary to discuss anything. Most are straightforward, so while this was tedious, it's now done. Thanks for reading through so carefully. On Thu, Nov 11, 2021, at 08:23, Francesca Palombini wrote: > 1. ----- https://github.com/httpwg/http2-spec/pull/977 > 2. ----- https://github.com/httpwg/http2-spec/pull/978 > 3. ----- https://github.com/httpwg/http2-spec/pull/979 > 4. ----- https://github.com/httpwg/http2-spec/pull/980 I chose to cite the section that defines frames rather than the IANA registry as this document only defines a subset of the frames in the registry. > 5. ----- https://github.com/httpwg/http2-spec/pull/981 You are right to point out that our flow control text is a little soft. I've tightened it up a little in this PR. > 6. ----- https://github.com/httpwg/http2-spec/pull/982 As above, I've cited the section, not the registry. > 7. ----- https://github.com/httpwg/http2-spec/pull/983 I've added a reference to the priority deprecation text to the first of these newly deprecated fields. > 8. ----- Cory got this one. > 9. ----- Cory got this one. > 10. ----- no action necessary > A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be > treated as special by endpoints. A zero value does prevent the > > FP: When is it ok that the 0 value is treated as special? A client that receives this from a server - and does not receive another SETTINGS in a reasonable time - cannot make new requests. It might decide that it cannot continue to use the connection in that case. > 11. ----- Cory got this one. Note that ignoring a value (if allowed or required) is applying it. > 12. ----- Cory got this one. > 13. ----- Unless someone else picks this up, I'm going to pass on adding more references to the definition of error codes. > 14. ----- > > set after receiving the HEADERS frame that opens a request or after > receiving a final (non-informational) status code MUST treat the > > FP: Where is a "non-informational status code" defined? This is a term of art in HTTP and necessary knowledge. I don't believe that a citation is necessary. > 15. ----- https://github.com/httpwg/http2-spec/pull/984 Yeah, I think we fix simplify by removing this second, contradictory sentence. Good catch. (Edits made 5 years apart don't always guarantee consistency.) > 16. ----- https://github.com/httpwg/http2-spec/pull/985 > 17. ----- Cory got this one. > 18. ----- https://github.com/httpwg/http2-spec/pull/986 > 19. ----- Cory got this one. > 20. ----- > FP: Can a reference be added to the section where the TCP FIN bit is defined? TCP is really terrible about this. FIN is so fundamental a concept it just ends up spread all over. Anything I might cite is not useful. So not really. > 21. ----- I don't plan to do anything about this. These are pictures, not code. > 22. ----- Cory got this one. > 23. ----- Cory got this one. > 24. ----- https://github.com/httpwg/http2-spec/pull/987 > 25. ---- https://github.com/httpwg/http2-spec/pull/988
Received on Friday, 12 November 2021 13:58:40 UTC