Xref: utzoo news.software.b:8183 news.admin:15052
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!kullmar!pkmab!ske
From: ske@pkmab.se (Kristoffer Eriksson)
Newsgroups: news.software.b,news.admin
Subject: Re: Cnews "dropped article" Notifications - another proposal
Message-ID: <5656@pkmab.se>
Date: 8 Jun 91 09:03:11 GMT
References: <1991Jun4.161440.4161@wynnds.xenitec.on.ca>
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
Lines: 52

Here's yet another proposal for what to do about articles that Cnews doesn't
want to propagate further, that I haven't seen anyone touch on yet.

The problem with having every Cnews site that encounters the objectionable
article returning a mail message to the author is that there is no upper
bound on how many messages the author may be sent from all over the net.

So one way to twist this problem is how to select which site or sites that
should return a message, if having all sites do that is out. My proposal is
to make it possible for every site to request this service of any other site,
and return messages only to those sites that have requested that. Each Cnews
site would have a list of sitenames that have requested notification of
errors, which it would check every time it encounters an objectionable
article. To make this work smoothely, one would need some automated means
of adding and removing ones own sitename to or from this list on any other
site of your choosing. A new type of control message would do. A mail server
would probably be the absolutely best solution, so requests could go directly
to the target site instead of being broadcast through the news system, but
that would bring us somewhat outside what can be contained in the Cnews system
alone. A friendly news admin could add sitenames manually to this list, too,
but a desireable goal is to remove the dependancy on friendly news admins, so
that wouldn't be quite enough. Thus I propose a control message as the best
solution.

Each site that worries about the well of their articles, would study their
net connections and determine one or several strategically placed sites
that they want to receive error messages from, for instance the nearest
Cnews site(s) or some regionally important big site. But ultimately it
would probably be wise for most sites to set up error-returning partners
like this, just as a routine matter, worries or not.

As a default, we could also let Cnews always return bad messages that
originated at an immediate neighboughr, even without any explicit request.
That shouldn't be too dangerous.

Apart from all that, I still think it is overly pedantic to drop articles
simply because of a missing space after a colon. I don't see that the space
carries any significance, any meaning of its own, right after that colon in
the header, especially not in non-essential headers. To me the space appears
only to be an aesthetic enhancement, comparable to white space between the
syntax elements of a programming language. In most laguages you can change
the number of spaces without affecting the meaning. That the RFCs specify
only exactly one space, can be viewed simply as the "default" rendering
that should be used when the header leaves your program, without saying
much about what your program is allowed to accept when it arrives at your
program. I think such an interpretation is in the spirit of "be liberal in
what you expect, and strict about what you emit".

-- 
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske