Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!coolidge
From: coolidge@brutus.cs.uiuc.edu (John Coolidge)
Newsgroups: news.software.b
Subject: Re: Supersedes problems with rapid-fire articles
Summary: stamp out rewriting!
Message-ID: <1989Aug31.234545.23296@brutus.cs.uiuc.edu>
Date: 31 Aug 89 23:45:45 GMT
References: <5200@looking.on.ca> <1989Aug30.052459.1166@vicom.com> <1989Aug30.204324.2675@paris.ics.uci.edu> <1989Aug30.225332.18770@brutus.cs.uiuc.edu> <1989Aug31.174054.15398@paris.ics.uci.edu>
Sender: news@brutus.cs.uiuc.edu
Reply-To: coolidge@cs.uiuc.edu (John L. Coolidge)
Organization: U of Illinois, CS Dept., Systems Research Group
Lines: 59

nagel@ics.uci.edu (Mark Nagel) writes:
>I write:
>>[...] Re-writing incoming articles to create a Lines:
>>header seems just plain wrong to me. Perhaps it would be a good idea if
>>you're running some sort of gateway (news-notes, mailing list, etc) but
>>at that point it should be the gateway program's job, not C news'.

>>Programs mainly intended for passing on
>>external news (relaynews, newsspool) still shouldn't do any rewriting not
>>required (and only Xref (not propagated) and Path are required, I think).

>Adding the code to inews is not sufficient, because not every site
>is going to add the Lines header locally.  Thus you end up with
>articles being propagated without Lines headers.  Amazingly enough,
>many users actually find these headers useful in determining whether
>an article is "read-worthy."  _Any_ piece of information aiding in
>article weeding is useful enough that it should be present in all
>articles.

Amazingly enough, I'm one of those people who finds Lines: very useful.
That's why I patched C News to do Lines: (right!) as soon as I knew that
it wasn't generating the header.

That being said, I reiterate my opposition to rewriting articles generated
at another site. With the exception of things like Path: (which is necessary
to ensure that things work right) and Xref: (which is really a performance
hack, and one graced by the RFC at that) I don't hold with rewriting at
all. In fact, this is one of the places I think Geoff and Henry should not
have "re-interpreted" the RFC --- Xrefs should not be passed on, IMHO,
simply because ANY local changes (excepting Path:) to an article not
generated locally shouldn't be passed on. If you want to add Lines: locally
but not propagate it, that's a different matter. But articles should be
passed on EXACTLY as received.

The alternative is to have every zealous sysadmin "fixing" broken articles
whenever possible. Bad subject line? No problem, I've got my Subject: fixer
that removes old was's and fixes spelling problems. Since lots more people
use Subject: to decide if an article is "read-worthy", it's obviously a
prime candidate for rewriting. Also, while we're at it, let's fix all the
Organizations: so they indicate the "correct" organization. And add
Reply-To:'s, Keywords:'s, and Summary:'s.

I just plain disagree here. Articles should be passed on exactly as
received. I strongly urge that everyone's machine generate Lines: (and
wish every newsreader would produce References:), and I urge Geoff and
Henry to put a notice in the release notes to C News saying "many people
think Lines: is a good idea. We don't enable it by default, and here's
why: <>. But if you think it's a good idea, turn it on by doing: <>."
I'd probably even support a change to the RFC making Lines: an offically
required header (especially if they'd make References: one too). But I
greatly disagree with rewriting articles on the fly, regardless of how
useful the resulting header is. The ends simply do not justify the means.

--John

--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge@cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed.