Re: New Version Notification for draft-nottingham-structured-headers-00.txt

2017-10-30 16:08 GMT+09:00 Poul-Henning Kamp <phk@phk.freebsd.dk>:
> --------
> In message <20171030060251.GB28950@1wt.eu>, Willy Tarreau writes:
>>On Mon, Oct 30, 2017 at 02:38:19PM +0900, Kazuho Oku wrote:
>
>>Instead I think that explaining very common implementation limits to be
>>expected in field (eg: 2^31-1, 2^32-1 and 2^63-1 for integers) would
>>help implementors decide what to support and what not. Ie if it's not
>>harder to support 2^63 than 2^32 for integers, better do it.
>
> ... unless your programming language thinks all numbers are
> floating-point.
>
> The 15 digit limit is to make sure that numbers will not loose
> precision in a floating-point double, while still being sufficiently
> large for any byte-count a HTTP header can expect to ever see.

While I fear I am going deep into a bikeshed, I oppose to the idea of
using IEEE 754 double as the limit for integers (either as a soft
limit or as a hard limit).

15 digits could be enough for counting bytes, but that is not the only
type of number that we want to send using an HTTP header.

Consider JSON.

Some (if not many) people use JSON for sending / receiving 64-bit
numbers. I say this based on the pressure I had against my JSON
decoder (picojson) to support 64bit int (it used to support IEEE754
doubles only).

Some people (e.g Twitter API) use strings to carry 64-bit numbers
because JSON doesn't guarantee interop.

It might be possible to argue that the majority of the use-case of
64-bit numbers (that do not fit into doubles) are IDs, but I still
think that requiring the use of string to carry a number is a pain for
the users. And there could be use-cases other than IDs that require
making calculations using the numbers on the endpoint.

So why not mandate support for 64-bit integers?

Ten years have passed since the discovery of JSON. We have much more
memory. We are building a new standard instead of adopting something
that existed another ten years ago (i.e. JavaScript).

Let's not repeat the failure made by JSON.

> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.



-- 
Kazuho Oku

Received on Tuesday, 31 October 2017 01:24:58 UTC