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

Poul-Henning Kamp <> Tue, 05 May 2020 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E66603A09F5 for <>; Tue, 5 May 2020 13:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, LOTS_OF_MONEY=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id APh0HxghuMO8 for <>; Tue, 5 May 2020 13:32:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB90D3A09F4 for <>; Tue, 5 May 2020 13:32:29 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jW4CD-00064A-1x for; Tue, 05 May 2020 20:29:41 +0000
Resent-Date: Tue, 05 May 2020 20:29:41 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jW4CB-00063P-Kf for; Tue, 05 May 2020 20:29:39 +0000
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jW4C3-0007XO-Qw for; Tue, 05 May 2020 20:29:34 +0000
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 70B931AF106; Tue, 5 May 2020 20:29:17 +0000 (UTC)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTPS id 045KTGda011204 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 May 2020 20:29:16 GMT (envelope-from
Received: (from phk@localhost) by (8.15.2/8.15.2/Submit) id 045KTDfk011203; Tue, 5 May 2020 20:29:13 GMT (envelope-from phk)
To: David Schinazi <>,,,,,,
cc: gen-art <>,, HTTP Working Group <>,
In-reply-to: <>
From: "Poul-Henning Kamp" <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 05 May 2020 20:29:13 +0000
Message-ID: <>
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jW4C3-0007XO-Qw 59e36f67ab3b3f9b34fa50d223fec202
Subject: Re: Genart last call review of draft-ietf-httpbis-header-structure-18
Archived-At: <>
X-Mailing-List: <> archive/latest/37569
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

In message <>om>, 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 or 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 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.