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

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:
> 
> ----------------------------------------------------------------------
> 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.

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.


> ----------------------------------------------------------------------
> 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.

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.

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

Text added.

> - 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.

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

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

Also in.

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

Fixed.

Cheers,

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