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 <p...@phk.freebsd.dk> wrote: > -------- > In message <CAPDSy+4y9ZZ-f= > myv1b_-t5oygyygdr3w4v4soilvgogzxk...@mail.gmail.com>, 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 > p...@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. >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
