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