Subject: Fwd: New Version Notification for draft-ietf-httpbis-header-structure-03.txt

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Feb 2018 10:55:12 +1100

This draft proposes solutions for a number of issues; see the change notes at the end as well as the issues closed to date:
  https://github.com/httpwg/http-extensions/issues?q=is%3Aissue+label%3Aheader-structure+is%3Aclosed <https://github.com/httpwg/http-extensions/issues?q=is:issue+label:header-structure+is:closed>

I'm planning on talking about the open issues in London:
  https://github.com/httpwg/http-extensions/issues?q=is%3Aissue+label%3Aheader-structure+is%3Aopen <https://github.com/httpwg/http-extensions/issues?q=is:issue+label:header-structure+is:open>
... but if you have feedback before that, it'd be great to hear it on the issues or here.

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-httpbis-header-structure-03.txt
> Date: 2 February 2018 at 10:49:51 am AEDT
> To: "Poul-Henning Kamp" <[email-masked]>, "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-httpbis-header-structure-03.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-ietf-httpbis-header-structure
> Revision:	03
> Title:		Structured Headers for HTTP
> Document date:	2018-02-01
> Group:		httpbis
> Pages:		18
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-structure-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-header-structure-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-header-structure-03
> 
> Abstract:
>   This document describes a set of data types and parsing algorithms
>   associated with them that are intended to make it easier and safer to
>   define and handle HTTP header fields.  It is intended for use by new
>   specifications of HTTP header fields as well as revisions of existing
>   header field specifications when doing so does not cause
>   interoperability issues.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 2 Feb 2018 10:25:12 +1000

On 2 February 2018 at 09:55, Mark Nottingham <[email-masked]> wrote:
> This draft proposes solutions for a number of issues; see the change notes
> at the end as well as the issues closed to date:
>
> https://github.com/httpwg/http-extensions/issues?q=is%3Aissue+label%3Aheader-structure+is%3Aclosed
>
> https://github.com/httpwg/http-extensions/issues?q=is%3Aissue+label%3Aheader-structure+is%3Aopen

One question springs to mind: should there be some sort of definition
for algorithmic operations like "remove"?  I can infer that it
captures and returns the relevant substring, as distinct from the
"discard" operation, but I feel like it shouldn't need to be inferred.

Am I being overly pedantic?

Oh, and what's with the underscore in 4.9.1 Parsing Binary Content from Text?

~~~
   3.  Let b64_content be the result of removing content of input_string
       up to but not including the first instance of the character "_".
       If there is not a "_" character before the end of input_string,
       throw an error.
~~~

Should that be an asterisk?

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Feb 2018 11:30:50 +1100

> Am I being overly pedantic?

If it uses different terms for the same operation, that's not great; I've tried to align terminology where I can, so if you see places where there's divergence, please point it out.

If one of the terms/phrases used is ambiguous, likewise; that said, I don't think we should define terms if they're not ambiguous.

> Should that be an asterisk?

Yes, thanks -- markdown. Fixed in source, hopefully.

Cheers,

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 2 Feb 2018 13:39:04 +1000

> If one of the terms/phrases used is ambiguous, likewise; that said, I don't think we should define terms if they're not ambiguous.

Well, in regular English "remove" means "take away/abolish/get rid
of", so "remove from its original position but retain separately for
further processing" is a bit of an ambiguity.  That said, if nobody
else has a problem with it I won't lose much sleep.

Although while I'm being picky, I just got quite confused by the way
numbers have been handled.  Section 4.4.1 Parsing an Item still refers
to "numbers" as a class of value, with a reference to section 4.5.1
"Parsing a Number from Text".  So the document still treats numbers as
a single type, at some level of abstraction.  In turn 4.5.1 says to
either "parse it as a floating point number" or "parse it as an
integer", so we get the reference to the sub-types.  No worries.

However, section 4.6 Floats says that the parsing algorithm for floats
(the one that, presumably, is referred to by the algorithm in 4.5.1)
is given in 4.5.1.  But that's the algorithm for parsing *numbers*,
which tells you to use some other algorithm for parsing floats...
Then I spun in circles for a bit, before I worked out why everything
is laid out the way it is.

I'd suggest rearranging it:

   4.5 Numbers
      <brief mention that there are two number types>
   4.5.1 Integers
      <current text from 4.5>
   4.5.2 Floats
      <current text from 4.6>
   4.5.3 Parsing a Number from Text
      <current text from 4.5.1>

... although I know that messes up the TOC.

Either that, or change the algorithm in 4.4.1 to no longer refer to
"numbers", and split 4.5.1 into "4.5.1 Parsing an Integer from Text"
and "4.6.1 Parsing a Float from Text".  That keeps the structure (and
TOC) cleaner, removes all reference to "numbers", but makes the Item
algorithm a bit of a bugger.  (Although it's already a bit of a
bugger, the way it handles inputs like "-" or "1..2" or "1-2")

Cheers

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Feb 2018 14:42:31 +1100

> On 2 Feb 2018, at 2:39 pm, Matthew Kerwin <[email-masked]> wrote:
> 

OK, let's see what folks think.

> integer", so we get the reference to the sub-types.  No worries.

This is just an incomplete change; I thought I'd caught all instances of 'numbers'. Will take a look.

> ... although I know that messes up the TOC.

It really, really does.

> bugger, the way it handles inputs like "-" or "1..2" or "1-2")

How about just

4.5.1 Parsing Integers and Floats from Text

?

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 2 Feb 2018 14:24:37 +1000

> 4.5.1 Parsing Integers and Floats from Text

Hmm, yeah, I think that might work.  I still have a bit of a hangup on
steps 3 and 4:

~~~
   3.  If input_number contains ".", parse it as a floating point number
       and let output_number be the result.

   4.  Otherwise, parse input_number as an integer and let output_number
       be the result.
~~~

Most of the algorithms are an alternative representation of the ABNF
for that type; however the what-is-currently-called-"number" algorithm
takes any old guff and suddenly leaves you on your own, armed with
nothing but two ABNF recipes and some value limits.  It doesn't even
say "If an error is encountered, throw it" like the other algorithms.
It doesn't feel right.

It could at least say:

~~~
   3. If input_number matches the <float> ABNF rule ...
   4. Otherwise, if input_number matches the <integer> ABNF rule ...
   5. Otherwise, barf.
~~~

Perhaps I'm just suffering from Friday afternoon laziness and would
rather not have to think while typing code.

Cheers

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Feb 2018 17:05:56 +1100

> rather not have to think while typing code.

Yep, I created <https://github.com/httpwg/http-extensions/issues/475> to track this; wanted to make sure the split to integers and floats got traction before I did the work.

Cheers,