Subject: Martin Duke's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Sun, 17 May 2020 15:21:59 -0700

Martin Duke has entered the following ballot position for
draft-ietf-httpbis-header-structure-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is probably a simple one, and perhaps I'm missing something obvious:

Throughout Section 3, the document specifies minimum data structure sizes (1024
list members, 256 inner list members, 64-character keys, etc.) that the
receiver MUST be able to process. What is the desired behavior if any of these
data structures exceeds what the receiver can process? Must it skip the entire
field, or can it process the first N entries and then ignore the rest? Given
the "Intentionally Strict Processing" principle, it would be good to spell this
out.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this noble attempt to tame the wildness that is the HTTP spec!

Comments:
- While this is by no means a required change to publish this document, I found
the order of Section 3 to be backwards from what would easiest to follow. The
higher-order concepts (e.g. lists) are defined first, and refer to low-level
concepts (like items) that are not defined till the end of the section.

Nits:
- In Sec 3.1.2, it might be useful to explain that in example-IntHeader, a is
TRUE.

- sec 3.2. Can you add some text to make it clear that the value in dictionary
entries is only optional (in brackets) because of Boolean TRUE? This was not
clear to me until I read sec. 4.1.2.

- Sec 4. s/before HPACK is applied/before compression with HPACK
(A receiver "applies" HPACK to decompress, and presumably before doing this
parsing)

- Sec 4.2. s/header value/field value

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 May 2020 15:32:21 +1000

Hi Martin,

Thanks for the review; responses below. I've incorporated your feedback in <https://github.com/httpwg/http-extensions/commit/97445903ddf>.

> On 18 May 2020, at 8:21 am, Martin Duke via Datatracker <[email-masked]> wrote:
> 

Good question; this didn't come up. I suspect that failing (i.e., skipping the field) is in keeping with the rest of the spec, but I agree that it's good to spell it out. See text in the commit; I put it in Implementation Notes.

I'm reluctant to make such a large change to the specification, even if it's largely mechanical at this point; to me, the risk of introducing errors outweighs the minor benefits.

> - In Sec 3.1.2, it might be useful to explain that in example-IntHeader, a is

Text added.

> clear to me until I read sec. 4.1.2.

The document already says this; see para starting "Members whose value is Boolean..."

> (A receiver "applies" HPACK to decompress, and presumably before doing this

Also in.

> - Sec 4.2. s/header value/field value

Fixed.

Cheers,

--
Mark Nottingham   https://www.mnot.net/