Re: Genart last call review of draft-ietf-httpbis-header-structure-18

[David Schinazi <[e-mail]>]

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 <[e-mail]> wrote:

> --------
> In message <CAPDSy+4y9ZZ-f=
> [e-mail]>, 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
> [e-mail]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>