Re: Miscellaneous Comments on -14

I think that I got these.

On 4 August 2014 12:34, Simpson, Robby (GE Energy Management)
<> 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.


> GOAWAY frame - does the "Additional Debug Data" count toward flow control?


>  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