- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 31 Oct 2017 08:26:30 +0000
- To: Kazuho Oku <kazuhooku@gmail.com>
- cc: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <CANatvzzOXL6vFjm_4KBxLvwosZ6vJYW_ic34_KCwFXtFXFTLsQ@mail.gmail.com> , Kazuho Oku writes: >So why not mandate support for 64-bit integers? > >[...] > >Let's not repeat the failure made by JSON. If we were designing a general-purpose data-carrier format, I would be 100% with you there, but we are not. The goal here is to design a maximally robust data-carrier format, and that means conservative choices and putting the inconvenience on the end which packages the data. The number format is intended for sending quantities on which arithmetic makes sense, and the point of the restriction is to reserve to the implementor the ability to use the most efficient hardware native data type, without loss of precision. 15 digits is 49¾ bits, and while I'm not prepared to state that "is enough for everybody" I think we can safely say that it covers all uses of arithmetic seen in HTTP until now. If your 64 bit number is an identifier, the only valid operation on it is "check for identity", and taking the detour over a decimal representation is not only uncalled for, but also very inefficient in terms of CPU cycles. The natural and most efficient format for such an identifier would be base64 binary, but if for some reason it has to be decimal, say convenience for human debuggers, one could prefix it with a "i" and send it as a label. -- 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.
Received on Tuesday, 31 October 2017 08:26:56 UTC