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

> On 2 Feb 2018, at 2:39 pm, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> 
> On 2 February 2018 at 10:30, Mark Nottingham <mnot@mnot.net> wrote:
>> On 2 Feb 2018, at 11:25 am, Matthew Kerwin <matthew@kerwin.net.au> wrote:
>>> 
>>> 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?
>> 
>> 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.
>> 
> 
> 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.

OK, let's see what folks think.

> 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

?


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

Received on Friday, 2 February 2018 03:42:59 UTC