From: Bruce Lilly (blilly@erols.com)
Date: Thu Apr 22 2004 - 10:23:32 CDT
Charles Lindsey wrote:
> Here are the changes to the draft to incorporate the Injection-Date
> header. In addition to what is shown here, all occurrences of
> "Injector-Info" are changed to "Injection-Info", and there are a few other
> consequential changes.
>
> Comments?
Our editor should not be introducing controversial syntax which has not
been discussed by the WG.
> 5.1. Date
>
> The Date-header contains the date and time that the article was
> prepared by the poster ready for transmission and SHOULD express the
> poster's local time. The content syntax makes use of syntax defined
> in [RFC 2822] (but see the revised definition of zone in section
> 2.4.3).
>
> header =/ Date-header
> Date-header = "Date" ":" SP Date-content
> Date-content = date-time
A general comment: the draft is already far too long; convoluted ABNF
such as the above could be replaced by
Date-header = "Date" ":" SP date-time
> | The date-time MUST NOT be more than 24 hours into the future
> | (injecting agents will reject such articles, possibly even when the
> | margin is less than 24 hours - see 8.2.2) and it SHOULD NOT be
> | inordinately far into the past. Relaying agents MUST NOT modify the
> | Date-header in transit.
> [Do you want me to be more specific about that "inordinately"?]
The whole of the text regarding past dates for this field is unnecessary
and inappropriate.
> 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.
> |
> | header =/ Injection-Date-header
> | Injection-Date-header
> | = "Injection-Date" ":" SP Injection-Date-content
> | *( ";" extension-parameter )
> | Injection-Date-content
> | = date-time
We have not discussed any "parameters". We have agreed to introduce the field
to convey the correct semantics which differ from the defined semantics for
the Date field, which the draft had previously used (with *no* "parameters").
> | An Injection-Date-header MUST NOT be added to an article except by an
> | injecting agent, hence it will never be present in a proto-article
> | (8.2.1). It MUST be added by each injecting agent but, once added,
> | it MUST NOT subsequently be changed or removed by any other agent,
> | even during reinjection (8.2.2).
[...]
> 6.19. Injection-Info
>
> | An Injection-Info-header MUST NOT be added to an article except by an
> injecting agent. Any Injection-Info-header present when an article
> | arrives at an injecting agent MUST be removed. In particular if, for
> | some exceptional reason, an article is being reinjected (8.2.2), the
> | Injection-Info-header will always relate to the latest injection (to
> | the extent that this happens, the Injection-Info-header can be
> | regarded as a variant header).
As noted elsewhere, "reinjection" has yet to be justified.
> 8.2. Duties of an Injecting Agent
>
> An Injecting Agent is responsible for taking a proto-article from a
> posting agent and either forwarding it to a moderator or injecting it
> into the relaying system for access by readers.
>
> As such, an injecting agent is considered responsible for ensuring
> that any article it injects conforms with the rules of this standard.
> It is also expected to bear some responsibility towards the rest of
> the network for the behaviour of its posters (and provision is
> therefore made for it to be easily contactable by email).
>
> In the normal course of events, an article that has already been
> | injected into a Netnews network will never pass through another
> | injecting agent. So, if an injecting agent receives an otherwise
> | valid article that has already been injected (as evidenced by the
> | presence of an Injection-Date-header, an Injection-Info-header, or
> | more thath one '%' path-delimiter in a Path-header) it MAY choose to
> | reject it, but otherwise SHOULD cause it to be relayed, as it stands,
> | by a relaying agent (8.3).
> |
> | Exceptionally, there may be good reasons to "reinject" an already
> | injected article. This standard does not prescribe any circumstances
> | in which such reinjection is to be considered legitimate (though some
> | possible examples are given below); rather this is a matter of policy
> | to be determined by the administrators of each injecting agent, who
> | have the responsibility to ensure that only articles consistent with
> | their policies are allowed to be reinjected. Nevertheless, in order
> | to preserve the integrity of the network, this standard does set out
> | the proper way to reinject.
> |
> | NOTE: Examples of some situations in which the policy of an
> | injecting agent might permit reinjection to occur:
> |
> | o an article injected by another injecting agent which was
> | temporarily unable to contact the relaying agent(s) with
> | which it normally peered;
Injecting agents don't "peer" with relaying agents. They are different
types of agents, not peers.
> | o an attempt to relay by a site which only had permission to
> | inject (whether due to some misunderstanding between the
> | sites or as part of some backup relaying mechanism);
Again, different agents are involved. If a proto-article is involved (i.e.
a message which has never been injected), then injection, not relaying, is
the appropriate action. If it is instead an article (i.e. it has already
been injected), then relaying is the appropriate action -- and is performed
by a different agent.
> | o an article which had been gatewayed out of Netnews into
> | some other medium, and then back again into the same, or a
> | different, Netnews network.
This possibly warrants further discussion, but it seems that the appropriate
behavior would be rejection by the x->news gateway.
> 8.2.2. Procedure to be followed by Injecting Agents
>
> An injecting agent receives proto-articles from posting and followup
> agents. It verifies them, adds headers where required, and then
> either forwards them to a moderator or injects them by passing them
> to serving or relaying agents.
>
> | Exceptionally, it MAY reinject an article, perhaps as a part of some
> | complex gatewaying process (in which case it will add a further '%'
> path-delimiter to the Path-header). It MUST NOT forward an already
> injected article to a moderator.
That is inconsistent; posting and followup agents produce proto-articles,
not articles. Relaying agents do not transfer articles to injecting agents.
Exactly where is an injecting agent supposed to get an article (N.B. not a
proto-article)?
> An injecting agent processes articles as follows:
Per the text above, it processes *proto-articles*, not articles.
> 1. It MUST remove any Injection-Info- or Complaints-To-header already
> present (though it might be useful to copy them to suitable X-
> headers). It SHOULD likewise remove any NNTP-Posting-Host or other
> undocumented tracing header.
If the "header" is undocumented, how can it be defined as "tracing", and
how is an injecting agent supposed to know about it?
> | 3. It SHOULD reject any article whose Date-header (5.1) is more than
> | 24 hours into the future (and MAY use a margin less than that 24
> | hours). It MUST, except when reinjecting, reject any article with
> | an Injection-Date-header already present (and SHOULD do likewise
> | with any NNTP-Posting-Date-header). It MAY when reinjecting, but
> | only if there is no Injection-Date-header present, reject any
> | article whose Date-header appears to be stale (e.g. more than 72
> | hours into the past).
This may be a problem for FAQ and similar articles which are posted
periodically, often with no change in content (and hence a Date field
with date-time well in the past).
> | 4. It MUST reject any article that does not have the correct
proto-article, not article.
> | mandatory headers for a proto-article (or, when reinjecting, all
> | the mandatory headers other than Injection-Date), or which
> contains any header that does not have legal contents. It SHOULD
> reject any article which contains any header deprecated for
> Netnews (4.2.1).
"legal" is rather vague. "SHOULD" may be too weak in the case of
Disposition-Notification-To.
> 5. If the article is rejected (for reasons given above, or for other
proto-article, not article.
> formatting errors or matters of site policy) the posting agent
> SHOULD be informed (such as via an NNTP 44x response code) that
> posting has failed and the article MUST NOT then be processed
> further.
ITYM 441 rather than 44x.
> 6. The Message-ID, Date and From-headers (and their contents) MUST be
> | added when not already present (but that situation could not arise
> | during reinjection).
Exactly where is an injection agent supposed to come up with content
for a From field?
> 7. A Path-header with a tail-entry (5.6.3) MUST be correctly added if
> not already present (except that it SHOULD NOT be added if the
> | article is to be forwarded to a moderator). During reinjection,
> | the existing Path-header SHOULD be retained.
To improve clarity and avoid confusion and awkward wording, it would
be best to include forwarding via email to moderators in the definition
of an injecting agent. And the determination of whether the agent is
forwarding or injecting should be described early. Then the steps taken
for the two processes can be described independently.
> 8. The path-identity of the injecting agent with a '%' path-delimiter
> (5.6.2) MUST be prepended to the Path-header; moreover, that
> path-identity MUST be an FQDN mailable address (5.6.2).
That warrants examination of the full draft text.
> 9. An Injection-Info-header (6.19) SHOULD be added, identifying the
> trusted source of the article, and a suitable Complaints-To-header
> (6.20) MAY be added (except that these two headers MUST NOT be
> added if the article is to be forwarded to a moderator).
More awkward wording due to lack of early mention of forwarding.
> 10.The injecting agent MUST NOT alter the body of the article in any
> | way. It MAY, except when reinjecting, add other headers not
> | already provided by the poster, but SHOULD NOT alter, delete, or
> reorder any existing header, with the specific exception of
> "tracing" headers such as Injection-Info and Complaints-To, which
> are to be removed as already mentioned.
Conflicts with numbered paragraph 1.
> 11.If the Newsgroups-header contains no moderated groups, or if it
> | contains an Approved-header, the injecting agent MUST then add an
> | Injection-Date-header (5.7) if one is not already present, but it
> | MUST NOT alter, or remove, an already present Injection-Date-
> | header (and likewise SHOULD NOT alter, or remove, an already
> | present NNTP-Posting-Date-header). Finally, it forwards the
> article to one or more relaying or serving agents.
This is a big problem in the overall design (or lack thereof); how
exactly is an injecting agent supposed to be able to determine which
newsgroups are moderated? Isn't NNTP-Posting-Date one of those undocumented
tracing "headers" that the injecting agent was supposed to have removed
in step 1?
> 12.Otherwise, when the Newsgroups-header contains one or more
> moderated groups and the article does NOT contain an Approved-
See above w.r.t. moderated groups.
> header, the injecting agent MUST forward it to the moderator of
> the first (leftmost) moderated group listed in the Newsgroups-
> header via email. There are two possibilities for doing this:
How does the injecting agent determine the email address of the moderator?
What happens if there is more than one moderator for a given newsgroup?
> (a) The complete article is encapsulated (headers and all) within
> the email, preferably using the Content-Type
> "application/news-transmission" (6.21.4.1) with any usage
> parameter set to "moderate". Moreover, there SHOULD NOT be
> more than one encapsulated article within the one email.
> This method has the advantage of removing any possible
> conflict between Netnews and Email headers, or of changes to
> those headers during transport through email.
>
> (b) The article is sent as an email as it stands, with the
> addition of such extra headers (e.g. a To-header) as are
> necessary for an email.
>
> Although both of these methods have seen use in the past, the
> preponderance of current usage on Usenet has been for method (b)
> and many moderators are ill-prepared to deal with method (a).
> Therefore, method (a) SHOULD NOT be used until such time as the
> majority of moderators are able to accept it.
Shouldn't there be a statement to the effect that moderators SHOULD
prepare to accept method (a)? Otherwise "such time" will be approximately
never.
> 13.This standard does not prescribe how the email address of the
> moderator is to be determined, that being a matter of policy to be
> arranged by the agency responsible for the oversight of each
> hierarchy. Nevertheless, there do exist various agents worldwide
That is a serious weakness in the design.
> which provide the service of forwarding to moderators, and the
> address to use with them is obtained as follows:
>
> (a) Each '.' in the newsgroup-name is replaced with a '-'.
>
> (b) The result of these operations is used as the local-part of
> the mailbox of the agent. For example, articles intended for
> "news.announce.important" would be emailed to "news-
> announce-important@forwardingagent.example".
If an injecting agent is to be permitted to mail to such a forwarding
agent rather than directly to the moderator, the text in earlier paragraphs
should so indicate.
> 8.4. Duties of a Serving Agent
>
> A serving agent processes articles as follows:
>
> | 2. It MUST examine the Injection-Date-header (or, if that is absent,
> | the Date-header) and reject the article as stale (5.7) if that
> | predates the earliest articles of which it normally keeps record,
> | or if it is more than 24 hours into the future (the margin MAY be
> | less than that 24 hours).
Do serving agents "reject" articles, or do they simply fail to store
them?
> 8.5. Duties of a Posting Agent
>
> A Posting Agent is used to assist the poster in creating a valid
> proto-article and forwarding it to an injecting agent.
>
> Postings agents SHOULD ensure that proto-articles they create are
> valid news articles according to this standard and other applicable
proto-articles, not articles.
> | policies. In particular, they MUST NOT create any Injection-Date-,
> | Injection-Info- or Complaints-To-header.
>
> Posting agents meant for use by ordinary posters SHOULD reject any
> attempt to post an article which cancels or Supersedes another
> article of which the poster is not the author.
Why is "Supersedes" capitalized?