Path: utzoo!utstat!jarvis.csri.toronto.edu!mailrus!uwm.edu!rutgers!ucsd!brian
From: brian@ucsd.Edu (Brian Kantor)
Newsgroups: news.software.nntp
Subject: Re: Suggested NNTP enhancements for user access control
Message-ID: <10124@ucsd.Edu>
Date: 12 Nov 89 18:29:32 GMT
References: <10095@ucsd.Edu> <1802@gazette.bcm.tmc.edu> <1544@intercon.com> <BOB.89Nov10164646@archer.MorningStar.Com>
Reply-To: brian@ucsd.edu (Brian Kantor)
Organization: The Avant-Garde of the Now, Ltd.
Lines: 21

I think the proposed DATE command (which would return the NNTP server's
idea of date and time as MMDDYY  HHMMSS or something) is probably a good
enough idea that it's worth adding as an optional command.

Why?  Well, it handles the timezone problem, which isn't solvable any
other easy way (I mean really, there are adjoining towns which either do
or don't observe summer time), and it's a cheap and easy hack.  People
who want to use it and don't want to go to the trouble of using NTP to
get a precise time may do so.

And there are commands in NNTP that require MMDDYY HHMMSS arguments.
It suits my sense of symmetry and completeness that we should be able to
provide some sort of reference point without having to go outside the
protocol.

But the winning argument came from some people who are using NNTP over
non-TCP (in fact, non-internet-protocol) links.  There is no time
protocol that they can use.

So I think I'll add it to the spec as an optional thing.
	- Brian