draft-ietf-usefor-usepro-09.txt   draft-ietf-usefor-usepro-10.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: May 13, 2008 November 10, 2007 Expires: February 4, 2009 August 3, 2008
Netnews Architecture and Protocols Netnews Architecture and Protocols
draft-ietf-usefor-usepro-09 draft-ietf-usefor-usepro-10
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 May 13, 2008. This Internet-Draft will expire on February 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 24 skipping to change at page 3, line 24
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
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. Duties of a Posting Agent . . . . . . . . . . . . . . . . 12 3.3. Article History and Duplicate Suppression . . . . . . . . 12
3.3.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 12 3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 13
3.3.2. Reinjection of Articles . . . . . . . . . . . . . . . 13 3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 14
3.3.3. Followups . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Reinjection of Articles . . . . . . . . . . . . . . . 14
3.3.4. Construction of the References Header Field . . . . . 14 3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Duties of an Injecting Agent . . . . . . . . . . . . . . . 15 3.4.4. Construction of the References Header Field . . . . . 15
3.4.1. Forwarding Messages to a Moderator . . . . . . . . . . 17 3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 16
3.5. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 18 3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 18
3.6. Duties of a Serving Agent . . . . . . . . . . . . . . . . 20 3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 19
3.7. Duties of a Reading Agent . . . . . . . . . . . . . . . . 21 3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 21
3.8. Duties of a Moderator . . . . . . . . . . . . . . . . . . 21 3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 22
3.9. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 23 3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 22
3.9.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 24 3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 24
3.9.2. Duties of an Incoming Gateway . . . . . . . . . . . . 24 3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 25
3.9.3. Gateway Example . . . . . . . . . . . . . . . . . . . 26 3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 25
4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.10.3. Gateway Example . . . . . . . . . . . . . . . . . . . 27
4.1. application/news-transmission . . . . . . . . . . . . . . 28 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 29 4.1. application/news-transmission . . . . . . . . . . . . . . 29
4.3. application/news-checkgroups . . . . . . . . . . . . . . . 30 4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 30
5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 32 4.3. application/news-checkgroups . . . . . . . . . . . . . . . 31
5.1. Authentication and Authorization . . . . . . . . . . . . . 32 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 33 5.1. Authentication and Authorization . . . . . . . . . . . . . 33
5.2.1. The newgroup Control Message . . . . . . . . . . . . . 33 5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 34
5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 35 5.2.1. The newgroup Control Message . . . . . . . . . . . . . 34
5.2.3. The checkgroups Control Message . . . . . . . . . . . 35 5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 36
5.3. The cancel Control Message . . . . . . . . . . . . . . . . 37 5.2.3. The checkgroups Control Message . . . . . . . . . . . 36
5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 37 5.3. The cancel Control Message . . . . . . . . . . . . . . . . 38
5.5. The ihave and sendme Control Messages . . . . . . . . . . 38 5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 38
5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 39 5.5. The ihave and sendme Control Messages . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 40
6.1. Compromise of System Integrity . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 41 6.1. Compromise of System Integrity . . . . . . . . . . . . . . 41
6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . . 44 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . . 44 8.1. Normative References . . . . . . . . . . . . . . . . . . . 45
Appendix A. Changes to the Existing Protocols . . . . . . . . . . 46 8.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 47 Appendix A. Changes to the Existing Protocols . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 50
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 12, line 24 skipping to change at page 12, line 24
to validate its <path-identity> and instead appended the <diag- to validate its <path-identity> and instead appended the <diag-
keyword> "SEEN" to indicate it knows the source of the article as keyword> "SEEN" to indicate it knows the source of the article as
isp.example. This may be either an expected <path-identity> or the isp.example. This may be either an expected <path-identity> or the
FQDN of the system from which it received the article. Presumably FQDN of the system from which it received the article. Presumably
foo.isp.example is a serving agent that then delivered the article to foo.isp.example is a serving agent that then delivered the article to
a reading agent. a reading agent.
baz.isp.example, bar.isp.example, and foo-news folded the Path header baz.isp.example, bar.isp.example, and foo-news folded the Path header
field. field.
3.3. Duties of a Posting Agent 3.3. Article History and Duplicate Suppression
Netnews normally uses a flood-fill algorithm for propagation of
articles in which each news server offers the articles it accepts to
multiple peers and each news server may be offered the same article
from multiple other news servers. Accordingly, duplicate suppression
is key; if a news server accepted every article it was offered, it
may needlessly accept (and then potentially retransmit) dozens of
copies of every article.
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.
Each article is uniquely identified by its message identifier, so a
relaying or serving agent could satisfy this requirement by storing a
record of every message identifier that agent has ever seen. Such a
history database would grow without bound, however, so it is common
and permitted to optimize based on the Injection-Date or Date header
field of an article as follows. (In the following discussion, the
"date" of an article is defined to be the date represented by its
Injection-Date header field if present, otherwise its Date header
field.)
o Agents MAY select a cutoff interval and reject any article with a
date farther in the past than that cutoff interval. If this
interval is shorter than the time it takes for an article to
propagate through the network, the agent might reject an article
it had not yet seen, so it ought not be aggressively short. For
Usenet, for example, a cutoff interval of no less than seven days
is conventional.
o 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.
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).
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 do not have extensive experience with
Netnews and the subtle effects of its flood-fill algorithm.
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-Date or Injection-Info header fields;
these headers will be added by the injecting agent. these headers will be added by the injecting agent.
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.
3.3.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-Date, Injection-Info, and Xref header fields MUST NOT
be present; the Path header field MUST NOT contain a "POSTED" <diag- be present; the Path header field MUST NOT contain a "POSTED" <diag-
keyword>; and any of the following mandatory header fields MAY be keyword>; and any of the following mandatory header fields MAY be
omitted: Message-ID, Date, and Path. In all other respects, a proto- omitted: Message-ID, Date, and Path. In all other respects, a proto-
article MUST be a valid Netnews article. In particular, the header article MUST be a valid Netnews article. In particular, the header
fields which may be omitted MUST NOT be present with invalid content. fields which may be 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 and Date MUST
be present and identical in all copies of the proto-article. be present and identical in all copies of the proto-article.
3.3.2. Reinjection of Articles 3.4.2. Reinjection of Articles
A given article SHOULD be processed by an injecting agent once and A given article SHOULD be processed by an injecting agent once and
only once. The Injection-Date or Injection-Info header fields are only once. The Injection-Date or Injection-Info header fields are
added by an injecting agent and are not permitted in a proto-article. added by an injecting agent and are not permitted in a proto-article.
Their presence (or the presence of other unstandardized or obsolete Their presence (or the presence of other unstandardized or obsolete
trace headers such as NNTP-Posting-Host, NNTP-Posting-Date, or trace headers such as NNTP-Posting-Host, NNTP-Posting-Date, or
X-Trace) indicates that the proto-article is instead an article and X-Trace) indicates that the proto-article is instead an article and
has already been processed by an injecting agent. A posting agent has already been processed by an injecting agent. A posting agent
SHOULD normally reject such articles. SHOULD normally reject such articles.
skipping to change at page 13, line 45 skipping to change at page 15, line 5
the existing Injection-Date or Date header fields that would the existing Injection-Date or Date header fields that would
otherwise be done by the injecting agent. otherwise be done by the injecting agent.
Reinjecting articles may cause loops, loss of trace information, and Reinjecting articles may cause loops, loss of trace information, and
other problems and should only be done with care and when there is no other problems and should only be done with care and when there is no
available alternative. A posting agent that does reinjection is a available alternative. A posting agent that does reinjection is a
limited type of gateway and as such is subject to all of the limited type of gateway and as such is subject to all of the
requirements of an incoming gateway in addition to the requirements requirements of an incoming gateway in addition to the requirements
of a posting agent. of a posting agent.
3.3.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
folding permitted). However, posters MAY then override that default folding permitted). However, posters MAY then override that default
before posting. before posting.
skipping to change at page 14, line 37 skipping to change at page 15, line 46
Subject header field unless it already begins with that string. Subject header field unless it already begins with that string.
NOTE: Prepending "Re: " serves no protocol function and hence NOTE: Prepending "Re: " serves no protocol function and hence
is not required, but it is widely expected and not doing so is not required, but it is widely expected and not doing so
would be surprising. would be surprising.
4. The Distribution header field SHOULD by default be inherited from 4. The Distribution header field SHOULD by default be inherited from
the precursor's Distribution header field, if present. the precursor's Distribution header field, if present.
5. The followup MUST have a References header field referring to its 5. The followup MUST have a References header field referring to its
precursor constructed in accordance with Section 3.3.4. precursor constructed in accordance with Section 3.4.4.
3.3.4. Construction of the References Header Field 3.4.4. Construction of the References Header Field
The following procedure is to be used whenever some previous article The following procedure is to be used whenever some previous article
(the "parent") is to be referred to in the References header field of (the "parent") is to be referred to in the References header field of
a new article, whether because the new article is a followup and the a new article, whether because the new article is a followup and the
parent is its precursor or for some other reason. parent is its precursor or for some other reason.
The content of the new article's References header field MUST be The content of the new article's References header field MUST be
formed from the content of the parent's References header field if formed from the content of the parent's References header field if
present and the content of the Message-ID header field of the parent. present and the content of the Message-ID header field of the parent.
If the parent had a References header, FWS as defined in [USEFOR] If the parent had a References header, FWS as defined in [USEFOR]
skipping to change at page 15, line 17 skipping to change at page 16, line 25
final CRLF), it MUST be trimmed (and otherwise MAY be trimmed). final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
Trimming means removing any number of message identifiers from its Trimming means removing any number of message identifiers from its
content, except that the first message identifier and the last two content, except that the first message identifier and the last two
MUST NOT be removed. MUST NOT be removed.
An essential property of the References header field, guaranteed by An essential property of the References header field, guaranteed by
the above procedure and REQUIRED to be maintained by any extensions the above procedure and REQUIRED to be maintained by any extensions
to this protocol, is that an article MUST NOT precede one of its to this protocol, is that an article MUST NOT precede one of its
parents. parents.
3.4. Duties of an Injecting Agent 3.5. Duties of an Injecting Agent
An injecting agent takes a proto-article from a posting agent and An injecting agent takes a proto-article from a posting agent and
either forwards it to a moderator or passes it to a relaying or either forwards it to a moderator or passes it to a relaying or
serving agent or agents. An injecting agent bears the primary serving agent or agents. An injecting agent bears the primary
responsibility for ensuring that any article it injects conforms with responsibility for ensuring that any article it injects conforms with
the rules of the Netnews standards. The administrator of an the rules of the Netnews standards. The administrator of an
injecting agent is also expected to bear some responsibility towards injecting agent is also expected to bear some responsibility towards
the rest of the Netnews network to which it is connected for the the rest of the Netnews network to which it is connected for the
articles the injecting agent accepts. articles the injecting agent accepts.
skipping to change at page 16, line 48 skipping to change at page 18, line 8
MAY add other header fields not already provided by the poster, MAY add other header fields not already provided by the poster,
but injecting agents are encouraged to use the Injection-Info but injecting agents are encouraged to use the Injection-Info
header for such information and to minimize the addition of header for such information and to minimize the addition of
other headers. It SHOULD NOT alter, delete, or reorder any other headers. It SHOULD NOT alter, delete, or reorder any
existing header field except the Path header field. It MUST NOT existing header field except the Path header field. It MUST NOT
alter or delete any existing Message-ID header field. alter or delete any existing Message-ID header field.
7. If the Newsgroups header contains one or more moderated groups 7. If the Newsgroups header contains one or more moderated groups
and the proto-article does not contain an Approved header field, and the proto-article does not contain an Approved header field,
the injecting agent MUST either forward it to a moderator as the injecting agent MUST either forward it to a moderator as
specified in Section 3.4.1 or, if that is not possible, reject specified in Section 3.5.1 or, if that is not possible, reject
it. This forwarding MUST be done after adding the Message-ID it. This forwarding MUST be done after adding the Message-ID
and Date headers if required, and before adding the Injection- and Date headers if required, and before adding the Injection-
Info and Injection-Date headers. Info and Injection-Date headers.
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. The injecting agent MUST then add an Injection-Date header field
containing the current date and time. 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.4.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:
1. The complete proto-article is encapsulated, header fields and 1. The complete proto-article is encapsulated, header fields and
all, within the email. This SHOULD be done by creating an email all, within the email. This SHOULD be done by creating an email
message with a Content-Type of application/news-transmission with message with a Content-Type of application/news-transmission with
the usage parameter set to "moderate". The body SHOULD NOT the usage parameter set to "moderate". The body SHOULD NOT
skipping to change at page 18, line 18 skipping to change at page 19, line 26
Forwarding proto-articles to moderators via email is the most general Forwarding proto-articles to moderators via email is the most general
method and most common in large Netnews networks such as Usenet, but method and most common in large Netnews networks such as Usenet, but
any means of forwarding the article that preserves it without any means of forwarding the article that preserves it without
injecting it MAY be used. For example, if the injecting agent has injecting it MAY be used. For example, if the injecting agent has
access to a database used by the moderator to store proto-articles access to a database used by the moderator to store proto-articles
awaiting processing, it may place the proto-article directly into awaiting processing, it may place the proto-article directly into
that database. Such methods may be more appropriate for smaller that database. Such methods may be more appropriate for smaller
Netnews networks. Netnews networks.
3.5. Duties of a Relaying Agent 3.6. Duties of a Relaying Agent
A relaying agent accepts injected articles from injecting and other A relaying agent accepts injected articles from injecting and other
relaying agents and passes them on to relaying or serving agents. To relaying agents and passes them on to relaying or serving agents. To
avoid bypass of injecting agent policies and forgery of Path and avoid bypass of injecting agent policies and forgery of Path and
Injector-Info headers, relaying agents SHOULD accept articles only Injector-Info headers, relaying agents SHOULD accept articles only
from trusted agents. from trusted agents.
An article SHOULD NOT be relayed unless the sending agent has been An article SHOULD NOT be relayed unless the sending agent has been
configured to supply and the receiving agent to receive at least one configured to supply and the receiving agent to receive at least one
of the <newsgroup-name>s in its Newsgroups header field and at least of the <newsgroup-name>s in its Newsgroups header field and at least
skipping to change at page 18, line 49 skipping to change at page 20, line 9
known alias thereof) appears as a <path-identity> (excluding within known alias thereof) appears as a <path-identity> (excluding within
the <tail-entry> or following a "POSTED" <diag-keyword>) in its Path the <tail-entry> or following a "POSTED" <diag-keyword>) in its Path
header field. header field.
A relaying agent processes an article as follows: A relaying agent processes an article as follows:
1. It MUST reject any article without a Newsgroups header field or 1. It MUST reject any article without a Newsgroups header field or
Message-ID header field, or without either an Injection-Date or Message-ID header field, or without either an Injection-Date or
Date header field. Date header field.
2. It MUST reject any article that has already been successfully 2. It MUST examine the Injection-Date header field or, if absent,
sent to it, based on the Message-ID header field of the article. the Date header field, and reject the article if that date is
To satisfy this requirement, a relaying agent normally keeps a more than 24 hours into the future. It MAY reject articles with
database of message identifiers it has already accepted. dates in the future with a smaller margin than 24 hours.
3. It MUST examine the Injection-Date header field or, if absent, 3. It MUST reject any article that has already been accepted. If it
the Date header field, and reject the article if that date implements one of the mechanisms described in Section 3.3, this
predates the earliest articles of which it keeps record or if means that it MUST reject any article whose date falls outside
that date is more than 24 hours into the future. It MAY reject the cutoff interval since it won't know whether such articles had
articles with dates in the future with a smaller margin than 24 been accepted previously or not.
hours.
4. It SHOULD reject any article that does not include all the 4. It SHOULD reject any article that does not include all the
mandatory header fields. It MAY reject any article that contains mandatory header fields. It MAY reject any article that contains
header fields that do not have valid contents. header fields that do not have valid contents.
5. It SHOULD reject any article that matches an already-received 5. It SHOULD reject any article that matches an already-received
cancel control message or the contents of the Supersedes header cancel control message or the contents of the Supersedes header
field of an accepted article, provided that the relaying agent field of an accepted article, provided that the relaying agent
chose (on the basis of local site policy) to honor that cancel chose (on the basis of local site policy) to honor that cancel
control message or Supersedes header field. control message or Supersedes header field.
skipping to change at page 20, line 5 skipping to change at page 21, line 7
inform the agent that passed the article to the relaying agent if the inform the agent that passed the article to the relaying agent if the
article was rejected. Relaying agents MUST NOT inform any other article was rejected. Relaying agents MUST NOT inform any other
external entity of the rejection of an article unless that external external entity of the rejection of an article unless that external
entity has explicitly requested that it be informed of such errors. entity has explicitly requested that it be informed of such errors.
Relaying agents MUST NOT alter, delete, or rearrange any part of an Relaying agents MUST NOT alter, delete, or rearrange any part of an
article except for the Path and Xref header fields. They MUST NOT article except for the Path and Xref header fields. They MUST NOT
modify the body of articles in any way. If an article is not modify the body of articles in any way. If an article is not
acceptable as-is, the article MUST be rejected rather than modified. acceptable as-is, the article MUST be rejected rather than modified.
3.6. Duties of a Serving Agent 3.7. Duties of a Serving Agent
A serving agent accepts articles from a relaying agent or injecting A serving agent accepts articles from a relaying agent or injecting
agent, stores it, and makes it available to reading agents. Articles agent, stores it, and makes it available to reading agents. Articles
are normally indexed by newsgroup and <article-locator> (Section are normally indexed by newsgroup and <article-locator> (Section
3.2.14 of [USEFOR]), usually in the form of a decimal number. 3.2.14 of [USEFOR]), usually in the form of a decimal number.
If the serving agent stores articles by newsgroup, control messages If the serving agent stores articles by newsgroup, control messages
SHOULD NOT be stored in the newsgroups listed in the control SHOULD NOT be stored in the newsgroups listed in the control
message's Newsgroups header field. Instead, they SHOULD be stored in message's Newsgroups header field. Instead, they SHOULD be stored in
a newsgroup in the hierarchy "control", which is reserved for this a newsgroup in the hierarchy "control", which is reserved for this
skipping to change at page 20, line 33 skipping to change at page 21, line 35
agent is deployed in combination with an injecting agent and can use agent is deployed in combination with an injecting agent and can use
the same list as the injecting agent. the same list as the injecting agent.
A serving agent processes articles as follows: A serving agent processes articles as follows:
1. It MUST reject any article that does not include all the 1. It MUST reject any article that does not include all the
mandatory header fields or any article which contains header mandatory header fields or any article which contains header
fields that do not have valid contents. fields that do not have valid contents.
2. It MUST examine the Injection-Date header field or, if absent, 2. It MUST examine the Injection-Date header field or, if absent,
the Date header field, and reject the article if that date the Date header field, and reject the article if that date is
predates the earliest articles of which it keeps record or if more than 24 hours into the future. It MAY reject articles with
that date is more than 24 hours into the future. It MAY reject dates in the future with a smaller margin than 24 hours.
articles with dates in the future with a smaller margin than 24
hours.
3. It MUST reject any article that has already been successfully 3. It MUST reject any article that has already been accepted. If it
sent to it, based on the Message-ID header field of the article. implements one of the mechanisms described in Section 3.3, this
To satisfy this requirement, a relaying agent normally keeps a means that it MUST reject any article whose date falls outside
database of message identifiers it has already accepted. the cutoff interval since it won't know whether such articles had
been accepted previously or not.
4. It SHOULD reject any article that matches an already-received and 4. It SHOULD reject any article that matches an already-received and
honored cancel message or Supersedes header field following the honored cancel message or Supersedes header field following the
same rules as a relaying agent (Section 3.5). same rules as a relaying agent (Section 3.6).
5. It MUST reject any article without an Approved header field 5. It MUST reject any article without an Approved header field
posted to any newsgroup listed as moderated. posted to any newsgroup listed as moderated.
6. It MUST update the Path header field as described in 6. It MUST update the Path header field as described in
Section 3.2.1. Section 3.2.1.
7. It MUST (except when specially configured to preserve the 7. It MUST (except when specially configured to preserve the
<article-locator>s set by the sending site) remove any Xref <article-locator>s set by the sending site) remove any Xref
header field from each article. It then MAY (and usually will) header field from each article. It then MAY (and usually will)
skipping to change at page 21, line 23 skipping to change at page 22, line 26
Serving agents MUST NOT create new newsgroups simply because an Serving agents MUST NOT create new newsgroups simply because an
unrecognized <newsgroup-name> occurs in a Newsgroups header field. unrecognized <newsgroup-name> occurs in a Newsgroups header field.
Newsgroups are normally created via control messages (Section 5.2.1). Newsgroups are normally created via control messages (Section 5.2.1).
Serving agents MUST NOT alter, delete, or rearrange any part of an Serving agents MUST NOT alter, delete, or rearrange any part of an
article except for the Path and Xref header fields. They MUST NOT article except for the Path and Xref header fields. They MUST NOT
modify the body of the articles in any way. If an article is not modify the body of the articles in any way. If an article is not
acceptable as-is, the article MUST be rejected rather than modified. acceptable as-is, the article MUST be rejected rather than modified.
3.7. Duties of a Reading Agent 3.8. Duties of a Reading Agent
Since a reading agent is only a passive participant in a Netnews Since a reading agent is only a passive participant in a Netnews
network, there are no specific protocol requirements placed on it. network, there are no specific protocol requirements placed on it.
See [USEAGE] for best-practice recommendations. See [USEAGE] for best-practice recommendations.
3.8. Duties of a Moderator 3.9. Duties of a Moderator
A moderator receives news articles, customarily by email, decides A moderator receives news articles, customarily by email, decides
whether to approve them and, if so, either passes them to an whether to approve them and, if so, either passes them to an
injecting agent or forwards them to further moderators. injecting agent or forwards them to further moderators.
Articles are normally received by the moderator in email either Articles are normally received by the moderator in email either
encapsulated as an object of Content-Type application/ encapsulated as an object of Content-Type application/
news-transmission (or possibly encapsulated but without an explicit news-transmission (or possibly encapsulated but without an explicit
Content-Type header field), or else directly as an email already Content-Type header field), or else directly as an email already
containing all the header fields appropriate for a Netnews article containing all the header fields appropriate for a Netnews article
(see Section 3.4.1). Moderators who may receive articles via email (see Section 3.5.1). Moderators who may receive articles via email
SHOULD be prepared to accept articles in either format. SHOULD be prepared to accept articles in either format.
There are no protocol restrictions on what criteria are used for There are no protocol restrictions on what criteria are used for
accepting or rejecting messages or on what modifications a moderator accepting or rejecting messages or on what modifications a moderator
may make to a message (both header fields and body) before injecting may make to a message (both header fields and body) before injecting
it. Recommended best practice, however, is to make the minimal it. Recommended best practice, however, is to make the minimal
required changes. Moderators need to be aware that modifications required changes. Moderators need to be aware that modifications
made to articles may invalidate signatures created by the poster or made to articles may invalidate signatures created by the poster or
previous moderators. See [USEAGE] for further best-practice previous moderators. See [USEAGE] for further best-practice
recommendations. recommendations.
skipping to change at page 22, line 21 skipping to change at page 23, line 24
If it is approved, the moderator proceeds with the following If it is approved, the moderator proceeds with the following
steps. steps.
2. If the Newsgroups header field contains further moderated 2. If the Newsgroups header field contains further moderated
newsgroups for which approval has not already been given, they newsgroups for which approval has not already been given, they
may either reach some agreement with the other moderators on the may either reach some agreement with the other moderators on the
disposition of the article or, more generally, add an indication disposition of the article or, more generally, add an indication
(identifying both the moderator and the name of the newsgroup) (identifying both the moderator and the name of the newsgroup)
that they approve the article and then forward it to the that they approve the article and then forward it to the
moderator of the leftmost unapproved newsgroup. This forwarding moderator of the leftmost unapproved newsgroup. This forwarding
SHOULD be done following the procedure in Section 3.4.1 and MAY SHOULD be done following the procedure in Section 3.5.1 and MAY
be done by rotating the <newsgroup-name>s in the Newsgroups be done by rotating the <newsgroup-name>s in the Newsgroups
header field so that the leftmost unapproved newsgroup is is the header field so that the leftmost unapproved newsgroup is is the
leftmost moderated newsgroup in that field and then posting it, leftmost moderated newsgroup in that field and then posting it,
letting the injecting agent do the forwarding. However, if using letting the injecting agent do the forwarding. However, if using
this mechanism, they MUST first ensure that the article contains this mechanism, they MUST first ensure that the article contains
no Approved header field. no Approved header field.
3. If the Newsgroups header field contains no further unapproved 3. If the Newsgroups header field contains no further unapproved
moderated groups, they add an Approved header field (see Section moderated groups, they add an Approved header field (see Section
3.2.1 of [USEFOR]) identifying the moderator and, insofar as is 3.2.1 of [USEFOR]) identifying the moderator and, insofar as is
skipping to change at page 23, line 5 skipping to change at page 24, line 8
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 (though there should be none) 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.9. 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
another medium, or translates the messages of another medium into another medium, or translates the messages of another medium into
news articles, or transforms articles into proto-articles for news articles, or transforms articles into proto-articles for
injection into a separate Netnews network. Encapsulation of a news injection into a separate Netnews network. Encapsulation of a news
article into a message of MIME type application/news-transmission, or article into a message of MIME type application/news-transmission, or
the subsequent undoing of that encapsulation, is not gatewaying, the subsequent undoing of that encapsulation, is not gatewaying,
since it involves no transformation of the article. since it involves no transformation of the article.
There are two basic types of gateway, the outgoing gateway that There are two basic types of gateway, the outgoing gateway that
skipping to change at page 23, line 50 skipping to change at page 25, line 4
instead where this is necessary. instead where this is necessary.
Safe bidirectional gatewaying between a mailing list and a newsgroup Safe bidirectional gatewaying between a mailing list and a newsgroup
is far easier if the newsgroup is moderated. Posts to the moderated is far easier if the newsgroup is moderated. Posts to the moderated
group and submissions to the mailing list can then go through a group and submissions to the mailing list can then go through a
single point that does the necessary gatewaying and then sends the single point that does the necessary gatewaying and then sends the
message out to both the newsgroup and the mailing list at the same message out to both the newsgroup and the mailing list at the same
time, eliminating most of the possibility of loops. Bidirectional time, eliminating most of the possibility of loops. Bidirectional
gatewaying between a mailing list and an unmoderated newsgroup, in gatewaying between a mailing list and an unmoderated newsgroup, in
contrast, is difficult to do correctly and is far more fragile. contrast, is difficult to do correctly and is far more fragile.
Newsgroups intended to be bidirectionally gated to a mailing list Newsgroups intended to be bidirectionally gated to a mailing list
SHOULD therefore be moderated where possible, even if the moderator SHOULD therefore be moderated where possible, even if the moderator
is a simple gateway and injecting agent that correctly handles is a simple gateway and injecting agent that correctly handles
crossposting to other moderated groups and otherwise passes all crossposting to other moderated groups and otherwise passes all
traffic. traffic.
3.9.1. Duties of an Outgoing Gateway 3.10.1. Duties of an Outgoing Gateway
From the perspective of Netnews, an outgoing gateway is just a From the perspective of Netnews, an outgoing gateway is just a
special type of reading agent. The exact nature of what the outgoing special type of reading agent. The exact nature of what the outgoing
gateway will need to do to articles depends on the medium to which gateway will need to do to articles depends on the medium to which
the articles are being gated. The operation of the outgoing gateway the articles are being gated. The operation of the outgoing gateway
is subject to additional constraints due to the possibility of one or is subject to additional constraints due to the possibility of one or
more corresponding incoming gateways back from that medium to more corresponding incoming gateways back from that medium to
Netnews, since this raises the danger of loops. Netnews, since this raises the danger of loops.
The following practices are encouraged for all outgoing gateways, The following practices are encouraged for all outgoing gateways,
skipping to change at page 24, line 40 skipping to change at page 25, line 44
3. The message should be tagged in some way so as to prevent its 3. The message should be tagged in some way so as to prevent its
reinjection into Netnews. This may be impossible to do without reinjection into Netnews. This may be impossible to do without
knowledge of potential incoming gateways, but it is better to try knowledge of potential incoming gateways, but it is better to try
to provide some indication even if not successful; at the least, to provide some indication even if not successful; at the least,
a human-readable indication that the article should not be gated a human-readable indication that the article should not be gated
back to Netnews can help locate a human problem. back to Netnews can help locate a human problem.
4. Netnews control messages should not be gated to another medium 4. Netnews control messages should not be gated to another medium
unless they would somehow be meaningful in that medium. unless they would somehow be meaningful in that medium.
3.9.2. Duties of an Incoming Gateway 3.10.2. Duties of an Incoming Gateway
The incoming gateway has the responsibility of ensuring that all of The incoming gateway has the responsibility of ensuring that all of
the requirements of this protocol are met by the articles that it the requirements of this protocol are met by the articles that it
forms. In addition to its special duties as a gateway, it bears all forms. In addition to its special duties as a gateway, it bears all
of the duties and responsibilities of a posting agent as well, and of the duties and responsibilities of a posting agent as well, and
additionally has the same responsibility of a relaying agent to additionally has the same responsibility of a relaying agent to
reject articles that it has already gatewayed. reject articles that it has already gatewayed.
An incoming gateway MUST NOT gate the same message twice. It may not An incoming gateway MUST NOT gate the same message twice. It may not
be possible to ensure this in the face of mangling or modification of be possible to ensure this in the face of mangling or modification of
the message, but at the very least a gateway, when given a copy of a the message, but at the very least a gateway, when given a copy of a
message it has already gated identical except for trace header fields message it has already gated identical except for trace header fields
(like Received in Email or Path in Netnews) MUST NOT gate the message (like Received in Email or Path in Netnews) MUST NOT gate the message
again. An incoming gateway SHOULD take precautions against having again. An incoming gateway SHOULD take precautions against having
this rule bypassed by modifications of the message that can be this rule bypassed by modifications of the message that can be
anticipated. anticipated.
News articles prepared by gateways MUST be valid news proto-articles News articles prepared by gateways MUST be valid news proto-articles
(see Section 3.3.1). This often requires the gateway to synthesize a (see Section 3.4.1). This often requires the gateway to synthesize a
conforming article from non-conforming input. The gateway MUST then conforming article from non-conforming input. The gateway MUST then
pass the article to an injecting agent, not directly to a relaying pass the article to an injecting agent, not directly to a relaying
agent. agent.
Incoming gateways MUST NOT pass control messages (articles containing Incoming gateways MUST NOT pass control messages (articles containing
a Control or Supersedes header field) without removing or renaming a Control or Supersedes header field) without removing or renaming
that header field. Gateways MAY, however, generate cancel control that header field. Gateways MAY, however, generate cancel control
messages for messages they have gatewayed. If a gateway receives a messages for messages they have gatewayed. If a gateway receives a
message that it can determine is a valid equivalent of a cancel message that it can determine is a valid equivalent of a cancel
control message in the medium it is gatewaying, it SHOULD discard control message in the medium it is gatewaying, it SHOULD discard
skipping to change at page 26, line 38 skipping to change at page 27, line 41
in preventing reinjection of old messages. in preventing reinjection of old messages.
An incoming gateway MUST add a Sender header field to the news An incoming gateway MUST add a Sender header field to the news
article it forms containing the <mailbox> of the administrator of the article it forms containing the <mailbox> of the administrator of the
gateway. Problems with the gateway may be reported to this gateway. Problems with the gateway may be reported to this
<mailbox>. The <display-name> portion of this <mailbox> SHOULD <mailbox>. The <display-name> portion of this <mailbox> SHOULD
indicate that the entity responsible for injection of the message is indicate that the entity responsible for injection of the message is
a gateway. If the original message already had a Sender header a gateway. If the original message already had a Sender header
field, it SHOULD be renamed so that its contents can be preserved. field, it SHOULD be renamed so that its contents can be preserved.
3.9.3. Gateway Example 3.10.3. Gateway Example
To illustrate the type of precautions that should be taken against To illustrate the type of precautions that should be taken against
loops, here is an example of the measures taken by one particular loops, here is an example of the measures taken by one particular
combination of mail-to-news and news-to-mail gateways designed to combination of mail-to-news and news-to-mail gateways designed to
handle bidirectional gatewaying between mailing lists and unmoderated handle bidirectional gatewaying between mailing lists and unmoderated
groups: groups:
1. The news-to-mail gateway preserves the message identifier of the 1. The news-to-mail gateway preserves the message identifier of the
news article in the generated email message. The mail-to-news news article in the generated email message. The mail-to-news
gateway likewise preserves the email message identifier provided gateway likewise preserves the email message identifier provided
skipping to change at page 28, line 22 skipping to change at page 29, line 22
default treatment as application/octet-stream by agents that did not default treatment as application/octet-stream by agents that did not
recognize it was counter-productive. The media type message/rfc822 recognize it was counter-productive. The media type message/rfc822
SHOULD be used in its place. SHOULD be used in its place.
4.1. application/news-transmission 4.1. application/news-transmission
The media type application/news-transmission is intended for the The media type application/news-transmission is intended for the
encapsulation of complete news articles where the intention is that encapsulation of complete news articles where the intention is that
the recipient should then inject them into Netnews. This application the recipient should then inject them into Netnews. This application
type provides one of the methods for mailing articles to moderators type provides one of the methods for mailing articles to moderators
(see Section 3.4.1) and may be used to convey messages to an (see Section 3.5.1) and may be used to convey messages to an
injecting agent. This encapsulation removes the need to transform an injecting agent. This encapsulation removes the need to transform an
email message into a Netnews proto-article and provides a way to send email message into a Netnews proto-article and provides a way to send
a Netnews article using MIME through a transport medium that does not a Netnews article using MIME through a transport medium that does not
support 8bit data. support 8bit data.
The MIME media type definition of application/news-transmission is: The MIME media type definition of application/news-transmission is:
MIME type name: application MIME type name: application
MIME subtype name: news-transmission MIME subtype name: news-transmission
Required parameters: none Required parameters: none
Optional parameters: One and only one of "usage=moderate", Optional parameters: One and only one of "usage=moderate",
"usage=inject", or "usage=relay". "usage=inject", or "usage=relay".
Encoding considerations: A transfer-encoding different from that of Encoding considerations: A transfer-encoding different from that
the article transmitted MAY be supplied to of the article transmitted MAY be
ensure correct transmission over some 7bit supplied to ensure correct transmission
transport medium. over some 7bit transport medium.
Security considerations: A news article may be a control message, Security considerations: A news article may be a control message,
which if processed could have effects on which if processed could have effects on
the recipient host's system beyond just the recipient host's system beyond just
storage of the article. storage of the article.
Published specification: This specification. Published specification: This specification.
Body part: A complete proto-article ready for Body part: A complete proto-article ready for
injection into Netnews or an article being injection into Netnews or an article
relayed to another agent being relayed to another agent.
usage=moderate indicates the article is intended for a moderator, usage=moderate indicates the article is intended for a moderator,
usage=inject for an injecting agent, and usage=relay for a relaying usage=inject for an injecting agent, and usage=relay for a relaying
agent. The entity receiving the article may only implement one type agent. The entity receiving the article may only implement one type
of agent, in which case the parameter MAY be omitted. of agent, in which case the parameter MAY be omitted.
Contrary to the prior registration of this media type, article Contrary to the prior registration of this media type, article
batches are not permitted as a body part. Multiple messages or a batches are not permitted as a body part. Multiple messages or a
message with multiple application/news-transmission parts may be used message with multiple application/news-transmission parts may be used
instead. instead.
skipping to change at page 29, line 22 skipping to change at page 30, line 22
The application/news-groupinfo media type is used in conjunction with The application/news-groupinfo media type is used in conjunction with
the newgroup control message (see Section 5.2.1). Its body part the newgroup control message (see Section 5.2.1). Its body part
contains brief information about a newsgroup: the newsgroup name, its contains brief information about a newsgroup: the newsgroup name, its
description, and its moderation status. description, and its moderation status.
The MIME media type definition of application/news-groupinfo is: The MIME media type definition of application/news-groupinfo is:
MIME type name: application MIME type name: application
MIME subtype name: news-groupinfo MIME subtype name: news-groupinfo
Required parameters: none Required parameters: none
Optional parameters: charset, which MUST be a charset registered Optional parameters: charset, which MUST be a charset
for use with MIME text types and has the registered for use with MIME text types
same syntax as the parameter defined for and has the same syntax as the parameter
text/plain [RFC2046]. Specifies the defined for text/plain [RFC2046].
charset of the body part. If not given, Specifies the charset of the body part.
the charset defaults to US-ASCII [ASCII]. If not given, the charset defaults to
US-ASCII [ASCII].
Disposition: by default, inline Disposition: by default, inline
Encoding considerations: 7bit or 8bit MUST be used to maintain Encoding considerations: 7bit or 8bit MUST be used to maintain
compatibility. compatibility.
Security considerations: None. Security considerations: None.
Published specification: This specification. Published specification: This specification.
The content of the application/news-groupinfo body part is defined The content of the application/news-groupinfo body part is defined
as: as:
groupinfo-body = [ newsgroups-tag CRLF ] groupinfo-body = [ newsgroups-tag CRLF ]
skipping to change at page 30, line 34 skipping to change at page 32, line 10
The application/news-checkgroups media type contains a list of The application/news-checkgroups media type contains a list of
newsgroups within a hierarchy or hierarchies, including their newsgroups within a hierarchy or hierarchies, including their
descriptions and moderation status. It is primarily for use with the descriptions and moderation status. It is primarily for use with the
checkgroups control message (see Section 5.2.3). checkgroups control message (see Section 5.2.3).
The MIME media type definition of application/news-checkgroups is: The MIME media type definition of application/news-checkgroups is:
MIME type name: application MIME type name: application
MIME subtype name: news-checkgroups MIME subtype name: news-checkgroups
Required parameters: none Required parameters: none
Optional parameters: charset, which MUST be a charset registered Optional parameters: charset, which MUST be a charset
for use with MIME text types and has the registered for use with MIME text types
same syntax as the parameter defined for and has the same syntax as the parameter
text/plain [RFC2046]. Specifies the defined for text/plain [RFC2046].
charset of the body part. If not given, Specifies the charset of the body part.
the charset defaults to US-ASCII [ASCII]. If not given, the charset defaults to
US-ASCII [ASCII].
Disposition: by default, inline Disposition: by default, inline
Encoding considerations: 7bit or 8bit MUST be used to maintain Encoding considerations: 7bit or 8bit MUST be used to maintain
compatibility. compatibility.
Security considerations: This media type provides only a means for Security considerations: This media type provides only a means
conveying a list of newsgroups and does not for conveying a list of newsgroups and
provide any information indicating whether does not provide any information
the sender is authorized to state which indicating whether the sender is
newsgroups should exist within a hierarchy. authorized to state which newsgroups
Such authorization must be accomplished by should exist within a hierarchy. Such
authorization must be accomplished by
other means. other means.
Published specification: This specification. Published specification: This specification.
The content of the application/news-groupinfo body part is defined The content of the application/news-groupinfo body part is defined
as: as:
checkgroups-body = *( valid-group CRLF ) checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see 4.2 valid-group = newsgroups-line ; see 4.2
The same restrictions on charset, <newsgroup-name>, and <newsgroup- The same restrictions on charset, <newsgroup-name>, and <newsgroup-
skipping to change at page 33, line 34 skipping to change at page 34, line 34
All of the group control messages MUST have an Approved header field All of the group control messages MUST have an Approved header field
(Section 3.2.1 of [USEFOR]). Group control messages without an (Section 3.2.1 of [USEFOR]). Group control messages without an
Approved header field SHOULD NOT be honored. Approved header field SHOULD NOT be honored.
Group control messages affecting specific groups (newgroup and Group control messages affecting specific groups (newgroup and
rmgroup control messages, for example) SHOULD include the <newsgroup- rmgroup control messages, for example) SHOULD include the <newsgroup-
name> for the group or groups affected in their Newsgroups header name> for the group or groups affected in their Newsgroups header
field. Other newsgroups MAY be included in the Newsgroups header field. Other newsgroups MAY be included in the Newsgroups header
field so that the control message will reach more news servers, but field so that the control message will reach more news servers, but
due to the special relaying rules for group control messages (see due to the special relaying rules for group control messages (see
Section 3.5) this is normally unnecessary and may be excessive. Section 3.6) this is normally unnecessary and may be excessive.
5.2.1. The newgroup Control Message 5.2.1. The newgroup Control Message
The newgroup control message requests the specified group be created The newgroup control message requests the specified group be created
or, if already existing, have its moderation status or description or, if already existing, have its moderation status or description
changed. The syntax of its Control header field is: changed. The syntax of its Control header field is:
control-command =/ Newgroup-command control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments Newgroup-command = "newgroup" Newgroup-arguments
Newgroup-arguments = 1*WSP newsgroup-name [ 1*WSP newgroup-flag ] Newgroup-arguments = 1*WSP newsgroup-name
[ 1*WSP newgroup-flag ]
newgroup-flag = "moderated" newgroup-flag = "moderated"
If the request is honored, the moderation status of the group SHOULD If the request is honored, the moderation status of the group SHOULD
be set in accordance with the presence or absence of the <newgroup- be set in accordance with the presence or absence of the <newgroup-
flag> "moderated". "moderated" is the only flag defined by this flag> "moderated". "moderated" is the only flag defined by this
protocol. Other flags MAY be defined by extensions to this protocol protocol. Other flags MAY be defined by extensions to this protocol
and accepted by agents. If an agent does not recognize the and accepted by agents. If an agent does not recognize the
<newgroup-flag> of a newgroup control message, it SHOULD ignore that <newgroup-flag> of a newgroup control message, it SHOULD ignore that
control message. control message.
skipping to change at page 44, line 9 skipping to change at page 45, line 9
application/news-transmission is a change to a previous registration. application/news-transmission is a change to a previous registration.
IANA is also requested to change the status of the message/news media IANA is also requested to change the status of the message/news media
type to "OBSOLETE". message/rfc822 should be used instead. type to "OBSOLETE". message/rfc822 should be used instead.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASCII] "American National Standard for Information Systems - [ASCII] American National Standard for Information Systems, "Coded
Coded Character Sets - 7-Bit American National Standard Character Sets - 7-Bit American National Standard Code for
Code for Information Interchange (7-Bit ASCII)", Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
ANSI X3.4, 1986.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
skipping to change at page 46, line 12 skipping to change at page 47, line 12
[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:
o A new, backward-compatible Path header field format that permits o A new, backward-compatible Path header field format that permits
standardized embedding of additional trace and authentication standardized embedding of additional trace and authentication
information is now RECOMMENDED. See Section 3.4 and Section 3.5. information is now RECOMMENDED. See Section 3.5 and Section 3.6.
Folding of the Path header is permitted. Folding of the Path header is permitted.
o Trimming of the References header field is REQUIRED and a o Trimming of the References header field is REQUIRED and a
mechanism for doing so is defined. mechanism for doing so is defined.
o Addition of the new Injection-Date header field is required for o Addition of the new Injection-Date header field is required for
injecting agents (Section 3.4) and MUST be used by news servers injecting agents (Section 3.5) and MUST be used by news servers
for date checks (Section 3.5). Injecting agents are strongly for date checks (Section 3.6). Injecting agents are strongly
encouraged to put all local trace information in the new encouraged to put all local trace information in the new
Injection-Info header field. Injection-Info header field.
o A new media type is defined for transmitting Netnews articles o A new media type is defined for transmitting Netnews articles
through other media (Section 4.1), and moderators SHOULD prepare through other media (Section 4.1), and moderators SHOULD prepare
to receive submissions in that format (Section 3.4.1). to receive submissions in that format (Section 3.5.1).
o Certain control messages (Section 5.6) are declared obsolete, and o Certain control messages (Section 5.6) are declared obsolete, and
the special significance of "cmsg" at the start of a Subject the special significance of "cmsg" at the start of a Subject
header field is removed. header field is removed.
o Additional media types are defined for improved structuring, o Additional media types are defined for improved structuring,
specification, and automated processing of control messages specification, and automated processing of control messages
(Section 4.2 and Section 4.3). (Section 4.2 and Section 4.3).
o Two new optional parameters are added to the checkgroups control o Two new optional parameters are added to the checkgroups control
skipping to change at page 49, line 7 skipping to change at page 50, line 7
Heald Green Heald Green
Cheadle Cheadle
Cheshire SK8 3JU Cheshire SK8 3JU
United Kingdom United Kingdom
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clerew.man.ac.uk Email: chl@clerew.man.ac.uk
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 49, line 44 skipping to change at line 2022
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 44 change blocks. 
124 lines changed or deleted 177 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/