From: Bruce Lilly (blilly@erols.com)
Date: Thu Apr 01 2004 - 19:32:04 CST
Charles Lindsey wrote:
> In <40660B84.8060608@erols.com> Bruce Lilly <blilly@erols.com> writes:
>
>
>>Charles Lindsey wrote:
>>
>>>In <4062F8AB.5010505@erols.com> Bruce Lilly <blilly@erols.com> writes:
>>>
>>>
>>>>I don't recall agreement about "reinjection". You seem to be the only
>>>>person insisting that it should happen. That warrants further discussion.
>
>
> I am not insisting that it should happen. I am asserting that it DOES
> happen (for a variety of reasons - some justifiable and some not). We have
> to live with that, and my concern is to make sure that if/when it happens
> it is not used as an excuse to rewrite the Injection-Date.
You seem to be the only person claiming that there are "justifiable"
"reasons" for "reinjection". Yet you have not specified what those
reasons are in sufficient detail.
>>None of those sections defines "reinjection".
>
>
> 5.6.4 speaks of "double-injection" which come to the same thing (I would
> probably change that to "reinjection" as part of the change). Likewise
> 8.2.1 contains the phrase "injected twice". 8.2.2 uses the term
> "reinject".
"[S]peaks of", "contains the phrase", and "uses the term" are
all different from "defines". Neither the term nor reasons
why the process might legitimately take place are defined.
> Anyway, if you want some further discussion on the circumstances where
> reinjection might reasonably occur, here is a first cut of some text that
> might go in the draft. However, it is probably the case that the less we
> say in the draft, the better, and so this text arguably says too much.
>
> In the normal course of events, an article that has already been
> injected into a Netnews network will never pass through another
> injecting agent. ...............
Agreed.
> Exceptionally, there may be good reasons to reinject an already
> injected article, and this standard therefore prescribes the proper way
> to do so. Examples of such circumstances include:
>
> . a relaying agent unable to relay an article to its usual peers due to
> unanticipated communication problems (for example, an agent on a laptop
> that has been physically disconnected from its usual environment) might
> attempt instead to reinject it at a site which did not recognize it as
> a peer;
If the article has been injected, it should be relayed, not "reinject"ed.
If the laptop has separate injecting and relaying agents, and the article
has already been injected, the relaying agent has it and is expected to
relay it (not inject or reinject it). If it has a combined injection/relaying
agent and that agent has accepted the article with all of the necessary
checks associated with injection, but finds that it cannot relay the article,
it might be reasonable for that agent to convert the article back into a
proto-article (removing Injection-Date, Injector-Info, etc.) and inject that.
> . a relaying agent receiving an attelpted relay from a source with
> which it did not have a peering agreement might choose to reinject it
> instead, in order to fulfil its obligation to the rest of the network
> (8.2) to be responsible ...
According to 8.2, an injection agent is responsible "for the behaviour
of its posters"; in the case you describe, either the relaying agent is
unable to fulfill that obligation or it has no reason to reject the
relayed article. Either way, [re]injection is not warranted.
> . there might be a genuine misunderstanding between two sites as to
> whether the relationship between them was as peers for relaying, or as
> client/server for injecting.
How can that happen given the requirement in 8.2 (as above)? An injection
agent must know its clients quite well.
> . an article might be gatewayed out of Netnews into some other medium,
> and then back again into the same, or a different, Netnews network.
In that case one or both gateways should take appropriate action (to be
discussed) to prevent reinjection into the same network, and to remove
Injection-Date, Path, etc. if entering a different network.
> In all such cases, it is up to the receiving agent to detect that the
> actual circumstance is consistent with its site policies for
> reinjection.
In all the cases described, an injection agent (or gateway assuming the
functionality of an injection agent) would need to have sufficient
information about the source of the article(s) to comply with the 8.2
obligations. In the specific case of gateways, the x-to-news gateway
will have to have sufficient information to be able to determine that
the network that the article will be injected into is in fact different
(i.e. disconnected from) any news network that the article may have
been posted to.
>>Then there is a problem with the definition. If "injecting" is
>>supposed to mean "either forwards them to a moderator or
>>injects them" then the definition is both circular and self-
>>contradictory.
>
>
> The way things currently work (with the exception of a few posting agents
> that generate the email to the moderator themselves) is that the
> _injecting_agent_ is the one that determines whether to inject the article
> immediately, or whether to email it to a moderator (thereby aborting the
> injection, as such). That is the way the process is set out in 8.2.2. If
> you follow the steps given there, there is no circularity.
That an injection agent may determine that an article is either mailed
to a moderator (and not injected) or injected (and not mailed to a
moderator) is not in dispute. Your earlier claim that the former
somehow constitutes "injection" is.
>>>>What about NNTP-Posting-Date? If it is to be ignored, then there is no
>>>>need to say that it MUST be retained.
>
>
>>If it's not supposed to be generated, then why mandate preservation?
>>If it's not used for anything, then it is effectively ignored.
>
>
> Because it is generally a Bad Thing to remove any header without good
> cause. But you may well argue that MUST is a bit strong here. I have made
> a note to review this when I come to writing that bit of the text.
There are some (e.g. Xref) that shouldn't be there in the first place,
and which should always be removed when relaying, gatewaying, etc. One
issue with what you wrote is indeed that under the circumstances
(NNTP-Posting-Date is ignored) "MUST be retained" is to strong. However,
it is arguable that NNTP-Posting-Date should not be ignored if it is
present and Injection-Date is not, in which case "MUST be retained" is
reasonable. Specifically, the date-time taken to be the time of
injection should probably be:
1. that specified in Injection-Date, if present, else
2..that specified in NNTP-Posting-Date, if present, else
3. that specified in Date, as a last resort
I.e. NNTP-Posting-Date fills an interim role until Injection-Date becomes
widely supported.
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################