Re: p6: maximum delta-seconds of 2147483648

On Nov 13, 2013, at 8:59 AM, Eliot Lear wrote:

> Roy,
> 
> My only issue with your proposed change is that we don't know what we
> don't know.  There are quite a lot of browsers in phones of all sorts
> and maybe other things that we haven't really tested.  It's a bit of a
> gamble to remove the MUST NOT, and I wonder if there really is any
> reason to do so.  Can we simply declare 68 years to be BIGNUM for
> purposes of caching?
> 
> Eliot

That's a good concern, but what does a requirement on senders do
for them?  The recipient parser is going to have to expect numbers
larger than 2^31, because they can't trust senders regardless, and
the remaining requirement (to treat overflow as either 2147483648
or INT_MAX) is intended to allow any device to handle this situation
properly.  That is, unlike the existing text, which requires overflow
be handled as 2147483648 even if the device is limited to 2^31-1.

BTW, the reason for 2^31 seems to be because the value is unsigned.
The concern was for overflow after arithmetic operations on Age, so
maybe I should point that out in the spec.

Yes, it is fair to say that 68 years is far beyond the realm for
delta-seconds, since it is relative to the time of receipt.
I don't think there is any confusion about 68 years being too long
for caching (most limit to one year or 10 years, regardless).

I am concerned that we have a MUST NOT in the spec that most people
simply ignore.  Some of these implementations probably assumed
that a time_t is always 32 bits, back in 1995-97; I haven't
found a sender of delta-seconds that checks for >= 2147483648.

....Roy

Received on Wednesday, 13 November 2013 18:43:52 UTC