Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Request for clarification; RFC 1123 sect. 5.2.14

2 views
Skip to first unread message

Dave Crocker

unread,
Oct 26, 1995, 3:00:00 AM10/26/95
to
At 10:29 AM 10/26/95, bra...@ISI.EDU wrote:
>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.
...
>Should 3*DIGIT years always be interpreted as a literal specification of a

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

bra...@isi.edu

unread,
Oct 26, 1995, 3:00:00 AM10/26/95
to

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


0 new messages