Thanks for going into detail on this Poul-Henning!
In my use-case the numbers are identifiers with some arithmetic properties
(ordering, and whether they're even or odd) so I think they fit into the class D
you described. I think a byte sequence with defined endianness and size
restriction should do the trick. That or just saying "if you reach 10^15 then
just restart your HTTP/3 connection"... I've filed an issue on my own draft to keep
track of this <https://github.com/DavidSchinazi/masque-drafts/issues/26>.
Thanks again,
David
On Tue, May 5, 2020 at 1:29 PM Poul-Henning Kamp <phk@xxxxxxxxxxxxxx> wrote:
--------
In message <CAPDSy+4y9ZZ-f=MyV1b_-t5OygyYgdr3W4V4soiLVGOgzXKdMg@xxxxxxxxxxxxxx>, David Schinazi writes:
>Sounds good. I was mainly curious because I defined a sh-integer in one of
>my drafts for a value that can in theory go up to 2^62-1, and I wonder if
>it's worth the added complexity to support values between 10^15 and 2^62...
Let me chime in here, as the 10^15 thing is largely my "fault".
Without resorting to "there are N kinds of people" jokes, there are
essentially four classes of numbers:
A) Normal numbers.
B) Scaled numbers
C) Identifying numbers
D) Cryptographic numbers
The 10^15 has historically been more than fine for class A, people
generally hate when there are more than 10 digits in a number, this
we know this because AT&T did a LOT of research on this, back when
people did a lot more with numbers by hand than we do today.
In class B people deal with huge numbers by downscaling: Millions,
Trillions, GigaBytes and PetaBytes. Nobody really cares if the
stimulus was 1.000.000.000.000 or 1.000.000.000.010 dollars, so
sawing of the right hand side is a good way to make numbers manageable,
at the cost of suffixing multiplier: $125M
In class C we have numbers which are used to enumerate things,
customer numbers, passport numbers and so on. By their nature these
numbers are not subject to arithmetic, but mainly because of the
punched cards and the numeric keypad, using digits for encoding
them is traditional. I would recommend that these be encoded either
as byte sequences, or if they are important for manual debugging
as strings.
Class D is strictly speaking not only cryptographic numbers, but
again, these are not usually subject of arithmetic, but in difference
from class C they have a fundamental numeric nature, and there
may be some mathematical operators which apply to them, for instance
ordering. For these, I would recommend using fixed size
byte sequences with a defined endianess. But again: If they are
important to human debugging, for instance being able to tell
which is larger/smaller, it may make more sense to put them
in a string with a suitable radix.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@xxxxxxxxxxx | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
