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

Willy Tarreau <w@1wt.eu> Thu, 17 November 2016 09:05 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A421294E4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Nov 2016 01:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3po7x55dZPfB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 17 Nov 2016 01:05:27 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2752D129629 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 17 Nov 2016 01:05:27 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c7IZw-0003b4-Rc for ietf-http-wg-dist@listhub.w3.org; Thu, 17 Nov 2016 09:01:56 +0000
Resent-Date: Thu, 17 Nov 2016 09:01:56 +0000
Resent-Message-Id: <E1c7IZw-0003b4-Rc@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <w@1wt.eu>) id 1c7IZr-0003Yn-2K for ietf-http-wg@listhub.w3.org; Thu, 17 Nov 2016 09:01:51 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <w@1wt.eu>) id 1c7IZk-0006cv-Mm for ietf-http-wg@w3.org; Thu, 17 Nov 2016 09:01:45 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id uAH91AJl010028; Thu, 17 Nov 2016 10:01:10 +0100
Date: Thu, 17 Nov 2016 10:01:10 +0100
From: Willy Tarreau <w@1wt.eu>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20161117090110.GA10016@1wt.eu>
References: <78354.1477853918@critter.freebsd.dk> <CANatvzx5RSnnN9ybqh6tRqKV=7NVO+PTpgAuVUU+6JuKGFtczg@mail.gmail.com> <20161117055345.GB9646@1wt.eu> <CANatvzwrPxyRPET5SO6fYGZ_6NnqToU9a630x1gjZXx5uAbeuw@mail.gmail.com> <1775eacb-65e5-7339-0910-c2f1ca1fd457@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1775eacb-65e5-7339-0910-c2f1ca1fd457@gmx.de>
User-Agent: Mutt/1.6.0 (2016-04-01)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.575, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c7IZk-0006cv-Mm 914ea5161f33a5942e76dddcc1adc2e9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)
Archived-At: <http://www.w3.org/mid/20161117090110.GA10016@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32923
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Thu, Nov 17, 2016 at 09:01:35AM +0100, Julian Reschke wrote:
> > For example, if we want to define a quality value like the one found
> > in Accept-Encoding, we should not use three-digit fixed point numbers,
> > but instead use an integral value between 0 to 1000.
> > 
> > That way, we can totally avoid the issues introduced by a dot within a number.
> > ...
> 
> +1 in general, but that approach wouldn't work well in cases where we want
> to allow different levels of precision (such as timestamps that optionally
> would allow fractions of seconds)

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. On the other hand
most of the time we don't care about the sub-microsecond accuracy, it just has
to be known (hence documented) that writing timestamp 1479372852.095647253 to
represent what I'm seeing now may very well end up being read as
1479372852.095648125 for example.

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*. That's
already OK for q= after all, which for many cases doesn't require accurate
processing :
  q=0           => always 0
  q=0.something => always >0 and <1
  q=1           => always 1

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.

Regards,
Willy