Re: p6: maximum delta-seconds of 2147483648

On 2013-11-13 19:43, Roy T. Fielding wrote:
> 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

Agreed.

This is the only current issue that holds up draft -25. If no further 
information comes up, I'll apply this change (unless Roy beats me to 
it), and submit -25 over the weekend.

Best regards, Julian

Received on Thursday, 14 November 2013 12:32:27 UTC