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