Request for clarification; RFC 1123 sect. 5.2.14
braden@isi.edu Thu, 26 October 1995 17:35 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18078; 26 Oct 95 13:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18074; 26 Oct 95 13:35 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14063; 26 Oct 95 13:35 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA09142>; Thu, 26 Oct 1995 10:27:22 -0700
Date: Thu, 26 Oct 1995 10:29:24 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: braden@isi.edu
Posted-Date: Thu, 26 Oct 1995 10:29:24 -0700
Message-Id: <199510261729.AA02014@can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4) id <AA02014>; Thu, 26 Oct 1995 10:29:24 -0700
To: ietf-hosts@isi.edu
Subject: Request for clarification; RFC 1123 sect. 5.2.14
Cc: braden@isi.edu, blilly!bruce@uu6.psi.com
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!bruce@mony.com Wed May 3 13:59:21 1995 Subject: Request for clarification; RFC 1123 sect. 5.2.14 To: Braden@ISI.EDU Date: Sun, 30 Apr 95 9:17:58 EDT From: Bruce Lilly <blilly!bruce@uu6.psi.com> Reply-To: lilb@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 -----