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

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.

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
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

Received on Friday, 2 February 2018 03:39:29 UTC