[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1416 Injection-Date: proposed diff
In <87bqe0dsia.fsf@xxxxxxxxxxxxxxxxxxxxx> Russ Allbery <rra@xxxxxxxxxxxx> writes:
>"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.
Which is actually quite common. The injection agent creates the Message-ID
(which is can probably do more reliably than poorly configured user
agents, which have been known to create message-ids with "@localhost" in
them).
>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.
Yes, I agree that Injection-Date without Date would be totally bizarre,
but if it does no harm then there is no point in wording to forbid it,
which means people just start wondering why you did so. So it is better to
say
"Posting agents MAY, as part of the injection process (i.e. immediately
before passing that proto-article to an injection agent), add an
Injection-Date header field to that proto-article (though it would be
unusual to do so if Date and Message-ID fields were not also being
provided)."
Generally speaking (especially if we say with option IR) we should be
encouraging posting agents to take advantage of this new "MAY" feature,
and unnecessary "small print" will just put them off.
Of course we all agree that it MUST be done in the case of multiple
injection.
>> 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.
But two "offerings".
Hmmm! It just seems an odd piece of English to say "a single-object ...
MUST be identical".
>>>+ <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.
Small local networks with more than one site tend to be run in an
amateurish fashion. So the second guy, who caused the extra "leak", may
have been badly configured, or ignorant, or both. One of the benefits of
encouraging the first guy to include an Injection-Date and forbidding
anyone anywhere ever to remove it is that such leaks will do less harm.
So the wording you have written in entirely correct, but I am not sure it
is enforceable.
>> 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.
Yes, but are there any particular constraints you have in mind here,
bearing in mind that your wording has already overridden the usual
proto-article constraints of all (well nearly all) of the headers which
are mentioned in the Proto-articles section?
>>>@@ -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.
OK, I am happy with a weaker wording than "SHOULD", all the way down to no
wording at all.
>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.
Then maybe a NOTE somewhere to the effect that multiple POSTEDs may
sometimes be seen and that they cause no harm but may serve as an
indication of some unusual behaviour or malpractice.
>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>
OK.
--
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@xxxxxxxxxxxxxxxx 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