Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)

"Poul-Henning Kamp" <> Thu, 17 November 2016 09:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D34301296E8 for <>; Thu, 17 Nov 2016 01:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7IbyIhsaPiuI for <>; Thu, 17 Nov 2016 01:52:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F78B12965A for <>; Thu, 17 Nov 2016 01:52:23 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c7JJN-0000tj-NT for; Thu, 17 Nov 2016 09:48:53 +0000
Resent-Date: Thu, 17 Nov 2016 09:48:53 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c7JJG-0000s7-L6 for; Thu, 17 Nov 2016 09:48:46 +0000
Received: from ([]) by with esmtp (Exim 4.84_2) (envelope-from <>) id 1c7JJA-0000A9-5q for; Thu, 17 Nov 2016 09:48:41 +0000
Received: from (unknown []) by (Postfix) with ESMTP id 74027273C6; Thu, 17 Nov 2016 09:48:17 +0000 (UTC)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id uAH9mGOw083462; Thu, 17 Nov 2016 09:48:16 GMT (envelope-from
To: Willy Tarreau <>
cc: Julian Reschke <>, Kazuho Oku <>, HTTP Working Group <>
In-reply-to: <>
From: "Poul-Henning Kamp" <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Date: Thu, 17 Nov 2016 09:48:16 +0000
Message-ID: <>
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=0.009, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.899, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c7JJA-0000A9-5q fce8fb4e23d67624788b1632a6af183c
Subject: Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)
Archived-At: <>
X-Mailing-List: <> archive/latest/32925
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

In message <>eu>, Willy Tarreau writes:
>On Thu, Nov 17, 2016 at 09:01:35AM +0100, Julian Reschke wrote:

(Sorry for going time-nut on you guys...)

>Sure but that's one example where we know the 53-bit mantissa already fails
>to represent sub-microsecond when the seconds represent the unix time since
>the epoch, so a struct timespec is misrepresented there.

Nobody outside a small group institutions, of which I am the founding
member[1], are able to generate such a timestamp with any level of
credibility as to its truthfullness.

>On the other hand most of the time we don't care about the sub-microsecond

Trust me:  We will never care about *timestamps* with sub-microsecond
resolution in HTTP headers. They barely make sense in the first
place and transmission noise and and delays will totally swamp any
information they might carry.

We might care about time *intervals* with sub-nanosecond resolution,
for instance how long it took to find something in memory.  Eleven
digits behind the decimal point is all you need for that[2] and
they should be stacked on top of a time_t offset of much lower

>Another option could be to state that some numbers can include a fractional
>part and that this part has to be processed separately *if required*. 

We are trying to *communicate* the number.  How people decide to
process the number on their own computer is not for us to decide [3].

>Or maybe Poul-Henning's 15-digit number can solve it as well. But we must not
>use it for any number as it would remove the ability to pass 64-bit integers.

15 digits is enough for a Content-Length of a petabyte, I don't think
anybody, now or in the future, will find that a sensible thing to do.

If you want to move cryptographic bits, there is a dedicated "blob"
datatype for that.



[2] This is phyics:  You have to get a certain number of electrons
    through an electrical circuit before the voltage crosses your
    triggering threshold, and they are swimming in thermal noise.

[3] But the 15 digit limitation is there to make it easier for them.

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.