From: Bruce Lilly (blilly@erols.com)
Date: Tue Apr 27 2004 - 07:37:54 CDT
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).
> 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.
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...
Contrary to "Our draft has always recognized that it happens...", the draft
text seems to appropriately go to lengths to assure that reinjection does
not happen. Why are you now changing that without WG consensus and without
adequate rationale?
> 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.
There is no "newly introduced problem". Injection-Date merely provides a
record of the time of injection, which had previously been handled by some
software-specific fields, or assumed to be equivalent to the time of
message composition (as recorded in the Date field). There is no problem
with stating that the Injection-Date field must be retained -- that in fact
implements the draft's requirement that "The message should be tagged in
some way so as to prevent its reinjection" when coupled with a requirement
that an article (N.B. it is not a proto-article) already containing an
Injection-Date field must not be reinjected. The latter is essential in
preventing such reinjection, as provided for in the existing draft text.
> 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.
So why are you irresponsibly changing the existing draft text which strongly
states that "reinjection" is to be "avoid[ed]", and "prevent[ed]"?
> 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.
>>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
By definition, an article which has been relayed has been relayed "successful[ly]".
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################