[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1416 Injection-Date: current wording proposal (corrected)
In <87slaj6hby.fsf@xxxxxxxxxxxxxxxxxxxxx> Russ Allbery <rra@xxxxxxxxxxxx> writes:
>Gr. Ignore the previous version of this message. Saving the file before
>regenerating the diff is useful. Please ignore the previous version and
>use this one instead.
OK, I have finally got around to reading the whole of this. Many of my
points are minor textual niggles, but some are quite substantive.
>--- usepro.xml 2007-02-19 22:20:06.000000000 -0800
>+++ usepro-1416.xml 2007-04-28 19:30:11.000000000 -0700
>@@ -446,6 +447,68 @@
>
>+ <section anchor="history"
>+ title="Article History and Duplicate Suppression">
>+
>+ <t>Relaying and serving agents therefore MUST keep a record of
>+ articles they have already seen and use that record to reject
>+ additional offers of the same article. This record is called the
>+ history file or database.</t>
^^^^^^^
"history"
{since you have jsut defined a new term}
>+
>+ <t>Agents that enforce such a cutoff MAY then drop records of
>+ articles that had dates older than the cutoff from their
>+ history databases. If such an article were offered to the
>+ agent again, it would be rejected due to the cutoff date, so
>+ the history record is no longer required to suppress the
>+ duplicate.</t>
>+
>+ <t>As an optimization for easier history database
>+ manipulation, agents MAY instead drop history records written
>+ longer ago than the cutoff interval plus one day. If this
>+ retention mechanism is used, the history retention period MUST
>+ be longer than the cutoff interval to allow for articles dated
>+ in the future unless the agent rejects all articles dated in
>+ the future. One day is the maximum allowed error into the
>+ future for article dates, so it is a convenient and safe
>+ extension for the retention interval.</t>
It takes a lot of VERY careful reading to spot the curicial diference
between those two cases (and Frank seems to have the same problem). I
therefore suggest the following alternative for the 2nd one:
Alternatively, agents MAY drop history records according to
the date when the article was received, in which case they
MUST retain them for 24 hours longer than the cutoff
interval, since the date that accompanies the article is
permitted to be up to 24 hours later than its actual time of
injection (see <xref duties-injecting>).
{BTW, I prefer using 24 hours rather than 1 day for such short time
intervals, especially since the discussion under duties-injecting speaks
of even shorter intervals}
>+ <t>This is just one implementation strategy for article history,
^^^^^^^^^^^^^^^^ ^^^^^^^^
These are just two strategies
>+ albeit the most common one. Relaying and serving agents are not
^^^
ones
>+ required to use this strategy, only to meet the requirement of not
>+ accepting an article more than once. ....
However, the next bit of the sermon is a bit overdone, and the use of
"default" seems not quite right:
>+ ......... However, implementors of
>+ general-purpose Netnews relaying and serving agents who do not
>+ have extensive experience with Netnews and the subtle effects of
>+ its flood-fill algorithm are encouraged to use the above algorithm
>+ by default.</t>
So I would suggest:
......... However, implementors are advised normally to use
these strategies, especially if they do not have extensive
experience with Netnews and the subtle effects of its flood-fill
algorithm.
>@@ -453,9 +516,33 @@
>
>+ applicable policies. They MUST NOT create an Injection-Info
^^
any
>+ header field; this header field will be added by the injecting
>+ agent.</t>
>+
>+ <t>If a proto-article contains both Message-ID and Date header
^ ^
the already
>+ fields, 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 the Date header field
>+ (representing the composition time of the proto-article) is more
>+ than a day in the past at the time of injection. If the
>+ proto-article is being sent to more than one injecting agent, see
^^^^
submitted
>+ <xref target="multi-injection" />.</t>
{Note that this paragraph might change if we adopt option IC rather than
IR}
>+
>+ <t>The Injection-Date header field is new in this revision of the
>+ Netnews protocol and is designed to permit the Date header field
^^^^^^
allow
>+ to hold the composition date (as defined in section 3.6.1 of <xref
^^^^^^^
recommended
>+ target="RFC2822" />), even if the proto-article is not injected
>+ for some time after its composition. However, note that all
>+ implementations predating this specification ignore the
>+ Injection-Date header field and use the Date header field in its
>+ stead for rejecting articles older than their cutoff (see <xref
>+ target="history" />), and injecting agents predating this
>+ specification do not add an Injection-Date header. Articles with
>+ a Date header field substantially in the past will still be
>+ rejected by implementations predating this specification,
>+ regardless of the Injection-Date header field, and may suffer poor
^ ^^^^
hence poorer
>+ propagation.</t>
>
>@@ -478,48 +565,70 @@
>
> <t>A proto-article has the same format as a normal article
>+ except that the Injection-Info and Xref header fields MUST NOT
>+ be present; the Path header field MUST NOT contain a "POSTED"
>+ <diag-keyword>; ........
I disagree with forbidding POSTED (already raised in a separate thread),
and am dubious about Xref ("SHOULD" would be quite strong enough).
>
> <t>If a posting agent intends to offer the same proto-article to
>+ multiple injecting agents, the header fields Message-ID, Date,
>+ and Injection-Date MUST be present and identical in all copies
>+ of the proto-article. See <xref target="multi-injection" />.</t>
^^^^^^^^^^^^^^^^^
it
>
>+ <section anchor="multi-injection"
>+ title="Multiple Injection of Articles">
>+ <t>Under some circumstances (posting to multiple disjoint
>+ networks, injecting agents with spotty connectivity, or
^
for
>+ redundancy, for example), a posting agent may wish to offer the
>+ same article to multiple injecting agents. In this unusual
>+ case, the goal is to not create multiple independent articles
>+ but rather to inject the same article at multiple points and let
>+ the normal duplicate suppression facility of Netnews (see
>+ <xref target="history" />) ensure that any given agent only
^^^^
>+ accepts the article once.</t>
^
only
>+
>+ <t>Whenever possible, multiple injection SHOULD be done by
>+ offering the same proto-article to multiple injecting agents.
>+ The posting agent MUST supply the Message-ID, Date, and
>+ Injection-Date header fields, and the proto-article offered to
^^^^^^^^^^^^^
proto-articles as
>+ each injecting agent MUST be identical.</t>
>+
>+ <t>In some cases, offering the same proto-article to all
>+ injecting agents may not be possible (such as when transferring,
^^^^^^^^^^^^
gatewaying
>+ after the fact, articles found on one Netnews network to
>+ another, unconnected one). .........
^^^^^^^^^^^^^^^^^^^^^^^^
another, supposedly unconnected, one
However, this does not really convey the scenario as it is anticipated to
occur. In essence, the first network is typically small and private and
the second network is usually large, and probably Usenet. And one does not
usually just "find" articles there - one usually placed them there
oneself.
So how about:
....... (such as when gatewaying, after the fact, articles
from a small private network, supposedly with no other
connections, to a larger network, such as Usenet). ......
>+ ... In this case, the posting agent MUST
>+ convert the article back into a proto-article before passing it
>+ to another injecting agent, but it MUST retain unmodified the
>+ Message-ID, Date, and Injection-Date header fields. It MUST NOT
>+ add an Injection-Date header field if it is missing from the
>+ existing article. It MUST remove any Xref header field and
^^^^ ^^^
MAY/SHOULD but
>+ either rename or remove any Injection-Info header field and
^
MUST
>+ other trace fields.</t>
^
(such as NNTP-Posting-Host and XTrace)
There is also the question of what to do about Path. My preference would
be for "MAY/SHOULD retain"
I think the next paragraph should be a NOTE. There is nothing normative
in it.
>+ <t>Multiple injection inherently risks duplicating articles.
>+ Multiple injection after the fact, by converting an article back
>+ to a proto-article and injecting it again, additionally risks
>+ loops, loss of trace information, and other problems and should
^
unintended reinjection into the same network,
>+ be done with care and only when there is no alternative. ......
In fact, it is usually "unintended reinjection" that is the cause of
"loops".
>+ <t>Multiple injection of an article listing one or more
>+ moderated newsgroups in its Newsgroups header field SHOULD only
>+ be done by a moderator and MUST only be done after the
>+ proto-article is approved for all moderated groups to which it
>+ is posted and has an Approved header field. .......
^ ^
to be (see <xref duties-moderator>)
>@@ -644,23 +753,24 @@
>
> <t>It MUST reject any proto-article that does not have the
> proper mandatory header fields for a proto-article; that has
>+ Injection-Info or Xref header fields; that has a Path header
^ ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
any field
>+ field containing the "POSTED" <diag-keyword>; or that is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>+ not syntactically valid as defined by <xref target="USEFOR"
>+ />. It SHOULD reject any proto-article which contains a
>+ header field deprecated for Netnews. It MAY reject any
^
(see e.g. <xref RFC2298>)
>+ proto-article that contains trace header fields indicating
^
(e.g. NNTP-Posting-Host or Xtrace)
>+ that it was already injected by an injecting agent that did
>+ not add Injection-Info or Injection-Date.</t>
>
> <t>It SHOULD reject any article whose Date header field is
> more than 24 hours into the future (and MAY use a margin less
> than 24 hours). It SHOULD reject any article whose Date
>+ header is too far into the past (older than the cutoff
^
field
>+ interval of a relaying agent the injecting agent is using, for
>+ example), .......
Would that apply to Injection-Date, if any? Or would you allow a stale
Date if there was a plausible Injection-Date?
>+ ...... since not all news servers support Injection-Date
>+ and only the injecting agent can provide a useful error
>+ message to the posting agent. This interval SHOULD NOT be any
>+ shorter than 72 hours into the past.</t>
Yes, I can accept the 72 hours in that last sentence. I could also accept
omitting the sentence entirely.
>
>@@ -704,8 +814,14 @@
>
>+ <t>If the proto-article already had an Injection-Date header
>+ field, it MUST NOT be modified or replaced. If the
>+ proto-article had both a Message-ID header field and a Date
>+ header field, an Injection-Date header field MUST NOT be
>+ added, since the proto-article may have been multiply injected
>+ by a posting agent that predates this standard. Otherwise,
>+ the injecting agent MUST add an Injection-Date header field
>+ containing the current date and time.</t>
That paragrpaph is one of the ones that would change if we adopt IC rather
than IR. ALternaitvely, one might consider s/MUST NOT be added/SHOULD NOT
be added/. My concern with the IR option is that it leaves no room for
some future day when everybody routinely implements Injection-Date and it
would be sensible for all injecting agents to add it regardless (unless
already present, of course).
>
>@@ -801,18 +917,15 @@
>+
>+ <t>It MUST reject any article that has already been
>+ successfully sent to it or that is dated older than its cutoff
>+ date, as described in <xref target="history" />.</t>
No, that won't work. You have not actually defined the term "cutoff date".
But, in any case even providing a "cutoff interval" is not a REQUIRTEMENT.
How about:
>+ <t>It MUST reject any article that has already been
successfully sent to it, or alternatively where its date
falls outwith any cutoff interval as described in <xref
history>.
>@@ -886,16 +999,13 @@
>
> <t>It MUST reject any article that has already been
>+ successfully sent to it or that is dated older than its cutoff
>+ date, as described in <xref target="history" />.</t>
Same problem - same cure.
I think some mention of Injection-Date also needs to be made in section
3.9.2 (incoming Gateways), though I am not quite sure what.
--
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@xxxxxxxxxxxxxxxx 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