Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!lll-tis!mcb From: mcb@lll-tis.arpa (Michael C. Berch) Newsgroups: news.admin Subject: Re: Expiration dates on OtherRealms Message-ID: <21616@lll-tis.arpa> Date: Mon, 27-Jul-87 13:37:54 EDT Article-I.D.: lll-tis.21616 Posted: Mon Jul 27 13:37:54 1987 Date-Received: Tue, 28-Jul-87 04:27:07 EDT References: <2525@hoptoad.uucp> Reply-To: mcb@lll-tis.arpa (Michael C. Berch) Organization: Lawrence Livermore National Laboratory, Livermore CA Lines: 31 I tend to agree with Chuq on this. He is using the "Expires:" field for exactly the purpose for which it was intended: when the author/poster of an article believes that it is of some more lasting use or value as opposed to the normal flood of Usenet articles. Otherrealms is a MAGAZINE. It's quite long, professionally edited, and comes out quarterly (formerly monthly). Just like the way print magazines live on the newstands, the previous issue should not expire (e.g., be discarded) before the new one replaces it; there should always be a "current issue" available for new readers. Compared with the flow of a normal newsgroup, even a moderated one, its disk usage should be statistically insignificant for administrative purposes. But for those sites that don't want to keep OR for longer than the default period, that is exactly what the override date options on expire are for. Rec.mag.otherrealms can just be in an expire line by itself with -e12 or whatever; overriding the date for it DOESN'T mean you have to override the date for other things like the map postings. In my opinion, Chuq is right to use the Expires: field the way he does, and John Gilmore is right to expire rec.mag.otherrrealms articles on his machine any way he sees fit. I don't see that there is really a policy conflict. (I do not claim to be unbiased; I am an enthusiastic reader of OtherRealms and have contributed to it in the past. I'm also a news administrator for a largish site and have to keep track of things -- like the fact that our /usr/spool overflowed this weekend...) Michael C. Berch ARPA: mcb@lll-tis.arpa UUCP: {ames,ihnp4,lll-crg,lll-lcc,mordor}!lll-tis!mcb