[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1416 Injection-Date: proposed diff
"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx> writes:
> In Duties of a Posting Agent:
>>+ <t>If the proto-article already contains both Message-ID and Date
>>+ header fields, posting agents MAY add an Injection-Date header
> ^
> , as part of the injection process,
>>+ field to that proto-article immediately before passing that
>>+ proto-article to an injection agent.
> That is where I don't see why they MAY add it only if both Message-ID and
> Date are present (see "???" above). What harm arises, even in IR, if they
> are allowed to add it anyway?
The language is written as it is because it's written from the perspective
of establishing a unique identity for the article and that can't be done
without the Message-ID header anyway. Thinking of an article with
Injection-Date and not Message-ID is rather weird to me, but I can't think
of any specific *problems* it would cause. It's similar to an article
with Date but no Message-ID today.
Adding Injection-Date when there's no Date header is just bizarre and
strange, since it means that one is not trying to use the "time of
composition" semantics of Date and it baffles me why they wouldn't just
let the injecting agent add the headers. Here I similarly can't put my
finger on any harm, but even more so than the Message-ID case, it's a
remarkably strange thing to do and I can't figure out why anyone would
want to do that or what meaningful semantics it would express.
I guess I'm not sure the right thing to say here.
>>+ ...... They SHOULD do so if the
>>+ Date header field (representing the composition time of the
>>+ proto-article) is more than a day in the past at the time of
>>+ injection. If the proto-article is being submitted to more than
> ^^
> They MUST do so if
>>+ one injecting agent, see <xref target="multi-injection" />.</t>
> Yes, that last MUST is redundant, but the point is important and
> you have a similar redundancy when discussing proto-articles further on.
Agreed. Changed in my draft.
> In Multiple Injection of Articles:
>>+ <t>Whenever possible, multiple injection SHOULD be done by
>>+ offering the same proto-article to multiple injecting agents.
>>+ The posting agent MUST supply the Message-ID, Date, and
>>+ Injection-Date header fields, and the proto-article as offered
> ^^^^^^^
> articles
>>+ to each injecting agent MUST be identical.</t>
Intentionally not plural because they're identical and hence there is only
one proto-article.
>>+ <t>In some cases, offering the same proto-article to all
>>+ injecting agents may not be possible (such as when gatewaying,
>>+ after the fact, articles found on one Netnews network to
>>+ another, supposedly unconnected one). In this case, the posting
>>+ agent MUST convert the article back into a proto-article before
>>+ passing it to another injecting agent, but it MUST retain
>>+ unmodified the Message-ID, Date, and Injection-Date header
>>+ fields. It MUST NOT add an Injection-Date header field if it is
>>+ missing from the existing article. It MUST remove any Xref
>>+ header field and either rename or remove any Injection-Info
>>+ header field and other trace fields.
> Technically, that is what we used to call "reinjection". Now it is called
> "Gatewaying after the fact", which is a bit of a mouthfull. Neither term
> really indicates that the person/entity doing it may be completely unaware
> that either multiple- or re-injection is taking place.
How could you not be aware that multiple injection is taking place? Some
agent involved in the process clearly *does* know this unless the multiple
injection is being done manually by a human, in which case the *human*
knows this. You're starting with an existing news article rather than
with a blank screen and an editor; that's a pretty obvious difference.
Whatever agent that is that knows this is going on is responsible for
doing the right thing in conjunction with the posting agent doing the
work.
> Also, I am not sure that "converting it back into a proto-article" is
> quite what is happening. What is important is that any Message-ID, Date
> and Injection-Date MUST stay, and any Xref and Injection-Info MUST go.
Which makes it a proto-article. I phrase it that way because I want to be
very clear that any constraints expressed in the Proto-articles section
apply to the resulting article.
> Also, it is not clear what is to happen to any Path. My preference would
> be to leave it (see discussion of this further down), or otherwise to
> rename it.
I agree that this isn't clear. I think I'm convinced that we can drop the
restriction on POSTED keywords in Path in proto-articles, but I'd like
other members of the working group to weigh in on that.
>>@@ -452,6 +455,66 @@
>> </section>
>> </section>
>>
>>+ <section anchor="history"
>>+ title="Article History and Duplicate Suppression">
>>+ <t>Netnews normally uses a flood-fill algorithm for propagation of
>>+ articles in which each news server offers articles it accepts to
> ^
> the
Changed.
>>+ multiple peers and each news server may be offered the same
>>+ article from multiple other news servers....
>>+
>>+ <list style="symbols">
>>+ <t>Agents MAY select a cutoff interval and reject any article
>>+ with a date farther in the past than that cutoff interval. If
>>+ this interval is shorter than the time it takes for an article
>>+ to propagate through the network, the agent may reject an
> ^^^
> might
Changed.
>>+ article it had not yet seen, so it ought not be aggressively
> ^
> to
>>+ short....
I think this is an English style difference. I believe the current text
is correct, and adding "to" seems less correct to me.
The wording is a little awkward, though, but the rephrasings occuring to
me are even more cumbersome.
>>+ <t>These are just two implementation strategies for article
>>+ history, albeit the most common ones. Relaying and serving agents
>>+ are not required to use these strategies, only to meet the
>>+ requirement of not accepting an article more than once. However,
>>+ these strategies are safe and widely deployed and implementors are
>>+ encouraged to use one of them, especially if they not have
> ^
> do
Changed (I think someone else had already caught that).
>>+ extensive experience with Netnews and the subtle effects of its
> ^^^
> with the more
>>+ flood-fill algorithm.</t>
I don't see how that's an improvement. The nouns joined with that
conjunction seem brief enough to me to not warrant repeating the
preposition.
>>@@ -459,9 +522,33 @@
>>
>>+ applicable policies. They MUST NOT create any Injection-Info
>>+ header field; this header field will be added by the injecting
> ^^^^^^^
> is only to be
>>+ agent.</t>
As much as I prefer to avoid using lowercase may, "may only" seems way
clearer here to me than either "will be" or "is only to be". Changed
accordingly.
>>+ <t>The Injection-Date header field is new in this revision of the
>>+ Netnews protocol and is designed to allow the Date header field to
>>+ hold the composition date (as recommended in section 3.6.1 of
>>+ <xref target="RFC2822" />), even if the proto-article is not
> ^
> to be
>>+ injected for some time after its composition....
Changed.
>>@@ -484,48 +571,73 @@
>> agent.</t>
>>
>> <t>A proto-article has the same format as a normal article
>>- except that the Injection-Date, Injection-Info, and Xref header
>>- fields MUST NOT be present; the Path header field MUST NOT
>>- contain a "POSTED" <diag-keyword>; and any of the following
>>- mandatory header fields MAY be omitted: Message-ID, Date, and
>>- Path. In all other respects, a proto-article MUST be a valid
>>- Netnews article. In particular, the header fields which may be
>>- omitted MUST NOT be present with invalid content.</t>
>>+ except that the Injection-Info and Xref header fields MUST NOT
>>+ be present; the Path header field MUST NOT contain a "POSTED"
>>+ <diag-keyword>; and any of the following mandatory header
>>+ fields MAY be omitted: Message-ID, Date, and Path. In all other
>>+ respects, a proto-article MUST be a valid Netnews article. In
>>+ particular, the header fields which may be omitted MUST NOT be
>>+ present with invalid content.</t>
> I would prefer a "SHOULD NOT contain a "POSTED" <diag-keyword>". No
> interoperability arises if a "POSTED" appears twice in a Path, though it
> may well be a cause for suspicion, and even for over-zealous agents to
> reject it.
I think SHOULD NOT is the worst thing we could say here; I think it should
either be MUST NOT so that parsers can rely on one and only one POSTED
diag, or we should remain quiet on it entirely and allow multiple POSTED
diags and expect people to do the right thing. SHOULD NOT leaves the
matter ambiguous for everyone and seems like a breeding point for later
arguments.
I'm leaning towards the latter, since otherwise we have to tell people to
throw out trace information that could help catch loops.
> Generally, I prefer to preserve all evidence from earlier Paths, for the
> netkops to interpret as they will (whether or not this results in multiple
> POSTEDs).
Yup.
>>+ <section anchor="multi-injection"
>>+ title="Multiple Injection of Articles">
>>+ <t>Under some circumstances (posting to multiple disjoint
> ^
> supposedly
Well, no, if the networks weren't disjoint, the posting agent wouldn't
need to offer the same article to multiple injecting agents. This
parenthetical is talking about the motivations, not the problems.
Instead, I added this to the end sentence of that paragraph and now have:
In this unusual case, the goal is to not create multiple
independent articles but rather to inject the same article at
multiple points and let the normal duplicate suppression
facility of Netnews (see <xref target="history" />) ensure that
any given agent accepts the article only once, even if
supposedly disjoint networks have unexpected links.</t>
>>+ <t>Multiple injection of an article listing one or more
>>+ moderated newsgroups in its Newsgroups header field SHOULD only
> ^^^^^^^^^^^
> SHOULD ONLY
>>+ be done by a moderator and MUST only be done after the
> ^^^^^^^^^
> MUST ONLY
SHOULD ONLY and MUST ONLY are not RFC 2119 keywords, and hence I don't
capitalize the only.
>>+ proto-article is approved for all moderated groups to which it
> ^^
> has been
>>+ is to be posted and has an Approved header field (see <xref
>>+ target="moderator" />)....
Changed.
>>+ <t>It MUST reject any article that has already been accepted.
>>+ If it implements the mechanism described in <xref
> ^^^^^^^^^^^^^
> one of the mechanisms
>>+ target="history" />, this means that it MUST reject any
>>+ article whose date falls outside the cutoff interval since it
>>+ won't know whether such articles had been accepted previously
>>+ or not.</t>
Changed in both places.
--
Russ Allbery (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/>