draft-ietf-usefor-usepro-10.txt   draft-ietf-usefor-usepro-11.txt 
Usenet Format Working Group R. Allbery, Ed. Usenet Format Working Group R. Allbery, Ed.
Internet-Draft Stanford University Internet-Draft Stanford University
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 (if approved) C. Lindsey
Intended status: Standards Track University of Manchester Intended status: Standards Track University of Manchester
Expires: February 4, 2009 August 3, 2008 Expires: February 23, 2009 August 22, 2008
Netnews Architecture and Protocols Netnews Architecture and Protocols
draft-ietf-usefor-usepro-10 draft-ietf-usefor-usepro-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 4, 2009. This Internet-Draft will expire on February 23, 2009.
Abstract Abstract
This document defines the architecture of Netnews systems and This document defines the architecture of Netnews systems and
specifies the correct manipulation and interpretation of Netnews specifies the correct manipulation and interpretation of Netnews
articles by software which originates, distributes, stores, and articles by software which originates, distributes, stores, and
displays them. It also specifies the requirements that must be met displays them. It also specifies the requirements that must be met
by any protocol used to transport and serve Netnews articles. by any protocol used to transport and serve Netnews articles.
Internet Draft Comments Internet Draft Comments
skipping to change at page 3, line 27 skipping to change at page 3, line 27
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 8 3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. General Principles . . . . . . . . . . . . . . . . . . . . 8 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 8
3.2. The Path Header Field . . . . . . . . . . . . . . . . . . 9 3.2. The Path Header Field . . . . . . . . . . . . . . . . . . 9
3.2.1. Constructing the Path Header Field . . . . . . . . . . 10 3.2.1. Constructing the Path Header Field . . . . . . . . . . 10
3.2.2. Path Header Field Example . . . . . . . . . . . . . . 11 3.2.2. Path Header Field Example . . . . . . . . . . . . . . 11
3.3. Article History and Duplicate Suppression . . . . . . . . 12 3.3. Article History and Duplicate Suppression . . . . . . . . 12
3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 13 3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 13
3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 14 3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Reinjection of Articles . . . . . . . . . . . . . . . 14 3.4.2. Multiple Injection of Articles . . . . . . . . . . . . 14
3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4. Construction of the References Header Field . . . . . 15 3.4.4. Construction of the References Header Field . . . . . 16
3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 16 3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 17
3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 18 3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 19
3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 19 3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 20
3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 21 3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 22
3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 22 3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 23
3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 22 3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 23
3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 24 3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 25
3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 25 3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 26
3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 25 3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 27
3.10.3. Gateway Example . . . . . . . . . . . . . . . . . . . 27 3.10.3. Gateway Example . . . . . . . . . . . . . . . . . . . 29
4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. application/news-transmission . . . . . . . . . . . . . . 29 4.1. application/news-transmission . . . . . . . . . . . . . . 30
4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 30 4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 31
4.3. application/news-checkgroups . . . . . . . . . . . . . . . 31 4.3. application/news-checkgroups . . . . . . . . . . . . . . . 32
5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 33 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Authentication and Authorization . . . . . . . . . . . . . 33 5.1. Authentication and Authorization . . . . . . . . . . . . . 34
5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 34 5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 35
5.2.1. The newgroup Control Message . . . . . . . . . . . . . 34 5.2.1. The newgroup Control Message . . . . . . . . . . . . . 35
5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 36 5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 37
5.2.3. The checkgroups Control Message . . . . . . . . . . . 36 5.2.3. The checkgroups Control Message . . . . . . . . . . . 37
5.3. The cancel Control Message . . . . . . . . . . . . . . . . 38 5.3. The cancel Control Message . . . . . . . . . . . . . . . . 39
5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 38 5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 39
5.5. The ihave and sendme Control Messages . . . . . . . . . . 39 5.5. The ihave and sendme Control Messages . . . . . . . . . . 40
5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 40 5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6.1. Compromise of System Integrity . . . . . . . . . . . . . . 41 6.1. Compromise of System Integrity . . . . . . . . . . . . . . 42
6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 42 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 43
6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 44
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1. Normative References . . . . . . . . . . . . . . . . . . . 45 8.1. Normative References . . . . . . . . . . . . . . . . . . . 46
8.2. Informative References . . . . . . . . . . . . . . . . . . 45 8.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Changes to the Existing Protocols . . . . . . . . . . 47 Appendix A. Changes to the Existing Protocols . . . . . . . . . . 48
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 48 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 51
1. Introduction 1. Introduction
1.1. Basic Concepts 1.1. Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing and
retrieving news "articles" whose format is defined in [USEFOR], and retrieving news "articles" whose format is defined in [USEFOR], and
for exchanging them amongst a readership that is potentially widely for exchanging them amongst a readership that is potentially widely
distributed. It is organized around "newsgroups", with the distributed. It is organized around "newsgroups", with the
expectation that each reader will be able to see all articles posted expectation that each reader will be able to see all articles posted
skipping to change at page 6, line 33 skipping to change at page 6, line 33
injecting agent and makes it available to readers. injecting agent and makes it available to readers.
A "user agent" is further distinguished into the roles of "posting A "user agent" is further distinguished into the roles of "posting
agent" and "reading agent". A "posting agent" is software which agent" and "reading agent". A "posting agent" is software which
assists in the preparation of a proto-article and then passes it to assists in the preparation of a proto-article and then passes it to
an injecting agent. A "reading agent" is software which retrieves an injecting agent. A "reading agent" is software which retrieves
articles from a serving agent for presentation to a reader. articles from a serving agent for presentation to a reader.
"Injecting" an article is the processing of a proto-article by an "Injecting" an article is the processing of a proto-article by an
injecting agent. Normally this action is done once and only once for injecting agent. Normally this action is done once and only once for
a given article. "Reinjecting" an article is passing an already- a given article. "Multiple injection" is passing the same article to
injected article to an injection agent. multiple injecting agents, either serially or in parallel, by one or
several posting agents.
A "gateway" is software which receives news articles and converts A "gateway" is software which receives news articles and converts
them to messages of some other kind (such as [RFC2822] mail them to messages of some other kind (such as [RFC2822] mail
messages), receives messages of some other kind and converts them to messages), receives messages of some other kind and converts them to
news articles, or conveys articles between two separate Netnews news articles, or conveys articles between two separate Netnews
networks. networks.
2. Transport 2. Transport
The exact means used to transmit articles from one agent to another The exact means used to transmit articles from one agent to another
skipping to change at page 13, line 37 skipping to change at page 13, line 37
Netnews and the subtle effects of its flood-fill algorithm. Netnews and the subtle effects of its flood-fill algorithm.
3.4. Duties of a Posting Agent 3.4. Duties of a Posting Agent
A posting agent is the component of a user agent that assists a A posting agent is the component of a user agent that assists a
poster in creating a valid proto-article and forwarding it to an poster in creating a valid proto-article and forwarding it to an
injecting agent. injecting agent.
Posting agents SHOULD ensure that proto-articles they create are Posting agents SHOULD ensure that proto-articles they create are
valid according to [USEFOR] and any other applicable policies. They valid according to [USEFOR] and any other applicable policies. They
MUST NOT create any Injection-Date or Injection-Info header fields; MUST NOT create any Injection-Info header field; this header field
these headers will be added by the injecting agent. may only be added by the injecting agent.
If the proto-article already contains both Message-ID and Date header
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. They MUST do so if the
proto-article is being submitted to more than one injecting agent;
see Section 3.4.2.
The Injection-Date header field is new in this revision of the
Netnews protocol and is designed to allow the Date header field to
hold the composition date (as recommended in section 3.6.1 of
[RFC2822]), even if the proto-article is not to be 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 Section 3.3), 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 hence may suffer
poorer propagation.
Contrary to [RFC2822], which implies that the mailbox or mailboxes in Contrary to [RFC2822], which implies that the mailbox or mailboxes in
the From header field should be that of the poster or posters, a the From header field should be that of the poster or posters, a
poster who does not, for whatever reason, wish to use his own mailbox poster who does not, for whatever reason, wish to use his own mailbox
MAY use any mailbox ending in the top level domain ".invalid" MAY use any mailbox ending in the top level domain ".invalid"
[RFC2606]. [RFC2606].
Posting agents meant for use by ordinary posters SHOULD reject any Posting agents meant for use by ordinary posters SHOULD reject any
attempt to post an article which cancels or Supersedes another attempt to post an article which cancels or Supersedes another
article of which the poster is not the author or sender. article of which the poster is not the author or sender.
skipping to change at page 14, line 15 skipping to change at page 14, line 35
3.4.1. Proto-articles 3.4.1. Proto-articles
A proto-article is an article in the format used by a posting agent A proto-article is an article in the format used by a posting agent
for offering to an injecting agent. It may omit certain header for offering to an injecting agent. It may omit certain header
fields which can be better-supplied by the injecting agent and will fields which can be better-supplied by the injecting agent and will
not contain header fields that are added by the injecting agent. A not contain header fields that are added by the injecting agent. A
proto-article is only for transmission to an injecting agent and proto-article is only for transmission to an injecting agent and
SHOULD NOT be transmitted to any other agent. SHOULD NOT be transmitted to any other agent.
A proto-article has the same format as a normal article except that A proto-article has the same format as a normal article except that
the Injection-Date, Injection-Info, and Xref header fields MUST NOT the Injection-Info and Xref header fields MUST NOT be present; the
be present; the Path header field MUST NOT contain a "POSTED" <diag- Path header field MUST NOT contain a "POSTED" <diag-keyword>; and any
keyword>; and any of the following mandatory header fields MAY be of the following mandatory header fields MAY be omitted: Message-ID,
omitted: Message-ID, Date, and Path. In all other respects, a proto- Date, and Path. In all other respects, a proto-article MUST be a
article MUST be a valid Netnews article. In particular, the header valid Netnews article. In particular, the header fields which may be
fields which may be omitted MUST NOT be present with invalid content. omitted MUST NOT be present with invalid content.
If a posting agent intends to offer the same proto-article to If a posting agent intends to offer the same proto-article to
multiple injecting agents, the header fields Message-ID and Date MUST multiple injecting agents, the header fields Message-ID, Date, and
be present and identical in all copies of the proto-article. Injection-Date MUST be present and identical in all copies of the
proto-article. See Section 3.4.2.
3.4.2. Reinjection of Articles 3.4.2. Multiple Injection of Articles
A given article SHOULD be processed by an injecting agent once and Under some circumstances (posting to multiple disjoint networks,
only once. The Injection-Date or Injection-Info header fields are injecting agents with spotty connectivity, or for redundancy, for
added by an injecting agent and are not permitted in a proto-article. example), a posting agent may wish to offer the same article to
Their presence (or the presence of other unstandardized or obsolete multiple injecting agents. In this unusual case, the goal is to not
trace headers such as NNTP-Posting-Host, NNTP-Posting-Date, or create multiple independent articles but rather to inject the same
X-Trace) indicates that the proto-article is instead an article and article at multiple points and let the normal duplicate suppression
has already been processed by an injecting agent. A posting agent facility of Netnews (see Section 3.3) ensure that any given agent
SHOULD normally reject such articles. accepts the article only once, even if supposedly disjoint networks
have unexpected links.
In the exceptional case that an article needs to be reinjected for Whenever possible, multiple injection SHOULD be done by offering the
some reason (such as transferring an article from one Netnews to same proto-article to multiple injecting agents. The posting agent
another where those networks have no relaying agreement), the posting MUST supply the Message-ID, Date, and Injection-Date header fields,
agent doing the reinjection MUST convert the article back into a and the proto-article as offered to each injecting agent MUST be
proto-article before passing it to an injecting agent (such as by identical.
renaming the Injection-Info and Injection-Date header fields and
removing any Xref header field) and MUST perform the date checks on
the existing Injection-Date or Date header fields that would
otherwise be done by the injecting agent.
Reinjecting articles may cause loops, loss of trace information, and In some cases, offering the same proto-article to all injecting
other problems and should only be done with care and when there is no agents may not be possible (such as when gatewaying, after the fact,
available alternative. A posting agent that does reinjection is a articles found on one Netnews network to another, supposedly
limited type of gateway and as such is subject to all of the unconnected one). In this case, the posting agent MUST convert the
requirements of an incoming gateway in addition to the requirements article back into a proto-article before passing it to another
of a posting agent. 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 either rename or remove any
Injection-Info header field and other trace fields.
NOTE: 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, unintended repeat injection into
the same network, and other problems. It should be done with care
and only when there is no alternative. The requirement to retain
Message-ID, Date, and Injection-Date header fields minimizes the
possibility of a loop and ensures that the newly injected article
is not treated as a new, separate article.
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 has been
approved for all moderated groups to which it is to be posted and has
an Approved header field (see Section 3.9). Multiple injection of an
unapproved article intended for moderated newsgroups will normally
only result in the moderator receiving multiple copies, and if the
newsgroup status is not consistent across all injecting agents, may
result in duplication of the article or other problems.
3.4.3. Followups 3.4.3. Followups
A followup is an article that contains a response to the contents of A followup is an article that contains a response to the contents of
an earlier article, its precursor. In addition to its normal duties, an earlier article, its precursor. In addition to its normal duties,
a posting agent preparing a followup is also subject to the following a posting agent preparing a followup is also subject to the following
requirements. Wherever in the following it is stated that by default requirements. Wherever in the following it is stated that by default
a header field is said to be inherited from one of those header a header field is said to be inherited from one of those header
fields in the precursor, it means that its initial content is to be a fields in the precursor, it means that its initial content is to be a
copy of the content of that precursor header field (with changes in copy of the content of that precursor header field (with changes in
skipping to change at page 17, line 14 skipping to change at page 18, line 11
received by the serving agent. received by the serving agent.
An injecting agent processes proto-articles as follows: An injecting agent processes proto-articles as follows:
1. It SHOULD verify that the article is from a trusted source (by, 1. It SHOULD verify that the article is from a trusted source (by,
for example, relying on the authorization capability of the for example, relying on the authorization capability of the
underlying transport used to talk to the posting agent). underlying transport used to talk to the posting agent).
2. It MUST reject any proto-article that does not have the proper 2. It MUST reject any proto-article that does not have the proper
mandatory header fields for a proto-article; that has Injection- mandatory header fields for a proto-article; that has Injection-
Date, Injection-Info, or Xref header fields; that has a Path Info or Xref header fields; that has a Path header field
header field containing the "POSTED" <diag-keyword>; or that is containing the "POSTED" <diag-keyword>; or that is not
not syntactically valid as defined by [USEFOR]. It SHOULD syntactically valid as defined by [USEFOR]. It SHOULD reject
reject any proto-article which contains a header field any proto-article which contains a header field deprecated for
deprecated for Netnews. It MAY reject any proto-article that Netnews (see, for example, [RFC3798]). It MAY reject any proto-
contains trace header fields indicating that it was already article that contains trace header fields (e.g., NNTP-Posting-
injected by an injecting agent that did not add Injection-Info Host) indicating that it was already injected by an injecting
or Injection-Date. agent that did not add Injection-Info or Injection-Date.
3. It SHOULD reject any article whose Date header field is more 3. It SHOULD reject any article whose Injection-Date or Date header
than 24 hours into the future (and MAY use a margin less than 24 field is more than 24 hours into the future (and MAY use a
hours). It SHOULD reject any article whose Date header appears margin less than 24 hours). It SHOULD reject any article whose
to be stale (more than 72 hours into the past, for example, or Injection-Date header field is too far in the past (older than
too old to still be recorded in the database of a relaying agent the cutoff interval of a relaying agent the injecting agent is
the injecting agent will be using) since not all news servers using, for example). It SHOULD similarly reject any article
support Injection-Date. whose Date header field is too far in the past, since not all
news servers support Injection-Date and only the injecting agent
can provide a useful error message to the posting agent. In
either case, this interval SHOULD NOT be any shorter than 72
hours into the past.
4. It SHOULD reject any proto-article whose Newsgroups header field 4. It SHOULD reject any proto-article whose Newsgroups header field
does not contain at least one <newsgroup-name> for a valid does not contain at least one <newsgroup-name> for a valid
group, or containing a <newsgroup-name> reserved for specific group, or containing a <newsgroup-name> reserved for specific
purposes by Section 3.1.4 of [USEFOR] unless that specific purposes by Section 3.1.4 of [USEFOR] unless that specific
purpose or local agreement applies to the proto-article being purpose or local agreement applies to the proto-article being
processed. Crossposting to unknown newsgroups is not precluded processed. Crossposting to unknown newsgroups is not precluded
provided that at least one of the newsgroups in the Newsgroups provided that at least one of the newsgroups in the Newsgroups
header is valid. header is valid.
skipping to change at page 18, line 23 skipping to change at page 19, line 23
8. Otherwise, a Path header field with a <tail-entry> MUST be added 8. Otherwise, a Path header field with a <tail-entry> MUST be added
if not already present. if not already present.
9. The injecting agent MUST then update the Path header field as 9. The injecting agent MUST then update the Path header field as
described in Section 3.2.1. described in Section 3.2.1.
10. An Injection-Info header field SHOULD be added identifying the 10. An Injection-Info header field SHOULD be added identifying the
source of the article and possibly other trace information as source of the article and possibly other trace information as
described in Section 3.2.8 of [USEFOR]. described in Section 3.2.8 of [USEFOR].
11. The injecting agent MUST then add an Injection-Date header field 11. If the proto-article already had an Injection-Date header field,
containing the current date and time. 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.
12. Finally, the injecting agent forwards the article to one or more 12. Finally, the injecting agent forwards the article to one or more
relaying agents, and the injection process is complete. relaying agents, and the injection process is complete.
3.5.1. Forwarding Messages to a Moderator 3.5.1. Forwarding Messages to a Moderator
An injecting agent MUST forward the proto-article to the moderator of An injecting agent MUST forward the proto-article to the moderator of
the leftmost moderated group listed in the Newsgroups header field, the leftmost moderated group listed in the Newsgroups header field,
customarily via email. There are two standard ways in which it may customarily via email. There are two standard ways in which it may
do this: do this:
skipping to change at page 23, line 46 skipping to change at page 25, line 5
The moderator who takes this step assumes responsibility for The moderator who takes this step assumes responsibility for
ensuring that the article was approved by the moderators of all ensuring that the article was approved by the moderators of all
moderated newsgroups to which it was posted. moderated newsgroups to which it was posted.
4. Moderators are encouraged to retain the Message-ID header field 4. Moderators are encouraged to retain the Message-ID header field
if it is valid, and also retain the Date header field unless it if it is valid, and also retain the Date header field unless it
appears to be stale (72 hours or more in the past) for reasons appears to be stale (72 hours or more in the past) for reasons
understood by the moderator (such as delays in the moderation understood by the moderator (such as delays in the moderation
process) in which case they MAY substitute the current date. Any process) in which case they MAY substitute the current date. Any
Injection-Date, Injection-Info, or Xref header fields already Injection-Date, Injection-Info, or Xref header fields already
present (though there should be none) MUST be removed. present MUST be removed.
5. Any Path header field MUST either be removed or truncated to only 5. Any Path header field MUST either be removed or truncated to only
those entries following its "POSTED" <diag-keyword>, if any. those entries following its "POSTED" <diag-keyword>, if any.
6. The moderator then passes the article to an injecting agent, 6. The moderator then passes the article to an injecting agent,
having first observed all the duties of a posting agent. having first observed all the duties of a posting agent.
3.10. Duties of a Gateway 3.10. Duties of a Gateway
A gateway transforms an article into the native message format of A gateway transforms an article into the native message format of
skipping to change at page 45, line 50 skipping to change at page 46, line 50
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006. RFC 3977, October 2006.
[USEAGE] Lindsey, C., "Usenet Best Practice". [USEAGE] Lindsey, C., "Usenet Best Practice".
Appendix A. Changes to the Existing Protocols Appendix A. Changes to the Existing Protocols
This document prescribes many changes, clarifications, and new This document prescribes many changes, clarifications, and new
features since the protocol described in [RFC1036]. Most notably: features since the protocol described in [RFC1036]. Most notably:
 End of changes. 18 change blocks. 
95 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/