RE: Minor points in draft 12

> Sorry about taking so long to get around to this.

No prob. We're all busy folks.

> https://github.com/http2/http2-spec/commit/77c47588c3180f24487a623c8e5b4d90853fe420

> 
> On 2 May 2014 23:47, Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com>
> wrote:
> > "Pad High:  Padding size high bits.  This field is only present if the PAD_HIGH flag is set."
> > "Pad Low:  Padding size low bits.  This field is only present if the PAD_LOW flag is set."
> > "E: A single bit flag indicates that the stream dependency is exclusive, see Section 5.3.  This field is optional and is only present if the PRIORITY flag is set."
> > It's a bit ambiguous just from the text if the fields are there but set to al zero or missing completely from the byte stream? If the bytes were missing i would make no sense for a single bit to be so.
> 
> The bytes are omitted entirely.  I'm not sure how to make this any clearer.  If
> you have any suggestions, that would help.

How about, instead of:
"E: A single bit flag indicates that the stream dependency is exclusive, see Section 5.3.  This field is optional and is only present if the PRIORITY flag is set."
Put: 
"E: A single bit flag indicates that the stream dependency is exclusive, see Section 5.3.  This field is optional and is only valid if the PRIORITY flag is set. Otherwise, it must be set to zero" or similar. It's just the idea of a single bit missing from the stream that makes the other text confusing.

(snip a lot of changes that I'm perfectly happy with)

> > "The maximum size of a frame payload varies by frame type."
> > It would be good if these were laid out explicitly at some point, rather than simply implied by reading the protocol docs.
> >It might encourage folks to write better validation code earlier.
> 
> It is.  Each frame type that stipulates a maximum other than the global
> maximum lays it out.

I meant in one place as a table or similar. Currently it's distributed throughout the doc.

(snip more changes)

> > "A receiver MUST treat the receipt of any other type of frame or a frame
> on a different stream as a connection error"
> > Maybe I'm missing something, but why the restriction on a frame on a
> different stream? I don't believe there's anywhere else in the protocol that
> such a restriction is made.
> 
> Yes, CONTINUATION is special and its intentional.

OK. Then I'm definitely missing something. Is there a link that explains the intent?

Received on Tuesday, 20 May 2014 11:27:57 UTC