From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Fri Apr 23 2004 - 05:58:41 CDT
In <4087D34B.9030409@erols.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> In <407DE495.9020403@erols.com> Bruce Lilly <blilly@erols.com> writes:
>>>If it is not legitimate, then we should state so clearly. If there are
>>>known instances where it happens regardless, we should be especially
>>>clear that those cases are forbidden.
>>
>>
>> Why?
>Because it [reinjection] causes problems,
What problems? At the present time, reinjection causes no problems at all.
As Russ has pointed out, "It happens all the time" (sometimes with good
reason, sometimes with bad). Our draft has always recognized that it
happens, and will continue to happen, though only in exceptional cases -
it is certainly not intended to be the norm.
Now we are introducing a new Injection-Date-header and requiring injecting
agents to create it. If we just do that, and if all injecting agents do it
regadless, then bad things WILL start to happen (loops will be created in
some situations). Therefore the protocol needs to state that, when
reinjecting, an existing Injection-Date MUST be retained. Then the newly
introduced problem goes away. Alternatively, as you say, you forbid
reinjection absolutely.
But then, if you do not make any special rule for handling the
Injection-Date, and some agents continue to reinject and write a new
Injection-Date-header (as the standard would then be telling them), then
you will have indeed created a problem, and will have broken one of the
fundamental principles on which Netnews is based, as reiterated in many
places including Son-of-1036 and our draft, which is "DO NOT CREATE
LOOPS".
I find it mind boggling that you are so naive as to suppose that simply
prohibiting that practice (which is fairly widespread) will actually cause
it to cease. It won't. The Usenet world does not work like that.
So which is worse? To attempt to change existing practice in a manner that
is likely to cause loops, or to anticipate the problem and write the
protocol in such a manner that the loops do not occur?
Since we are inventing a new header which has never been seen in the wild
before, it is perfectly easy to specify its associated protocol so as to
avoid that potential problem. It would be totally irresponsible not to do
so.
Moreover, all this was discussed over six weeks ago, and AFAIAC the issue
was settled then. Certainly you did not raise any objection during that
earlier discussion.
>> Yes, but in the case where this sort of thing is likely to be important
>> (examples I am aware of include control messages and important announce
>> groups) the actual relaying/posting is likely to be done by some automated
>> script
>That matters not -- once the article has been injected *and* relayed
>it is a matter for propagation as handled by flood fill. You have
>failed to present a case for "reinjection".
Only if the relaying was successful (once an article has reached 2 or 3
servers our there, the flood-fill will indeed take care of it).
>>>That is utter nonsense; if the article (N.B. not proto-article) cannot
>>>be relayed (why on Earth is A trying to relay to B, when it is an established
>>>fact that B does not accept relayed articles from A?)
Perhaps because B advertises that reinjection capability as a service to
users to whom it does not offer full peering rights? Yes, there are
servers that offer that capability and no, it would not be a sensible
alternative to do a duplicate primary injection at such servers because
that would take extra bandwidth and machine resources. And even INN out of
the box can be configured (AIUI) to accept relaying by non-approved sites
(though not to reinject without hacking its source code first). Russ
explained all this during our discussions 6 weeks ago, and he also agreed
that hacking the code so as to reinject was a possibly sensible thing to
do where the site concerned needed to ensure that it could fulfil its
responsibilities to the rest of the net.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5