- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 13 Aug 2014 10:29:40 -0700
- To: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I think that I got these. On 4 August 2014 12:34, Simpson, Robby (GE Energy Management) <robby.simpson@ge.com> wrote: > Various ASCII art header figures show fields aligned on byte and word > boundaries (e.g., "DATA Frame Payload", "HEADERS Frame Payload", "Setting > Format", "PUSH_PROMISE Payload Format"). The text doesn't mention this at > all. Is byte and word alignment intended? Byte, yes. Word, no. > The plurality of the phrase "header block fragment" is ambiguous to me and > seems to vary in the text. Can a HEADERS, PUSH_PROMISE, or CONTINUATION > frame contain "fragments" or "a fragment"? I went through and corrected one instance. If you can be more specific, then I can too. > In 6.6, "PADDED (0x8): Bit 4 being set indicates that the Pad Length > field is present." This needs to also indicate that "Padding" may also be > present, dependent on the Pad Length. Also "Padding: Padding octets" > needs to state that it is only present if PADDING flag is set and Pad > Length > 0. OK. > GOAWAY frame - does the "Additional Debug Data" count toward flow control? No. > I think not, but I could see this field growing large. I understand we > may not wish to block GOAWAY frames, but there may be a hole here with an > unbounded size. (HEADERS, as a counter-example, at least has a limited > size in SETTINGS). Is it OK just to rely on MAX_FRAME_SIZE? I think so. There is plenty of incentive to keep this small already. Realistically, MSS is likely to be a limiting factor. > 9.2 states "Implementations of HTTP/2 MUST support TLS 1.2 [TLS12] for > HTTP/2 over TLS." then "An implementation of HTTP/2 over TLS MUST use TLS > 1.2 or higher with the restrictions on feature set and cipher suite > described in this section." So which is it? == 1.2 or >= 1.2 It's >= 1.2. Supporting 1.2 is a natural prerequisite of all TLS versions above 1.2. > In 6.5.2, SETTINGS_MAX_FRAME_SIZE initial value is defined "The initial > value is 2^14 (16,384) octets." In 11.3 its 65536. Someone caught that for me already. > In 7, "Error codes share a common code space. Some error codes apply only > to either streams or the entire connection and have no defined semantics > in the other context." I would suggest re-wording as this could be > misread. Taking suggestions.
Received on Wednesday, 13 August 2014 17:30:12 UTC