From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Wed Apr 28 2004 - 08:11:09 CDT
In <408E5422.80301@erols.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> 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?
>Loops, multiple copies of an article (with different message-ids).
What ARE you talking about? Where have those "different message-ids"
suddenly sprung from? The loops we are concerned with here arise because
an article might come around again with the SAME message-id.
However, under the present setup where the Date-header is used,
reinjection does no harm because the Date-header never gets altered, and
so if the reinjected message arrives again at a site where it has already
been seen and expired earlier, then the ancient Date-header is sufficient
to stop it being accepted again. So no loops and no problems.
Therefore, the present draft had no need to mention any special
precautions to be taken by injecting agents when reinjecting, and hence
the reason why reinjection was only ever mentioned in passing as an oddity
that might occasionally happen, leaving some trace in the Path header but
not actually causing any harm.
So there was no reason to regard it as not legitimate, which is as well
because in practice it happens quite a lot for all sorts of assorted
reasons (good or bad).
Now we are in a different ball park. Injection agents are now instructed
to add an Injection-Date header, and relaying and serving agents are going
to use it in preference to the old Date-header for preventing those loops.
Since reinjection is still going to happen (because old habits die hard,
if nothing else), it would be totally irresponsible for us not to say
that the new instruction to add an Injection-Date header DOES NOT apply in
the case of reinjection. For otherwise, things which have been working
quite happily for hte last 15 years will suddenly start to cause loops.
That is an unacceptable position for us to get into.
>> 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.
>You have yet to provide a single example of such an exceptional case
>which makes even the slightest bit of sense.
I have provided several examples, and you admitted yourself that the
example of complex gatewaying (which has been explicitly mentioned in the
draft in that context for I don't know how long) had an arguable case.
>The current draft (Nov. 2003) states:
> In order to prevent the reinjection...
> The most common problem ...loops that cause previously posted articles to be reinjected
> ...avoid reinjection...
> ...prevent its reinjection into Netnews
> ...preventing reinjection...
Yes, but all those are references to accidental/inadvertent reinjection
caused by badly configured relaying/serving (not injection) agents. What I
am talking about is the *deliberate* reinjection, making use of an
injection agent, at a site which had chosen to allow it for
well-understood reasons. OK, maybe I chose the wrong term "reinjection",
and maybe I should have stuck with "second injection" (since I can hardly
imagine a case where a third injection would be sensible). I don't mind
having a rethink over my terminology.
>> 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.
>AFAICR the draft text quoted above was not specifically discussed.
The discussion 6 (well more than 6 now) weeks ago discussed the proper
actions to be taken with regard to the Injection-Date-header in the event
that an already injected article should be offered for injection again. We
would not have been discussing that if we had not recognized that it was a
circumstance that was expected to happen (albeit exceptionally).
>>
>>
>> Only if the relaying was successful
>By definition, an article which has been relayed has been relayed "successful[ly]".
And if the attempted relaying failed, then it was not "successful". In
which case it is reasonable to take other steps to get it out (such as by
finding another site that will take it).
-- 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