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

Re: p6: maximum delta-seconds of 2147483648

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 15 Nov 2013 13:49:39 +0100
Message-ID: <52861863.5020303@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>
CC: Willy Tarreau <w@1wt.eu>, Eliot Lear <lear@cisco.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2013-11-15 09:41, Roy T. Fielding wrote:
> This is what I am about to commit (and am happy to let Julian make any
> tweaks later if more discussion calls for it) ...
>
> 1.2.1.  Delta Seconds
>
>     The delta-seconds rule specifies a non-negative integer, representing
>     time in seconds.
>
>       delta-seconds  = 1*DIGIT
>
>     A recipient parsing a delta-seconds value and converting it to binary
>     form ought to use an arithmetic type of at least 31 bits of non-
>     negative integer range.  If a cache receives a delta-seconds value
>     greater than the greatest integer it can represent, or if any of its
>     subsequent calculations overflows, the cache MUST consider the value
>     to be either 2147483648 (2^31) or the greatest positive integer it can
>     conveniently represent.
>
>        Note: The value 2147483648 is here for historical reasons,
>        effectively represents infinity (over 68 years), and does not need
>        to be stored in binary form; an implementation could produce it as
>        a canned string if any overflow occurs, even if the calculations
>        are performed with an arithmetic type incapable of directly
>        representing that number.  What matters here is that an overflow
>        be detected and not treated as a negative value in later
>        calculations.
>
> Cool?
>
> ....Roy

Yep (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2494>).

I believe we can now proceed to produce a new set of drafts -- I'll take 
care of that over the weekend.

Best regards, Julian
Received on Friday, 15 November 2013 12:50:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC