From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Thu Apr 29 2004 - 05:18:23 CDT
In <Pine.LNX.4.21.0404281537140.12471-100000@deathstar.prodigy.com> Usenet News Support <support@deathstar.prodigy.com> writes:
>On Fri, 16 Apr 2004, Charles Lindsey wrote:
>> 5.7. Injection-Date
>>
>> | The Injection-Date-header contains the date and time that the article
>> | was injected into the network (or more precisely, the time at which
>> | the injecting agent first offered it to a relaying agent, which might
>> | be some time later than when the injecting agent first began to
>> | process it). Its purpose is to prevent the reinjection into the news
>> | stream of "stale" articles which have already expired by the time
>> | they arrive at some relaying or serving agent.
>Let's start here... "the time at which the injecting agent first offered
>it to a relaying agent" is something no one will implement, and therefore
>we shoudn't specify. Taken literally it implies that the header should not
>be written until it is actually offered to another host, which in some
>cases may be hours or even days after receipt. I can't believe that it
>will be so implemented, I'd bet that it will be the date accepted and
>queued for relay.
No, I wrote that because I could see how to implement it, and circumstances
where it might be useful. Suppose someone runs a private newsserver on an
offline machine, but has arranged to peer with a site(s) to which he dials
in twice a day.
So he writes an article and injects it to his own server. It is now there,
and he can read it on his server (and so can anyone else with access to
that server). But it has no Injection-Date yet (and that cannot cause any
harm so far). Or, for convenience of implementation, it has a dummy
Injection-Date which can be overwritten later.
Now he dials in to his upstream and sets the relaying process in motion.
The relaying process looks at each article it is about to relay and, if
the Injection-Date is absent it creates it in the local copy before
relaying it. Hence every site that sees it on the wider Usenet will see
that Injection-Date, and moreover they will all see the same
Injection-date. But it will be up to 12 hours later that it would
otherwise have been.
Essentially, with this hack, the injecting function of this particular
server has been modified so that the process occurs in two stages - one
that is immediate for the local users and one that is postponed until the
first attempt to relay. Quite safe, and quite useful in that sort of
setup.
>> | This header is intended to replace the currently-used but nowhere-
>> | documented header "NNTP-Posting-Date", whose use is now deprecated.
>I'd bet that most people will simply use the existing code for the current
>header, which gets added when the article is accepted via POST regardless
>of relaying.
For those injecting agents which currently add NNTP-Posting-Date (which
AFAICS is only a minority of them), it is indeed a simple change to the
existing code.
>I agree with the intent of this header, but I doubt it will be implemented
>to the letter of what we specified, and I suggest that simply blessing the
>existing NNTP-Posting-Date header would work fine, given a few clear rules
>about not rewriting the header if it is present in the offered article.
We discussed this earlier, and the opinion was that the present header was
unsatisfactory for long term use because
a) It was nothing to do with NNTP
b) It was nothng to do with 'posting' (it is an odditiy of NNTP that
it uses the command POST in order to perform injection).
Moreover, we were also deprecating the continued use of NNTP-Posting-Host
in favour of the new Injection-Info header.
But I have no problem if, as an interim measure, people treat the
NNTP-Posting-Date the way they are now supposed to treat Injection-Date,
for the purpose of catching stale articles.
-- 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@clerew.man.ac.uk 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