[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1416 Injection-Date: current wording proposal (corrected)
Charles Lindsey <chl@xxxxxxxxxxxxxxxx> writes:
> 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.
Changes snipped without remark have been accepted and made in my draft
text.
>> + <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}
I couldn't resist wordsmithing this a bit, but I think I retained the
intent. I now have:
o Alternatively, agents MAY drop history records according to the
date when the article was first seen by that agent rather than the
date of the article. In this case, the history retention interval
MUST be at least 24 hours longer than the cutoff interval to allow
for articles dated in the future. This interval matches the
allowable error in the date of the article (see Section 3.5).
>> + <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.
I now have:
These are just two implementation strategies for article history,
albeit the most common ones. Relaying and serving agents are not
required to use these strategies, only to meet the requirement of not
accepting an article more than once. However, these strategies are
safe and widely deployed and implementors are encouraged to use one
of them, especially if they not have extensive experience with
Netnews and the subtle effects of its flood-fill algorithm.
going with explaining why this is a good idea rather than just emphasizing
it.
>> @@ -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).
I'm not sure we've reached a conclusion on those other threads yet. So
far, I've not made any changes here.
>> <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
This was intentional. It reads awkwardly, but it's clearer. "It" is
somewhat ambiguous and I kept stumbling over thinking it referred to the
posting agent for a moment.
>> + <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>
I'm intentionally not pluralizing proto-article, since the whole point is
that there's only one of them, sent to multiple locations. Adding "as"
does make the sentence read better to me, though, so I did that.
>> + <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
Okay.
> 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). ......
Well, that's one of the cases where offering the same proto-article to all
injecting agents *is* possible, normally, so I'm not sure it's a great
example. That's the use case where I really wish people would just use
normal multiple injection.
>> + ... 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"
As discussed above, I haven't made any changes here.
>> @@ -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
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Likewise here.
>> + 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>)
RFC 2298 is obsolete, so I don't really want to generate even an
informative reference to it, and the superseding RFC (RFC 3798) makes no
mention of Netnews, so I'm not sure this is a great example or
particularly helpful for the reader.
>> + proto-article that contains trace header fields indicating
> ^
> (e.g. NNTP-Posting-Host or Xtrace)
Added just NNTP-Posting-Host, since USEFOR already mentions and explicitly
obsoletes it.
>> + 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?
Covered in another thread.
>> + <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>.
I now have:
3. It MUST reject any article that has already been successfully
sent to it, which may include rejecting articles whose dates fall
outside a cutoff interval as described in Section 3.3.
--
Russ Allbery (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/>