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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 20 May 2020 07:16:05 -0700

Robert Wilton 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:
----------------------------------------------------------------------

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 May 2020 12:34:26 +1000

Hi Rob,

Thanks for the feedback. The commit mentioned below is <https://github.com/httpwg/http-extensions/commit/5eb50dafa>.

> On 21 May 2020, at 12:16 am, Robert Wilton via Datatracker <[email-masked]> wrote:
> 

There's a fair bit of history here. HTTP headers have typically been defined using ABNF as you suggest. That has led to a number of interoperability (and often security) problems, because the vast majority people don't write ABNF-based parsers or serialisers; they manually interpret the ABNF, prose and examples and write a bespoke parser and serialiser. These issues are exacerbated by the relatively diffuse pool of new field authors (people mint HTTP headers outside the IETF on a regular basis, for a large variety of reasons), and by the even more diffuse pool of people who actually send headers (people writing .htaccess files in Apache, people writing PHP and CGI scripts, people sending a header in XmlHttpRequest or Fetch, etc.). 

All of this led us to try a different approach - specifying parsing and serialisation via pseudo-code. This is the way that the WHATWG writes their specifications (including HTML and Fetch), and it's arguably improved interoperability for Web developers -- which is also our audience -- considerably.

The ABNF is included mostly to make folks who are used to thinking of HTTP fields in those terms more comfortable. As we've seen during the IESG evaluation, that's led to some confusion, so the most recent changes have attempted to make the status of the ABNF more clear.

> produced by the algorithm.

Thank you, that's good wording. See the commit.

> become clear what the expected behavior is later in the document.

This has been clarified as a result of other comments.

> presume that it is the order that they are listed in the request)

In the commit.

> Are "00" "01" "-0", "-01" all allowed?

They're all allowed in the serialisation, but aren't necessarily distinct in the data model. Do you (and others) think it's worth mentioning here?

> in the parameter and dictionaries sections?

That's a good clarification; in the commit.

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 May 2020 11:10:45 +1000

> On 21 May 2020, at 8:00 pm, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
>>> 3.3.1 Integers
>> They're all allowed in the serialisation, but aren't necessarily distinct
>> in the data model. Do you (and others) think it's worth mentioning here?
> [RW] 
> 
> I would.  There doesn't seem to be downside to being explicit that they are allowed, even if not recommended.

See:
  https://github.com/httpwg/http-extensions/commit/9e2bb280faa05

Thanks again,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 May 2020 05:11:22 +0200

>    https://github.com/httpwg/http-extensions/commit/9e2bb280faa05

Hm.

I'm a bit confused, as the spec in other cases tries to be as strict as
possible for serialization.

Is there a reason why we don't just disallow leading 0s, or trailing 0s
after the decimal point? In particular in the case of Decimals, some
implementations preserving "precision" and others not doing so could be
problematic.

Best regards, Julian