Re: Origins of DATE command
Brian Kantor <brian@nothing.ucsd.edu> Mon, 15 July 1996 01:31 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10912;
14 Jul 96 21:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10908;
14 Jul 96 21:31 EDT
Received: from PHEASANT.ACADEM.COM by CNRI.Reston.VA.US id aa13811;
14 Jul 96 21:31 EDT
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by
pheasant.academ.com (8.7.5/8.6.9) with ESMTP id UAA05232 for
<ietf-nntp@PHEASANT.ACADEM.COM>; Sun, 14 Jul 1996 20:30:10 -0500
Received: from nothing.ucsd.edu (nothing.ucsd.edu [132.239.1.4]) by academ.com
(8.7.5/8.7.1) with SMTP id UAA01846 for <ietf-nntp@academ.com>;
Sun, 14 Jul 1996 20:30:09 -0500 (CDT)
Received: by nothing.ucsd.edu (8.6.12/UCSDGENERIC.5)
id SAA03029 to ; Sun, 14 Jul 1996 18:29:46 -0700
Date: Sun, 14 Jul 1996 18:29:46 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Brian Kantor <brian@nothing.ucsd.edu>
Message-Id: <199607150129.SAA03029@nothing.ucsd.edu>
To: ietf-nntp@academ.com, paulo@turnpike.com
Subject: Re: Origins of DATE command
The DATE command is implemented in all current versions of NNTP servers that I'm aware of. The history of it is this: we discovered soon after we added the NEWNEWS command that clients in other timezones or on stupid machines like Macs and PCs [remember that the original PC didn't have a clock in it] needed some way to get the time of day as evaluated by the server. So we added the DATE command. In the arguments over the NNTPv2 spec, one of the concerns was that clients would use the DATE command as a remote time clock, and beat the NNTP server to death asking about the time of day. [In today's light, what with hardware clocks in nearly everything, and the NTP to keep it all sync'd, that seems silly. But it wasn't then.] Some wanted to omit the DATE command entirely for that reason, and it was omitted from the v2 draft for many revisions. What we agreed to do - though it never made it to hard copy - was to add a command (never named) which would represent a 'magic cookie' that could be fed to the NEWNEWS command just as the ISO date is in the v1 implementation. It was to be a server-dependent item; you would request it and save it and return it, but you didn't interpret it. Whether it was an ISO format timestamp, an encrypted version of it, an offset into the history file, or whatever, wasn't important. It was to be documented as "not dependably the time of day" so that clients wouldn't use it as a clock. Hope that perspective helps a bit. - Brian PS: two things to keep in mind: 1) the v1 spec was written BEFORE implementation, so it does not represent what the actual usage of the protocol is. That was done because, back in those days, in order to get a reservered TCP port, you had to have an RFC. We thought we needed a reserved port in order to develop things. Probably better that we did, since ad-hoc port assignments tend to live forever. I argued that it should never be made a standards document because it was incorrect from GO, but hey, the network politicos needed a standard and accuracy was the loser. Thus the crying need for Stan's how-it-really-works document and suchlike. 2) the v2 spec as it stands is, as far as I know, the draft brought to one of the various working committee meetings for discussions. Each such meeting resulted in copious notes on what should be changed, many of which items were to go into an NNRP protocol draft that, to my knowledge, was never written. Nor were many of the changes that were discussed ever re-incorporated into the draft. Simply, we all just got too busy doing the things they paid us for, and NNTPv2 fell by the wayside. Sorry about that.
- Origins of DATE command Paul Overell
- Re: Origins of DATE command Stan Barber
- Re: Origins of DATE command Brian Kantor
- Re: Origins of DATE command Tom Limoncelli
- Re: Origins of DATE command Brian Kantor
- Re: Origins of DATE command markd
- Re: Origins of DATE command Harald Kipp