IMO, 3*DIGIT is dumb. An error in the bnf notation. the rule
should be changed to (2DIGIT / 4DIGIT).
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcro...@brandenburg.com
Sunnyvale, CA 94086 USA http://users.aimnet.com/~dcrocker/
*** Email address is changed from the
*** long-standing stanford mailbox
Sorry, I have lost track of whether I ever answered this, or at least
forwarded it to the wise people on the old Host Requirements mailing
list.
Bob Braden
----- Begin Included Message -----
From broadcast.sony.com!blilly!br...@mony.com Wed May 3 13:59:21 1995
Subject: Request for clarification; RFC 1123 sect. 5.2.14
To: Bra...@ISI.EDU
Date: Sun, 30 Apr 95 9:17:58 EDT
From: Bruce Lilly <blilly!br...@uu6.psi.com>
Reply-To: li...@sots.sony.com
X-Mailer: ELM [version 2.2 PL16]
Content-Length: 955
X-Lines: 24
Robert,
RFC 1123 section 5.2.14 extends the RFC 822 date field syntax
for years from 2*DIGIT to 2*4DIGIT. Clearly, 2*DIGIT would
allow backwards compatibility with RFC 822 headers, and 4*DIGIT
(which is recommended) provides a full specification of the
year, at least for the next 8 millenia.
But the specification 2*4DIGIT aslo permits a year matching the
specification 3*DIGIT. It is unclear what the semantics of a
3*DIGIT year are, and RFC 1123 is silent on this matter.
Should 3*DIGIT years always be interpreted as a literal specification of a
date in the 2nd through 10th centuries A.D., i.e. as an error
(in which case, the revised specification should be (2*DIGIT / 4*DIGIT)
), or is there some other specific interpretation which should be applied?
By the way, the last sentence of section 5.2.14 incorrectly refers to
section 3 of RFC 822; that should be section 5.
Best regards.
--
Bruce Lilly ...uupsi!monymsys!sonyd1!blilly!bruce
----- End Included Message -----