Erik Kline's No Objection on draft-ietf-httpbis-header-structure-18: (with COMMENT)

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-httpbis-header-structure-18: No Objection

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/



----------------------------------------------------------------------
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 <thing>" 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!