W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: Minor points in draft 12

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Tue, 20 May 2014 13:57:45 +0000
To: "Richard Wheeldon (rwheeldo)" <rwheeldo@cisco.com>, Martin Thomson <martin.thomson@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <7d4c90f68a56496387caa83cccb58307@BL2PR03MB132.namprd03.prod.outlook.com>
But Richard, the E field *isn't* zero if PRIORITY isn't set.  It is *absent.*  Not sent.  Go straight to the next field while parsing.

And it's not that a single bit is absent -- there's a thirty-two-bit segment that is present or absent based on the presence of the PRIORITY flag, and that thirty-two-bit segment contains E (1 bit) and Stream Dependency (31 bits).  Rather than introduce a new parceling type, Martin has simply indicated that both these fields are present/absent based on that flag.

-----Original Message-----
From: Richard Wheeldon (rwheeldo) [mailto:rwheeldo@cisco.com] 
Sent: Tuesday, May 20, 2014 4:27 AM
To: Martin Thomson
Cc: HTTP Working Group
Subject: 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/77c47588c3180f24487a623c8e5

> b4d90853fe420
> 
> 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 13:58:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC