Re: [Technical Errata Reported] RFC7231 (5448)

Perhaps fodder for consideration in http core but not 7231 errata I'm. Open
a http core issue instead?

On Thu, Aug 2, 2018, 12:03 Amos Jeffries <squid3@treenet.co.nz> wrote:

> 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
>
>