draft-ietf-usefor-usepro-01.txt   draft-ietf-usefor-usepro-02.txt 
INTERNET-DRAFT Charles H. Lindsey INTERNET-DRAFT Charles H. Lindsey
Usenet Format Working Group University of Manchester Usenet Format Working Group University of Manchester
September 2004 December 2004
News Article Architecture and Protocols News Article Architecture and Protocols
<draft-ietf-usefor-usepro-01.txt> <draft-ietf-usefor-usepro-02.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in disclosed, or will be disclosed, and any of which I become aware
accordance with RFC 3668. will be disclosed, in accordance with RFC 3668.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.html.
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 in March 2005. This Internet-Draft will expire in June 2005.
Abstract Abstract
This Draft, together with its companion draft [USEFOR], are This Draft, together with its companion draft [USEFOR], are
intended as standards track documents, together obsoleting RFC intended as standards track documents, together obsoleting RFC
1036, which itself dates from 1987. 1036, which itself dates from 1987.
This Standard defines the architecture of Netnews systems and This Standard defines the architecture of Netnews systems and
specifies the requirements to be met by software which originates, specifies the requirements to be met by software which originates,
distributes, stores and displays Netnews articles. distributes, stores and displays Netnews articles.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
technology is now in widespread use for other purposes. technology is now in widespread use for other purposes.
Backward compatibility has been a major goal of this endeavour, but Backward compatibility has been a major goal of this endeavour, but
where this standard and earlier documents or practices conflict, this where this standard and earlier documents or practices conflict, this
standard should be followed. In most such cases, current practice is standard should be followed. In most such cases, current practice is
already compatible with these changes. already compatible with these changes.
A companion Current Best Practice document [USEAGE], addressing A companion Current Best Practice document [USEAGE], addressing
requirements which are present for Social rather than Normative requirements which are present for Social rather than Normative
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
reasons is in preparation. reasons is in preparation.
[The use of the words "this standard" within this document when [The use of the words "this standard" within this document when
referring to itself does not imply that this draft yet has pretensions referring to itself does not imply that this draft yet has pretensions
to be a standard, but rather indicates what will become the case if and to be a standard, but rather indicates what will become the case if and
when it is accepted as an RFC with the status of a proposed or draft when it is accepted as an RFC with the status of a proposed or draft
standard.] standard.]
[Remarks enclosed in square brackets and aligned with the left margin, [Remarks enclosed in square brackets and aligned with the left margin,
skipping to change at page 2, line 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction .................................................. 4 1. Introduction .................................................. 4
1.1. Basic Concepts ............................................ 4 1.1. Basic Concepts ............................................ 4
1.2. Objectives ................................................ 5 1.2. Objectives ................................................ 5
1.3. Historical Outline ........................................ 5 1.3. Historical Outline ........................................ 5
2. Definitions, Notations and Conventions ........................ 6 2. Definitions, Notations and Conventions ........................ 6
2.1. Definitions ............................................... 6 2.1. Definitions ............................................... 6
2.2. Defining the Architecture ................................. 7 2.2. Defining the Architecture ................................. 7
2.3. Textual Notations ......................................... 8 2.3. Header Properties ......................................... 8
3. Changes to the existing protocols ............................. 9 2.3.1. Inheritable Headers ................................... 8
3.1. Principal Changes ......................................... 9 2.3.2. Variant Headers ....................................... 9
3.2. Transitional Arrangements ................................. 10 2.4. Textual Notations ......................................... 9
4. Transport ..................................................... 11 3. Changes to the existing protocols ............................. 10
5. Definition of new Media Types ................................. 11 3.1. Principal Changes ......................................... 10
5.1. Application/news-transmission ............................. 11 3.2. Transitional Arrangements ................................. 11
5.2. Message/news obsoleted .................................... 12 4. Transport ..................................................... 12
5.3. Application/news-groupinfo ................................ 13 5. Definition of new Media Types ................................. 12
5.4. Application/news-checkgroups .............................. 14 5.1. Application/news-transmission ............................. 12
6. Control Messages .............................................. 14 5.2. Message/news obsoleted .................................... 13
6.1. Digital Signature of Headers .............................. 15 5.3. Application/news-groupinfo ................................ 14
6.2. Group Control Messages .................................... 15 5.4. Application/news-checkgroups .............................. 15
6.2.1. The 'newgroup' Control Message ........................ 15 6. Control Messages .............................................. 15
6.2.1.1. The Body of the 'newgroup' Control Message ........ 16 6.1. Digital Signature of Headers .............................. 16
6.2.1.2. Initial Articles .................................. 16 6.2. Group Control Messages .................................... 17
6.2.1.3. Example ........................................... 17 6.2.1. The 'newgroup' Control Message ........................ 17
6.2.2. The 'rmgroup' Control Message ......................... 17 6.2.1.1. The Body of the 'newgroup' Control Message ........ 17
6.2.2.1. Example ........................................... 18 6.2.1.2. Initial Articles .................................. 18
6.2.3. The 'mvgroup' Control Message ......................... 18 6.2.1.3. Example ........................................... 19
6.2.3.1. Example ........................................... 19 6.2.2. The 'rmgroup' Control Message ......................... 19
6.2.4. The 'checkgroups' Control Message ..................... 20 6.2.2.1. Example ........................................... 20
6.3. Cancel .................................................... 21 6.2.3. The 'mvgroup' Control Message ......................... 20
6.4. Ihave, sendme ............................................. 22 6.2.3.1. Example ........................................... 21
6.5. Obsolete control messages. ............................... 24 6.2.4. The 'checkgroups' Control Message ..................... 22
7. Duties of Various Agents ...................................... 24 6.3. Cancel .................................................... 23
7.1. General principles to be followed ......................... 24 6.4. Ihave, sendme ............................................. 24
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
7.2. Duties of an Injecting Agent .............................. 25 6.5. Obsolete control messages. ............................... 26
7.2.1. Proto-articles ........................................ 25 7. Duties of Various Agents ...................................... 26
7.2.2. Procedure to be followed by Injecting Agents .......... 26 7.1. General principles to be followed ......................... 26
7.2.3. Procedure for Forwarding to a Moderator ............... 28 7.2. Duties of an Injecting Agent .............................. 27
7.3. Duties of a Relaying Agent ................................ 29 7.2.1. Proto-articles ........................................ 27
7.3.1. Path-Header Example ................................... 31 7.2.2. Procedure to be followed by Injecting Agents .......... 28
7.4. Duties of a Serving Agent ................................. 32 7.2.3. Procedure for Forwarding to a Moderator ............... 30
7.5. Duties of a Posting Agent ................................. 33 7.3. Duties of a Relaying Agent ................................ 31
7.6. Duties of a Followup Agent ................................ 34 7.3.1. Path-Header Example ................................... 33
7.7. Duties of a Reading Agent ................................. 35 7.4. Duties of a Serving Agent ................................. 34
7.8. Duties of a Moderator ..................................... 35 7.5. Duties of a Posting Agent ................................. 35
7.9. Duties of a Gateway ....................................... 37 7.6. Duties of a Followup Agent ................................ 36
7.9.1. Duties of an Outgoing Gateway ......................... 38 7.7. Duties of a Reading Agent ................................. 37
7.9.2. Duties of an Incoming Gateway ......................... 39 7.8. Duties of a Moderator ..................................... 37
7.9.3. Example ............................................... 41 7.9. Duties of a Gateway ....................................... 39
8. Security and Related Considerations ........................... 42 7.9.1. Duties of an Outgoing Gateway ......................... 40
8.1. Leakage ................................................... 42 7.9.2. Duties of an Incoming Gateway ......................... 41
8.2. Attacks ................................................... 42 7.9.3. Example ............................................... 43
8.2.1. Denial of Service ..................................... 42 8. Security and Related Considerations ........................... 44
8.2.2. Compromise of System Integrity ........................ 44 8.1. Leakage ................................................... 44
8.3. Liability ................................................. 45 8.2. Attacks ................................................... 44
9. IANA Considerations ........................................... 45 8.2.1. Denial of Service ..................................... 44
10. References ................................................... 45 8.2.2. Compromise of System Integrity ........................ 46
11. Acknowledgements ............................................. 47 8.3. Liability ................................................. 47
12. Contact Address .............................................. 47 9. IANA Considerations ........................................... 47
Appendix A.1 - A-News Article Format .............................. 47 10. References ................................................... 47
Appendix A.2 - Early B-News Article Format ........................ 48 11. Acknowledgements ............................................. 49
Appendix A.3 - Obsolete Control Messages .......................... 48 12. Contact Address .............................................. 49
Appendix B - Notices .............................................. 49 Appendix A.1 - A-News Article Format .............................. 49
Appendix C - Change Log ........................................... 50 Appendix A.2 - Early B-News Article Format ........................ 50
Appendix A.3 - Obsolete Control Messages .......................... 50
Appendix B - Notices .............................................. 51
Appendix C - Change Log ........................................... 52
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
[This draft [USEPRO] and its partner [USEFOR] are an interim stage in [This draft [USEPRO] and its partner [USEFOR] are an interim stage in
the splitting into two parts of the earlier draft [ARTICLE]. There is a the splitting into two parts of the earlier draft [ARTICLE]. There is a
certain amount of material - basic concepts, definitions, etc - which certain amount of material - basic concepts, definitions, etc - which
ultimately need occur in only one of the documents, and further such ultimately need occur in only one of the documents, and further such
material which may not be needed at all (e.g. terms currently defined material which may not be needed at all (e.g. terms currently defined
which in the event may not get used). For the moment, all such material which in the event may not get used). For the moment, all such material
has been retained in the present draft (it being, in any case, easier to has been retained in the present draft (it being, in any case, easier to
take unwanted stuff out than to put new stuff in). It has also to be take unwanted stuff out than to put new stuff in). It has also to be
decided, for such material which is needed by both documents, which one decided, for such material which is needed by both documents, which one
skipping to change at page 5, line 5 skipping to change at page 5, line 5
recognized "hierarchies". Anybody can join (it is simply necessary recognized "hierarchies". Anybody can join (it is simply necessary
to negotiate an exchange of articles with one or more other to negotiate an exchange of articles with one or more other
participating hosts). participating hosts).
A "policy" is a rule intended to facilitate the smooth operation of a A "policy" is a rule intended to facilitate the smooth operation of a
network by establishing parameters which restrict behaviour that, network by establishing parameters which restrict behaviour that,
whilst technically unexceptionable, would nevertheless contravene whilst technically unexceptionable, would nevertheless contravene
some accepted standard of "Good Netkeeping". Since the ultimate some accepted standard of "Good Netkeeping". Since the ultimate
beneficiaries of a network are its human readers, who will be less beneficiaries of a network are its human readers, who will be less
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
tolerant of poorly designed interfaces than mere computers, articles tolerant of poorly designed interfaces than mere computers, articles
in breach of established policy can cause considerable annoyance to in breach of established policy can cause considerable annoyance to
their recipients. their recipients.
1.2. Objectives 1.2. Objectives
The purpose of this present standard is to define the overall The purpose of this present standard is to define the overall
architecture and the protocols to be used for Netnews in general, and architecture and the protocols to be used for Netnews in general, and
for Usenet in particular, and to set standards to be followed by for Usenet in particular, and to set standards to be followed by
skipping to change at page 6, line 5 skipping to change at page 6, line 5
A Draft popularly referred to as "Son of 1036" [Son-of-1036] was A Draft popularly referred to as "Son of 1036" [Son-of-1036] was
written in 1994 by Henry Spencer. Much is taken directly from Son of written in 1994 by Henry Spencer. Much is taken directly from Son of
1036, and it is hoped that we have followed its spirit and 1036, and it is hoped that we have followed its spirit and
intentions. intentions.
[It is anticipated that [Son-of-1036] will shortly be published as an [It is anticipated that [Son-of-1036] will shortly be published as an
informational RFC (for purposes of historical documentation only), in informational RFC (for purposes of historical documentation only), in
which case most historical information can be removed from this draft, which case most historical information can be removed from this draft,
including the whole of Appendix A.1 and Appendix A.2.] including the whole of Appendix A.1 and Appendix A.2.]
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
2. Definitions, Notations and Conventions 2. Definitions, Notations and Conventions
2.1. Definitions 2.1. Definitions
An "article" is the unit of news, synonymous with an [RFC 2822] An "article" is the unit of news, synonymous with an [RFC 2822]
"message". "message". A "proto-article" (7.2.1) is one that has been created by
a "posting agent" but has not yet been injected into a Netnews system
A "proto-article" (7.2.1) is one that has been created by a "posting system by an "injecting agent". It may lack some otherwise mandatory
agent" but has not yet been injected into a Netnews system system by headers.
an "injecting agent". It may lack some otherwise mandatory headers.
A "message identifier" (a-5.3) is a unique identifier for an article, A "message identifier" (a-5.3) is a unique identifier for an article,
usually supplied by the posting agent which posted it or, failing usually supplied by the posting agent which posted it or, failing
that, by the injecting agent. It distinguishes the article from every that, by the injecting agent. It distinguishes the article from every
other article ever posted anywhere. Articles with the same message other article ever posted anywhere. Articles with the same message
identifier are treated as if they are the same article regardless of identifier are treated as if they are the same article regardless of
any differences in the body or headers. any differences in the body or headers.
A "newsgroup" is a single news forum, a logical bulletin board, A "newsgroup" is a single news forum, a logical bulletin board,
having a name and nominally intended for articles on a specific having a name and nominally intended for articles on a specific
skipping to change at page 6, line 41 skipping to change at page 6, line 40
A newsgroup may be "moderated", in which case submissions are not A newsgroup may be "moderated", in which case submissions are not
posted directly, but mailed to a "moderator" for consideration and posted directly, but mailed to a "moderator" for consideration and
possible posting. Moderators are typically human but may be possible posting. Moderators are typically human but may be
implemented partially or entirely in software. implemented partially or entirely in software.
A "hierarchy" is the set of all newsgroups whose names share a first A "hierarchy" is the set of all newsgroups whose names share a first
component (as defined in a-5.5). The term "sub-hierarchy" is also component (as defined in a-5.5). The term "sub-hierarchy" is also
used where several initial components are shared. used where several initial components are shared.
A "poster" is the person or software that composes and submits a A "poster" is the person or software that composes a possibly
possibly compliant article to a posting agent. The poster is compliant article for submission to a posting agent. The poster is
synonymous with [RFC 2822]'s author. synonymous with [RFC 2822]'s author.
A "reader" is the person or software reading news articles. A "reader" is the person or software reading news articles.
A "followup" is an article containing a response to the contents of [Alternative-1.]
an earlier article (the followup's "precursor").
[Alternative definition, to bu ised if similar woprding is not added to
the description of the References-header (a-6.10):]
A "followup" is an article containing a response to the contents of A "followup" is an article containing a response to the contents of
an earlier article (its "precursor"), or which is otherwise intended an earlier article.
to be grouped with that article for purposes of display (e.g. as part
of a multipart posting such as a FAQ). An article is a "precursor" of some later article which is a followup
to it, or which is otherwise intended to be grouped with it for
purposes of display (e.g. as a part of a multipart posting such as a
FAQ).
[Alternative-2.]
A "followup" to an earlier article (its "precursor") is one intended
to be grouped with that article for purposes of display (e.g. because
it is a response to its contents or is a part of a multipart posting
News Article Architecture and Protocols December 2004
such as a FAQ).
[End of alternatives]
An (email) "address" is the mailbox [RFC 2822] (or more particularly An (email) "address" is the mailbox [RFC 2822] (or more particularly
the addr-spec within that mailbox) which directs the delivery of an the addr-spec within that mailbox) which directs the delivery of an
email to its intended recipient, who is said to "own" that address. email to its intended recipient, who is said to "own" that address.
News Article Architecture and Protocols September 2004
An article's "reply address" is the address to which mailed replies An article's "reply address" is the address to which mailed replies
should be sent. This is the address specified in the article's From- should be sent. This is the address specified in the article's From-
header (a-5.2), unless it also has a Reply-To-header (a-6.1). header (a-5.2), unless it also has a Reply-To-header (a-6.1).
A "sender" is the person or software (usually, but not always, the A "sender" is the person or software (usually, but not always, the
same as the poster) responsible for the operation of the posting same as the poster) responsible for the operation of the posting
agent or, which amounts to the same thing, for passing the article to agent or, which amounts to the same thing, for passing the article to
the injecting agent. the injecting agent.
[Is the definition in RFC 2822 sufficient?]
A "control message" is an article which is marked as containing A "control message" is an article which is marked as containing
control information; a "serving agent" receiving such an article may control information; a "serving agent" (and in some cases a "relaying
(subject to the policies observed at that site) take actions beyond agent") receiving such an article may (subject to the policies
just filing and passing on the article. observed at that site) take actions beyond just filing and passing on
the article.
2.2. Defining the Architecture 2.2. Defining the Architecture
A Netnews system is a distributed database composed of "agents" of A Netnews system is a distributed database composed of "agents" of
various types which, acting together according to the protocols various types which, acting together according to the protocols
defined in section 7 of this standard, causes articles to be defined in section 7 of this standard, causes articles to be
propagated throughout the system and to be made available to its propagated throughout the system and to be made available to its
readers. The protocols ensure that all copies of a given article, readers. The protocols ensure that all copies of a given article,
wherever stored, are identical apart from those headers defined as wherever stored, are identical apart from those headers defined as
variant (a-4.2.5.3). variant (a-4.2.5.3).
A "posting agent" is the software that assists posters to prepare A "posting agent" is the software that assists posters to prepare
proto-articles in compliance with [USEFOR]. The proto-article is proto-articles in compliance with [USEFOR]. The proto-article is
then passed on to an "injecting agent" for final checking and then passed on to an "injecting agent" for final checking and
injection into the news stream. If the article is not compliant, or injection into the news stream. If the article is not compliant, or
is rejected by the injecting agent, then the posting agent informs is rejected by the injecting agent, then the posting agent informs
the poster with an explanation of the error. the poster with an explanation of the error.
A "reading agent" is software which presents articles to a reader. A "reading agent" is software which presents articles to a reader.
[Alternative-1.]
A "followup agent" is a combination of reading agent and posting A "followup agent" is a combination of reading agent and posting
agent that aids in the preparation and posting of a followup. agent that aids in the preparation and posting of a followup.
[Alternative definition, to be used if the alternative definition for
"followup" is used:] [Alternative-2.]
A "followup agent" is a combination of reading agent and posting A "followup agent" is a combination of reading agent and posting
agent that aids in the preparation and posting of a response intended agent that aids in the preparation and posting of an article which is
as a followup to a precursor. a response to some precursor.
News Article Architecture and Protocols December 2004
[End of alternatives]
An "injecting agent" takes the finished article from the posting An "injecting agent" takes the finished article from the posting
agent (often via the NNTP "POST" command), performs some final checks agent (often via the NNTP "POST" command), performs some final checks
and passes it on to a "relaying agent" for general distribution. It and passes it on to a "relaying agent" for general distribution. It
is expected to bear some responsibility towards the rest of the is expected to bear some responsibility towards the rest of the
network for the behaviour of its posters (and provision is therefore network for the behaviour of its posters (and provision is therefore
made for it to be easily contactable by email). made for it to be easily contactable by email).
A "relaying agent" is software which receives allegedly compliant A "relaying agent" is software which receives allegedly compliant
articles from injecting agents and/or other relaying agents, and articles from injecting agents and/or other relaying agents, and
possibly passes copies on to other relaying agents and "serving possibly passes copies on to other relaying agents and "serving
agents". agents".
News Article Architecture and Protocols September 2004
A "serving agent" receives an article from a relaying agent and files A "serving agent" receives an article from a relaying agent and files
it in a "news database". It also provides an interface for reading it in a "news database". It also provides an interface for reading
agents to access the news database. agents to access the news database.
A "news database" is the set of articles and related structural A "news database" is the set of articles and related structural
information stored by a serving agent and made available for access information stored by a serving agent and made available for access
by reading agents. by reading 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 (e.g. mail to a mailing list), or them to messages of some other kind (e.g. mail to a mailing list), or
skipping to change at page 8, line 28 skipping to change at page 8, line 42
straddles boundaries between different methods of message exchange. straddles boundaries between different methods of message exchange.
The most common type of gateway connects newsgroup(s) to mailing The most common type of gateway connects newsgroup(s) to mailing
list(s), either unidirectionally or bidirectionally, but there are list(s), either unidirectionally or bidirectionally, but there are
also gateways between news networks using this standard's news format also gateways between news networks using this standard's news format
and those using other formats. and those using other formats.
Posting, reading and followup agents (which are usually just Posting, reading and followup agents (which are usually just
different services provided by the same piece of software) are known different services provided by the same piece of software) are known
collectively as "user agents". collectively as "user agents".
2.3. Textual Notations 2.3. Header Properties
There are two special properties that may apply to particular
headers, namely: "inheritable", and "variant". When a header is
defined, in this (or any future) standard, as having one (or possibly
more) of these properties, it is subject to special treatment, as
indicated below.
2.3.1. Inheritable Headers
Subject only to the overriding ability of the poster to determine the
contents of the headers in a proto-article, headers with the
inheritable property MUST be copied by followup agents (perhaps with
some modification) into the followup article, and headers without
that property MUST NOT be so copied.
The following headers (see [USEFOR] for their definitions) are
classified as "inheritable":
o Newsgroups (a-5.5) - copied from the precursor, subject to any
News Article Architecture and Protocols December 2004
Followup-To-header.
o Subject (a-5.4) - often modified by prefixing with "Re: ", but
otherwise copied from the precursor.
o References (a-6.10) - copied from the precursor, with the
addition of the precursor's Message-ID.
o Distribution (a-6.6) - copied from the precursor.
NOTE: The Keywords-header is not inheritable, though some older
newsreaders treated it as such.
2.3.2. Variant Headers
Headers with the variant property may differ between (or even be
completely absent from) copies of the same article as stored or
relayed throughout a Netnews system. The manner of the difference (or
absence) MUST be as specified in this (or some future) standard.
Typically, these headers are modified as articles are propagated, or
they reflect the status of the article on a particular serving agent,
or cooperating group of such agents. The variant header MAY be placed
anywhere within the headers (though placing it first is recommended).
The following headers (see [USEFOR] for their definitions) are
classified as "variant":
o Path (a-5.6) - augmented at each relaying agent that an article
passes through.
o Xref (a-6.16) - used to keep track of the article locators of
crossposted articles so that reading agents serviced by a
particular serving agent can mark such articles as read.
2.4. Textual Notations
This standard contains explanatory NOTEs using the following format. This standard contains explanatory NOTEs using the following format.
These may be skipped by persons interested solely in the content of These may be skipped by persons interested solely in the content of
the specification. The purpose of the notes is to explain why choices the specification. The purpose of the notes is to explain why choices
were made, to place them in context, or to suggest possible were made, to place them in context, or to suggest possible
implementation techniques. implementation techniques.
NOTE: While such explanatory notes may seem superfluous in NOTE: While such explanatory notes may seem superfluous in
principle, they often help the less-than-omniscient reader grasp principle, they often help the less-than-omniscient reader grasp
the purpose of the specification and the constraints involved. the purpose of the specification and the constraints involved.
skipping to change at page 8, line 53 skipping to change at page 10, line 4
"US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4]. "US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4].
US-ASCII is a 7 bit character set. Please note that this standard US-ASCII is a 7 bit character set. Please note that this standard
requires that all agents be 8 bit clean; that is, they must accept requires that all agents be 8 bit clean; that is, they must accept
and transmit data without changing or omitting the 8th bit. and transmit data without changing or omitting the 8th bit.
Certain words, when capitalized, are used to define the significance Certain words, when capitalized, are used to define the significance
of individual requirements. The key words "MUST", "REQUIRED", of individual requirements. The key words "MUST", "REQUIRED",
"SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words
associated with the word "NOT", are to be interpreted as described in associated with the word "NOT", are to be interpreted as described in
News Article Architecture and Protocols December 2004
[RFC 2119]. [RFC 2119].
NOTE: The use of "MUST" or "SHOULD" implies a requirement that NOTE: The use of "MUST" or "SHOULD" implies a requirement that
would or could lead to interoperability problems if not would or could lead to interoperability problems if not
followed. followed.
News Article Architecture and Protocols September 2004
NOTE: A requirement imposed on a relaying or serving agent NOTE: A requirement imposed on a relaying or serving agent
regarding some particular article should be understood as regarding some particular article should be understood as
applying only if that article is actually accepted for applying only if that article is actually accepted for
processing (since any agent may always reject any article processing (since any agent may always reject any article
entirely, for reasons of site policy). entirely, for reasons of site policy).
Wherever the context permits, use of the masculine includes the Wherever the context permits, use of the masculine includes the
feminine and use of the singular includes the plural, and vice versa. feminine and use of the singular includes the plural, and vice versa.
Throughout this standard we will give examples of various Throughout this standard we will give examples of various
skipping to change at page 9, line 53 skipping to change at page 10, line 59
certainty. certainty.
o Large parts of MIME are recognized as an integral part of o Large parts of MIME are recognized as an integral part of
Netnews. Netnews.
o There is a new Control message 'mvgroup' to facilitate moving a o There is a new Control message 'mvgroup' to facilitate moving a
group to a different place (name) in a hierarchy. group to a different place (name) in a hierarchy.
o There is a new mandatory Injection-Date-header to facilitate the o There is a new mandatory Injection-Date-header to facilitate the
rejection of stale articles. rejection of stale articles.
o There are several new optional headers defined, notably Archive, o There are several new optional headers defined, notably Archive,
Complaints-To, Injection-Info, Mail-Copies-To, Posted-And-Mailed Complaints-To, Injection-Info, Mail-Copies-To, Posted-And-Mailed
and User-Agent, leading to increased functionality. and User-Agent, leading to increased functionality.
o Provision has been made for almost all headers to have MIME-style
parameters (to be ignored if not recognized), thus facilitating
extension of those headers in future standards.
o Certain headers and Control messages (a-Appendix A.3 and Appendix o Certain headers and Control messages (a-Appendix A.3 and Appendix
A.3) have been made obsolete. A.3) have been made obsolete.
News Article Architecture and Protocols December 2004
o Distributions are expected to be checked at the receiving end, as o Distributions are expected to be checked at the receiving end, as
well as the sending end, of a relaying link. well as the sending end, of a relaying link.
o There are numerous other small changes, clarifications and o There are numerous other small changes, clarifications and
News Article Architecture and Protocols September 2004
enhancements. enhancements.
3.2. Transitional Arrangements 3.2. Transitional Arrangements
An important distinction must be made between serving and relaying An important distinction must be made between serving and relaying
agents, which are responsible for the distribution and storage of agents, which are responsible for the distribution and storage of
news articles, and user agents, which are responsible for news articles, and user agents, which are responsible for
interactions with users. It is important that the former should be interactions with users. It is important that the former should be
upgraded to conform to this standard as soon as possible to provide upgraded to conform to this standard as soon as possible to provide
the benefit of the enhanced facilities. Fortunately, the number of the benefit of the enhanced facilities. Fortunately, the number of
skipping to change at page 10, line 58 skipping to change at page 12, line 4
standards (using strict US-ASCII) will be unaffected. Many user standards (using strict US-ASCII) will be unaffected. Many user
agents already support it, at least to the extent of widely used agents already support it, at least to the extent of widely used
charsets such as ISO-8859-1. Users expecting to read articles charsets such as ISO-8859-1. Users expecting to read articles
using other charsets will need to acquire suitable reading using other charsets will need to acquire suitable reading
agents. It is not intended, in general, that any single user agents. It is not intended, in general, that any single user
agent will be able to display every charset known to IANA, but agent will be able to display every charset known to IANA, but
all such agents MUST support US-ASCII. Serving and relaying all such agents MUST support US-ASCII. Serving and relaying
agents are not affected. agents are not affected.
o The new Control: mvgroup command will need to be implemented in o The new Control: mvgroup command will need to be implemented in
serving agents. For the benefit of older serving agents it is serving agents. For the benefit of older serving agents it is
News Article Architecture and Protocols December 2004
therefore RECOMMENDED that it be followed shortly by a therefore RECOMMENDED that it be followed shortly by a
corresponding newgroup command and it MUST always be followed by corresponding newgroup command and it MUST always be followed by
a rmgroup command for the old group after a reasonable overlap a rmgroup command for the old group after a reasonable overlap
News Article Architecture and Protocols September 2004
period. An implementation of the mvgroup command as an alias for period. An implementation of the mvgroup command as an alias for
the newgroup command would thus be minimally conforming. User the newgroup command would thus be minimally conforming. User
agents are unaffected. agents are unaffected.
o Provision is made for relaying and serving agents to use the o Provision is made for relaying and serving agents to use the
Date-header in the case of articles injected through existing Date-header in the case of articles injected through existing
agents which do not provide an Injection-Date-header. agents which do not provide an Injection-Date-header.
o All the headers newly introduced by this standard can safely be o All the headers newly introduced by this standard can safely be
ignored by existing software, albeit with loss of the new ignored by existing software, albeit with loss of the new
functionality. functionality.
skipping to change at page 11, line 57 skipping to change at page 13, line 4
5. Definition of new Media Types 5. Definition of new Media Types
This standard defines (or redefines) several new Media Types, which This standard defines (or redefines) several new Media Types, which
require to be registered with IANA as provided for in [RFC 2048]. require to be registered with IANA as provided for in [RFC 2048].
5.1. Application/news-transmission 5.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
News Article Architecture and Protocols December 2004
type provides one of the methods for mailing articles to moderators type provides one of the methods for mailing articles to moderators
(see 7.2.2) and it is also the preferred method when sending to an (see 7.2.2) and it is also the preferred method when sending to an
email-to-news gateway (see 7.9.2). email-to-news gateway (see 7.9.2).
News Article Architecture and Protocols September 2004
NOTE: The benefit of such encapsulation is that it removes NOTE: The benefit of such encapsulation is that it removes
possible conflict between news and email headers and it provides possible conflict between news and email headers and it provides
a convenient way of "tunnelling" a news article through a a convenient way of "tunnelling" a news article through a
transport medium that does not support 8bit characters. transport medium that does not support 8bit characters.
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
skipping to change at page 12, line 57 skipping to change at page 14, line 4
When the parameter "relay" is used, or implied, the body part MAY be When the parameter "relay" is used, or implied, the body part MAY be
a batch of articles to be transmitted together, in which case the a batch of articles to be transmitted together, in which case the
batch format defined in section 6.4 MUST be used. batch format defined in section 6.4 MUST be used.
5.2. Message/news obsoleted 5.2. Message/news obsoleted
The Media Type "message/news", as previously registered with IANA, is The Media Type "message/news", as previously registered with IANA, is
hereby declared obsolete. It was never widely implemented, and its hereby declared obsolete. It was never widely implemented, and its
default treatment as "application/octet-stream" by agents that did default treatment as "application/octet-stream" by agents that did
News Article Architecture and Protocols December 2004
not recognize it was counter productive. The Media Type not recognize it was counter productive. The Media Type
"message/rfc822" SHOULD be used in its place. "message/rfc822" SHOULD be used in its place.
News Article Architecture and Protocols September 2004
5.3. Application/news-groupinfo 5.3. Application/news-groupinfo
The "application/news-groupinfo" is used in conjunction with the The "application/news-groupinfo" is used in conjunction with the
"newgroup" (6.2.1) and "mvgroup" (6.2.3) control messages. The "newgroup" (6.2.1) and "mvgroup" (6.2.3) control messages. The
newsgroup-name in the newsgroups-line MUST agree with the newsgroup- newsgroup-name in the newsgroups-line MUST agree with the newsgroup-
name in the "newgroup" or "mvgroup" control message. The Media Type name in the "newgroup" or "mvgroup" control message. The Media Type
"application/news-groupinfo" MUST NOT be used except as a part of "application/news-groupinfo" MUST NOT be used except as a part of
such control messages. such control messages.
The "application/news-groupinfo" body part contains brief information The "application/news-groupinfo" body part contains brief information
skipping to change at page 13, line 58 skipping to change at page 15, line 4
[ 1*HTAB newsgroup-description ] [ 1*HTAB newsgroup-description ]
[ 1*WSP moderation-flag ] [ 1*WSP moderation-flag ]
newsgroup-description newsgroup-description
= utext *( *WSP utext ) = utext *( *WSP utext )
moderation-flag = %x28.4D.6F.64.65.72.61.74.65.64.29 moderation-flag = %x28.4D.6F.64.65.72.61.74.65.64.29
; case sensitive "(Moderated)" ; case sensitive "(Moderated)"
The newsgroup-description MUST NOT contain any occurrence of the The newsgroup-description MUST NOT contain any occurrence of the
string "(Moderated)" within it. Although optional, the newsgroups- string "(Moderated)" within it. Although optional, the newsgroups-
tag SHOULD be included until such time as this standard has been tag SHOULD be included until such time as this standard has been
widely adopted, to ensure compatibility with present practice.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
widely adopted, to ensure compatibility with present practice.
Moderated newsgroups MUST be marked by appending the case sensitive Moderated newsgroups MUST be marked by appending the case sensitive
text " (Moderated)" at the end. It is NOT recommended that the text " (Moderated)" at the end. It is NOT recommended that the
moderator's email address be included in the newsgroup-description as moderator's email address be included in the newsgroup-description as
has sometimes been done. has sometimes been done.
NOTE: There is no provision for the use of charsets other than NOTE: There is no provision for the use of charsets other than
US-ASCII within a newsgroup-description. Such a facility may be US-ASCII within a newsgroup-description. Such a facility may be
provided in a future extension to this standard. provided in a future extension to this standard.
[That may seem harsh, but if we make any such provision now, it will [That may seem harsh, but if we make any such provision now, it will
skipping to change at page 14, line 55 skipping to change at page 15, line 57
checkgroups-body = *( valid-group CRLF ) checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see 5.3 valid-group = newsgroups-line ; see 5.3
6. Control Messages 6. Control Messages
The following sections document the control messages. "Message" is The following sections document the control messages. "Message" is
used herein as a synonym for "article" unless context indicates used herein as a synonym for "article" unless context indicates
otherwise. otherwise.
Each control message comprises a verb, which indicates the action to
be taken, and argument(s), which supply the details. In some cases
the body of the article may also supply details. The following
News Article Architecture and Protocols December 2004
sections contain syntactic definitions for the verb, arguments, and
possibly the body, for each type of control message.
The Newsgroups-header of each control message SHOULD include the
newsgroup-name(s) for the group(s) affected (i.e. groups to be
created, modified or removed, or containing articles to be canceled).
This is to ensure that the message propagates to all sites which
receive (or would receive) that group(s). It MAY include other
newsgroup-names so as to improve propagation (but this practice may
cause the control message to propagate also to places where it is
unwanted, or even cause it not to propagate where it should, so it
should not be used without good reason).
NOTE: Propagation is controlled by relaying agents, and it may
be necessary for relaying agents to take special steps to ensure
that control messages such as newgroup messages for not-yet-
existent newsgroups are propagated correctly (see 7.3).
[The first of those paragraphs was originally scheduled to be moved to
USEFOR (and it may yet be so moved). It has been reinstated here (at
least temporarily) to make sure that it does not get overlooked.]
The presence of a Subject-content starting with the string "cmsg "
and followed by a <control-message> was construed under [RFC 1036] as
a request to perform that control action (even if no genuine Control
header was present). Indeed, some implementations went further and
added the implied Control header before injecting. Likewise, the
presence of a newsgroup-name ending in ".ctl" in the Newsgroups
header caused the Subject header content (not starting with "cmsg" in
this case) to be interpreted as a <control-message>.
All these practices are now declared to be Obsolete, and Subject
headers MUST NOT now be interpreted as <control-message>s under any
circumstances.
The descriptions below set out REQUIREMENTS to be followed by sites The descriptions below set out REQUIREMENTS to be followed by sites
that receive control messages and choose to honour them. However, that receive control messages and choose to honour them. However,
nothing in these descriptions should be taken as overriding the right nothing in these descriptions should be taken as overriding the right
of any such site, in accordance with its local policy, to refuse to of any such site, in accordance with its local policy, to refuse to
honour any particular control message, or to refer it to an honour any particular control message, or to refer it to an
News Article Architecture and Protocols September 2004
administrator for approval (either as a class or on a case-by-case administrator for approval (either as a class or on a case-by-case
basis). basis).
Relaying Agents MUST propagate all control messages regardless of 6.1. Digital Signature of Headers
whether or not they are recognized or processed locally.
In the following sections, each type of control message is defined It is most desirable that group control messages (6.2) in particular
syntactically by defining its verb, its arguments, and possibly its be authenticated by incorporating them within some digital signature
body. scheme that encompasses other headers closely associated with them
(including at least the Approved-, Message-ID- and Date-headers). At
the time of writing, this is usually done by means of a protocol
known as "PGPverify" ([PGPVERIFY]), and continued usage of this is
encouraged at least as an interim measure.
6.1. Digital Signature of Headers News Article Architecture and Protocols December 2004
[Removed to [USEFOR] (unless it remains in this document as the Primary However, PGPverify is not considered suitable for standardization in
document, in which case it would not be placed here.] its present form, for various technical reasons. It is therefore
expected that an early extension to this standard will provide a
robust and general purpose digital authentication mechanism with
applicability to all situations requiring protection against
malicious use of, or interference with, headers. That extension
would also address other Netnews security issues.
6.2. Group Control Messages 6.2. Group Control Messages
"Group control messages" are the sub-class of control messages that "Group control messages" are the sub-class of control messages that
request some update to the configuration of the groups known to a request some update to the configuration of the groups known to a
serving agent, namely "newgroup", "rmgroup", "mvgroup" and serving agent, namely "newgroup", "rmgroup", "mvgroup" and
"checkgroups", plus any others created by extensions to this "checkgroups", plus any others created by extensions to this
standard. standard.
All of the group control messages MUST have an Approved-header All of the group control messages MUST have an Approved-header
skipping to change at page 16, line 5 skipping to change at page 17, line 53
be acted on outside of those subnets. be acted on outside of those subnets.
NOTE: Specifically, some alternative flags such as "y" and "m", NOTE: Specifically, some alternative flags such as "y" and "m",
which are sent and recognized by some current software, are NOT which are sent and recognized by some current software, are NOT
part of this standard. Moreover, some existing implementations part of this standard. Moreover, some existing implementations
treat any flag other than "moderated" as indicating an treat any flag other than "moderated" as indicating an
unmoderated newsgroup. Both of these usages are contrary to this unmoderated newsgroup. Both of these usages are contrary to this
standard and control messages with such non-standard flags standard and control messages with such non-standard flags
should be ignored. should be ignored.
News Article Architecture and Protocols September 2004
6.2.1.1. The Body of the 'newgroup' Control Message 6.2.1.1. The Body of the 'newgroup' Control Message
The body of the newgroup message contains the following subparts, The body of the newgroup message contains the following subparts,
preferably in the order shown: preferably in the order shown:
1. An "application/news-groupinfo" part (5.3) containing the name and 1. An "application/news-groupinfo" part (5.3) containing the name and
newsgroups-line of the group. This part MUST be present and SHOULD newsgroups-line of the group. This part MUST be present and SHOULD
be used to update any copy of the newsgroups-line (5.3) maintained be used to update any copy of the newsgroups-line (5.3) maintained
News Article Architecture and Protocols December 2004
by the serving agent. by the serving agent.
2. Other parts containing useful information about the background of 2. Other parts containing useful information about the background of
the newgroup message (typically of type "text/plain"). the newgroup message (typically of type "text/plain").
3. Parts containing initial articles for the newsgroup. See section 3. Parts containing initial articles for the newsgroup. See section
6.2.1.2 for details. 6.2.1.2 for details.
In the event that there is only the single (i.e. application/news- In the event that there is only the single (i.e. application/news-
groupinfo) subpart present, it will suffice to include a "Content- groupinfo) subpart present, it will suffice to include a "Content-
skipping to change at page 17, line 5 skipping to change at page 18, line 51
The proto-article SHOULD be injected at the serving agent that The proto-article SHOULD be injected at the serving agent that
processes the control message AFTER the newsgroup in question has processes the control message AFTER the newsgroup in question has
been created or modified. It MUST NOT be injected if the newsgroup been created or modified. It MUST NOT be injected if the newsgroup
is not, in fact, created (for whatever reason). It MUST NOT be is not, in fact, created (for whatever reason). It MUST NOT be
submitted to any relaying agent for transmission beyond the serving submitted to any relaying agent for transmission beyond the serving
agent(s) upon which the newsgroup creation has just been effected (in agent(s) upon which the newsgroup creation has just been effected (in
other words, it is to be treated as having a "Distribution: local" other words, it is to be treated as having a "Distribution: local"
header, whether such a header is actually present or not). header, whether such a header is actually present or not).
News Article Architecture and Protocols September 2004
NOTE: It is not precluded that the proto-article is itself a NOTE: It is not precluded that the proto-article is itself a
control message or other type of special article, to be control message or other type of special article, to be
activated only upon creation of the new newsgroup. However, activated only upon creation of the new newsgroup. However,
except as might arise from that possibility, any except as might arise from that possibility, any
"application/news-transmission" within some nested "multipart/*" "application/news-transmission" within some nested "multipart/*"
structure within the proto-article is not to be activated. structure within the proto-article is not to be activated.
News Article Architecture and Protocols December 2004
6.2.1.3. Example 6.2.1.3. Example
A "newgroup" with its charter: A "newgroup" with its charter:
From: "example.all Administrator" <admin@noc.example> From: "example.all Administrator" <admin@noc.example>
Newsgroups: example.admin.info,example.admin.announce Newsgroups: example.admin.info,example.admin.announce
Date: 27 Feb 2002 12:50:22 +0200 Date: 27 Feb 2002 12:50:22 +0200
Subject: cmsg newgroup example.admin.info moderated Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example Approved: admin@noc.example
Control: newgroup example.admin.info moderated Control: newgroup example.admin.info moderated
skipping to change at page 18, line 5 skipping to change at page 19, line 55
6.2.2. The 'rmgroup' Control Message 6.2.2. The 'rmgroup' Control Message
control-message =/ Rmgroup-message control-message =/ Rmgroup-message
Rmgroup-message = "rmgroup" Rmgroup-arguments Rmgroup-message = "rmgroup" Rmgroup-arguments
Rmgroup-arguments = CFWS newsgroup-name Rmgroup-arguments = CFWS newsgroup-name
The "rmgroup" control message requests that the specified group be The "rmgroup" control message requests that the specified group be
removed from the list of valid groups. The Media Type of the body is removed from the list of valid groups. The Media Type of the body is
unspecified; it MAY contain anything, usually an explanatory text. unspecified; it MAY contain anything, usually an explanatory text.
News Article Architecture and Protocols September 2004
NOTE: It is entirely proper for a serving agent to retain the NOTE: It is entirely proper for a serving agent to retain the
group until all the articles in it have expired, provided that group until all the articles in it have expired, provided that
it ceases to accept new articles. it ceases to accept new articles.
News Article Architecture and Protocols December 2004
6.2.2.1. Example 6.2.2.1. Example
From: "example.all Administrator" <admin@noc.example> From: "example.all Administrator" <admin@noc.example>
Newsgroups: example.admin.obsolete, example.admin.announce Newsgroups: example.admin.obsolete, example.admin.announce
Date: 4 Apr 2002 22:04 -0900 (PST) Date: 4 Apr 2002 22:04 -0900 (PST)
Subject: cmsg rmgroup example.admin.obsolete Subject: cmsg rmgroup example.admin.obsolete
Message-ID: <rm-example.admin.obsolete-20020404@noc.example> Message-ID: <rm-example.admin.obsolete-20020404@noc.example>
Approved: admin@noc.example Approved: admin@noc.example
Control: rmgroup example.admin.obsolete Control: rmgroup example.admin.obsolete
skipping to change at page 19, line 5 skipping to change at page 20, line 55
after a suitable overlap period to allow the network to adjust to the after a suitable overlap period to allow the network to adjust to the
new arrangement. new arrangement.
At the same time as a serving agent acts upon this message, all At the same time as a serving agent acts upon this message, all
injecting agents associated with that serving agent SHOULD inhibit injecting agents associated with that serving agent SHOULD inhibit
the posting of new articles to the old group (preferably with some the posting of new articles to the old group (preferably with some
indication to the poster that the new group should have been used). indication to the poster that the new group should have been used).
Relaying agents, however, MUST continue to propagate such articles Relaying agents, however, MUST continue to propagate such articles
during the overlap period. during the overlap period.
News Article Architecture and Protocols September 2004
NOTE: It is to be expected that different serving agents will NOTE: It is to be expected that different serving agents will
act on this message at different points of time, users of the act on this message at different points of time, users of the
old group will have to become accustomed to the new arrangement, old group will have to become accustomed to the new arrangement,
and followups to already established threads will likely and followups to already established threads will likely
continue under the old group. Therefore, there needs to be an continue under the old group. Therefore, there needs to be an
overlap period during which articles may continue to be accepted overlap period during which articles may continue to be accepted
News Article Architecture and Protocols December 2004
by relaying and serving agents in either group. This standard by relaying and serving agents in either group. This standard
does not specify any standard period of overlap (though it would does not specify any standard period of overlap (though it would
be expected to be expressed in days rather than in months). The be expected to be expressed in days rather than in months). The
inhibition of injection of new articles to the old group may inhibition of injection of new articles to the old group may
seem draconian, but it is the surest way to prevent the seem draconian, but it is the surest way to prevent the
changeover from dragging on indefinitely. changeover from dragging on indefinitely.
Since the "mvgroup" control message is newly introduced in this Since the "mvgroup" control message is newly introduced in this
standard and may not be widely implemented initially, it SHOULD be standard and may not be widely implemented initially, it SHOULD be
followed shortly afterwards by a corresponding "newgroup" control followed shortly afterwards by a corresponding "newgroup" control
skipping to change at page 20, line 4 skipping to change at page 21, line 55
as to which groups are, or are not, supposed to exist in that as to which groups are, or are not, supposed to exist in that
hierarchy. Note that the "mvgroup" control message is not really hierarchy. Note that the "mvgroup" control message is not really
intended to be used for merging two existing groups. intended to be used for merging two existing groups.
6.2.3.1. Example 6.2.3.1. Example
From: "example.all Administrator" <admin@noc.example> From: "example.all Administrator" <admin@noc.example>
Newsgroups: example.oldgroup,example.newgroup,example.admin.announce Newsgroups: example.oldgroup,example.newgroup,example.admin.announce
Date: 30 Apr 2002 22:04 -0500 (EST) Date: 30 Apr 2002 22:04 -0500 (EST)
Subject: cmsg mvgroup example.oldgroup example.newgroup moderated Subject: cmsg mvgroup example.oldgroup example.newgroup moderated
News Article Architecture and Protocols September 2004
Message-ID: <mvgroup-example.oldgroup-20020430@noc.example> Message-ID: <mvgroup-example.oldgroup-20020430@noc.example>
Approved: admin@noc.example Approved: admin@noc.example
Control: mvgroup example.oldgroup example.newgroup moderated Control: mvgroup example.oldgroup example.newgroup moderated
News Article Architecture and Protocols December 2004
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=nxt Content-Type: multipart/mixed; boundary=nxt
--nxt --nxt
Content-Type: application/news-groupinfo Content-Type: application/news-groupinfo
For your newsgroups file: For your newsgroups file:
example.newgroup The new replacement group (Moderated) example.newgroup The new replacement group (Moderated)
--nxt --nxt
skipping to change at page 21, line 5 skipping to change at page 22, line 57
chkscope = 1*( CFWS ["!"] newsgroup-name ) chkscope = 1*( CFWS ["!"] newsgroup-name )
chksernr = CFWS "#" 1*DIGIT chksernr = CFWS "#" 1*DIGIT
A "checkgroups" message applies to any (sub-)hierarchy with a prefix A "checkgroups" message applies to any (sub-)hierarchy with a prefix
listed in the chkscope parameter, provided that the rightmost listed in the chkscope parameter, provided that the rightmost
matching newsgroup-name in the list is not immediately preceded by a matching newsgroup-name in the list is not immediately preceded by a
"!". If no chkscope parameter is given, it applies to all "!". If no chkscope parameter is given, it applies to all
hierarchies for which group statements appear in the body of the hierarchies for which group statements appear in the body of the
message. message.
News Article Architecture and Protocols September 2004
NOTE: Some existing software does not support the "chkscope" NOTE: Some existing software does not support the "chkscope"
parameter. Thus a "checkgroups" message SHOULD also contain the parameter. Thus a "checkgroups" message SHOULD also contain the
groups of other subhierarchies the sender is not responsible groups of other subhierarchies the sender is not responsible
for. "New" software MUST ignore groups which do not fall within for. "New" software MUST ignore groups which do not fall within
News Article Architecture and Protocols December 2004
the chkscope parameter of the "checkgroups" message. the chkscope parameter of the "checkgroups" message.
The chksernr parameter is a serial number, which can be any positive The chksernr parameter is a serial number, which can be any positive
integer (e.g. just numbered or the date in YYYYMMDD). It SHOULD integer (e.g. just numbered or the date in YYYYMMDD). It SHOULD
increase by an arbitrary value with every change to the group list increase by an arbitrary value with every change to the group list
and MUST NOT ever decrease. and MUST NOT ever decrease.
NOTE: This was added to circumvent security problems in NOTE: This was added to circumvent security problems in
situations where the Date-header cannot be authenticated. situations where the Date-header cannot be authenticated.
skipping to change at page 22, line 4 skipping to change at page 23, line 56
The cancel message requests that a target article be "canceled", i.e. The cancel message requests that a target article be "canceled", i.e.
be withdrawn from circulation or access. be withdrawn from circulation or access.
control-message =/ Cancel-message control-message =/ Cancel-message
Cancel-message = "cancel" Cancel-arguments Cancel-message = "cancel" Cancel-arguments
Cancel-arguments = CFWS msg-id [CFWS] Cancel-arguments = CFWS msg-id [CFWS]
The argument identifies the article to be cancelled by its message The argument identifies the article to be cancelled by its message
identifier. The body SHOULD contain an indication of why the identifier. The body SHOULD contain an indication of why the
cancellation was requested. The cancel message SHOULD be posted to cancellation was requested. The cancel message SHOULD be posted to
News Article Architecture and Protocols September 2004
the same newsgroup, with the same distribution, as the article it is the same newsgroup, with the same distribution, as the article it is
attempting to cancel. attempting to cancel.
News Article Architecture and Protocols December 2004
A serving agent that elects to honour a cancel message SHOULD make A serving agent that elects to honour a cancel message SHOULD make
the article unavailable for relaying or serving (perhaps by deleting the article unavailable for relaying or serving (perhaps by deleting
it completely). If the target article is unavailable, and the it completely). If the target article is unavailable, and the
acceptability of the cancel message cannot be established without it, acceptability of the cancel message cannot be established without it,
activation of the cancel message SHOULD be delayed until the target activation of the cancel message SHOULD be delayed until the target
article has been seen. See also sections 7.3 and 7.4. article has been seen. See also sections 7.3 and 7.4.
NOTE: It is expected that the security extension envisaged in NOTE: It is expected that the security extension envisaged in
section a-7.1 will make more detailed provisions for section 6.1 will make more detailed provisions for establishing
establishing whether honouring a particular cancel message is in whether honouring a particular cancel message is in order. In
order. In particular, it is likely that there will be provision particular, it is likely that there will be provision for the
for the digital signature of 3rd party cancels (i.e. those digital signature of 3rd party cancels (i.e. those issued other
issued other than by the sender, the moderator, or the than by the sender, the moderator, or the injector).
injector).
NOTE: A cancel submitted by the poster for an article in a NOTE: A cancel submitted by the poster for an article in a
moderated group will be forwarded to the moderator of that moderated group will be forwarded to the moderator of that
group, and it is up to that moderator to act upon it (7.8). group, and it is up to that moderator to act upon it (7.8).
NOTE: The former requirement [RFC 1036] that the From and/or NOTE: The former requirement [RFC 1036] that the From and/or
Sender-headers of the cancel message should match those of the Sender-headers of the cancel message should match those of the
original article has been removed from this standard, since it original article has been removed from this standard, since it
only encouraged cancel issuers to conceal their true identity, only encouraged cancel issuers to conceal their true identity,
and it was not usually checked or enforced by canceling and it was not usually checked or enforced by canceling
skipping to change at page 23, line 4 skipping to change at page 24, line 57
The two messages share the same syntax: The two messages share the same syntax:
control-message =/ Ihave-message control-message =/ Ihave-message
Ihave-message = "ihave" Ihave-arguments Ihave-message = "ihave" Ihave-arguments
Ihave-arguments = relayer-name Ihave-arguments = relayer-name
control-message =/ Sendme-message control-message =/ Sendme-message
Sendme-message = "sendme" Sendme-arguments Sendme-message = "sendme" Sendme-arguments
Sendme-arguments = Ihave-arguments Sendme-arguments = Ihave-arguments
relayer-name = path-identity ; see a-5.6.1 relayer-name = path-identity ; see a-5.6.1
ihave-body = *( msg-id CRLF ) ihave-body = *( msg-id CRLF )
News Article Architecture and Protocols September 2004
sendme-body = ihave-body sendme-body = ihave-body
News Article Architecture and Protocols December 2004
The body of the message consists of a list of msg-ids, one per line. The body of the message consists of a list of msg-ids, one per line.
[RFC 1036] also permitted the list of msg-ids to appear in the Ihave- [RFC 1036] also permitted the list of msg-ids to appear in the Ihave-
or Sendme-arguments with the syntax or Sendme-arguments with the syntax
Ihave-arguments = [FWS] *( msg-id FWS ) [relayer-name] Ihave-arguments = [FWS] *( msg-id FWS ) [relayer-name]
but this form SHOULD NOT now be used, though relaying agents MAY but this form SHOULD NOT now be used, though relaying agents MAY
recognize and process it for backward compatibility. recognize and process it for backward compatibility.
The ihave message states that the named relaying agent has received The ihave message states that the named relaying agent has received
articles with the specified message identifiers, which may be of articles with the specified message identifiers, which may be of
interest to the relaying agents receiving the ihave message. The interest to the relaying agents receiving the ihave message. The
skipping to change at page 24, line 5 skipping to change at page 25, line 57
first component of a newsgroup-name). The control message SHOULD then first component of a newsgroup-name). The control message SHOULD then
be delivered ONLY to the relaying agent(s) identified by that be delivered ONLY to the relaying agent(s) identified by that
relayer-name, and any relaying agent receiving such a message which relayer-name, and any relaying agent receiving such a message which
includes its own relayer-name MUST NOT propagate it further. Each includes its own relayer-name MUST NOT propagate it further. Each
pair of relaying agent(s) sending and receiving these messages MUST pair of relaying agent(s) sending and receiving these messages MUST
be immediate neighbors, exchanging news directly with each other. be immediate neighbors, exchanging news directly with each other.
Each relaying agent advertises its new arrivals to the other using Each relaying agent advertises its new arrivals to the other using
ihave messages, and each uses sendme messages to request the articles ihave messages, and each uses sendme messages to request the articles
it lacks. it lacks.
News Article Architecture and Protocols September 2004
To reduce overhead, ihave and sendme messages SHOULD be sent To reduce overhead, ihave and sendme messages SHOULD be sent
relatively infrequently and SHOULD contain reasonable numbers of relatively infrequently and SHOULD contain reasonable numbers of
message identifiers. If ihave and sendme are being used to implement message identifiers. If ihave and sendme are being used to implement
a backup feed, it may be desirable to insert a delay between a backup feed, it may be desirable to insert a delay between
News Article Architecture and Protocols December 2004
reception of an ihave and generation of a sendme, so that a slightly reception of an ihave and generation of a sendme, so that a slightly
slow primary feed will not cause large numbers of articles to be slow primary feed will not cause large numbers of articles to be
requested unnecessarily via sendme. requested unnecessarily via sendme.
6.5. Obsolete control messages. 6.5. Obsolete control messages.
The following control messages (as described in Appendix A.3) are The following control messages (as described in Appendix A.3) are
declared obsolete by this standard: declared obsolete by this standard:
sendsys sendsys
skipping to change at page 25, line 5 skipping to change at page 26, line 55
Be liberal in what you accept, and conservative in what you Be liberal in what you accept, and conservative in what you
send. send.
However, in the case of news there is an even more important However, in the case of news there is an even more important
principle, derived from a much older code of practice, the principle, derived from a much older code of practice, the
Hippocratic Oath (we may thus call this the Hippocratic Principle): Hippocratic Oath (we may thus call this the Hippocratic Principle):
First, do no harm. First, do no harm.
News Article Architecture and Protocols September 2004
It is VITAL to realize that decisions which might be merely It is VITAL to realize that decisions which might be merely
suboptimal in a smaller context can become devastating mistakes when suboptimal in a smaller context can become devastating mistakes when
amplified by the actions of thousands of hosts within a few minutes. amplified by the actions of thousands of hosts within a few minutes.
News Article Architecture and Protocols December 2004
In the case of gateways, the primary corollary to this is: In the case of gateways, the primary corollary to this is:
Cause no loops. Cause no loops.
7.2. Duties of an Injecting Agent 7.2. Duties of an Injecting Agent
An Injecting Agent is responsible for taking a proto-article from a An Injecting Agent is responsible for taking a proto-article from a
posting agent and either forwarding it to a moderator or injecting it posting agent and either forwarding it to a moderator or injecting it
into the relaying system for access by readers. into the relaying system for access by readers.
skipping to change at page 26, line 4 skipping to change at page 27, line 57
7.2.1. Proto-articles 7.2.1. Proto-articles
A proto-article SHOULD NOT be propagated in that form to other than A proto-article SHOULD NOT be propagated in that form to other than
injecting agents. injecting agents.
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
some of the following mandatory headers MAY be omitted: Message-Id- some of the following mandatory headers MAY be omitted: Message-Id-
header, Date-header, Path-header (and even From-header if the header, Date-header, Path-header (and even From-header if the
particular injecting agent can derive that information from other particular injecting agent can derive that information from other
sources). However, if it is intended to offer the proto-article to sources). However, if it is intended to offer the proto-article to
News Article Architecture and Protocols September 2004
two or more injecting agents in parallel, then it is only the Path- two or more injecting agents in parallel, then it is only the Path-
header that MAY be omitted. The headers that can be omitted MUST NOT header that MAY be omitted. The headers that can be omitted MUST NOT
contain invalid values; they MUST either be correct or not present at contain invalid values; they MUST either be correct or not present at
all. all.
News Article Architecture and Protocols December 2004
[Maybe omit that last sentence.] [Maybe omit that last sentence.]
NOTE: An article that is offered for reinjection has, by NOTE: An article that is offered for reinjection has, by
definition, already been injected once, and is not therefore to definition, already been injected once, and is not therefore to
be considered as a proto-article. Hence a genuine proto-article be considered as a proto-article. Hence a genuine proto-article
will not contain any Injection-Date-header nor any '%' path- will not contain any Injection-Date-header nor any '%' path-
delimiter in its Path-header. It MAY contain path-identities delimiter in its Path-header. It MAY contain path-identities
with other path-delimiters in the pre-injection portion of its with other path-delimiters in the pre-injection portion of its
Path-header (a-5.6.3). Path-header (a-5.6.3).
skipping to change at page 26, line 51 skipping to change at page 28, line 47
3. It SHOULD reject any article whose Date-header (a-5.1) is more 3. It SHOULD reject any article whose Date-header (a-5.1) is more
than 24 hours into the future (and MAY use a margin less than that than 24 hours into the future (and MAY use a margin less than that
24 hours). It MUST, except when reinjecting, reject any article 24 hours). It MUST, except when reinjecting, reject any article
with an Injection-Date-header already present (and SHOULD do with an Injection-Date-header already present (and SHOULD do
likewise with any NNTP-Posting-Date-header). It MAY when likewise with any NNTP-Posting-Date-header). It MAY when
reinjecting, but only if there is no Injection-Date-header reinjecting, but only if there is no Injection-Date-header
present, reject any article whose Date-header appears to be stale present, reject any article whose Date-header appears to be stale
(e.g. more than 72 hours into the past). (e.g. more than 72 hours into the past).
4. It MUST reject any article that does not have the correct 4. It MUST reject any article that does not have the proper mandatory
mandatory headers for a proto-article (or, when reinjecting, all headers for a proto-article (or, when reinjecting, all the
the mandatory headers other than Injection-Date), or which mandatory headers other than Injection-Date), or which contains
contains any header that does not have legal contents. It SHOULD any header that does not have legal contents. It SHOULD reject
reject any article which contains any header deprecated for any article which contains any header deprecated for Netnews (a-
Netnews (a-4.2.1). It SHOULD reject any article whose 4.2.1). It SHOULD reject any article whose Newsgroups-header does
Newsgroups-header does not contain at least one newsgroup-name for not contain at least one newsgroup-name for an existing group (as
an existing group (as listed by its associated serving agent) and listed by its associated serving agent) and it MAY reject any
it MAY reject any newsgroup-name which, although syntactically newsgroup-name which, although syntactically correct, violates a
correct, violates a policy restriction established, for some policy restriction established, for some (sub-)hierarchy, by an
agency with the appropriate authority (1.2). Observe that
News Article Architecture and Protocols September 2004 crossposting to unknown newsgroups is not precluded provided at
least one of those in the Newsgroups-header is listed.
(sub-)hierarchy, by an agency with the appropriate authority News Article Architecture and Protocols December 2004
(1.2). Observe that crossposting to unknown newsgroups is not
precluded provided at least one of those in the Newsgroups-header
is listed.
NOTE: This ability to reject newsgroup-names in breach of NOTE: This ability to reject newsgroup-names in breach of
established policy does not extend to relaying agents, though it established policy does not extend to relaying agents, though it
might be reasonable for posting agents to do it. might be reasonable for posting agents to do it.
5. If the article is rejected (for reasons given above, or for other 5. If the article is rejected (for reasons given above, or for other
formatting errors or matters of site policy) the posting agent formatting errors or matters of site policy) the posting agent
SHOULD be informed (such as via an NNTP 44x response code) that SHOULD be informed (such as via an NNTP 44x response code) that
posting has failed and the article MUST NOT then be processed posting has failed and the article MUST NOT then be processed
further. further.
skipping to change at page 28, line 5 skipping to change at page 29, line 54
10.It MUST then prepend the path-identity of the injecting agent and 10.It MUST then prepend the path-identity of the injecting agent and
a '%' path-delimiter (which serves to separate the pre-injection a '%' path-delimiter (which serves to separate the pre-injection
and post-injection regions of the Path-content) to the Path- and post-injection regions of the Path-content) to the Path-
content; this SHOULD then be followed by CRLF and WSP if it would content; this SHOULD then be followed by CRLF and WSP if it would
otherwise result in a line longer than 79 characters. The otherwise result in a line longer than 79 characters. The
prepended path-identity MUST be an FQDN mailable address (a- prepended path-identity MUST be an FQDN mailable address (a-
5.6.2). This could result in more that one '%' path-delimiter in 5.6.2). This could result in more that one '%' path-delimiter in
the case of reinjection. See a-5.6.4 for the significance of the the case of reinjection. See a-5.6.4 for the significance of the
various path-delimiters. various path-delimiters.
News Article Architecture and Protocols September 2004
11.An Injection-Info-header (a-6.19) SHOULD be added, identifying the 11.An Injection-Info-header (a-6.19) SHOULD be added, identifying the
trusted source of the article, and a suitable Complaints-To-header trusted source of the article, and a suitable Complaints-To-header
(a-6.20) MAY be added. Each injecting agent SHOULD use a (a-6.20) MAY be added. Each injecting agent SHOULD use a
consistent form of the Injection-Info-header for all articles consistent form of the Injection-Info-header for all articles
emanating from the same or similar origins. emanating from the same or similar origins.
News Article Architecture and Protocols December 2004
NOTE: The step above is the only place in which an Injection- NOTE: The step above is the only place in which an Injection-
Info- or Complaints-To-header is to be created. It follows that Info- or Complaints-To-header is to be created. It follows that
these headers MUST NOT be created, replaced, changed or deleted these headers MUST NOT be created, replaced, changed or deleted
by any other agent (except during reinjection, in which case by any other agent (except during reinjection, in which case
they will always relate to the latest injection and can, to that they will always relate to the latest injection and can, to that
extent, be regarded as variant headers). extent, be regarded as variant headers).
12.The injecting agent MUST then add an Injection-Date-header (a-5.7) 12.The injecting agent MUST then add an Injection-Date-header (a-5.7)
if one is not already present, but it MUST NOT alter, or delete, if one is not already present, but it MUST NOT alter, or delete,
an already present Injection-Date-header (and likewise SHOULD NOT an already present Injection-Date-header (and likewise SHOULD NOT
skipping to change at page 29, line 5 skipping to change at page 30, line 56
addition of such extra headers (e.g. a To-header) as are addition of such extra headers (e.g. a To-header) as are
necessary for an email. The existing Message-ID-header SHOULD necessary for an email. The existing Message-ID-header SHOULD
be retained. be retained.
Although both of these methods have seen use in the past, the Although both of these methods have seen use in the past, the
preponderance of current usage on Usenet has been for method (b) preponderance of current usage on Usenet has been for method (b)
and many moderators are ill-prepared to deal with method (a). and many moderators are ill-prepared to deal with method (a).
Therefore, method (a) SHOULD NOT be used until such time as the Therefore, method (a) SHOULD NOT be used until such time as the
majority of moderators are able to accept it. majority of moderators are able to accept it.
News Article Architecture and Protocols September 2004
2. This standard does not prescribe how the email address of the 2. This standard does not prescribe how the email address of the
moderator is to be determined, that being a matter of policy to be moderator is to be determined, that being a matter of policy to be
arranged by the agency responsible for the oversight of each arranged by the agency responsible for the oversight of each
hierarchy. Nevertheless, there do exist various agents worldwide hierarchy. Nevertheless, there do exist various agents worldwide
which provide the service of forwarding to moderators, and the which provide the service of forwarding to moderators, and the
News Article Architecture and Protocols December 2004
address to use with them is obtained as follows: address to use with them is obtained as follows:
(a) Each '.' in the newsgroup-name is replaced with a '-'. (a) Each '.' in the newsgroup-name is replaced with a '-'.
(b) The result of these operations is used as the local-part of (b) The result of these operations is used as the local-part of
the mailbox of the agent. For example, articles intended for the mailbox of the agent. For example, articles intended for
"news.announce.important" would be emailed to "news- "news.announce.important" would be emailed to "news-
announce-important@forwardingagent.example". announce-important@forwardingagent.example".
7.3. Duties of a Relaying Agent 7.3. Duties of a Relaying Agent
skipping to change at page 29, line 35 skipping to change at page 31, line 30
according to mutually agreed policy. Relaying agents SHOULD accept according to mutually agreed policy. Relaying agents SHOULD accept
articles ONLY from trusted agents. articles ONLY 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-names in its Newsgroups-header and at least one of of the newsgroup-names in its Newsgroups-header and at least one of
the distributions in its Distribution-header, if any. Exceptionally, the distributions in its Distribution-header, if any. Exceptionally,
ALL relaying agents are deemed willing to supply or accept the ALL relaying agents are deemed willing to supply or accept the
distribution "world", and NO relaying agent should supply or accept distribution "world", and NO relaying agent should supply or accept
the distribution "local". the distribution "local".
[That SHOULD has been demoted from a MUST in draft-13. Any objections?]
However, if the particular implementation does not relay non-existent
newsgroups, even when included in the Newsgroups-header and implied
(e.g. by some "wild card" notation) in the configuration tables, then
the agent MUST examine all group control messages (6.2) in order to
ensure that relaying of those messages proceeds normally.
NOTE: Although it would seem redundant to filter out unwanted NOTE: Although it would seem redundant to filter out unwanted
distributions at both ends of a relaying link (and it is clearly distributions at both ends of a relaying link (and it is clearly
more efficient to do so at the sending end), many sending sites more efficient to do so at the sending end), many sending sites
have been reluctant, historically speaking, to apply such have been reluctant, historically speaking, to apply such
filters (except to ensure that distributions local to their own filters (except to ensure that distributions local to their own
site or cooperating subnet did not escape); moreover they tended site or cooperating subnet did not escape); moreover they tended
to configure their filters on an "all but those listed" basis, to configure their filters on an "all but those listed" basis,
so that new and hitherto unheard of distributions would not be so that new and hitherto unheard of distributions would not be
caught. Indeed many "hub" sites actually wanted to receive all caught. Indeed many "hub" sites actually wanted to receive all
skipping to change at page 30, line 5 skipping to change at page 32, line 5
Therefore, it is desirable to provide facilities for rejecting Therefore, it is desirable to provide facilities for rejecting
unwanted distributions at the receiving end. Indeed, it may be unwanted distributions at the receiving end. Indeed, it may be
simpler to do so locally than to inform each sending site of simpler to do so locally than to inform each sending site of
what is required, especially in the case of specialized what is required, especially in the case of specialized
distributions (for example for control messages, such as cancels distributions (for example for control messages, such as cancels
from certain issuers) which might need to be added at short from certain issuers) which might need to be added at short
notice. The possibility for reading agents to filter notice. The possibility for reading agents to filter
distributions has been provided (7.7) for the same reason. distributions has been provided (7.7) for the same reason.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
An article SHOULD NOT be relayed if the path-identity of the In order to avoid unnecessary relaying, an article SHOULD NOT be
receiving agent (or some known alias thereof) appears in its Path- relayed if the path-identity of the receiving agent (or some known
header, and the receiving agent MAY detect whether its own path- alias thereof) appears in its Path-header.
identity is already present in the Path-content so as to avoid
further unnecessary relaying.
[See related remarks under serving agents.]
A relaying agent processes articles as follows: A relaying agent processes articles as follows:
1. It MUST establish the trusted identity of the source of the 1. It MUST establish the trusted identity of the source of the
article and compare it with the leftmost path-identity of the article and compare it with the leftmost path-identity of the
Path-content. If it matches it MUST then prepend its own path- Path-content. If it matches it MUST then prepend its own path-
identity and a '/' path-delimiter to the Path-content; this SHOULD identity and a '/' path-delimiter to the Path-content; this SHOULD
then be followed by CRLF and WSP if it would otherwise result in a then be followed by CRLF and WSP if it would otherwise result in a
line longer than 79 characters. If it does not match then it line longer than 79 characters. If it does not match then it
prepends instead two entries to the Path-content; firstly the true prepends instead two entries to the Path-content; firstly the true
skipping to change at page 30, line 41 skipping to change at page 32, line 38
not routinely query an external entity (such as a DNS-server) in not routinely query an external entity (such as a DNS-server) in
order to verify an article (though a local cache of the required order to verify an article (though a local cache of the required
information might usefully be consulted). information might usefully be consulted).
2. It MUST examine the Injection-Date-header (or, if that is absent, 2. It MUST examine the Injection-Date-header (or, if that is absent,
the Date-header) and reject the article as stale (a-5.7) if that the Date-header) and reject the article as stale (a-5.7) if that
predates the earliest articles of which it normally keeps record, predates the earliest articles of which it normally keeps record,
or if it is more than 24 hours into the future (the margin MAY be or if it is more than 24 hours into the future (the margin MAY be
less than that 24 hours). less than that 24 hours).
3. It MUST reject any article that does not have the correct 3. It SHOULD reject any article that does not include all the
mandatory headers (section a-5) present with legal contents. mandatory headers (section a-5).
4. It SHOULD reject any article whose optional headers (section a-6) 4. It MAY reject any article whose headers do not have legal
do not have legal contents. contents.
[Is that too strong? Are relaying agents really expected to check
headers in that detail? I suggest s/SHOULD/MAY/. Even the MUST in Step 4
for mandatory headers might be demoted to SHOULD.]
5. It SHOULD reject any article that has already been sent to it (a 5. It SHOULD reject any article that has already been sent to it (a
database of message identifiers of recent messages is usually kept database of message identifiers of recent messages is usually kept
and matched against). and matched against).
NOTE: Even though commonly derived from the domain name of the
originating site (and domain names are case-insensitive), a
message identifier MUST NOT be altered in any way during
transport, or when copied (as into a References-header), and
thus a simple (case-sensitive) comparison of octets will always
suffice to recognize that same message identifier wherever it
subsequently reappears.
NOTE: These requirements are to be contrasted with those of the
un-normalized msg-ids defined by [RFC 2822], which may perfectly
legitimately become normalized (or vice versa) during transport
or copying in email systems.
News Article Architecture and Protocols December 2004
6. It SHOULD reject any article that matches an already received 6. It SHOULD reject any article that matches an already received
cancel message (or an equivalent Supersedes-header) issued by its cancel message (or an equivalent Supersedes-header) issued by its
poster or by some other trusted entity. poster or by some other trusted entity.
7. It MAY reject any article without an Approved-header posted to 7. It MAY reject any article without an Approved-header posted to
newsgroups known to be moderated (this practice is strongly newsgroups known to be moderated (this practice is strongly
recommended, but the information necessary to do so may not be recommended, but the information necessary to do so may not be
News Article Architecture and Protocols September 2004
available to all agents). available to all agents).
8. It MAY delete any Xref-header that is present. 8. It MAY delete any Xref-header that is present.
9. Finally, it passes the articles on to neighbouring relaying and 9. Finally, it passes the articles on to neighbouring relaying and
serving agents. serving agents.
If the article is rejected as being invalid, unwanted or unacceptable If the article is rejected as being invalid, unwanted or unacceptable
due to site policy, the agent that passed the article to the relaying due to site policy, the agent that passed the article to the relaying
agent SHOULD be informed (such as via an NNTP 43x response code) that agent SHOULD be informed (such as via an NNTP 43x response code) that
relaying failed. In order to prevent a large number of error messages relaying failed. In order to prevent a large number of error messages
being sent to one location, relaying agents MUST NOT inform any other being sent to one location, relaying agents MUST NOT inform any other
external entity that an article was not relayed UNLESS that external external entity that an article was not relayed 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 expect for headers designated as variant (a-4.2.5.3). In article expect for headers designated as variant (2.3.2). In
particular particular
o they MUST NOT create or augment a User-Agent-header in order to o they MUST NOT create or augment a User-Agent-header in order to
identify themselves; identify themselves;
o they MUST NOT rewrite the Newsgroups-header in any way, even if o they MUST NOT rewrite the Newsgroups-header in any way, even if
some supposedly non-existent newsgroup is included; some supposedly non-existent newsgroup is included;
o they MUST NOT refold any header (i.e. they must pass on the o they MUST NOT refold any header (i.e. they must pass on the
folding as received), even to remove FWS from a Newsgroups- folding as received), even to remove FWS from a Newsgroups-
header; header;
o they MUST NOT alter the Date-header or the Injection-Date-header; o they MUST NOT alter the Date-header or the Injection-Date-header;
skipping to change at page 31, line 52 skipping to change at page 34, line 5
Path: foo.isp.example/ Path: foo.isp.example/
foo-server/bar.isp.example?10.123.12.2/old.site.example! foo-server/bar.isp.example?10.123.12.2/old.site.example!
barbaz/baz.isp.example%dialup123.baz.isp.example!not-for-mail barbaz/baz.isp.example%dialup123.baz.isp.example!not-for-mail
NOTE: That article was injected into the news stream by NOTE: That article was injected into the news stream by
baz.isp.example (complaints may be addressed to baz.isp.example (complaints may be addressed to
abuse@baz.isp.example). The injector has taken care to record abuse@baz.isp.example). The injector has taken care to record
that it got it from dialup123.baz.isp.example. "not-for-mail" is that it got it from dialup123.baz.isp.example. "not-for-mail" is
a dummy tail-entry, though sometimes a real userid is put there. a dummy tail-entry, though sometimes a real userid is put there.
News Article Architecture and Protocols December 2004
The article was relayed, perhaps by UUCP, to the machine known, The article was relayed, perhaps by UUCP, to the machine known,
at least to old.site.example, as "barbaz". at least to old.site.example, as "barbaz".
Barbaz relayed it to old.site.example, which does not yet Barbaz relayed it to old.site.example, which does not yet
conform to this standard (hence the '!' path-delimiter). So one conform to this standard (hence the '!' path-delimiter). So one
cannot be sure that it really came from barbaz. cannot be sure that it really came from barbaz.
News Article Architecture and Protocols September 2004
Old.site.example relayed it to a site claiming to have the IP Old.site.example relayed it to a site claiming to have the IP
address [10.123.12.2], and claiming (by using the '/' path- address [10.123.12.2], and claiming (by using the '/' path-
delimiter) to have verified that it came from old.site.example. delimiter) to have verified that it came from old.site.example.
[10.123.12.2] relayed it to "foo-server" which, not being [10.123.12.2] relayed it to "foo-server" which, not being
convinced that it truly came from [10.123.12.2], did a reverse convinced that it truly came from [10.123.12.2], did a reverse
lookup on the actual source and concluded it was known as lookup on the actual source and concluded it was known as
bar.isp.example (that is not to say that [10.123.12.2] was not a bar.isp.example (that is not to say that [10.123.12.2] was not a
correct IP address for bar.isp.example, but simply that that correct IP address for bar.isp.example, but simply that that
connection could not be substantiated by foo-server). Observe connection could not be substantiated by foo-server). Observe
skipping to change at page 32, line 50 skipping to change at page 34, line 57
6.2.1), and SHOULD include in that list all groups likely to be 6.2.1), and SHOULD include in that list all groups likely to be
crossposted to from those groups (e.g. all other groups in the same crossposted to from those groups (e.g. all other groups in the same
hierarchy(ies)). hierarchy(ies)).
NOTE: Since control messages are often of interest, but should NOTE: Since control messages are often of interest, but should
not be displayed as normal articles in regular newsgroups, it is not be displayed as normal articles in regular newsgroups, it is
common for serving agents to make them available in a pseudo- common for serving agents to make them available in a pseudo-
newsgroup named "control" or in a pseudo-newsgroup in a sub- newsgroup named "control" or in a pseudo-newsgroup in a sub-
hierarchy under "control." (e.g. "control.cancel"). hierarchy under "control." (e.g. "control.cancel").
A serving agent MAY decline to accept an article if its own path- A serving agent MAY decline to accept an article if the Path-content
identity is already present in the Path-content or if the Path- contains some path-identity whose articles the serving agent does not
content contains some path-identity whose articles the serving agent want, as a matter of local policy.
does not want, as a matter of local policy.
[That has been changed from a-5.6.1 in previous drafts, where it said "A
relaying agent MAY decline...". That seemed plain wrong to me. It is
fine for a relaying agent to ignore articles which have apparently
already passed through it (and I still say that), but surely it is for
serving agents to "reject" for policy reasons, and to which the NOTE
below would apply. Comments?]
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
NOTE: This last facility is sometimes used to detect and decline NOTE: This last facility is sometimes used to detect and decline
control messages (notably cancel messages) which have been control messages (notably cancel messages) which have been
deliberately seeded with a path-identity to be "aliased out" by deliberately seeded with a path-identity to be "aliased out" by
sites not wishing to act upon them. sites not wishing to act upon them.
[Again, is this "aliasing out" usually detected by the serving agent, or [INN at least does this. It might be argued that it is not necessary to
does it more usually work because the previous relaying agent will never mention it here.]
have sent it in the first place?]
A serving agent processes articles as follows: A serving agent processes articles as follows:
1. It MUST establish the trusted identity of the source of the 1. It MUST establish the trusted identity of the source of the
article and modify the Path-header as for a relaying agent (7.3). article and modify the Path-header as for a relaying agent (7.3).
2. It MUST examine the Injection-Date-header (or, if that is absent, 2. It MUST examine the Injection-Date-header (or, if that is absent,
the Date-header) and reject the article as stale (a-5.7) if that the Date-header) and reject the article as stale (a-5.7) if that
predates the earliest articles of which it normally keeps record, predates the earliest articles of which it normally keeps record,
or if it is more than 24 hours into the future (the margin MAY be or if it is more than 24 hours into the future (the margin MAY be
less than that 24 hours). less than that 24 hours).
3. It MUST reject any article that does not have the correct 3. It MUST reject any article that does not include all the mandatory
mandatory headers (section a-5) present, or which contains any headers (section a-5), or which contains any header that does not
header that does not have legal contents. have legal contents.
4. It SHOULD reject any article that has already been sent to it (a 4. It SHOULD reject any article that has already been sent to it (a
database of message identifiers of recent articles is usually kept database of message identifiers of recent articles is usually kept
and matched against). and matched against).
5. It SHOULD reject any article that matches an already received 5. It SHOULD reject any article that matches an already received
cancel message (or an equivalent Supersedes-header) issued by its cancel message (or an equivalent Supersedes-header) issued by its
poster or by some other trusted entity. poster or by some other trusted entity.
6. It MUST reject any article without an Approved-header posted to 6. It MUST reject any article without an Approved-header posted to
skipping to change at page 34, line 5 skipping to change at page 35, line 58
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 in any other way. The list of particular cases given for article in any other way. The list of particular cases given for
relaying agents (7.3) applies here also. relaying agents (7.3) applies here also.
7.5. Duties of a Posting Agent 7.5. Duties of a Posting Agent
A Posting Agent is used to assist the poster in creating a valid A Posting Agent is used to assist the poster in creating a valid
proto-article and forwarding it to an injecting agent. proto-article and forwarding it to an injecting agent.
News Article Architecture and Protocols September 2004
Postings agents SHOULD ensure that proto-articles they create are Postings agents SHOULD ensure that proto-articles they create are
valid according to [USEFOR] and other applicable policies. In valid according to [USEFOR] and other applicable policies. In
particular, they MUST NOT create any Injection-Date-, Injection-Info- particular, they MUST NOT create any Injection-Date-, Injection-Info-
News Article Architecture and Protocols December 2004
or Complaints-To-header. or Complaints-To-header.
Contrary to [RFC 2822], which states that the mailbox(es) in the From
header is that of the poster(s), a poster who does not, for whatever
reason, wish to use his own mailbox MAY use any mailbox ending in the
top level domain ".invalid" [RFC 2606].
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. article of which the poster is not the author or sender.
7.6. Duties of a Followup Agent 7.6. Duties of a Followup Agent
A Followup Agent is a special case of a posting agent, and as such is A Followup Agent is a special case of a posting agent, and as such is
bound by all the posting agent's requirements. Followup agents MUST bound by all the posting agent's requirements. Followup agents MUST
create valid followups and are subject to special requirements create valid followups and are subject to special requirements
involving certain inheritable (a-4.2.5.2) and other headers. involving certain inheritable (2.3.1) and other headers. Wherever in
Wherever in the following it is stated that, "by default", a header the following it is stated that, "by default", a header is to be
is to be taken from some header in the precursor, it means that its taken from some header in the precursor, it means that its initial
initial content (plus its extension-parameters, if any) are to be content is to be copied from the content of that precursor header.
copied from those of that precursor header. However, posters MAY However, posters MAY then override that default before posting if
then override that default before posting if they so wish. they so wish.
NOTE: There is no provision in this standard for a followup to NOTE: There is no provision in this standard for a followup to
have more than one precursor (though it might be permitted in have more than one precursor (though it might be permitted in
some future extension). some future extension).
1. The Newsgroups-header (a-5.5) SHOULD by default be taken from the 1. The Newsgroups-header (a-5.5) SHOULD by default be taken from the
precursor's Followup-To-header if present, and otherwise from the precursor's Followup-To-header if present, and otherwise from the
precursor's Newsgroups-header. However, if the content of that precursor's Newsgroups-header. However, if the content of that
Followup-To-header consists of "poster" (and the user does not Followup-To-header consists of "poster" (and the user does not
override it), then the followup MUST NOT be posted but, rather, is override it), then the followup MUST NOT be posted but, rather, is
to be emailed to the precursor's poster. to be emailed to the precursor's poster.
2. The Subject-header SHOULD by default be taken from that of the 2. The Subject-header SHOULD by default be taken from that of the
precursor. The case sensitive string "Re: " MAY be prepended to precursor. The case sensitive string "Re: " MAY be prepended to
its Subject-Content unless it already begins with that string. its Subject-Content unless it already begins with that string.
3. The Distribution-header (a-6.6) SHOULD by default be taken from 3. The Distribution-header (a-6.6) SHOULD by default be taken from
the precursor's Distribution-header, if any. the precursor's Distribution-header, if any.
4. If the precursor did not have a References-header (a-6.10), the 4. If the precursor did not have a References-header (a-6.10), the
followup's References-content MUST be formed by the message followup's References-content MUST be taken from the Message-ID-
identifier of the precursor. A followup to an article which had a content of the precursor. A followup to an article which already
References-header MUST have a References-header containing the had a References-header MUST have a References-header comprising
precursor's References-content (subject to trimming as described the precursor's References-content (subject to trimming as
below) plus the precursor's message identifier appended to the end described below) followed by CFWS and the Message-ID-content of
of the list (separated from it by CFWS). the precursor.
Followup agents MAY trim References-headers which have grown to Followup agents MAY trim References-headers which have grown to
excessive length, but the first and last message identifiers from excessive length, but the first and last message identifiers from
the precursor MUST NOT be removed. the precursor MUST NOT be removed.
News Article Architecture and Protocols December 2004
5. If the precursor contains a Mail-Copies-To-header (a-6.8), the 5. If the precursor contains a Mail-Copies-To-header (a-6.8), the
actions to be taken, in accordance with the Mail-Copies-To- actions to be taken, in accordance with the Mail-Copies-To-
content, (and subject to manual override by the poster) are as content, (and subject to manual override by the poster) are as
News Article Architecture and Protocols September 2004
follows: follows:
"nobody" (or when the header is absent) "nobody" (or when the header is absent)
The followup agent SHOULD NOT email a copy of a posted The followup agent SHOULD NOT email a copy of a posted
followup to the poster of the precursor. followup to the poster of the precursor.
"poster" "poster"
The followup agent SHOULD (if it has the necessary The followup agent SHOULD (if it has the necessary
capability) email a copy of a posted followup, which MUST capability) email a copy of a posted followup, which MUST
then be sent to the address(es) in the Reply-To-header, and then be sent to the address(es) in the Reply-To-header, and
in the absence of that to the address(es) in the From- in the absence of that to the address(es) in the From-
header. header.
a copy-addr a copy-addr
The followup agent SHOULD likewise email a copy of a posted The followup agent SHOULD likewise email a copy of a posted
followup, which MUST then be sent to the copy-addr. followup, which SHOULD then be sent to the copy-addr.
When emailing a copy, the followup agent SHOULD also include a When emailing a copy, the followup agent SHOULD also include a
"Posted-And-Mailed: yes" header (a-6.9). "Posted-And-Mailed: yes" header (a-6.9).
Followup agents SHOULD NOT attempt to send email to any address Followup agents SHOULD NOT attempt to send email to any address
ending in ".invalid". ending in ".invalid".
7.7. Duties of a Reading Agent 7.7. Duties of a Reading Agent
A reading agent downloads articles from a serving agent, as directed A reading agent downloads articles from a serving agent, as directed
by the reader, and displays them (or processes them in some other by the reader, and displays them (or processes them in some other
manner). The article as displayed MUST be identical to the article manner), subject to any limitations of the reading agent, such as
as originally posted, subject only to limitations of the display availability of charsets, and having first decoded any Content-
device (such as availability of charsets, etc.). It MUST provide Transfer-Encodings, encoded-words, etc. It SHOULD also have the
facilities for decoding any Content-Transfer-Encodings, encoded- capability to show the raw article exactly as received.
words, etc., but SHOULD also have the capability to show the article
exactly as received.
It MAY present lists of articles available for display, and MAY It MAY present lists of articles available for display, and MAY
structure those lists so as to show the relationships between the structure those lists so as to show the relationships between the
articles, as determined by the References-, Subject-, Date- and articles, as determined by the References-, Subject-, Date- and
other-headers (see [USEAGE] for some usual methods of doing this). It other-headers (see [USEAGE] for some usual methods of doing this).
MAY also be configured so that unwanted distributions (a-6.6) are [This whole section may yet get omitted]
ignored.
7.8. Duties of a Moderator 7.8. Duties of a Moderator
A Moderator receives news articles by email, decides whether to A Moderator receives news articles by email, decides whether to
accept them and, if so, either injects them into the news stream or accept them and, if so, either injects them into the news stream or
forwards them to further moderators. forwards them to further moderators.
Articles will be received by the moderator either encapsulated as an Articles will be received by the moderator either encapsulated as an
object of Content-Type application/news-transmission (or possibly object of Content-Type application/news-transmission (or possibly
encapsulated but without an explicit Content-Type-header), or else encapsulated but without an explicit Content-Type-header), or else
directly as an email already containing all the headers appropriate directly as an email already containing all the headers appropriate
for a Netnews article (see 7.2.2). Moderators SHOULD be prepared to for a Netnews article (see 7.2.2). Moderators SHOULD be prepared to
accept articles in either format. accept articles in either format.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
A moderator processes an article, as submitted to any newsgroup that A moderator processes an article, as submitted to any newsgroup that
he moderates, as follows: he moderates, as follows:
1. He decides, on the basis of whatever moderation policy applies to 1. He decides, on the basis of whatever moderation policy applies to
his group, whether to accept or reject the article. He MAY do this his group, whether to accept or reject the article. He MAY do this
manually, or else partially or wholly with the aid of appropriate manually, or else partially or wholly with the aid of appropriate
software for whose operation he is then responsible. If the software for whose operation he is then responsible. If the
article is a cancel nessage (6.3) issued by the poster of an article is a cancel nessage (6.3) issued by the poster of an
earlier article, then he is expected to cancel that earlier earlier article, then he is expected to cancel that earlier
skipping to change at page 37, line 5 skipping to change at page 39, line 5
is sometimes used for this purpose). The approval may also be is sometimes used for this purpose). The approval may also be
confirmed with some form of digital signature (a-7.1). confirmed with some form of digital signature (a-7.1).
3. If the Newsgroups-header contains no further unapproved moderated 3. If the Newsgroups-header contains no further unapproved moderated
groups, he adds an Approved-header (a-6.14) identifying himself groups, he adds an Approved-header (a-6.14) identifying himself
and, insofar as is possible, all the other moderators who have and, insofar as is possible, all the other moderators who have
approved the article. He thus assumes responsibility for having approved the article. He thus assumes responsibility for having
ensured that the article was acceptable to the moderators of all ensured that the article was acceptable to the moderators of all
the moderated groups involved. the moderated groups involved.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
4. The Date-header SHOULD be retained. Any Injection-Date-header 4. The Date-header SHOULD be retained. Any Injection-Date-header
already present (though there should be none) MUST be removed. already present (though there should be none) MUST be removed.
Exceptionally, if it is known that the injecting agent does not Exceptionally, if it is known that the injecting agent does not
yet support the Injection-Date-header and the Date-header appears yet support the Injection-Date-header and the Date-header appears
to be stale (a-5.7) for reasons understood by the moderator (e.g. to be stale (a-5.7) for reasons understood by the moderator (e.g.
delays in the moderation process) he MAY substitute the current delays in the moderation process) he MAY substitute the current
date. The Message-ID-header SHOULD also be retained unless it is date. The Message-ID-header SHOULD also be retained unless it is
obviously non-compliant with this standard. obviously non-compliant with this standard.
NOTE: A message identifier created by a conforming posting or NOTE: A message identifier created by a conforming posting or
injecting agent, or even by a mail user agent conforming to [RFC injecting agent, or even by a mail user agent conforming to [RFC
2822], may reasonably be supposed to be conformant (and will, in 2822], may reasonably be supposed to be conformant (and will, in
any case, be caught by the injecting agent if it is not). any case, be caught by the injecting agent if it is not).
5. Any variant headers (a-4.2.5.3) MUST be removed, except that a 5. Any variant headers (2.3.2) MUST be removed, except that a Path-
Path-header MAY be truncated to only its pre-injection region (a- header MAY be truncated to only its pre-injection region (a-
5.6.3). Any Injection-Info-header (a-6.19) or Complaints-To- 5.6.3). Any Injection-Info-header (a-6.19) or Complaints-To-
header (a-6.20) SHOULD be removed (and if they are not, the header (a-6.20) SHOULD be removed (and if they are not, the
injecting agent will do so, as required in 7.2.2). injecting agent will do so, as required in 7.2.2).
6. He then causes the article to be injected, having first observed 6. He then causes the article to be injected, having first observed
all the duties of a posting agent. all the duties of a posting agent.
NOTE: This standard does not prescribe how the moderator or NOTE: This standard does not prescribe how the moderator or
moderation policy for each newsgroup is established; rather it moderation policy for each newsgroup is established; rather it
assumes that whatever agencies are responsible for the relevant assumes that whatever agencies are responsible for the relevant
skipping to change at page 38, line 5 skipping to change at page 40, line 5
Above all, prevent loops. Above all, prevent loops.
Transformation of an article into another medium stands a very high Transformation of an article into another medium stands a very high
chance of discarding or interfering with the protection inherent in chance of discarding or interfering with the protection inherent in
the news system against duplicate articles. The most common problem the news system against duplicate articles. The most common problem
caused by gateways is "spews," gateway loops that cause previously caused by gateways is "spews," gateway loops that cause previously
posted articles to be reinjected repeatedly into Usenet. To prevent posted articles to be reinjected repeatedly into Usenet. To prevent
this, a gateway MUST take precautions against loops, as detailed this, a gateway MUST take precautions against loops, as detailed
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
below. below.
If bidirectional gatewaying (both an incoming and an outgoing If bidirectional gatewaying (both an incoming and an outgoing
gateway) is being set up between Netnews and some other medium, the gateway) is being set up between Netnews and some other medium, the
incoming and outgoing gateways SHOULD be coordinated to avoid incoming and outgoing gateways SHOULD be coordinated to avoid
unintended reinjection of gated articles. Circular gatewaying unintended reinjection of gated articles. Circular gatewaying
(gatewaying a message into another medium and then back into Netnews) (gatewaying a message into another medium and then back into Netnews)
SHOULD NOT be done; encapsulation of the article SHOULD be used SHOULD NOT be done; encapsulation of the article SHOULD be used
instead where this is necessary. instead where this is necessary.
skipping to change at page 39, line 5 skipping to change at page 41, line 5
In general, the following practices are recommended for all outgoing In general, the following practices are recommended for all outgoing
gateways, regardless of whether there is known to be a related gateways, regardless of whether there is known to be a related
incoming gateway, both as a precautionary measure and as a guideline incoming gateway, both as a precautionary measure and as a guideline
to quality of implementation. to quality of implementation.
1. The message identifier of the news article should be preserved if 1. The message identifier of the news article should be preserved if
at all possible, preferably as or within the corresponding unique at all possible, preferably as or within the corresponding unique
identifier of the other medium, but if not at least as a comment identifier of the other medium, but if not at least as a comment
in the message. This helps greatly with preventing loops. in the message. This helps greatly with preventing loops.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
2. The Date and Injection-Date of the news article should also be 2. The Date and Injection-Date of the news article should also be
preserved if possible, for similar reasons. preserved if possible, for similar reasons.
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, a to provide some indication even if not successful; at the least, a
human-readable indication that the article should not be gated 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.
skipping to change at page 40, line 5 skipping to change at page 42, line 5
Incoming gateways MUST NOT pass control messages (articles containing Incoming gateways MUST NOT pass control messages (articles containing
a Control- or Supersedes-header) without removing or renaming that a Control- or Supersedes-header) without removing or renaming that
header. Gateways MAY, however, generate their own cancel messages, header. Gateways MAY, however, generate their own cancel messages,
under the general allowance for injecting agents to cancel their own under the general allowance for injecting agents to cancel their own
messages ([USEAGE]). If a gateway receives a message that it can messages ([USEAGE]). If a gateway receives a message that it can
determine is a valid equivalent of a cancel message in the medium it determine is a valid equivalent of a cancel message in the medium it
is gatewaying, it SHOULD discard that message without gatewaying it, is gatewaying, it SHOULD discard that message without gatewaying it,
generate a corresponding cancel message of its own, and inject that generate a corresponding cancel message of its own, and inject that
cancel message. cancel message.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
Incoming gateways MUST NOT inject control messages other than Incoming gateways MUST NOT inject control messages other than
cancels. Encapsulation SHOULD be used instead of gatewaying, when cancels. Encapsulation SHOULD be used instead of gatewaying, when
direct posting is not possible or desirable. direct posting is not possible or desirable.
NOTE: It is not unheard of for mail-to-news gateways to be used NOTE: It is not unheard of for mail-to-news gateways to be used
to post control messages, but encapsulation should be used for to post control messages, but encapsulation should be used for
these cases instead. Gateways by their very nature are these cases instead. Gateways by their very nature are
particularly prone to loops. Spews of normal articles are bad particularly prone to loops. Spews of normal articles are bad
enough; spews of control messages with special significance to enough; spews of control messages with special significance to
skipping to change at page 41, line 5 skipping to change at page 43, line 5
identifiers has to be used to avoid collisions. It would identifiers has to be used to avoid collisions. It would
obviously be preferable for there to be only one gateway which obviously be preferable for there to be only one gateway which
crossposts, but this may not be possible to coordinate. crossposts, but this may not be possible to coordinate.
If no date information is available, the gateway MAY supply a Date- If no date information is available, the gateway MAY supply a Date-
header with the gateway's current date. If no injection-date header with the gateway's current date. If no injection-date
information is available, the gateway MUST supply an Injection-Date- information is available, the gateway MUST supply an Injection-Date-
header with whatever date information is available, and otherwise header with whatever date information is available, and otherwise
with the gateway's current date. If only partial information is with the gateway's current date. If only partial information is
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
available (e.g. date but not time), this SHOULD be fleshed out to a available (e.g. date but not time), this SHOULD be fleshed out to a
full Date- and/or Injection-Date-header by adding default values full Date- and/or Injection-Date-header by adding default values
rather than discarding this information. Only in very exceptional rather than discarding this information. Only in very exceptional
circumstances should Date information be discarded, as it plays an circumstances should Date information be discarded, as it plays an
important role in preventing reinjection of old messages. important role in preventing reinjection of old messages.
An incoming gateway MUST add a Sender-header to the news article it An incoming gateway MUST add a Sender-header to the news article it
forms containing the mailbox of the administrator of the gateway. forms containing the mailbox of the administrator of the gateway.
Problems with the gateway may be reported to this mailbox. The Problems with the gateway may be reported to this mailbox. The
skipping to change at page 42, line 5 skipping to change at page 44, line 5
the envelope sender. Instead, articles that are rejected by the the envelope sender. Instead, articles that are rejected by the
news server (for reasons not warranting silent discarding of the news server (for reasons not warranting silent discarding of the
message) result in a bounce message sent to an errors address message) result in a bounce message sent to an errors address
known not to forward to any mailing lists, so that they can be known not to forward to any mailing lists, so that they can be
handled by the news administrators. handled by the news administrators.
These precautions have proven effective in practice at preventing These precautions have proven effective in practice at preventing
loops for this particular application (bidirectional gatewaying loops for this particular application (bidirectional gatewaying
between mailing lists and locally distributed newsgroups where both between mailing lists and locally distributed newsgroups where both
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
gateways can be designed together). General gatewaying to world-wide gateways can be designed together). General gatewaying to world-wide
newsgroups poses additional difficulties; one must be very wary of newsgroups poses additional difficulties; one must be very wary of
strange configurations, such as a newsgroup gated to a mailing list strange configurations, such as a newsgroup gated to a mailing list
which is in turn gated to a different newsgroup. which is in turn gated to a different newsgroup.
8. Security and Related Considerations 8. Security and Related Considerations
There is no security. Don't fool yourself. Usenet is a prime example There is no security. Don't fool yourself. Usenet is a prime example
of an Internet Adhocratic-Anarchy; that is, an environment in which of an Internet Adhocratic-Anarchy; that is, an environment in which
skipping to change at page 43, line 5 skipping to change at page 45, line 5
to their precursors, or which quote their precursors in full with the to their precursors, or which quote their precursors in full with the
addition of minimal extra material (especially if this process is addition of minimal extra material (especially if this process is
iterated), and by crossposting to, or setting followups to, totally iterated), and by crossposting to, or setting followups to, totally
unrelated newsgroups. unrelated newsgroups.
Many have argued that "spam", massively multiposted (and to a lesser Many have argued that "spam", massively multiposted (and to a lesser
extent massively crossposted) articles, usually for advertising extent massively crossposted) articles, usually for advertising
purposes, also constitutes a DoS attack in its own regard. This may purposes, also constitutes a DoS attack in its own regard. This may
be so. be so.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
Such articles intended to deny service, or other articles of an Such articles intended to deny service, or other articles of an
inflammatory nature, may also have their From or Reply-To addresses inflammatory nature, may also have their From or Reply-To addresses
set to valid but incorrect email addresses, thus causing large set to valid but incorrect email addresses, thus causing large
volumes of email to descend on the true owners of those addresses. volumes of email to descend on the true owners of those addresses.
Similar effects could be caused by any email header which could cause Similar effects could be caused by any email header which could cause
every reading agent receiving it to take some externally visible every reading agent receiving it to take some externally visible
action. For example, the Disposition-Notification-To-header defined action. For example, the Disposition-Notification-To-header defined
in [RFC 2298] could cause huge numbers of acknowledgements to be in [RFC 2298] could cause huge numbers of acknowledgements to be
emailed to an unsuspecting third party (for which reason [RFC 2298] emailed to an unsuspecting third party (for which reason [RFC 2298]
declares that that header SHOULD NOT be used in Netnews). declares that that header SHOULD NOT be used in Netnews).
It is a violation of this standard for a poster to use as his address It is a violation of this standard for a poster to use as his address
a mailbox which he is not entitled to use. Even addresses with an a mailbox which he is not entitled to use. Even addresses with an
invalid local-part but a valid domain can cause disruption to the invalid local-part but a valid domain can cause disruption to the
administrators of such domains. Posters who wish to remain anonymous administrators of such domains. Posters who wish to remain anonymous
or to prevent automated harvesting of their addresses, but who do not or to prevent automated harvesting of their addresses, but who do not
care to take the additional precautions of using more sophisticated care to take the additional precautions of using more sophisticated
anonymity measures, should avoid that violation by the use of anonymity measures, should avoid that violation by the use of
addresses ending in the ".invalid" top-level-domain (see a-5.2). addresses ending in the ".invalid" top-level-domain (see 7.5).
A malicious poster may also prevent his article being seen at a A malicious poster may also prevent his article being seen at a
particular site by preloading that site into the Path-header (a- particular site by preloading that site into the Path-header (a-
5.6.1) and may thus prevent the true owner of a forged From or 5.6.1) and may thus prevent the true owner of a forged From or
Reply-To address from ever seeing it. Reply-To address from ever seeing it.
A malicious complainer may submit a modified copy of an article (e.g. A malicious complainer may submit a modified copy of an article (e.g.
with an altered Injection-Info-header) to the administrator of an with an altered Injection-Info-header) to the administrator of an
injecting agent in an attempt to discredit the author of that article injecting agent in an attempt to discredit the author of that article
and even to have his posting privileges removed. Administrators and even to have his posting privileges removed. Administrators
skipping to change at page 44, line 5 skipping to change at page 46, line 5
the network by making proper use of the Injection-Info- (a-6.19) and the network by making proper use of the Injection-Info- (a-6.19) and
Complaints-To- (a-6.20) headers, it makes no provision for Complaints-To- (a-6.20) headers, it makes no provision for
enforcement, which may in consequence be patchy. Nevertheless, enforcement, which may in consequence be patchy. Nevertheless,
injecting sites which persistently fail to honour their injecting sites which persistently fail to honour their
responsibilities or to comply with generally accepted standards of responsibilities or to comply with generally accepted standards of
behaviour are likely to find themselves blacklisted, with their behaviour are likely to find themselves blacklisted, with their
articles refused propagation and even subject to cancellation, and articles refused propagation and even subject to cancellation, and
other relaying sites would be well advised to withdraw peering other relaying sites would be well advised to withdraw peering
arrangements from them. arrangements from them.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
8.2.2. Compromise of System Integrity 8.2.2. Compromise of System Integrity
The posting of unauthorized (as determined by the policies of the The posting of unauthorized (as determined by the policies of the
relevant hierarchy) control messages can cause unwanted newsgroups to relevant hierarchy) control messages can cause unwanted newsgroups to
be created, or wanted ones removed, from serving agents. be created, or wanted ones removed, from serving agents.
Administrators of such agents SHOULD therefore take steps to verify Administrators of such agents SHOULD therefore take steps to verify
the authenticity of such control messages, either by manual the authenticity of such control messages, either by manual
inspection (particularly of the Approved-header) or by checking any inspection (particularly of the Approved-header) or by checking any
digital signatures that may be provided (see a-7.1). In addition, digital signatures that may be provided (see a-7.1). In addition,
skipping to change at page 45, line 5 skipping to change at page 47, line 5
Reading agents should be chary of acting automatically upon MIME Reading agents should be chary of acting automatically upon MIME
objects with an "application" Content-Type that could change the objects with an "application" Content-Type that could change the
state of that agent, except in contexts where such applications are state of that agent, except in contexts where such applications are
specifically expected (see a-6.21). Even the Content-Type specifically expected (see a-6.21). Even the Content-Type
"text/html" could have unexpected side effects on account of embedded "text/html" could have unexpected side effects on account of embedded
objects, especially embedded executable code or URLs that invoke objects, especially embedded executable code or URLs that invoke
non-news protocols such as HTTP [RFC 2616]. It is therefore non-news protocols such as HTTP [RFC 2616]. It is therefore
generally recommended that reading agents do not enable the execution generally recommended that reading agents do not enable the execution
of such code (since it is extremely unlikely to have a valid of such code (since it is extremely unlikely to have a valid
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
application within Netnews) and that they only honour URLs referring application within Netnews) and that they only honour URLs referring
to other parts of the same article. to other parts of the same article.
Non-printable characters embedded in article bodies may have Non-printable characters embedded in article bodies may have
surprising effects on printers or terminals, notably by reconfiguring surprising effects on printers or terminals, notably by reconfiguring
them in undesirable ways which may become apparent only after the them in undesirable ways which may become apparent only after the
reading agent has terminated. reading agent has terminated.
8.3. Liability 8.3. Liability
skipping to change at page 46, line 5 skipping to change at page 48, line 5
clarification and additional optional parameters, to an existing clarification and additional optional parameters, to an existing
registration. "Message/rfc822" should now be used in place of registration. "Message/rfc822" should now be used in place of
the obsoleted "message/news". the obsoleted "message/news".
10. References 10. References
[To Do: Split this section into Normative and Informative references. [To Do: Split this section into Normative and Informative references.
This will probably be delayed until the final draft, for technical This will probably be delayed until the final draft, for technical
reasons.] reasons.]
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
[ANSI X3.4] "American National Standard for Information Systems - [ANSI X3.4] "American National Standard for Information Systems -
Coded Character Sets - 7-Bit American National Standard Code for Coded Character Sets - 7-Bit American National Standard Code for
Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986. Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
[ARTICLE] Charles H. Lindsey, "News Article Format and Transmission", [ARTICLE] Charles H. Lindsey, "News Article Format and Transmission",
draft-ietf-usefor-article-format-*.txt. draft-ietf-usefor-article-format-*.txt.
[NNTP] Clive D.W. Feather, "Network News Transport Protocol", draft- [NNTP] Clive D.W. Feather, "Network News Transport Protocol", draft-
ietf-nntpext-base-*.txt. ietf-nntpext-base-*.txt.
[PGPVERIFY] David Lawrence,
<ftp://ftp.isc.org/pub/pgpcontrol/README.html>.
[RFC 1036] M. Horton and R. Adams, "Standard for Interchange of [RFC 1036] M. Horton and R. Adams, "Standard for Interchange of
USENET Messages", RFC 1036, December 1987. USENET Messages", RFC 1036, December 1987.
[RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail [RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[RFC 2048] N. Freed, J. Klensin, and J. Postel, "Multipurpose [RFC 2048] N. Freed, J. Klensin, and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996. Procedures", RFC 2048, November 1996.
skipping to change at page 46, line 58 skipping to change at page 49, line 5
messages", RFC 850, June 1983. messages", RFC 850, June 1983.
[RFC 976] Mark R. Horton, "UUCP mail interchange format standard", [RFC 976] Mark R. Horton, "UUCP mail interchange format standard",
RFC 976, February 1986. RFC 976, February 1986.
[Son-of-1036] Henry Spencer, "News article format and transmission", [Son-of-1036] Henry Spencer, "News article format and transmission",
<ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>, June 1994. <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>, June 1994.
[USEAGE] draft-ietf-usefor-useage-*.txt. [USEAGE] draft-ietf-usefor-useage-*.txt.
News Article Architecture and Protocols December 2004
[USEFOR] C. H. Lindsey et al, "News Article Format", draft-ietf- [USEFOR] C. H. Lindsey et al, "News Article Format", draft-ietf-
usefor-usefor-format-*.txt. usefor-usefor-format-*.txt.
News Article Architecture and Protocols September 2004
[USEPRO] This Standard. [USEPRO] This Standard.
11. Acknowledgements 11. Acknowledgements
TBD TBD
12. Contact Address 12. Contact Address
Editor Editor
skipping to change at page 47, line 57 skipping to change at page 50, line 4
Usenet Etiquette - Please Read Usenet Etiquette - Please Read
body body
body body
body body
The first line consisted of an "A" followed by an article ID The first line consisted of an "A" followed by an article ID
(analogous to a message identifier and used for similar purposes). (analogous to a message identifier and used for similar purposes).
The second line was the list of newsgroups. The third line was the The second line was the list of newsgroups. The third line was the
path. The fourth was the date, in the format above (all fields fixed path. The fourth was the date, in the format above (all fields fixed
width), resembling an Internet date but not quite the same. The fifth width), resembling an Internet date but not quite the same. The fifth
was the subject.
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
was the subject.
This format is documented for archeological purposes only. Articles This format is documented for archeological purposes only. Articles
MUST NOT be generated in this format. MUST NOT be generated in this format.
Appendix A.2 - Early B-News Article Format Appendix A.2 - Early B-News Article Format
The obsolete pseudo-Internet article format, used briefly during the The obsolete pseudo-Internet article format, used briefly during the
transition between the A News format and the modern format, followed transition between the A News format and the modern format, followed
the general outline of a MAIL message but with some non-standard the general outline of a MAIL message but with some non-standard
headers. For example: headers. For example:
skipping to change at page 49, line 5 skipping to change at page 51, line 5
reply address. Whilst of some utility when Usenet was much smaller reply address. Whilst of some utility when Usenet was much smaller
than it is now, they had become no more than a tool for the malicious than it is now, they had become no more than a tool for the malicious
sending of mailbombs. Moreover, many organizations now consider sending of mailbombs. Moreover, many organizations now consider
information about their internal connectivity to be confidential. information about their internal connectivity to be confidential.
version version
sendsys sendsys
whogets whogets
senduuname senduuname
News Article Architecture and Protocols September 2004 News Article Architecture and Protocols December 2004
"Version" requested details of the transport software in use at a "Version" requested details of the transport software in use at a
site. "Sendsys" requested the full list of newsgroups taken, and the site. "Sendsys" requested the full list of newsgroups taken, and the
peering arrangements. "Who gets" was similar, but restricted to a peering arrangements. "Who gets" was similar, but restricted to a
named newsgroup. "Senduuname" resembled "sendsys" but restricted to named newsgroup. "Senduuname" resembled "sendsys" but restricted to
the list of peers connected by UUCP. the list of peers connected by UUCP.
Historically, a checkgroups body consisting of one or two lines, the Historically, a checkgroups body consisting of one or two lines, the
first of the form "-n newsgroup", caused check-groups to apply to first of the form "-n newsgroup", caused check-groups to apply to
only that single newsgroup. only that single newsgroup.
skipping to change at page 49, line 30 skipping to change at page 51, line 30
the actions, in the same way the Control-header does now. the actions, in the same way the Control-header does now.
These forms are documented for archeological purposes only; they MUST These forms are documented for archeological purposes only; they MUST
NO LONGER be used. NO LONGER be used.
Appendix B - Notices Appendix B - Notices
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
This document and translations of it may be copied and furnished to except as set forth therein, the authors retain all their rights.
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
News Article Architecture and Protocols September 2004
Internet organizations, except as needed for the purpose of This document and the information contained herein are provided on an
developing Internet standards in which case the procedures for "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
copyrights defined in the Internet Standards process must be OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
followed, or as required to translate it into languages other than ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
English.
The limited permissions granted above are perpetual and will not be News Article Architecture and Protocols December 2004
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix C - Change Log Appendix C - Change Log
[This Appendix is to be removed prior to final publication.] [This Appendix is to be removed prior to final publication.]
For version 01 For version 01
1 Numerous texts describing protocol features related to 1 Numerous texts describing protocol features related to
particular headers in parts of [ARTICLE] which were destined to particular headers in parts of [ARTICLE] which were destined to
become part of [USEFOR] have been moved to appropriate locations become part of [USEFOR] have been moved to appropriate locations
skipping to change at line 2758 skipping to change at page 52, line 41
3 Some demotions MUST -> SHOULD -> MAY, as noted in pseudo- 3 Some demotions MUST -> SHOULD -> MAY, as noted in pseudo-
comments, have been made or proposed in sections comments, have been made or proposed in sections
7.3 7.3
7.3 Step 4. 7.3 Step 4.
4 Part of the procedure for examining Path-headers by relaying 4 Part of the procedure for examining Path-headers by relaying
agents has been moved to serving agents, as explained in agents has been moved to serving agents, as explained in
pseudo-comments in section 7.4. pseudo-comments in section 7.4.
5 Some renumbering of sections and minor textual clarifications. 5 Some renumbering of sections and minor textual clarifications.
For version 02
1 2nd para. of a-7 temporarily reinstated in section 6.
2 Para. in section 6 relating to propagation of control messages
and local policy removed to [USEAGE].]
News Article Architecture and Protocols December 2004
3 Requirement for some relaying agents to examine control messages
for non-existent groups
6
7.3
4 Text regarding "aliasing out" brought into line with actual
practice.
7.3
5 More realistic wording regarding the expectations of reading
agents
7.7
7.4
6 "Precursor" is now defined for all cases in which a References
header may be used (even though "followup" is not always defined
under Alternative-1).
2.1
7 Provision is made for a poster to use a mailbox ending in
".invalid" in a From header (formerly in a-5.2).
7.5
8 "Inheritable" and "Variant" headers defined (formerly in a-
4.2.5).
2.3
9 Additional wording regarding function of verb/arguments/body in
control messages (formerly in a-6.13).
6
10 NOTE regarding not altering message indentifiers during
transport or copying added (formerly in a-5.3).
7.3
11 All mention of MIME-style parameters and extension-parameters
removed.
3.1
7.6
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/