W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 17 Nov 2016 10:01:10 +0100
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>
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.

Received on Thursday, 17 November 2016 09:01:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 November 2016 09:01:53 UTC