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

--------
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