- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 18 May 2009 19:00:23 +0200
- To: Brian Smith <brian@briansmith.org>
- CC: 'HTTP Working Group' <ietf-http-wg@w3.org>
Brian Smith wrote: >> That doesn't sound better to me, but that may be caused by me not being >> a native English speaker. > > "...defined in the RFC 5322 constructs..." means the definition is inside > the construct. I thnk you meant "...defined in RFC 5322 for the > constructs...". Indeed. Fixed. > The only instances of this problem are one-digit days in asctime-date (just > prepend a zero to get a day), day-name-l (just drop all characters after the > first three to get a day-name), and two-digit years. I doubt there is an > interpretation of two-digit years commonly accepted by all implementations. > Probably the most common implementation is to either ignore dates using > rfc850-date format and/or return (400) errors when rfc850-date is > encountered. That is what all my implementations do. Accordingly, I don't > think support for rfc850-date should be a MUST- or even SHOULD- level > requirement. Yes, the 2-digit dates are a can of worms. This is a mess, we do both say "MUST accept", but then do not say what it means. That being said, changing a normative requirement from RFC2616, even if it's underspecified, is something we shouldn't do lightly. BR, Julian
Received on Monday, 18 May 2009 17:01:15 UTC