From: Bruce Lilly (blilly@erols.com)
Date: Wed Apr 28 2004 - 23:21:34 CDT
Charles Lindsey wrote:
> In <408E5422.80301@erols.com> Bruce Lilly <blilly@erols.com> writes:
>
>
>>Charles Lindsey wrote:
>>>>>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.
The obvious case would be a proto-article (the only sort of object that
injection agents handle) with no message-id -- the injection agent adds
one, and if the proto-article is reinjected, a different message-id
will be added. You have also in the past noted that Message-ID fields
are optional in mail and other applications of RFC [2]822 Internet
Message Format, so it is possible (though IMO unlikely) that a
Message-ID field might be elided in the process of gatewaying.
> However, under the present setup where the Date-header is used,
[...]
> 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).
No good reasons have yet been supplied, and in fact the latest (November
2003) draft speaks of "avoid[ing]" and "preventing" reinjection. Only
you have recently proposed legitimizing it -- with no rationale.
> 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.
[...]
Changing the name of the field used from "Date" to "injection-Date"
hardly qualifies as "a different ball park". In any event, it is
not the matter of requirements for normal operation w.r.t. Injection-
Date that are at issue, it is the change from "avoid[ing]" and
"preventing" reinjection (current draft) to legitimizing it (your
proposed text) that is objectionable.
>>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.
No, I said that among the purported examples, it was the only one that
was not nonsense, and that it "possibly warrants further discussion".
I most certainly did not say "had an arguable case". I would now add
that it seems incompatible with the text of the current draft:
If bidirectional gatewaying (both an incoming and an outgoing
gateway) is being set up between Netnews and some other medium, the
incoming and outgoing gateways SHOULD be coordinated to avoid
reinjection of gated articles. Circular gatewaying (gatewaying a
message into another medium and then back into Netnews) SHOULD NOT be
done;
"avoid reinjection" seems quite clear.
>>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.
You have yet to provide a single sensible example -- if the practice is
as common as you claim (with no supporting data), it should be simple
for you to come up with a sensible example. If you cannot do so, then
I see no reason to change the tone of the November draft w.r.t. the
matter.
>>>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).
*You* claimed that is was expected, and have yet -- despite repeated
requests -- to produce a single clear example of legitimate "reinjection".
Again, the issue is not actions to be taken by injection agents in the
course of injection, but rather the peculiar text regarding "reinjection",
which has yet to be clearly defined or justified.
>>>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".
And therefore "relaying" did not take place. Exactly what are you
having difficulty in understanding about that?