[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1416 Injection-Date: proposed diff
"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx> writes:
> Russ Allbery <rra@xxxxxxxxxxxx> writes:
>> 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).
Yeah, and the agent may want to allow for an injecting agent that doesn't
create Injection-Date. Okay, that makes sense.
> 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.
That sounds fine to me. I now have:
<t>Posting agents MAY add an Injection-Date header field to that
proto-article immediately before passing that proto-article to an
injection agent. They SHOULD do so if a Date header field
(representing the composition time of the proto-article) is
present in the proto-article and is more than a day in the past at
the time of injection. They MUST do so if the proto-article is
being submitted to more than one injecting agent; see <xref
target="multi-injection" />.</t>
I don't think we need to say that it's unusual, but I can add that if need
be.
>> 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.
Right, but either it's a normal relaying agent to relaying agent
connection that leaks, or he knew he was reinjecting. He may not know how
to configure it properly.
> 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.
This I do agree with.
> So the wording you have written in entirely correct, but I am not sure
> it is enforceable.
The person who takes an existing news message and reposts it is the person
who needs to take the necessary precautions, because they're the person
doing something outside of the regular Usenet protocol. However, I do
agree that it makes sense to make the whole system more robust against
people who do that without knowing what they're doing.
>> 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?
I don't override them, just restate them (I think). No, I don't have any
others in mind.
--
Russ Allbery (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/>