Re: [Technical Errata Reported] RFC7231 (5448)

On 03/08/18 01:31, RFC Errata System wrote:
> The following errata report has been submitted for RFC7231,
> "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5448
> 
> --------------------------------------
> Type: Technical
> Reported by: Magnar Ovedal Myrtveit
> 
> Section: 7.1.1.1
> 
> Original Text
> -------------
> Recipients of a timestamp value in rfc850-date format, which uses a
> two-digit year, MUST interpret a timestamp that appears to be more
> than 50 years in the future as representing the most recent year in
> the past that had the same last two digits.
> 
> Corrected Text
> --------------
> Recipients of a timestamp value in rfc850-date format, which uses a
> two-digit year, MUST interpret a timestamp that appears to be more
> than 200 years in the future as representing the most recent date in
> the past that also matches the timestamp.
> 
> Notes
> -----
> The combination of day-of-the-week, day-of-the-month, month, and the two last digits of the year repeats every 400 years. For example, "Friday, 01-Jan-00 00:00:00 GMT" (as formatted by rfc850) happens in the years ...1300, 1700, 2100, 2500, 2900...
> 
> With the original text, "Friday, 01-Jan-00 00:00:00 GMT" is interpreted as year 2000, since year 2100 is more than 50 years in the future, and year 2000 is the most recent year in the past with the same last two digits as 2100. However, if it really was year 2000, it should have said "Saturday, 01-Jan-00 00:00:00 GMT". So it would make more sense to interpret it as either year 1700 or year 2100. The corrected text interprets it as year 2100.
> 
> "Monday, 01-Jan-00 00:00:00 GMT" happens in years ...1100, 1500, 1900, 2300, 2700..., and is interpreted as year 1900, since 2300 is more than 200 years in the future.
> 

Three counter points:

1) this is guidance for values in HTTP messages on todays Internet. As
such this text only applies to gateways relaying messages from long ago
obsolete software.


2) modern HTTP agents already have to handle messages on the order of
hundreds of thousand per second. Having to account for this type of
resolution at those speeds and traffic pressures is a significant
additional overhead even if it only comes along on rare messages.
 Whereas adding +/-50 to the year can be done extremely fast with zero
permanent memory overhead for a periodic calendar calculation or lookup.


3) this assumes that the Wkday is both present and accurate. RFC 850
agents are encouraged (even required) to adjust timezones to match their
local with no guidance on the other fields being kept in sync. This can
have profound impact on whether the weekday can be trusted at all.


So I am for keeping it as-is, even if technically a greater resolution
can be achieved.

AYJ

Received on Thursday, 2 August 2018 16:00:21 UTC