Subject: #1335 Injection-date

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Jul 2006 01:45:20 -0700

Current text (omitting the comments about MUST, which are in closed 
issue #1088):

3.2.1.  Injection-Date

   The Injection-Date header field contains the date and time that the
   article was injected into the network.  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 news server.

 Ralph Babel said:

 > If they have already "expired", then "reinjection"
 > isn't an issue. Quite the contrary: once everybody starts
 > depending on "Injection-Date" and - ignoring "Date" - uses
 > it to check against the history cut-off limit, reinjection
 > of stale articles (after stripping "Injection-Date",
 > of course) will become a lot _easier_.
 >
 > I thought its purpose was to aid in the _propagation_ of
 > articles that are "injected" a long time _after_ their
 > "Date" header field has been added locally by the client.

Suggested rephrase of last sentence:

   Its purpose is to allow news servers that try to reject "stale" 
articles to check
   a date field that was added by a news server at injection time, 
rather than the
   Date: field that is added by the user agent at message composition time.

Works?

                       Harald

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 27 Jul 2006 11:07:39 -0400

>    Date: field that is added by the user agent at message composition time.

Using Injection-date to prevent re-injection as described in USEPRO
depends that all agents work as described and never alter or remove
the header.  This is not robust, and I don't see how it offers significant 
improvement over Date:.

There is language that an "injecting agent" receiving a message with an 
injection-date, SHOULD cause the message to be relayed.

USEPRO is not germane at the momenet, but all the distinctions of "agent"
are meaningless and not helpful.  The way that INN relays messages
is to accept them.  It sends messages from the same storage as they exist
for reading.

So USEPRO in 7.2 says that INN, as the injecting agent, "SHOULD cause [the
message] to be relayed" (note no mention of rejecting stale Injecting dates).

And in 7.2.2. #3 it says an injecting agent MUST reject any article with such a 
field, except when re-injecting. (Which is a meaningless tautology, I suppose.)

Then in 7.3 #2 it says that INN, as relaying agent, MUST examine Injection-Date:
and reject as stale if that predates the local cutoff.

So, USEPRO states "SHOULD cause to be relayed" + "MUST reject" for those
stale injection-dates.

Right.  Who thought this scheme through?

Again....

Chair, we are chartered to conclude ALL OF THIS, USEPRO TOO, by April 2005.

How can we be continuing?

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 29 Jul 2006 22:19:19 GMT

>the header.  This is not robust, and I don't see how it offers significant 

USEPRO clearly states that removing Injection-Date is a MUST NOT (indeed
changing ANY non-variant header during relaying is a MUST NOT).

>injection-date, SHOULD cause the message to be relayed.

No, that "SHOULD" only comes into effect if, when reinjecting (where an
Injection-Date may be already present), the injecting agent chose (MAY)
not to reject it. A very specific and special circumstance.

>is to accept them.  It sends messages from the same storage as they exist

The effect is to be as if injecting, relaying and storing were separate
processes that have to be gone through. INN and other servers may well
combine these operations for convenience of implementation. But in CNews,
to take a contrary example, the injection and the subsequent relaying are
indeed separate operations. Also, there are plenty of relayers around that
do not store.

>message] to be relayed" (note no mention of rejecting stale Injecting dates).

The word "INN" does not occur in that section.
And there is nothing to say that the relaying agent may not fail to relay
for some reason.

>field, except when re-injecting. (Which is a meaningless tautology, I suppose.)

No, an explicit exception for an explicit case.

>and reject as stale if that predates the local cutoff.

Again, the word "INN" does not occur in that section

-- 
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: [email-masked]      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

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 29 Jul 2006 21:39:59 GMT

>Works?

I don't like the word "try". Rejecting stale articles is a MUST in USEPRO
(you can end up with looping if you omit that check).

So it should be:

   Its purpose is to enable news servers, when checking for "stale"
   articles [refer to USEPRO if you like], to use a <date-time> that was
   added by a news server at injection time rather than one added by the
   user agent at message composition time.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 29 Jul 2006 21:39:59 GMT

So it should be: