From: John Stanley (stanley@peak.org)
Date: Mon Feb 02 2004 - 13:12:55 CST
Russ Allbery (rra@stanford.edu):
>Usenet wants the Date header to be the injection time, not the time at
>which the message was written, for protocol reasons.
USENET appears to want the date the article was written by the poster,
which is what most people would consider the "time that the article
was prepared by the poster ready for transmission". I would certainly
call any article that is written and posted "offline" was prepared for
transmission at the time it was posted offline, not the time the system
next came online to talk to the injecting agent.
If we want to rewrite the definition of the Date header to be the
injection time, then now is the time to do it, so to speak.
5.1. Date
The Date-header contains the date and time that the article was
prepared by the poster ready for transmission and SHOULD express the
poster's local time. ...
...
In order to prevent the reinjection of expired articles into the news
stream, relaying and serving agents MUST refuse "stale" articles
whose Date-header predates the earliest articles of which they
normally keep record, or which is more than 24 hours into the future
(though they MAY use a margin less than that 24 hours). Relaying
agents MUST NOT modify the Date-header in transit.
The issue is in 8.2.2, which covers the duties of the injecting agent,
not the relaying or serving agents.
The reason given for keeping the time for rejection short is that the
longer the time required, the longer the history file must be.
However, in 8.2.1:
... A proto-article has the same format as a normal article
except that some of the following mandatory headers MAY be omitted:
Message-Id-header, ...
So, we are talking about an article which may have a Date header but no
message id. A history file is useless in this context, since there is no
reasonable way for the injector to keep track of id-less articles. It
might be argued that a hash of the article body would be sufficient to
detect dupes, but it is possible for the same body to appear in more than
one article (RFC and CFV posted to bypass Q5, e.g.). Hashing the entire
proto-article would be required, but I don't know if this would be broken
by any permissiveness we currently have in the draft.
If hasing the entire article is required to implement the injecting agent
history mechanism, then we can certainly assume that this history file
will be considerably smaller than a relaying agent's, since the injector
deals only with articles it injects and not everything else on the wire.
It can be longer in time than the relaying agents with much less impact on
the system.
If we want the Date header to be injection time, then we must modify
8.2.1 to say that Date is prohibited, and 8.2.2 to say that it is the
duty of the injector to insert the date always. Certainly, this is one
way to solve the issue of how far into the past an injector should
allow the date header to be in a proto-article. It also solves the issue
of how far into the future. :-) Does it fit with current practice and
current posting agents? Does it fit with user expectations for this
header?
(Another example of "offline" which is not truly "offline": many years
ago, I was using a news server which suffered a lot of failures in
posting. History files full, rebuilding history, socket timeouts, etc.
At that time, I got around the problem by creating a local queue of
proto-articles which were "posted" by a demon that tried every hour or
so. Clearly, those proto-articles were "ready for transmission" at the
time I wrote them, even though it was sometimes a day or more before
they actually got injected.
Although this was many years ago, the news server I am using now has
the same issues, and I am almost at the point I am going to set up
the old queue system.)