[#1416] Who adds Ijection-Date When?

["Charles Lindsey" <[e-mail]>]

In <[e-mail]> [e-mail] writes:

>    Date: Saturday, November 10, 2007 @ 11:48:28
>  Author: eagle
>Revision: 3224

>Make usepro-09.

>Modified:
>  docs/usefor/usepro.xml

>Modified: docs/usefor/usepro.xml
>===================================================================
>--- docs/usefor/usepro.xml	2007-11-10 01:20:34 UTC (rev 3223)
>+++ docs/usefor/usepro.xml	2007-11-10 19:48:28 UTC (rev 3224)

OK, nice to see some action. It's been a quiet summer (I have found lots
off other things to do) but we really need to get back to this.

Issue 1416 is the major outstanding item. I posted a sunnary of where we
were at in http://www.imc.org/ietf-usefor/mail-archive/msg04240.html, and
Russ agreed that it was a fair summary.

I repeat that text here:



The main outstanding matter is Issue #1416, which I shall now try to
summarize as I see it.

Essentially, we have to choose between two options, which we have in the
past named "IR" and "IC". The current text reflects IR. The differences
relate to when an Injection-Date header MUST/MUST NOT/Whatever be added by
Posting and Injection agents.

Option IR
---------

Adding Injection-Date by Posting agent, according to headers present in
proto-article and intention wrt multiple injection:

						MUST	MUSTNOT	SHOULD	MAY
Multiple injection (also requires Msgid & Date)	YES
"Reinjection" (aka "gatewaying after the fact")		YES
Message-ID and stale Date present				YES
Message-ID _and_ Date present						YES
Message-ID or Date or both absent					???

[Where I believe "???" should be "YES", but text doesn't actually say so]

Adding Injection-Date by Injecting agent, according to headers present in
incoming proto-article:

						MUST	MUSTNOT	SHOULD	MAY
Injection-Date already present				YES
Message-ID _and_ Date present				YES
Message-ID or Date or both absent		YES

Option IC
---------

Adding Injection-Date by Posting agent, according to headers present in
proto-article and intention wrt multiple injection:

						MUST	MUSTNOT	SHOULD	MAY
Multiple injection (also requires Msgid & Date)	YES
"Reinjection" (aka "gatewaying after the fact")		YES
Message-ID and stale Date present				YES
All other cases (Message-ID or Date or neither)				YES

Adding Injection-Date by Injecting agent, according to headers present in
incoming proto-article:

						MUST	MUSTNOT	SHOULD	MAY
Injection-Date already present				YES
All other cases (Message-ID or Date or neither)	YES


Discussion of IR
----------------

The essential difference is the rule that Injecting agents MUST NOT add
Injection-Date if _both_ Message-ID and Date are already present, and MUST
add it otherwise. This rule is counter-intuitive and confusing.

A consequence of the rule is that it will forever remain the case that
some articles will never acquire an Injection-Date (those where the
Posting agent provides both of Message-ID and Date).

Russ counters this by claiming that, in time, Posting agents will learn to
add the Injection-Date themselves, but this is only a "MAY" as specified,
and I remain unconvinced that implementors will take the hint.

So if we decide to remain with Option IR, I would want to see a much
stronger wording in place of that "MAY" (not necessarily a "SHOULD", but
some indication that it was intended to become standard practice).

Moreover, there is a danger that Posting agent implementors will do it
wrongly, adding the Injection-Date _before_ they are sure they have a
working connection to an Injecting agent. Yes, multiple injectors have to
get this right, but people doing multiple injection can be expected to
have a higher level of "clue".

Discussion of IC
----------------

We distinguish between "OLD" agents which are unaware of our new standard,
and "NEW" agents which implement it as written.

The following scenario, which I understand to be the case Russ is worried
about, illustrates the problem with IC. If anyone knows of a different, or
a simpler, scenario that exhibits the same problem, then please speak up.

Day 0	OLD Posting agent P composes an article (with Date: Day0) and some
	Message-ID. P is in the habit of multi-injecting.
Day 1	P injects the message to (OLD or NEW) Injecting agent A (the ACopy).
Day 2	P injects the message to NEW Injecting agent B (the BCopy); B adds
	Injection-Date: Day2.
meanwhile:
Day 1	The ACopy propagates rapidly and arrives at NEW Serving agent C,
	which stores it and puts it in its history file (which it
	normally retains for 7 days).
Day 2	The BCopy arrives at Relaying agent D, which promptly breaks and goes
	offline for 7 days (or otherwise causes that propagation delay).
Day 8	C removes the ACopy from its history file.
Day 9	D wakes up, embarks on a massive catchup, and releases the BCopy.
Day 9	The BCopy arrives at C, which observes that it is (just) within 7
	days of its Injection-Date, and so accepts and stores it again.

	Which is, of course, a Bad Thing. C's users will say "Didn't I
	already see that article last week?" But it is no worse than that;
	in particular, I cannot see any way that looping could arise.

Observe that this Bad Thing would not have happened if:
	. B had been an OLD agent
	. C had been an OLD agent
	. P had been a NEW agent
	. The delay at D had been 1 day less
	. The delay at D had been 1 day more

So yes, the Bad Thing would not have happened on the current network, and
it will not happen when the whole network is NEW - so it is a transitional
problem whilst OLD and NEW agents are still around. Moreover, you might
think the whole scenario is somewhat artificial (hence the invitation to
propose more realistic scenarios).

So the choice you people have to make is between this possible, but rare,
Bad Thing, and the counter-intuitive properties of option IR.

We have discussed this extensively, and I don't think there is much more
to be said. I therefore request our Chair to conduct a Head Count on IR
versus IC.

I think we can assume that Russ will vote for IR and I will vote for IC,
so it is the rest of you that will effectively decide it.

For details of bits of the draft that wouild be affected if we decide to go
with IC, please refer to
http://www.imc.org/ietf-usefor/mail-archive/msg04240.html.


There are several other issues outstanding, of which #1415 is the most
important (but nowhere as controversial as #1416).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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