Structured Field Values for HTTP
draft-ietf-httpbis-header-structure-19

[Ballot comment]
Thank you for addressing my discuss (and comment!) points, and explaining
in cases where they were non-issues.

I do wonder whether (In Sections 3.3.1 and 3.3.2) it might be better to say
"might not be preserved" rather than "may not be preserved", though it
hopefully doesn't matter.

[Ballot comment]
Thanks for explaining the parsing algorithms in my earlier DISCUSS points.
====
** Section 4.1. Reading steps 1 – 6 like pseudo-code, if Step 1 is true, output_string will be undefined in Step 6.    There needs to be a step 0 which reads “Let output_string be an empty string” or Step 1 needs to explicitly initialize output_string.

** Section 4.1.8.  Per Step 1, “If input_bytes is not a sequence of bytes, fail serialization”, what input wouldn’t be considered as sequence of bytes?

** Section 4.2.  An algorithmic style nit.  In Section 4.1, the text used an “IF x ELSE IF y ELSE IF z ELSE fail” convention.  Here the text is a series of simple “IF x; IF y; IF z; …” statements.

** Section 4.2.  Editorial.  In step 8, s/Otherwise, return output./Else, return output./

[Ballot comment]
Thanks for this work.

I support Benjamin's DISCUSS point about case sensitivity especially with respect to how a consumed dictionary should be used.  It's fine if you want to say that the rules for key matching are left to the authors of specifications of future structured fields, but if that's the case, please do say so.

Should Section 3.1 be explicit that lists are ordered?  It does say "array" but some definitions I found for that term don't explicitly say anything about order either, just a "collection".

As my colleagues have already done a rather thorough job, all I have left is a few nits:

Nits:

Section 3.1.2:
* "... key-values pairs ..." -- s/values/value/

Section 3.2:
* First paragraph, two instances of "items" should be capitalized.
* "Note that dictionaries ..." -- capitalize "dictionaries"
* "... Inner List of tokens:" -- capitalize "tokens"
* "A Dictionary with a mix of singular and list values ..." -- capitalize "list", and maybe "Item" instead of "singular"?

[Ballot discuss]
(I appreciate that this is pseudo-code which has inherent ambiguity sometimes, so please let me know if I've interpreted it in an unintended way)

** Section 4.2.6.  There appears to be an inconsistency here in my reading of the algorithm given the ABNF in Section 3.3.4

-- Let’s assume of token of input_string =“*foo”

-- Step 1: pass since input_string[0] = “*”

-- Step 2: Set output_string = “”

-- Step 3: pass since input_string[0] = “*”,

-- Step 3.1: input_string[0] is still “*” and not a tchar, “:” or “/” causing a output_string=”” to be returned

This doesn’t seem correct.

** Section 4.2.7.  The parsing guidance doesn’t follow for me given the ABNF in Section 3.3.5.

-- Let’s assume input_string = “:cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:”, the example in Section 3.3.5

-- Step 1: pass since input_string[0] = “:”

-- Step 2: Set input_string = “cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:”

-- Step 3: pass since the last character of input_string is “:”

-- Step 4: Set b64_content = “cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==”

-- Step 5 says “consume the “:” character at the beginning of the input_string, but there is no such character.  It was discarded in Step 2.

[Ballot comment]
** Section 4.1. Reading steps 1 – 6 like pseudo-code, if Step 1 is true, output_string will be undefined in Step 6.    There needs to be a step 0 which reads “Let output_string be an empty string” or Step 1 needs to explicitly initialize output_string.

** Section 4.1.8.  Per Step 1, “If input_bytes is not a sequence of bytes, fail serialization”, what input wouldn’t be considered as sequence of bytes?

** Section 4.2.  An algorithmic style nit.  In Section 4.1, the text used an “IF x ELSE IF y ELSE IF z ELSE fail” convention.  Here the text is a series of simple “IF x; IF y; IF z; …” statements.

** Section 4.2.  Editorial.  In step 8, s/Otherwise, return output./Else, return output./

[Ballot discuss]
A. Section 3.1:

  The ABNF for Lists in HTTP fields is:

  sh-list      = list-member *( *SP "," *SP list-member )
  list-member  = sh-item / inner-list

  Each member is separated by a comma and optional whitespace.

To me there is a clarity issue that could lead to interoperability issues. Namely the difference in the meaning of whitespace between RFC 7230 and this document. Structured headers appear to not allow the HTAB that RFC7230 allows. And that is fine, but I would expect this to be more clearly discussed. If the intention was to allow for HTAB you need to use WSP rather than SP in above rule.

[Ballot comment]
1. Section 2, page 8:
  --8<--
    42. Foo-Example Header

  The Foo-Example HTTP header field conveys information about how
  much Foo the message has.

  Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
  an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

    Foo-Example = sh-integer

  Its value indicates the amount of Foo in the message, and MUST
  be between 0 and 10, inclusive; other values MUST cause
  the entire header field to be ignored.

  The following parameters are defined:
  * A Parameter whose name is "foourl", and whose value is a String
    (Section Y.Y of [RFCxxxx]), conveying the Foo URL
    for the message. See below for processing requirements.

  "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
  its value is not a valid URI-reference, the entire header field
  MUST be ignored. If its value is a relative reference (Section 4.2
  of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
  being used.

  For example:

    Foo-Example: 2; foourl="https://foo.example.com/"
  --8<--

To me this example indicates several unclarities in this specification.

First there is a lack of discussion of the definition of the field-name and clearly identify it. In the above example it is only implicit identified. I would propose that this example has an additional paragraph that explicitly defined the Structure header name as discussed in the paragraph above this example.

Per RFC 7230 Section 3.2 a header field is the complete structure of field-name ":" OWS field-value OWS. However looking at this example it appears that structured header field only define the field-value. Wouldn't it be better to be explicit about these two components although I understand that field-name is a constant. This is also evident in what appears to be a grammatical error in the above paragraph:

  Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
  an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

The second "Its" would to me indicate Foo-Example a Item Structured Header, not the header value (field-value in ABNF) which is defined. I would suggest changing the second Its to "The Structured header value ABNF is:"

[Ballot comment]
== Discuss resolved, as have these nits below.

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

[Ballot comment]
Hi,

Thank you for writing this document.  As per the other comments, more effort to have a tighter specification of HTTP header fields is likely to be beneficial, particularly if there are readily usable open source libraries that implement these.

However, my main comment (which possibly could have been a discuss) questions how this is specified.  In my experience other specifications of encodings define exactly what the format the encoding must take, but leave it up to implementation to decide how to perform that encoding.  Whereas this document specifies the format in 3 ways: (i) as a prose description of the format, (ii) as an ABNF description of the format, (iii) as a pair of algorithms that construct or parse the format.  I would prefer for the ANBF to be definitive along with prose to describe/refine the ANBF as required.  For the algorithms, I would have preferred that they are held in the appendix as non-normative text that provides a description of one possible method of writing the serialization or parsing code.  The corner cases that the algorithm cover could be in the normative prose/ABNF description.  I appreciate that this would be a significant change to the document and hence will leave it to authors/responsible AD to decide whether to process or ignore this comment.

A few other comments on particular sections that I noted:

1.2.  Notational Conventions

  When parsing from HTTP fields, implementations MUST follow the
  algorithms, but MAY vary in implementation so as the behaviors are
  indistinguishable from specified behavior.
 
I find that sentence slightly strange in that the first part of the sentence states that your MUST follow the algorithm, and the second part states that you don't have to follow the algorithm.  It might be more clear if this was worded differently.  E.g. MUST have behavior that is indistinguishable from that produced by the algorithm.

3.1  Lists:

  An empty List is denoted by not serializing the field at all.
 
This was slightly unclear to me.  Does this mean that it isn't possible to distinguish between not providing the header and providing an empty list?  Possibly it might be worth clarifying this here, although I note that it does become clear what the expected behavior is later in the document.

3.2.  Dictionaries

  Dictionaries are ordered maps of name-value pairs, where the names
  are short, textual strings
 
"short, textual" => short textual"
 
It might also be helpful to explicitly state what the ordering is (i.e. I presume that it is the order that they are listed in the request)

3.3.1 Integers
Are "00" "01" "-0", "-01" all allowed?

3.3.6.  Booleans
Should this cover the fact that if the boolean value is not present it is interpreted as true in a parameter or dictionary?  E.g. as per the description in the parameter and dictionaries sections?

Regards,
Rob

[Ballot comment]
The document starts with "Specifying the syntax of new HTTP header (and trailer) fields is an onerous task; even with the guidance in Section 8.3.1 of [RFC7231], there are many decisions - and pitfalls - for a prospective HTTP field author." -- having never done this, I'll just have to take the authors' word on this. I'm balloting NoObj in the "This is outside my area of expertise, but it is interesting" sense :-)

[Ballot comment]
Thank you for the work put into this document. The document is easy to read. And I loved the good old ASCII scissors "--8<--"

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
In the sentence "the mechanisms described herein are only intended to be used with those that explicitly opt into them.", does "those" mean "existing HTTP header" or "header", this little ambiguity should be lifted.
 
-- Section 4.1.2 --
Wow, I am impressed that nowadays, even a dictionary is sent as an HTTP header. (just a plain comment of mine even if an example would be useful for me).

[Ballot discuss]
Thanks for this document; it will be very nice to have this
more-structured mechanism available for future HTTP header (and trailer)
fields.

(0) There seem to still be a few lingering internal inconsistencies that
merit further discussion.

Most notably, there is the inherent risk of skew when both prose
algorithms and ABNF constructions are provided for the same structures.
While Section 1.2 is careful to disclaim that the prose algorithm takes
precedence over the ABNF for parsing, to my reading the coverage in the
following paragraph of serialization procedures imply that it is the
ABNF that is authoritative.  In particular, "[i]mplementations MAY vary
from the specified behavior so long as the output still matches the
ABNF" seems to admit deviations from the prose algorithms but require
compliance with the ABNF, in effect making the ABNF take precedence over
the prose algorithm.  Having a different description of the procedure
normative for generation vs. consumption invites
interoperability-affecting feature skew, such as the handling of empty
lists as Julian noted on the list.

Similarly, Section 3.1.1's prose says that inner lists are delimited "by
a single space", but the ABNF uses (1*SP), allowing for more than
one space.

Additionally, when Section 4.2.3.2 discusses parsing parameter map keys,
the handling for duplicate map key names is specified as overwriting the
previous value, in contrast to the prose description (Section 3.1.2)
that describes these keys as "unique within the scope [of] the
Parameters they occur within".  (While dictionary key names might be
expected to have a similar behavior, I did not find conflicting text for
that behavior.)

Finally, at a prose level we employ needlessly different descriptions in
several places for what is effectively the same procedure; while I do
not think any of these affect interoperability (and thus the full
details are in the COMMENT section), it does seem to be continuing the
theme.  (These are things like how we describe the algorithm to skip
implicit-true for booleans, whether we initialize the output string to
the empty string only to immediately add a constant literal character to
it vs. initializing the output string to that literal character, etc.)

A couple other points that may need further discussion:

(1) What aspect(s) of structured field processing are case (in)sensitive?
The only mentions I see of case sensitivity are in Section 4.2 discussing
header field names and (implicitly) Section 4.2.2 discussing a
"character-for-character" comparison of dictionary key names, but of
course we cite RFC 5234 for ABNF, which uses case-insensitive matching.
On the other hand, base64 encoding requires case sensitivity for
successful round-tripping of arbitrary binary data.

(2) One of the stated goals of this document is to define intentionally
strict processing rules, but there are several places where we could
have removed additional optionality but elected to not do so.  What is
the criterion for "too far" towards strictness?  For example, Section
4.2.7 gives optionality with respect to base64 padding (see COMMENT).

[Ballot comment]
Is the document toolchain used for this document responsible for the
rendering of em dashes as a single hyphen, as opposed to normal RFC
style which uses two hyphens for an em dash?

What's the motivation for "MUST omit values of boolean true" (in
parameters and dictionaries)?  It seems to make the output rules more
complicated without a significant gain in encoding size.

Section 1.2

  When parsing from HTTP fields, implementations MUST follow the
  algorithms, but MAY vary in implementation so as the behaviors are
  indistinguishable from specified behavior.  If there is disagreement

nit: was this intended to be "so long as"?

Section 2

  o  Define the semantics of those structures.

nit: it's not clear to me what the referent for "those" is intended to
be (as while the previous bullet point does give a list of types of
structures, it seems to be saying that any given field has to pick
exactly one, which is inconsistent with the plural "those").

  o  Specify any additional constraints upon the structures used, as
      well as the consequences when those constraints are violated.

nit: similarly, the plural "structures" may not be needed here.

  Typically, this means that a field definition will specify the top-
  level type - List, Dictionary or Item - and then define its allowable
  types, and constraints upon them.  For example, a header defined as a

It's a little unfortunate that we task the word "type" with two
different meanings (the top-level List/Dictionary/Item and also the more
fine-grained Integer/String/etc.).  We also haven't mentioned the latter
type of "type" yet, though perhaps that's not an issue.

  List might have all Integer members, or a mix of types; a header
  defined as an Item might allow only Strings, and additionally only
  strings beginning with the letter "Q".  Likewise, Inner Lists are
  only valid when a field definition explicitly allows them.

(We haven't mentioned Inner Lists yet, so the reader might not know what
to expect from them.)

  When parsing fails, the entire field is ignored (see Section 4.2); in
  most situations, violating field-specific constraints should have the
  same effect.  Thus, if a header is defined as an Item and required to
  be an Integer, but a String is received, the field will by default be
  ignored.  If the field requires different error handling, this should
  be explicitly specified.

Explicitly specified in the specification that defines the structured
field, I trust?

Also, I worry that just leaving this as "in most cases" is a bit
antithetical to the goals of structured headers -- don't we want to nail
things down as tightly as we can?  If someone wants an exception, they
don't have to use structured headers...

  To further assure that this extensibility is available in the future,
  and to encourage consumers to use a complete parser implementation, a
  field definition can specify that "grease" Parameters be added by

Do you want to reference RFC 8701 here?

  An extension to a structured field can then require that an entire
  field value be ignored by a recipient that understands the extension
  if constraints on the value it defines are not met.

This seems to set us up for a situation in which an implementation that
does not understand the extension will happily process the header field
and ignore the extension, but implementations that do understand the
extension will ignore the header field entirely.  Is that really what's
intended?  (When might this be desirable?)

Section 3

  This section defines the abstract value types that can be composed
  into Structured Fields.  The ABNF provided represents the on-wire

nit: I don't understand the sense in which "composed into" is used --
don't individual Structured Fields need to be exactly one of these three
types, irregardless of whether there is additional substructure?

Section 3.1

  An empty List is denoted by not serializing the field at all.

So any structured field definition that allows for an empty list has to
define its semantics to be equivalent to the semantics used for when the
peer does not support that structured field at all?

Section 3.1.1

  Inner Lists are denoted by surrounding parenthesis, and have their
  values delimited by a single space.  A field whose value is defined

The ABNF does not seem to support the "single" in "single space".

  A header field whose value is defined as a List of Inner Lists with
  Parameters at both levels could look like:

Is this also an inner list of strings?

Section 3.1.2

  Parameters are an ordered map of key-values pairs that are associated

nit: is the plural "values" intentional?

  parameters    = *( ";" *SP parameter )
  parameter    = param-name [ "=" param-value ]
  param-name    = key
  key          = ( lcalpha / "*" )
                  *( lcalpha / DIGIT / "_" / "-" / "." / "*" )

Huh, so I could have a key that was "*" or "*****"?  (I assume that no
special "wildcard" semantics are afforded to the asterisk in either
usage...)

  Example-ParamListHeader: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w

Is it worth writing out which item/list each parameter applies to?

  Parsers MUST support at least 256 parameters on an Item or Inner
  List, and support parameter keys with at least 64 characters.  Field
  specifications can constrain the types and cardinality of individual
  parameter names and values as they require.

In what way might I further constrain the *type* of a parameter *name*?

Section 3.2

  Implementations MUST provide access to Dictionaries both by index and
  by name.  Specifications MAY use either means of accessing the
  members.

  Example-DictHeader: en="Applepie", da=:w4ZibGV0w6ZydGU=:

I, for one, would appreciate a bit of commentary on the interpretation
of the final '=', even if just a forward reference to §3.3.5.

  Typically, a field specification will define the semantics of
  Dictionaries by specifying the allowed type(s) for individual member
  names, as well as whether their presence is required or optional.

Similarly to my previous comment, I'm not sure I understand what is
meant by the "type" of a member name.

Section 3.3.3

Are the parentheses around "chr" in the sh-string construction doing
anything?

Section 3.3.5

  A Byte Sequence is delimited with colons and encoded using base64
  ([RFC4648], Section 4).  For example:

Thank you for the section reference to disambiguate base64 and
base64url!

Section 4

  This section defines how to serialize and parse Structured Fields in
  field values, and protocols compatible with them (e.g., in HTTP/2
  [RFC7540] before HPACK [RFC7541] is applied).

nit: I'm not sure I'm parsing this sentence correctly: what does
"protocols compatible with them" bind to -- is it part of what "this
section defines"?
(I don't actually see any text anywhere in this document that I would
consider to be described by "protocols compatible with them".)

Section 4.1

It's interesting to note that some of the subsections treat "input item
of wrong type" as an explicit failure case (e.g., 4.1.3.1) whereas
others implicitly assume that the input is one of the appropriate types
(e.g., 4.1.1).

  Given a structure defined in this specification, return an ASCII
  string suitable for use in a HTTP field value.

nit: I would have expected wording like "the following procedure
returns" or "return [...] value as follows" or similar; the current
sentence is an imperative that does not indicate how to fulfil it.
(The same comment applies to basically all of the subsections, and a
similar one to § 4.2 and its subsections.)

  6.  Return output_string converted into an array of bytes, using
      ASCII encoding [RFC0020].

This implicitly assumes that output_string contains only characters
representable in ASCII.  I believe this is currently true based on the
relevant ABNF constructions and serialization procedures, but it still
feels like a needless dangling edge case.

Section 4.1.2

Is the nesting level correct for these (sub)procedures?  It seems like
top-level steps 3, 4, and 5 are logically children of step 2.

Section 4.1.6

  3.  Let output be an empty string.

  4.  Append DQUOTE to output.

Can't we consolidate steps 3 and 4 (as is done in § 4.1.1.1 where output
is initialized to "("?

Section 4.1.8

  1.  If input_bytes is not a sequence of bytes, fail serialization.

side note: perhaps this is just my roots as a C programmer showing
through, but how could you end up with something that's not a sequence
of bytes? :)

Section 4.2

  Strings split across multiple field lines will have unpredictable
  results, because comma(s) and whitespace inserted upon combination
  will become part of the string output by the parser.  Since
  concatenation might be done by an upstream intermediary, the results
  are not under the control of the serializer or the parser.

This seems to have the implication that the results are unpredictable
even if a serializer and parser collaborate to use a procedure that, in
disregard of this specification, splits individual list and/or
dictionary entries across multiple field lines, due to the potential for
an intermediary that is not complicit in the deviation from the spec.
In some sense, that might be the key implication of this statement, in
which case it's surprising to not see it spelled out more clearly.

Section 4.2.1.2

  3.  While input_string is not empty:

      1.  Discard any leading SP characters from input_string.

      2.  If the first character of input_string is ")":

Don't we need to check if the input_string is empty again after
consuming leading SP but before attempting to consume anything else?

Section 4.2.2

  Given an ASCII string as input_string, return an ordered map whose
  values are (item_or_inner_list, parameters) tuples. input_string is

Should we say anything about the map keys?

Section 4.2.3.2

Why do we use a different procedure to implement the "implicit true"
property of booleans than we did in Section 4.2.2?

Section 4.2.4

        4.  Otherwise, prepend char to input_string, and exit the loop.

This is the only place in the document where we use "prepend" in an
algorithm.  That might make it surprising to the reader; is it easy to
reformulate this without greedily consuming input that does not match?

        2.  If output_number is outside the range -999,999,999,999,999
            to 999,999,999,999,999 inclusive, fail parsing.

[I'm not sure how this check could trigger given the length check in 7.5]

Section 4.2.7

  Because some implementations of base64 do not allow reject of encoded
  data that is not properly "=" padded (see [RFC4648], Section 3.2),
  parsers SHOULD NOT fail when it is not present, unless they cannot be
  configured to do so.

This is a new protocol mechanism; why do we need to be so accommodating
to inflexible implementations?
(Also, nit: "rejection")

  Because some implementations of base64 do not allow rejection of
  encoded data that has non-zero pad bits (see [RFC4648], Section 3.5),
  parsers SHOULD NOT fail when it is present, unless they cannot be
  configured to do so.

(ibid)
Also, nit: singular/plural mismatch "bits"/"it is"

Section 6

It seems worth mentioning the handling for duplicated key names (e.g.,
in parameters and dictionaries) w.r.t. overwrite or must-be-unique, and
how there have been previous vulnerabilities relating to different
implementations choosing "first one wins" vs. "last one wins".

Appendix B

  Implementers should note that Dictionaries and Parameters are order-
  preserving maps.  Some fields may not convey meaning in the ordering
  of these data types, but it should still be exposed so that
  applications which need to use it will have it available.

This far through the document I still have no idea when the order might
actually be useful; even this text is only noting that (at least
sometimes) the order does not convey meaning.

[Ballot comment]
Per the Gen-ART review, it seems like at a minimum the options available for integers larger than 10^15 should be noted somewhere so that readers are alert to it, even if no particular option is recommended.

[Ballot comment]
Overall, several questions I had while reading the first time were answered,
either directly or implicitly, by text that followed.

[[ questions ]]

* It's documented as possible for field definitions to place constraints on
  cardinality; what about constraints on order as well in certain situations?

  This came to mind again when I got to section 3.2 and read that index-based
  access was required for dictionaries.  Is it possible for a field definition
  to place requirements on the order of things in a dictionary?

  The phrase "ordered " appears repeatedly, and Appendix B has important
  notes about order-preserving structures.  Did I perhaps miss some text early
  on about this, or should/could this be highlighted in non-appendix text?

* [ section 4.1.2 ]
  Should items 3, 3.1, .. 5.2 be indented and renumbered under 2 after 2.1?

* [ section 4.1.8 ]
  Just to confirm: does serializing an empty byte sequence result in ::?
  (assuming a context where the entire structured field would not otherwise
  have been left unserialized)

  My reading of 4.2.7 is that :: would parse correctly as a 0-length byte
  sequence.

[[ random ]]
* The named ABNF productions are all sh-*, which I assume is for "structured
  header".  I assume it's too late at this point, but sf-* for "structured
  field" seemed like a logical choice to me.  Not the least bit important,
  though!

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

[Ballot 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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-httpbis-header-structure-18, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-04):

From: The IESG
To: IETF-Announce
CC: ietf-http-wg@w3.org, httpbis-chairs@ietf.org, barryleiba@gmail.com, tpauly@apple.com, draft-ietf-httpbis-header-structure@ietf.org, Tommy Pauly
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Structured Field Values for HTTP) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'Structured Field Values for HTTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a set of data types and associated algorithms
  that are intended to make it easier and safer to define and handle
  HTTP header and trailer fields, known as "Structured Fields",
  "Structured Headers", or "Structured Trailers".  It is intended for
  use by specifications of new HTTP fields that wish to use a common
  syntax that is more restrictive than traditional HTTP field values.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/ballot/


No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for draft-ietf-httpbis-header-structure

## 1. Summary

Tommy Pauly is the document shepherd. Barry Leiba is the responsible Area Director.

This document defines a standard set of data types for HTTP headers and trailers, with detailed algorithms for how to serialize and parse these fields. This set of strictly-typed fields is referred to as "Structured Fields". These definitions do not apply retroactively to any existing header fields, but allow future headers to improve interoperability and consistency. Several in-progress documents rely on the format defined in Structured Fields.

## 2. Review and Consensus

This document has been an active area of discussion in the working group for over three years during its development. Many members of the working group have engaged in reviews and discussions on the mailing list, particularly due to the wide applicability of the structured field definitions that the document establishes. Several details required taking consensus calls in the past year (such as the handling of empty lists and URLs). These generated lively discussion, which did converge and reach consensus.

The working group last call was a relatively long call, about one month, during which time many detailed reviews were provided. All review comments have been incorporated.

## 3. Intellectual Property

The authors have confirmed that to their direct, personal knowledge, all IPR related to this document has already been disclosed. There are no IPR disclosures on the document.

## 4. Other

This document has no downrefs or IANA considerations.

# Shepherd Writeup for draft-ietf-httpbis-header-structure

## 1. Summary

Tommy Pauly is the document shepherd. Barry Leiba is the responsible Area Director.

This document defines a standard set of data types for HTTP headers and trailers, with detailed algorithms for how to serialize and parse these fields. This set of strictly-typed fields is referred to as "Structured Fields". These definitions do not apply retroactively to any existing header fields, but allow future headers to improve interoperability and consistency. Several in-progress documents rely on the format defined in Structured Fields.

## 2. Review and Consensus

This document has been an active area of discussion in the working group for over three years during its development. Many members of the working group have engaged in reviews and discussions on the mailing list, particularly due to the wide applicability of the structured field definitions that the document establishes. Several details required taking consensus calls in the past year (such as the handling of empty lists and URLs). These generated lively discussion, which did converge and reach consensus.

The working group last call was a relatively long call, about one month, during which time many detailed reviews were provided. All review comments have been incorporated.

## 3. Intellectual Property

The authors have confirmed that to their direct, personal knowledge, all IPR related to this document has already been disclosed. There are no IPR disclosures on the document.

## 4. Other

This document has no downrefs or IANA considerations.