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

On 2 February 2018 at 13:42, Mark Nottingham <> wrote:
>> On 2 Feb 2018, at 2:39 pm, Matthew Kerwin <> wrote:
>> 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.
> This is just an incomplete change; I thought I'd caught all instances of 'numbers'. Will take a look.
>> 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.
> It really, really does.
>> 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")
> How about just
> 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.

  Matthew Kerwin

Received on Friday, 2 February 2018 04:25:01 UTC