Subject: I-D Action: draft-ietf-httpbis-header-structure-15.txt

From: [email-masked]
Date: Tue, 28 Jan 2020 22:45:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the HTTP WG of the IETF.

        Title           : Structured Headers for HTTP
        Authors         : Mark Nottingham
                          Poul-Henning Kamp
	Filename        : draft-ietf-httpbis-header-structure-15.txt
	Pages           : 39
	Date            : 2020-01-28

Abstract:
   This document describes a set of data types and associated algorithms
   that are intended to make it easier and safer to define and handle
   HTTP header fields.  It is intended for use by specifications of new
   HTTP header fields that wish to use a common syntax that is more
   restrictive than traditional HTTP field values.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-15
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-header-structure-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-header-structure-15

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 29 Jan 2020 20:17:41 +0200 (EET)

4.1.5.  Serializing a Decimal
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-15#section-4.1.5

|   Given a decimal_number as input_decimal, return an ASCII string
|   suitable for use in a HTTP header value.
|
|   1.  Let output be an empty string.
|
|   2.  If input_decimal is less than (but not equal to) 0, append "-" to
|       output.
|
|   3.  Append input_decimal's integer component represented in base 10
|       (using only decimal digits) to output; if it is zero, append "0".
|
|   4.  If the number of characters appended in the previous step is
|       greater than 12, fail serialisation.
|
|   5.  Append "." to output.
|
|   6.  If input_decimal's fractional component is zero, append "0" to
|       output.
|
|   7.  Else if input_decimal's fractional component has up to three
|       digits, append them represented in base 10 (using only decimal
|       digits) to output.
|
|   8.  Otherwise, append the first three digits of input_decimal's
|       fractional component (represented in base 10, using only decimal
|       digits) to output, rounding the final digit to the nearest value,
|       or to the even value if it is equidistant.
|
|   9.  Return output.

I'm not sure how this works.

Let's input_decimal  to be 123.9998

After step 3 output is "123"

After step 5 output is "123."

On step 8 the first three digits of input_decimal's fractional component
are "999".

The final digit is "9".  There is no possiblity to round up that digit.

So final output is "123.999".

Is that orrect ? That is effectively truncation.

If 123.9998 is rounded to 3 fractional decimals, value is 124.000,
but that serialization can not produce it.

/ Kari Hurtta

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Jan 2020 19:41:20 +0100

On 29.01.2020 19:17, Kari Hurtta wrote:
> ...

That seems to assume that the integer component always is positive...?

Best regards, Julian

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 29 Jan 2020 21:34:48 +0200 (EET)

2.  Defining New Structured Headers
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-15#section-2

|   The following parameters are defined:
|   * A parameter whose name is "fooUrl", and whose value is a string
|     (Section Y.Y of [RFCxxxx]), conveying the Foo URLs
|     for the message. See below for processing requirements.
|
|   "fooUrl" contains a URI-reference (Section 4.1 of
|   [RFC3986], Section 4.1). If its value is not a valid URI-reference,
|   that URL MUST be ignored. If its value is a relative reference
|   (Section 4.2 of [RFC3986]), it MUST be resolved (Section 5 of
|   [RFC3986]) before being used.
|
|   For example:
|
|     Foo-Example: 2; foourl="https://foo.example.com/"

Example is fixed to use foourl, but text still uses "fooUrl" (uppercase letter).

3.1.2.  Parameters
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-15#section-3.1.2

says that parameter name is lcalpha  -- therefore foourl

| The ABNF for parameters in HTTP headers is:
|
|   parameter     = ";" *SP param-name [ "=" param-value ]
|   param-name    = key
|   key           = lcalpha *( lcalpha / DIGIT / "_" / "-" / "." / "*" )
|   lcalpha       = %x61-7A ; a-z
|   param-value   = bare-item

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2020 09:20:18 +1100

Hi Kari,

Good catch; we recently updated the example to match the ABNF, but missed the prose. 

I wonder, however, if it's better to leave the disparity, to emphasise that keys are lc-only.

Cheers,

> On 30 Jan 2020, at 6:34 am, Kari Hurtta <[email-masked]> wrote:
> 

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2020 09:21:56 +1100

Hi Kari,

Very good catch; I noticed this a while back but forgot to file an issue. Now:
  https://github.com/httpwg/http-extensions/issues/1043

Cheers,

> On 30 Jan 2020, at 5:17 am, Kari Hurtta <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2020 09:22:39 +1100

> On 30 Jan 2020, at 5:41 am, Julian Reschke <[email-masked]> wrote:
> 

How so? Is "using only decimal digits" unclear?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Jan 2020 06:52:11 +0100

> How so? Is "using only decimal digits" unclear?

That part is clear. But what guarantees that the integer component is
positive? That might be easily fixable by saying "the absolute value of...".

Best regards, Julian

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 30 Jan 2020 07:52:29 +0200 (EET)

>   https://github.com/httpwg/http-extensions/issues/1043

| ... still isn't right, as Kari noticed. E.g., a value of 1.9944 won't get rounded to 2.0.

You mean:  E.g., a value of 1.9998  won't get rounded to 2.0.

Algorithm produces  three digits for fractional component.

And 1.994 is correct rounding for 1.9944, I think.

> Cheers,

Another thing what can be issue when rounding is applied.

> > |       greater than 12, fail serialisation.

A decimal_number  number can be  -999 999 999 999.9997 or 999 999 999 999.9997

In step 3 there is  digits 999999999999 so no failure on step 4

> > |       or to the even value if it is equidistant.

First theree digits for fractional component are 999

"Correct" rounding for  -999 999 999 999.9997  is -1 000 000 000 000.0 and
for 999 999 999 999.9997 is 1 000 000 000 000.0, but there are 13 digits 
on integer component.

That is "solved" if 
when decimal_number < -999 999 999 999.999 or
decimal_number > 999 999 999 999.999, fractional component
is truncated to 3 digits and rounding is not tried.

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2020 16:56:06 +1100

> And 1.994 is correct rounding for 1.9944, I think.

Corrected.