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

From: Erik Kline via Datatracker <[email-masked]>
Date: Sun, 17 May 2020 17:20:11 -0700

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!

---

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

Hi Erik,

Thanks for the feedback; responses below.

> On 18 May 2020, at 10:20 am, Erik Kline via Datatracker <[email-masked]> wrote:
> 

Yes (although I think this would be somewhat unusual). When I looked at the text to address this, I found that talking about cardinality of dictionary members and parameters didn't make sense, because they're required to be unique. So, see:
  <https://github.com/httpwg/http-extensions/commit/d585c4b4339>

>  on about this, or should/could this be highlighted in non-appendix text?

I'm struggling to find something to say; is "ordered" not clear enough? The text in the appendix was put there to make it more likely to be noticed. If you can suggest fitting text elsewhere, I'd be grateful. 

>  Should items 3, 3.1, .. 5.2 be indented and renumbered under 2 after 2.1?

Already fixed in source; please confirm at <https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#ser-dictionary>.

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

Yes.

>  field" seemed like a logical choice to me.  Not the least bit important,

That's a good point; we forgot to convert these when we moved to more correct terminology. I don't think it's too late; updated in <https://github.com/httpwg/http-extensions/commit/b9ef2abb333>.

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 May 2020 16:13:56 +1000

> On 18 May 2020, at 4:09 pm, Erik Kline <[email-masked]> wrote:
> 
> It was clear. I think it was just a little unexpected for me vis. my
> expectations around "dictionary"; but if I think not of
> std::unordered_map but instead more of std::map then I guess I'm good.
> 
> I guess I'm still wondering what the value of ordering a dictionary
> might be.  But if it helps in some way -- especially to produce a
> constrained spec that helps eliminate differences in externally
> visible behavior -- it works for me.

Personally, I struggle with it a bit too; I'd prefer just a normal map. However, we got pretty strong input that it would address more use cases to order it, and no implementer pushback (ordered maps seem to be pretty common in modern languages).

Cheers,