draft-ietf-usefor-article-01.txt   draft-ietf-usefor-article-02.txt 
News Article Format News Article Format
draft-ietf-usefor-article-01 draft-ietf-usefor-article-02
USEFOR Working Group USEFOR Working Group
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-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- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
"work in progress." "work in progress."
skipping to change at line 71 skipping to change at line 74
This document is intended to provide a definitive guide to the This document is intended to provide a definitive guide to the
article format and interpretations thereof. Backward article format and interpretations thereof. Backward
compatibility is a major goal, but where this document and compatibility is a major goal, but where this document and
earlier documents or practices collide, this document should be earlier documents or practices collide, this document should be
used. used.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Definitions, Notations and Conventions 1.1 Scope and Objectives
2.1 Definitions.
2.2. Textual Notations
2.3. Syntax Notation
2.4. Language
3. Relation To [MAIL] (RFC 822 etc.)
4. Basic Format
4.1 Overall Syntax
4.2. Syntax of News Articles
4.3. Headers
4.3.1. Names and Contents
4.3.2 Header Classes
4.3.3 Experimental Headers
4.3.4 Persistent Headers
4.3.5. Variant Headers
4.3.6. Header Classes
4.3.6.1 Experimental Headers
4.3.6.2 Persistent Headers
4.3.6.3 Examples
4.3.6.4 Comment Headers
4.3.6.5. Variant Headers
4.3.7. White Space and Continuations
4.3.8 Comments
4.3.9. Undesirable Headers
4.4. Body
4.4.1. Body Format Issues
4.4.2. Body Conventions
4.5. Characters And Character Sets
4.5.1. Character Sets within Article Headers
4.5.2 Character Sets within Article Bodies
4.6. Size Limits
4.7. Example
5. Mandatory Headers
5.1. Date
5.2. From
5.2.1 Examples:
5.3. Message-ID
5.4. Subject
5.4.1 Examples:
5.5. Newsgroups
5.5.1 Forbidden newsgroup names
5.6 Path
5.6.1 Format
5.6.2 Adding an entry to the Path header.
5.6.3 The tail Entry
5.6.4 The Injecting Agent Entry
5.6.5 Delimiter Summary
5.6.6 Other formatting Issues
5.6.6.1 Use of "!"
5.6.7 Suggested Verification Methods
5.6.8 Issues
6. Optional Headers "Netnews" is a set of protocols that enables news "articles"
6.1 Followup-To (which resemble mail messages) to be broadcast to
6.2 Expires potentially-large audiences, using a flooding algorithm which
6.3. Reply-To propagates copies throughout a network of participating hosts,
6.3.1 Examples: typically storing only one copy per host and making it
6.4. References available on demand to readers able to access that host.
6.4.1 Examples: Articles are grouped, for convenience of access, into
6.5. Control "newgroups", and the newsgroups themselves are arranged into
6.6. Control Messages "hierarchies". An important characteristic of Netnews is the
6.6.1 The "newgroup" Control Message lack of any requirement for a central administration or for
6.6.1.1 multipart/newsgroupinfo the establishment of any controlling host to manage the
6.6.1.2 application/newsgroupinfo network. A network which limits participation to some
6.6.1.3 Initial Named Articles restricted set of hosts (within some company, for example) is
6.6.2 The "rmgroup" Control Message a "closed" network; otherwise it is an "open" network. A set
6.6.3 The "mvgroup" Control Message of hosts within a network which, by mutual arrangement,
6.6.3.1 Single group operates some variant (whether more or less restrictive) of
6.6.3.2 Multiple Groups the Netnews protocols is a "cooperating subnet".
6.6.4 The "checkgroups" Control Message
6.6.4.1 Example:
6.6.5 application/newscheckgroups
6.6.5.1 Examples
6.6.6 Cancel
6.6.7 ihave, sendme
6.6.8 Obsolete control messages.
6.7. Distribution
6.8. Keywords
6.9. Summary
6.10. Approved
6.11 Lines
6.12. Xref
6.13. Organization
6.14. User-Agent
6.14.1 Examples:
6.15 MIME headers
6.15.1 Syntax
6.15.2 Content-Transfer-Encoding
6.15.3 Content-Type
6.15.3.1 Text
6.15.3.2 Application
6.15.3.4 Image, Audio and Video
6.15.3.5 Multipart
6.15.3.6 Message
6.15.3.7 Character Sets
6.15.4 MIME within headers
6.15. Supersedes / Replaces
6.15.1 Message-ID version numbers chain procedure.
6.15.2 Implementation and Use Note
6.15.3 Transition
6.15.4 Replaced-by
6.15.5.1 Examples
6.15.5.2 Example
6.15.6 Dates
6.15.7 Issues
6.16 Archive
6.17. Obsolete Headers
7. Duties of Various Agents "Usenet" is a particular worldwide open network based upon the
7.1 Duties of an Injecting Agent. Netnews protocols. Anybody can join (it is simply necessary to
7.1.1 Proto-articles. negotiate an exchange of articles with one or more other
7.1.2 Procedure followed by Injecting Agents. participating hosts). Usenet "belongs" to those who administer
7.1.3 Headers added by Injecting Agents. the hosts of which it is comprised. There is no Cabal with
7.2 Duties of a Relaying Agent overall authority to direct what is to be be allowed.
7.2.1 Unwanted and Invalid articles Nevertheless, there do exist agencies within Usenet that have
7.3 Duties of a Serving Agent authority to establish policies and to perform administrative
7.3.1 Unwanted articles functions, but such authority derives solely from the consent
7.4 Duties of a Posting Agent. of those sites which choose to recognise it (and who can
7.5 Duties of a Followup Agent decline to exchange articles with sites which choose not to
7.6 Duties of a Gateway recognise it). Usually, the authority of such an agency is
restricted to a particular hierarchy, or group of hierarchies.
8. Propagation and Processing A "policy" is a rule intended to facilitate the smooth
operation of a network by establishing parameters which
restrict behaviour that, whilst technically unexceptionable,
would nevertheless contravene some accepted standard of "Good
Netkeeping". Since the ultimate beneficiaries of a network are
its human readers, who will be less tolerant of poorly
designed interfaces than mere computers, articles in breach of
established policy can cause considerable annoyance to their
recipients.
9. Security And Related Issues Policies may well vary from network to network, from hierarchy
9.1 Attacks to hierarchy within one network, and even between individual
newgroups within one hierarchy. It is assumed, for the
purposes of this document, that agencies with the proper
authority to establish such policies will exist. However, for
the benefit of networks and hierarchies without such agencies,
and to provide a basis upon which such agencies can build,
this present document often provides default policy
parameters, usually introducing them by a phrase such as "As a
matter of policy ...".
[If we follow this route, then that phrase (or one like it, perhaps
using the word "default") can be introduced at various places in the
existing text, for example when discussing the lengths of lines in
articles, when discussing the lengths of components of newsgroup names,
and when discussing Mime Content-Types, and also in connection with the
Checkpolicies header, if we decide to have it.]
10. Security Considerations The purpose of this present document is to define the
protocols to be used for Netnews in general, and for Usenet in
particular, and to set standards to be followed by software
that implements those protocols.
11. References: It is NOT the purpose of this document to define how the
authority of various agencies to exercise control or oversight
of the various parts of Usenet is established (that is itself
a matter of policy). Nevertheless, it is assumed that such
authorities will exist, and tools are provided within the
protocols for their use.
1. Introduction 1.2 Historical Outline
Network news articles resemble mail messages but are Network news originated as the medium of communication for
broadcast to potentially-large audiences, using a flooding Usenet, circa 1980. Since then Usenet has grown explosively,
algorithm that propagates one copy to each interested host and many Internet sites participate in it. In addition, the
(or groups thereof), typically stores only one copy per news technology is now in widespread use for other purposes,
host, and does not require any central administration or on the Internet and elsewhere.
systematic registration of interested users. Network news
originated as the medium of communication for Usenet, circa
1980. Since then Usenet has grown explosively, and many
Internet sites participate in it. In addition, the news
technology is now in widespread use for other purposes, on the
Internet and elsewhere.
The earliest news interchange used the so-called "A News" The earliest news interchange used the so-called "A News"
article format. Shortly thereafter, an article format article format. Shortly thereafter, an article format vaguely
vaguely resembling Internet mail was devised and used resembling Internet mail was devised and used briefly. Both
briefly. Both of those formats are completely obsolete; of those formats are completely obsolete; they are documented
they are documented in appendix A for historical reasons in appendix A for historical reasons only. With publication
only. With publication of RFC 850 [rrr] in 1983, news of [RFC-850] in 1983, news articles came to closely resemble
articles came to closely resemble Internet mail messages, Internet mail messages, with some restrictions and some
with some restrictions and some additional headers. RFC additional headers. [RFC-1036] in 1987 updated [RFC-850]
1036 in 1987 updated RFC 850 without making major changes. without making major changes.
A Draft popularly referred to as "Son of 1036" was written in A Draft popularly referred to as "Son of 1036" [RFC-1036BIS]
1992 by Henry Spencer. That document formed the original basis was written in 1994 by Henry Spencer. That document formed the
for this document. Much is taken directly from Son of 1036, and original basis for this document. Much is taken directly from
it is hoped that we have followed its spirit and intentions. Son of 1036, and it is hoped that we have followed its spirit
and intentions.
1.3 Transport
As in this document's predecessors, the exact means used to As in this document's predecessors, the exact means used to
transmit articles from one host to another is not specified. transmit articles from one host to another is not specified.
NNTP [rrr] is the most common transmission method on the NNTP [RFC-977] is the most common transmission method on the
Internet, but a number of others are in use, including the Internet, but much transmission takes place entirely
UUCP protocol [rrr] extensively used in the early days of independent of the Internet. Other methods in use include the
Usenet, FTP, tape archives, and physically delivered magnetic UUCP protocol [RFC-976] extensively used in the early days of
and optical media. Usenet, FTP, downloading via satellite, tape archives, and
physically delivered magnetic and optical media.
Several of the mechanisms described in this document may seem
somewhat strange or even bizarre at first reading. As with
Internet mail, there is no reasonable possibility of updating
the entire installed base of news software promptly, so
interoperability with old software is critical and will
remain so. Compatibility with existing practice and
robustness in an imperfect world necessarily take priority
over elegance. Elegance is left to the implementors.
2. Definitions, Notations and Conventions 2. Definitions, Notations and Conventions
2.1 Definitions. 2.1 Definitions.
An "article" is the unit of news, analogous to a [MAIL] An "article" is the unit of news, analogous to a [MAIL]
"message". "message".
A "poster" is the person or software that composes and submits A "poster" is the person or software that composes and submits
a possibly compliant article to an injecting agent. The poster a possibly compliant article to an injecting agent. The poster
skipping to change at line 342 skipping to change at line 274
A "control message" is an article which is marked as A "control message" is an article which is marked as
containing control information; a relaying or serving agent containing control information; a relaying or serving agent
receiving such an article may (subject to permissions etc.) receiving such an article may (subject to permissions etc.)
take actions beyond just filing and passing on the article. take actions beyond just filing and passing on the article.
An article's "reply address" is the address to which mailed An article's "reply address" is the address to which mailed
replies should be sent. This is the address specified in the replies should be sent. This is the address specified in the
article's From header (see section 5.2), unless it also has a article's From header (see section 5.2), unless it also has a
Reply-To header (see section 6.3). Reply-To header (see section 6.3).
2.2. Textual Notations 2.2 Textual Notations
Throughout this document, [MAIL] is short for "the current RFCs
governing electronic mail formats, beginning with the
historical RFC 822 and continuing to its modern successors.
"ASCII" is short for "the ANSI X3.4 character set" [rrr]. Throughout this document, [MAIL] is short for "the current
While "ASCII" is often misused to refer to various character RFCs governing electronic mail formats, beginning with the
sets somewhat similar to X3.4, in this document, "ASCII" means historical [RFC-822] and continuing to its modern successors".
X3.4 and only X3.4. ASCII is a 7 bit character set. Please "ASCII" is short for "the ANSI X3.4 character set" [ANSI-
note that this document requires that all agents be 8 bit clean; X3.4]. While "ASCII" is often misused to refer to various
that is, they must accept and transmit data without changing character sets somewhat similar to X3.4, in this document
or omitting the 8th bit. "ASCII" means X3.4 and only X3.4. ASCII is a 7 bit character
set. Please note that this document requires that all agents
be 8 bit clean; that is, they must accept and transmit data
without changing or omitting the 8th bit.
Certain words used to define the significance of individual Certain words used to define the significance of individual
requirements are capitalized. "MUST", "SHOULD", "MAY" and requirements are capitalized. "MUST", "SHOULD", "MAY" and the
the same words followed by "NOT" should be read as having the same words followed by "NOT" should be read as having the same
same meaning as in RFC 2119. meaning as in [RFC-2119]. In particular, to be fully compliant
with this document, software must satisfy every relevant
"MUST" requirement. Software that satisfies every relevant
"SHOULD" requirement but not every "MUST" requirement is
partially compliant.
[However, we could step back from this by requiring less rigour in
observing "SHOULD" in the case of "matters of policy". Or perhaps we
could introduce an "OUGHT" category.]
This document contains explanatory notes using the following This document contains explanatory notes using the following
format. These may be skipped by persons interested solely format. These may be skipped by persons interested solely in
in the content of the specification. The purpose of the the content of the specification. The purpose of the notes is
notes is to explain why choices were made, to place them in to explain why choices were made, to place them in context, or
context, or to suggest possible implementation techniques. to suggest possible 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 principle, they often help the less-than-omniscient reader
grasp the purpose of the specification and the constraints grasp the purpose of the specification and the constraints
involved. Given the limitations of natural language for involved. Given the limitations of natural language for
descriptive purposes, this improves the probability that descriptive purposes, this improves the probability that
implementors and users will understand the true intent of implementors and users will understand the true intent of the
the specification in cases where the wording is not entirely specification in cases where the wording is not entirely
clear. clear.
[Remarks enclosed in square brackets, such as this one, are not part of
this document, but are editorial notes to explain matters amongst
ourselves, or to point out alternatives, or to indicate work yet to be
done.]
All numeric values are given in decimal unless otherwise All numeric values are given in decimal unless otherwise
indicated. Octets are assumed to be unsigned values for indicated. Octets are assumed to be unsigned values for this
this purpose. purpose.
Through this document we will give examples of various Throughout this document we will give examples of various
definitions, headers and other specifications. It MUST be definitions, headers and other specifications. It MUST be
remembered that these samples are for the aid of the reader remembered that these samples are for the aid of the reader
only and do NOT define any specification themselves. In order only and do NOT define any specification themselves. In order
to prevent possible conflict with "Real World" entities and to prevent possible conflict with "Real World" entities and
people the top level domain of ".example" is used in all people the top level domain of ".example" is used in all
sample domains and addresses. The hierarchy of example.* is sample domains and addresses. The hierarchy of example.* is
also used a sample hierarchy. Information on the ".example" also used as a sample hierarchy. Information on the ".example"
top level domain is in [TEST-TLDS] . top level domain is in [TEST-TLDS] .
2.3. Syntax Notation 2.3 Relation To Mail and MIME
The primary intent of this document is to describe the news
article format. Insofar as news articles are a subset of
[MAIL]'s message format augmented by some new headers, this
document incorporates many (though not all) of the provisions
of [MESSFOR], with the aim of enabling news articles to pass
through mail systems and vice versa, provided only that they
contain the minimum headers required for the mode of transport
being used. Unfortunately, the match is not perfect, but it is
the intention of this document that gateways between [MAIL]
and news should be able to operate with the minimum of
tinkering.
[This document has been designed to fit on top of the drafts currently
in preparation for Mail [MESSFOR]. It is expected that those drafts will
have progressed to the RFC stage by the time the present document in
complete, at which time all references to [MESSFOR] in the present text
will be replaced by references to that RFC.]
Likewise, this document incorporates many (though not all) of
the provisions of the MIME standards [RFC-2045 et seq] which,
though designed with [MAIL] in mind, are mostly applicable to
news.
2.4 Syntax Notation
This document uses the Augmented Backus Naur Form described in This document uses the Augmented Backus Naur Form described in
[ABNF]. A discussion of this is outside the bounds of this [RFC-2234]. A discussion of this is outside the bounds of
document, but it is expected that implementors will be able to this document, but it is expected that implementors will be
quickly understand it with reference to the defining document. able to quickly understand it with reference to the defining
document.
This document is intended to be self-contained; all syntax Much of the syntax in this document is incorporated directly
rules used in it are defined within it, and a rule with the from that given in [MESSFOR] or in the Mime specifications
same name as one found in [MAIL] does not have the same [RFC-2045 et seq], but with appropriate modifications to
definition. The lexical layer of [MAIL] is NOT, repeat NOT, permit the use of full 8bit characters, and to remove those
used in this document, and its presence must not be parts of the syntax given in [MESSFOR] that are regarded as
assumed; notably, this document spells out all places where "obsolete". Full details of this are explained in section 4.1.
white space is permitted/required and all places where [Alternatively, we could move some parts of 4.1 forward to here.]
constructs resembling [MAIL] comments can occur.
NOTE: News parsers historically have been much less NOTE: News parsers historically have been much less
permissive than [MAIL] parsers. permissive than [MAIL] parsers, and this is reflected in the
modifications referred to, and in some further specific rules.
Text in newsgroup names, header parameters, etc. is
case-sensitive unless stated otherwise.
NOTE: This is at variance with [MAIL], which is NOTE: Following [RFC-2234], literal text included in the
case-insensitive unless stated otherwise, but is syntax is to be regarded as case-insensitive. However, in
consistent with news historical practice and contradistinction to [MAIL], the NetNews protocols are
existing news software. See the comments on backward sensitive to case in some instances (as in newsgroup names,
compatibility in section 1. some header parameters, etc.). Care has been taken to indicate
this explicitly where required.
2.4. Language 2.5 Language
Various constant strings in this document, such as header names Various constant strings in this document, such as header names
and month names, are derived from English words. Despite and month names, are derived from English words. Despite
their derivation, these words do NOT change when the poster their derivation, these words do NOT change when the poster
or reader employing them is interacting in a language other or reader employing them is interacting in a language other
than English. Posting and reading agents MAY translate than English. Posting and reading agents MAY translate
as appropriate in their interaction with the poster or as appropriate in their interaction with the poster or
reader, but the forms that actually appear in articles reader, but the forms that actually appear in articles
MUST be the English-derived ones defined in this document. MUST be the English-derived ones defined in this document.
3. Relation To [MAIL] (RFC 822 etc.) 3. Changes to the existing protocols
The primary intent of this document is to completely describe This document prescribes many changes, clarifications and new
the news article format. News articles were once considered as features since the protocols described in [RFC-1036] and
a subset of [MAIL]'s message format augmented by some new [RFC-1036BIS]. It is the intention that they can be
headers; this is no longer the case. News and [MAIL] have assimilated into Usenet as it presently operates without major
diverged. It is the intention of this document that gateways interruption to the service, though some of the new features
between [MAIL] and news still be capable of performing this may not begin to show benefit until they become widely
function automatically. implemented. This sections summarizes the main changes, and
comments on some features of the transition.
[MAIL] and news do follow some of the same standards, however. 3.1 Principal Changes
In particular, the MIME standards apply equally to news
articles. o The [MAIL] conventions for parenthesis-enclosed comments
in headers are supported.
o Whitespace is permitted in Newsgroups headers, permitting
folding of such headers. Indeed, all news headers can now
be folded.
o An enhanced syntax for the Path header enables the
injection point of and the route taken by an article to be
determined with certainty.
o Netnews is firmly established as an 8bit medium.
o Large parts of MIME are recognized as an integral part of
Netnews.
o The charset for headers is always UTF-8. This will, inter
alia, permit newsgroup-names with non-ASCII characters.
o There is a new Control command 'mvgroup' to facilitate
group renaming.
o There are several new headers defined, such as Replaces
and Author-Ids, leading to increased functionality.
o There are numerous other small changes, clarifications and
enhancements.
[Doubtless many other changes should be listed, but there is little
point in doing so until our text is nearing completion. The above gives
the flavour of what should be said.]
3.2 Transitional Arrangements
An important distinction must be made between serving and
relaying agents which are responsible for the distribution and
storage of news articles, and user agents which are
responsible for interactions with users. It is important that
the former should be upgraded to conform to this document as
soon as possible to provide the benefit of the enhanced
facilities. Fortunately, the number of distinct
implementations of such agents is rather small, at least so
far as the main "backbone" of Usenet is concerned, and many of
the new features are already supported. Contrariwise, there
are a great number of implementations of user agents,
installed on a vastly greater number of small sites.
Therefore, the new functionality has been designed so that
existing agents may continue to be used, although the full
benefits may not be realised until a substantial proportion of
them have been upgraded.
In the list which follows, care has been taken to distinguish
the implications for both kinds of agent.
o [MAIL] style comments in headers do not affect serving and
relaying agents (note that the Newsgroups and Path headers
do not contain them). They are unlikely to hinder their
proper display in existing user agents except in the case
of the References header in agents which thread articles.
Therefore, it is provided that they SHOULD NOT be
generated except where permitted by the previous
standards.
o Because of its importance to all serving agents, the
extension permitting whitespace and folding in Newsgroup
headers SHOULD NOT be used unless the user is willing to
take the risk of misprocessed articles. It is believed most
existing implementations handle correctly, but this is not
certain. User agents are unaffected.
o The new style of Path header is already consistent with
the previous standards. However, the intention is that
relaying agents should henceforth reject articles in the
old style, and so this should be offered as a configurable
option for relaying agents. User agents are unaffected.
o The vast majority of serving, relaying and transport
agents are believed to be already 8bit clean (in the
slightly restricted sense in which that term is used in
the MIME standards). User agents that do not implement
MIME may be disadvantaged, but no more so than at present
when faced with 8bit characters (which currently abound in
spite of the previous standards).
o The introduction of MIME reflects a practice that is
already widespread. Articles in strict compliance with
the previous standards (using strict ASCII) will be
unaffected. Many user agents already support it, at least
to the extent of widely used charsets such as ISO8859-1.
Users expecting to read articles using the more exotic
charsets will need to acquire suitable reading agents. It
is not intended, in general, that any single user agent
will be able to display every charset known to IANA, but
all such agents MUST support ASCII. Serving and relaying
agents are not affected.
o The use of the UTF-8 charset for headers will not affect
any existing usage, since ASCII is a strict subset of
UTF-8. Insofar as newsgroup names containing non-ASCII
characters can now be expected to arise, support from
serving and relaying agents will be necessary. It is
believed that the customary storage structure used by
serving agents can already cope (perhaps not ideally) with
such names. Note that it is not necessary for serving and
relaying agents to understand all the characters available
in UTF-8, though it is desirable for them to be
displayable for diagnostic purposes via some escape
mechanism using, for example, the visible subset of ASCII.
For users expecting to use the more exotic charsets
available under UTF-8, the remarks already made in
connection with MIME will apply.
o The new Control: mvgroup command will need to be
implemented in serving agents. It SHOULD be used in
conjunction with pairs of matching rmgroup and newgroup
commands (injected shortly after the mvgroup) until such
time as mvgroup is widely implemented. The new Replaces
header is also effectively a Control command, and
transitional arrangements are provided which should be
used in the meantime. User agents are unaffected.
o The headers newly introduced by this document can safely
be ignored by existing software, albeit with loss of the
new functionality.
4. Basic Format 4. Basic Format
4.1 Overall Syntax 4.1 Overall Syntax
Much of the syntax of News Articles is based on the Much of the syntax of News Articles is based on the
corresponding syntax defined by [MESSFOR], which is deemed to corresponding syntax defined by [MESSFOR], which is deemed to
have been incorporated into this standard as required. have been incorporated into this standard as required.
However, there are some important differences arising from the However, there are some important differences arising from the
fact that [MESSFOR] does not recognise anything other than fact that [MESSFOR] does not recognise anything other than
skipping to change at line 549 skipping to change at line 624
NOTE: Terminology here follows the current custom in the news NOTE: Terminology here follows the current custom in the news
community, rather than the [MESSFOR] convention of referring community, rather than the [MESSFOR] convention of referring
to what is here called a "header" as a "header-field" or to what is here called a "header" as a "header-field" or
"field". "field".
Note that the separator line must be truly empty, not just a Note that the separator line must be truly empty, not just a
line containing white space. Further empty lines following it line containing white space. Further empty lines following it
are part of the body, as are empty lines at the end of the are part of the body, as are empty lines at the end of the
article. article.
NOTE: The syntax above defines the canonical form of a news article as a
sequence of lines each terminated by CRLF. This does not prevent serving
agents or transport agents from storing or handling the article in other
formats (e.g. using a single LF in place of CRLF) so long as the overall
effects achieved are as defined by this document when operating on the
canonical form.
4.3. Headers 4.3. Headers
4.3.1. Names and Contents 4.3.1. Names and Contents
Despite the restrictions on header-name syntax imposed by the Despite the restrictions on header-name syntax imposed by the
grammar, relayers and reading agents SHOULD tolerate header grammar, relayers and reading agents SHOULD tolerate header
names containing any ASCII printable character other than names containing any ASCII printable character other than
colon (":", ASCII 58). [That brings it into line with colon (":", ASCII 58). [That brings it into line with
<optional-field> as given in [MESSFOR].] <optional-field> as given in [MESSFOR].]
skipping to change at line 589 skipping to change at line 671
Header-names are case-insensitive. There is a preferred case Header-names are case-insensitive. There is a preferred case
convention, which posters and posting agents SHOULD use: convention, which posters and posting agents SHOULD use:
each hyphen-separated "word" has its initial letter (if any) each hyphen-separated "word" has its initial letter (if any)
in uppercase and the rest in lowercase, except that some in uppercase and the rest in lowercase, except that some
abbreviations have all letters uppercase (e.g. "Message-ID" abbreviations have all letters uppercase (e.g. "Message-ID"
and "MIME-Version"). The forms used in this standard are the and "MIME-Version"). The forms used in this standard are the
preferred forms for the headers described herein. Relaying and preferred forms for the headers described herein. Relaying and
reading agents MUST, however, tolerate articles not obeying reading agents MUST, however, tolerate articles not obeying
this convention. this convention.
[I thought we were doing away with header classes, except to
discuss eXperimental. Consensus, please?]
4.3.2 Header Classes 4.3.2 Header Classes
There are four special classes of headers that may be present There are four special classes of headers that may be present
in an article: Experimental, Persistent, Comment, and in an article: Experimental, Persistent, Comment, and
Variant. All other headers are ephemeral. These classes are Variant. All other headers are ephemeral. These classes are
significant in how newsreaders and servers should treat them significant in how newsreaders and servers should treat them
when encountered. when encountered.
4.3.3 Experimental Headers 4.3.3 Experimental Headers
skipping to change at line 907 skipping to change at line 992
of the quoted text (even if it is empty) with the character of the quoted text (even if it is empty) with the character
">" (or preferably with "> "). This will result in multiple ">" (or preferably with "> "). This will result in multiple
levels of ">" when quoted content itself contains quoted levels of ">" when quoted content itself contains quoted
content. The followup agent SHOULD also precede the quoted content. The followup agent SHOULD also precede the quoted
content by an "attribution line" incorporating at least the content by an "attribution line" incorporating at least the
name of the precursor's poster. name of the precursor's poster.
The following convention for attribution lines, whilst not The following convention for attribution lines, whilst not
mandated by this Standard, is intended to facilitate their mandated by this Standard, is intended to facilitate their
automatic recognition and processing by sophisticated reading automatic recognition and processing by sophisticated reading
agents. The following fields describing the precursor should, agents. The following fields describing the precursor SHOULD,
if present, be in the given order. if present, be in the given order.
A single Newsgroup name (the one from which the followup is A single Newsgroup name (the one from which the followup is
being made) enclosed within <...> or <news:...> being made) enclosed within <...> or <news:...>
The precursor's Message-ID enclosed within <...> or <news:...> The precursor's Message-ID enclosed within <...> or <news:...>
The precursor's poster's Name enclosed within "..." The precursor's poster's Name enclosed within "..."
The precursor's poster's Email address enclosed within <...> or The precursor's poster's Email address enclosed within <...> or
skipping to change at line 1093 skipping to change at line 1178
that length, both in headers and in bodies, and all such that length, both in headers and in bodies, and all such
software SHOULD support lines of arbitrary length. In software SHOULD support lines of arbitrary length. In
particular, relaying agents MUST transmit lines of arbitrary particular, relaying agents MUST transmit lines of arbitrary
length without truncation or any other modification. length without truncation or any other modification.
NOTE: The limit of 998 octets is consistent with the NOTE: The limit of 998 octets is consistent with the
corresponding limit in [MESSFOR]. corresponding limit in [MESSFOR].
In plain-text messages (those with no MIME headers, or those In plain-text messages (those with no MIME headers, or those
with a MIME Content-Type of text/plain) posting agents SHOULD with a MIME Content-Type of text/plain) posting agents SHOULD
encourage the practice of keeping the length of body lines to endeavour to keep the length of body lines within some
within 79 characters at most, and preferably to within 72 reasonable limit. The size of this limit is a matter of
characters (to allow room for quoting in followups). However, policy, the default being to keep within 79 characters at
posting agents MUST permit the poster to include longer lines most, and preferably within 72 characters (to allow room for
if he so insists. quoting in followups). However, posting agents MUST permit
the poster to include longer lines if he so insists.
NOTE: Plain-text messages are intended to be displayed "as-is" NOTE: Plain-text messages are intended to be displayed "as-is"
without any special action (such as automatic line splitting) without any special action (such as automatic line splitting)
on the part of the recipient. The limit (72 or 79) is on the part of the recipient. The policy limit (e.g. 72 or 79)
expressed as a number of characters (as they will be displayed should be expressed as a number of characters (as they will be
by a reading agent) rather than as the number of octets used displayed by a reading agent) rather than as the number of
to encode them. octets used to encode them.
Posting agents SHOULD fold headers by inserting CRLF followed Posting agents SHOULD fold headers by inserting CRLF followed
by 1*WSP at positions (preferably higher-level ones - see by 1*WSP at positions (preferably higher-level ones - see
4.3.2) where this is syntactically allowed so as to keep, so 4.3.2) where this is syntactically allowed so as to keep, so
far as is possible, all header lines within 79 characters. far as is possible, all header lines within 79 characters.
Likewise, injecting agents SHOULD fold any headers generated Likewise, injecting agents SHOULD fold any headers generated
automatically by themselves. Relaying agents MUST NOT fold automatically by themselves. Relaying agents MUST NOT fold
header lines (i.e. they must pass on the folding as received). header lines (i.e. they must pass on the folding as received).
NOTE: There is NO restriction on the number of lines into NOTE: There is NO restriction on the number of lines into
skipping to change at line 1244 skipping to change at line 1330
subject-content = [ back-reference ] pure-subject CRLF subject-content = [ back-reference ] pure-subject CRLF
pure-subject = nonblank-text pure-subject = nonblank-text
back-reference = %x52.65.3A.20 ; which is a case-sensitive back-reference = %x52.65.3A.20 ; which is a case-sensitive
"Re: " "Re: "
The pure-subject MUST NOT begin with "Re: ". The default The pure-subject MUST NOT begin with "Re: ". The default
subject-content of a followup is the string "Re: " followed by subject-content of a followup is the string "Re: " followed by
the contents of the pure-subject of the precursor. Any leading the contents of the pure-subject of the precursor. Any leading
"Re: " in the pure-subject MUST be stripped. "Re: " in the pure-subject MUST be stripped.
Followup agents SHOULD remove instances of non-standard Followup agents MAY remove instances of non-standard
back-reference (such as "Re(2): ", "Re:", "RE: ", or "Sv: ") back-reference (such as "Re(2): ", "Re:", "RE: ", or "Sv: ")
from the subject-content when composing the subject of a from the subject-content when composing the subject of a
followup and add a correct back-reference in front of the followup and add a correct back-reference in front of the
result. result.
NOTE: that would be "SHOULD remove instances" except that we
cannot find a sufficiently robust and simple algorithm to do
the necessary natural language processing.
Followup agents MUST NOT use any other string except "Re: " as Followup agents MUST NOT use any other string except "Re: " as
a back reference. Specifically, a translation of "Re: " into a a back reference. Specifically, a translation of "Re: " into a
local language or usage MUST NOT be used. local language or usage MUST NOT be used.
Agents SHOULD NOT depend on nor enforce the use of back Agents SHOULD NOT depend on nor enforce the use of back
references by followup agents. For compatibility with legacy references by followup agents. For compatibility with legacy
news software the subject-content of a control message MAY news software the subject-content of a control message MAY
start with the string "cmsg ", non-control messages MUST NOT start with the string "cmsg ", non-control messages MUST NOT
start with the string "cmsg ". start with the string "cmsg ".
skipping to change at line 1279 skipping to change at line 1369
Subject: Re: Film at 11 Subject: Re: Film at 11
Subject: Use of Godwin's law considered harmful (was: Film at 11) Subject: Use of Godwin's law considered harmful (was: Film at 11)
Subject: Godwin's law (was: Film at 11) Subject: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law (was: Film at 11) Subject: Re: Godwin's law (was: Film at 11)
5.5. Newsgroups 5.5. Newsgroups
The Newsgroups header's content specifies which newsgroup(s) The Newsgroups header's content specifies which newsgroup(s)
the article is posted to: the article is posted to:
Newsgroups-content = newsgroup-name *( ng-delim newsgroup-name) Newsgroups-content = newsgroup-name
newsgroup-name = *FWS component *( "." component ) *FWS *( ng-delim *FWS newsgroup-name ) *FWS
component = component-start [*component-rest component-start] newsgroup-name = component
component-start = lowercase / digit *( "." component )
lowercase = <Unicode Letter, Lowercase> / <Unicode Letter, Other> component = component-start
uppercase = <Unicode Letter, Uppercase> / <Unicode Letter, Titlecase> *( component-start / component-other )
digit = <Unicode Number, Decimal Digit> / <Unicode Number, Other> component-start = Un-lowercase / Un-digit
component-rest = component-start / "+" / "-" / "_" Un-lowercase = <Unicode Letter, Lowercase> /
<Unicode Letter, Other>
Un-uppercase = <Unicode Letter, Uppercase> /
<Unicode Letter, Titlecase>
Un-digit = <Unicode Number, Decimal Digit> /
<Unicode Number, Other>
component-other = "+" / "-" / "_"
ng-delim = "," ng-delim = ","
where the <Unicode ...> items are as described in [UNICODE]. where the <Unicode ...> items are as described in [UNICODE].
An article's Newsgroups header may not contain a duplicated
newsgroup-name component.
The inclusion of folding white space within a newsgroup-name The inclusion of folding white space within a newsgroup-name
is a newly introduced feature in this standard. It MUST be is a newly introduced feature in this standard. It MUST be
accepted by all conforming implementations (relaying agents, accepted by all conforming implementations (relaying agents,
serving agents and reading agents). On the other hand, posting serving agents and reading agents). Posting agents should be
agents MUST NOT generate such whitespace and injecting agents aware that except for experimental posting to 'test' newsgroups
MUST NOT accept such whitespace (except for experimental or within cooperating subnets, such postings may be rejected by
postings to 'test' newsgroups or within cooperating subnets) overly-critical old-style relaying agents. When a sufficient
until after AGREED IMPLEMENTATION DATE. After AGREED number of relay agents are in conformance, posting agents
IMPLEMENTATION DATE such agents MAY generate such whitespace SHOULD generate such whitespace in the form of <CRLF WS> so as
anywhere and SHOULD generate it in the form of <CRLF WS> so as
to keep the length of lines in the relevant headers (notably to keep the length of lines in the relevant headers (notably
Newsgroups and Followup-To) to no more than than 79 Newsgroups and Followup-To) to no more than than 79 characters
characters. Before AGREED IMPLEMENTATION DATE, injecting (or other agreed policy limit - see 4.6). Before such critical
agents MAY reformat such headers by removing whitespace mass occurs, injecting agents MAY reformat such headers by removing
inserted by the posting agent, but relaying agents MUST NOT do whitespace inserted by the posting agent, but relaying agents
so. MUST NOT do so.
A newsgroup name consists of one or more components. A newsgroup name consists of one or more components.
Components MAY contain non-ASCII letters, but these MUST be Components MAY contain non-ASCII letters, but these MUST be
encoded in UTF-8 and not according to RFC-2047. A component encoded in UTF-8 and not according to RFC-2047. A component
MUST contain at least one letter (and must, according to the MUST contain at least one letter (and must, according to the
syntax, begin and end with a letter or digit). Components syntax, begin and end with a letter or digit). Components
SHOULD begin with a letter. Composite characters (made by SHOULD begin with a letter. Composite characters (made by
overlaying one character with another) and format characters, overlaying one character with another) and format characters,
as allowed in certain parts of Unicode and needed by certain as allowed in certain parts of Unicode and needed by certain
languages, must use whatever canonical conventions apply to languages, must use whatever canonical conventions apply to
skipping to change at line 1333 skipping to change at line 1431
problems for the commonly used implementation technique of problems for the commonly used implementation technique of
using the component as the name of a directory, whilst also using the component as the name of a directory, whilst also
using sequential numbers to distinguish the articles within a using sequential numbers to distinguish the articles within a
group. group.
NOTE: Uppercase letters MUST NOT be used. Although converting NOTE: Uppercase letters MUST NOT be used. Although converting
ASCII uppercase letters to their lowercase counterparts is ASCII uppercase letters to their lowercase counterparts is
straightforward enough, it would be unreasonable to expect straightforward enough, it would be unreasonable to expect
software to do the same in parts of Unicode for which it was software to do the same in parts of Unicode for which it was
not configured (in general, a table lookup would be required). not configured (in general, a table lookup would be required).
Thus software MAY attempt to convert uppercase letters Thus software MAY attempt to convert Un-uppercase letters
according to the mappings defined by [UNICODE], but this according to the mappings defined by [UNICODE], but this
behaviour is not required. behaviour is not required.
Whilst there is no longer any technical reason to limit the Whilst there is no longer any technical reason to limit the
length of a component (formerly, it was limited to 14 length of a component (formerly, it was limited to 14
characters) nor to limit the total length of a newsgroup-name, characters) nor to limit the total length of a newsgroup-name,
it should be noted that these names are also used in the it should be noted that these names are also used in the
newsgroups line (...) where an overall limit applies, and newsgroups line (6.6.1.2) where an overall limit applies, and
moreover excessively long names can be exceedingly moreover excessively long names can be exceedingly
inconvenient in practical use. Those responsible for the inconvenient in practical use. Agencies responsible for
management of the various netnews hierarchies SHOULD therefore individual hierarchies SHOULD therefore, as a matter of
set reasonable limits for the length of a component and of a policy, set reasonable limits for the length of a component
newsgroup name. In the absence of such explicit policies, and of a newsgroup name. In the absence of such explicit
figures of 30 characters and 72 characters respectively are policies, the default figures are 30 characters and 72
recommended. characters respectively.
NOTE: The newsgroup-name as encoded in UTF-8 should be NOTE: The newsgroup-name as encoded in UTF-8 should be
regarded as the canonical form. Reading agents may convert it regarded as the canonical form. Reading agents may convert it
to whatever character set they are able to display (see 4.5.2) to whatever character set they are able to display (see 4.5.2)
and serving agents may possibly need to convert it to some and serving agents may possibly need to convert it to some
form more suitable as a filename. Simple algorithms for both form more suitable as a filename. Simple algorithms for both
kinds of conversion are readily available. kinds of conversion are readily available.
Posters SHOULD use only the names of existing newsgroups in Posters SHOULD use only the names of existing newsgroups in
the Newsgroups header, because newsgroups are not created the Newsgroups header, because newsgroups are not created
skipping to change at line 1375 skipping to change at line 1473
agents MUST NOT rewrite Newsgroups headers in any way, even if agents MUST NOT rewrite Newsgroups headers in any way, even if
some or all of the newsgroups do not exist on the relaying some or all of the newsgroups do not exist on the relaying
agent's host. agent's host.
5.5.1 Forbidden newsgroup names 5.5.1 Forbidden newsgroup names
The following newsgroup-names MUST NOT be used: The following newsgroup-names MUST NOT be used:
Newsgroup-names having only one component (reserved for Newsgroup-names having only one component (reserved for
newsgroups whose propagation is restricted to a single host, newsgroups whose propagation is restricted to a single host,
or the administrative equivalent). or local network, and for pseudo-newsgroups such as "poster"
(because it has special meaning in the Followup-To header (see
"poster" (because it has special meaning in the Followup-To section 6.1)), "newsgroups" (likewise), "junk" (frequently
header (see section 6.1).) used for pseudo-newsgroups internal to serving agents)
and "control" (likewise).
"newsgroups" (likewise)
"junk" (frequently used for pseudo-newsgroups internal to
serving agents)
"control" (likewise)
Any newsgroup-name beginning with "control." (likewise) Any newsgroup-name beginning with "control." (Used as a
pseudo-newsgroup by many serving agents.)
Any newsgroup-name containing the component "ctl" (likewise) Any newsgroup-name containing the component "ctl" (likewise)
"to" or any newsgroup-name beginning with "to." (reserved for "to" or any newsgroup-name beginning with "to." (reserved for
test messages sent on an essentially point-to-point basis (see test messages sent on an essentially point-to-point basis (see
also the ihave/sendme protocol described in section 7.2) also the ihave/sendme protocol described in section 7.2)
Any newsgroup-name containing the component "all" (because Any newsgroup-name containing the component "all" (because
this is used as a wildcard in some implementations) this is used as a wildcard in some implementations)
A newsgroup SHOULD NOT appear more than once in the Newsgroups A newsgroup MUST NOT appear more than once in the Newsgroups
header. The order of newsgroup names in the Newsgroups header. The order of newsgroup names in the Newsgroups
header is not significant. header is not significant.
5.6 Path 5.6 Path
The Path header shows the route a message took from its entry The Path header shows the route a message took from its entry
into the USENET system to the current system. It is a list of into the USENET system to the current system. It is a list of
site identifiers with the origin on the right. Each relaying, site identifiers with the origin on the right. Each relaying,
injecting or serving agent that processes the article adds one injecting or serving agent that processes the article adds one
or more entries to this header. Aside from tracing the route or more entries to this header. Aside from tracing the route
skipping to change at line 1479 skipping to change at line 1572
address encodings are advised. For the purposes of comparison, address encodings are advised. For the purposes of comparison,
FQDN entries should be put in an all-lower-case canonical form. FQDN entries should be put in an all-lower-case canonical form.
Because RFC1036 specified any punctuation or whitespace could Because RFC1036 specified any punctuation or whitespace could
act as delimiter, programs SHOULD accept this, with the act as delimiter, programs SHOULD accept this, with the
exception that IPv6 addresses containing colons MUST be treated exception that IPv6 addresses containing colons MUST be treated
as a single unit. Modern programs MUST generate only the set as a single unit. Modern programs MUST generate only the set
"!,%@" plus optional additional whitespace. "!,%@" plus optional additional whitespace.
When a site receives an article from another site, it SHOULD When a site receives an article from another site, it SHOULD
(MUST after draft-implementation-date ), verify the identity of (and eventually MUST) verify the identity of
the source site. When processing an article from a source, the the source site. When processing an article from a source, the
leftmost entry of the Path line should be extracted, converted leftmost entry of the Path line should be extracted, converted
to a canonical form, and tested to see if it matches the to a canonical form, and tested to see if it matches the
canonical form of the verified identity of the source. If it canonical form of the verified identity of the source. If it
does, a "," should be used as the delimiter, and thus the does, a "," should be used as the delimiter, and thus the
comma, and then the receiving site's path-identity MUST be comma, and then the receiving site's path-identity MUST be
prepended to the Path line. prepended to the Path line.
The method of verification is up to the site. Any method of The method of verification is up to the site. Any method of
suitable authenticity may be chosen, with the consideration suitable authenticity may be chosen, with the consideration
that in the event of problems at the source site, the relaying that in the event of problems at the source site, the relaying
site may be called upon to reliably identify it. site may be called upon to reliably identify it.
If the leftmost entry does not match the verified identity of If the leftmost entry does not match the verified identity of
the source, then the receiving site should prepend an "@" the source, then the receiving site should prepend an "@"
delimiter, then a simple form of the verified identity of the delimiter, then a simple form of the verified identity of the
source, then a "," delimiter and then the receiving site's own source, then a "," delimiter and then the receiving site's own
path-identity. This adding of two identities to the line path-identity. This adding of two identities to the line
should not be done if the provided and verified identities MUST NOT be done if the provided and verified identities
match. For articles received from an internet source, the match. For articles received from an internet source, the
unique 32 bit IPv4 address or properly verified FQDN, whichever unique IPv4 (or IPv6) address or properly verified FQDN, whichever
is shorter, is encouraged for the generated ID. is shorter, is encouraged for the generated ID.
5.6.3 The tail Entry 5.6.3 The tail Entry
For historical reasons, the rightmost entry in the Path string For historical reasons, the rightmost entry in the Path string
generated by most systems is not a site name, but a "user generated by most systems is not a site name, but a "user
name". However, the Path string is not an E-mail address and name". However, the Path string is not an E-mail address and
MUST NOT be used to contact the user. Injecting agents MAY MUST NOT be used to contact the user. Injecting agents MAY
place any string here that is not a path-identity. If no place any string here that is not a path-identity. If no
meaning is anticipated the string "x" SHOULD be used. meaning is anticipated the string "x" SHOULD be used.
skipping to change at line 1596 skipping to change at line 1689
5.6.6.1 Use of "!" 5.6.6.1 Use of "!"
Old USENET relaying and injecting programs almost all delimit Old USENET relaying and injecting programs almost all delimit
Path: entries with the "!" delimiter, and these entries are Path: entries with the "!" delimiter, and these entries are
not verified. As such, the presence of "%" as a delimiter not verified. As such, the presence of "%" as a delimiter
will indicate the article was injected by software conforming will indicate the article was injected by software conforming
to this standard, and the presence of "!" as a delimiter will to this standard, and the presence of "!" as a delimiter will
indicate the message passed through systems developed prior indicate the message passed through systems developed prior
to this standard. Prior to the draft-implementation-date, to this standard. Prior to the draft-implementation-date,
messages with mixed sets of delimiters will be common. After messages with mixed sets of delimiters will be common. After
that date, all messages should have no "!" delimiters prior that date, all messages SHOULD NOT have "!" delimiters prior
to the "%" delimiter. to the "%" delimiter.
5.6.7 Suggested Verification Methods 5.6.7 Suggested Verification Methods
Sites attempting to verify an incoming entry SHOULD take the Sites attempting to verify an incoming entry SHOULD take the
following approaches for common transports. They are not following approaches for common transports. They are not
required, but not following them may lead to wasteful required, but not following them may lead to wasteful
double-entry Path additions. double-entry Path additions.
If the incoming article arrives through some protocol local to If the incoming article arrives through some protocol local to
skipping to change at line 1674 skipping to change at line 1767
Followup-To-content = Newsgroups-content / "poster" Followup-To-content = Newsgroups-content / "poster"
The syntax is the same as that of the Newsgroups content, with The syntax is the same as that of the Newsgroups content, with
the exception that the magic word "poster" means that the exception that the magic word "poster" means that
followups should be mailed to the article's reply address followups should be mailed to the article's reply address
rather than posted. In the absence of Followup-To, the default rather than posted. In the absence of Followup-To, the default
newsgroup(s) for a followup are those in the Newsgroups header newsgroup(s) for a followup are those in the Newsgroups header
and for this reason the Followup-To header should not be and for this reason the Followup-To header should not be
included if it just duplicates the Newsgroups header. included if it just duplicates the Newsgroups header.
6.2 Expires 6.2 Sender
The Sender header specifies the email address of the entity
which actually sent this article, if that entity is different
from the From header. This header SHOULD NOT appear in an
article unless the sender is different from the author. This
header is appropriate for use by automatic article posters.
See [DRUMS] for
Sender-content = mailbox-list
6.3 Expires
The Expires header content specifies a date and time when The Expires header content specifies a date and time when
the article is deemed to be no longer useful and should be the article is deemed to be no longer useful and should be
removed ("expired"). The content syntax is the same as that of removed ("expired"). The content syntax is the same as that of
the Date content which is defined in the Message Format the Date content which is defined in the Message Format
Standard [MESSFOR] . Standard [MESSFOR] .
expires-content = date-time expires-content = date-time
A Expires header SHOULD only be used in an article if the A Expires header SHOULD only be used in an article if the
skipping to change at line 1815 skipping to change at line 1919
6.6.1 The "newgroup" Control Message 6.6.1 The "newgroup" Control Message
newgroup-ctrl = "newgroup" FWS groupname [ FWS flags ] newgroup-ctrl = "newgroup" FWS groupname [ FWS flags ]
flags = "moderated" flags = "moderated"
groupname ; defined in [NEWS] groupname ; defined in [NEWS]
The "newgroup" control message requests the specified group be The "newgroup" control message requests the specified group be
created or changed. The text "moderated" is appended to mark created or changed. The text "moderated" is appended to mark
the group as moderated. The message contains a the group as moderated. The message contains a
"multipart/newsgroupinfo" (section 6.6.1 body) part containing "multipart/news-groupinfo" (section 6.6.1 body) part containing
machine- and human-readable information about the group. machine- and human-readable information about the group.
The newgroup command is also used to update the description The newgroup command is also used to update the description
line or moderation status of a group. line or moderation status of a group.
NOTE: It is also possible to send newgroups for existing NOTE: It is also possible to send newgroups for existing
groups that don't change anything to ensure the group exist on groups that don't change anything to ensure the group exist on
all systems ("booster" newgroups). Implementations might want all systems ("booster" newgroups). Implementations might want
to test for this condition before attempting to update their to test for this condition before attempting to update their
configuration. configuration.
6.6.1.1 multipart/newsgroupinfo 6.6.1.1 multipart/news-groupinfo
The "multipart/newsgroupinfo" body structure contains The "multipart/news-groupinfo" body structure contains
information about a (new) newsgroup. information about a (new) newsgroup.
The MIME content type definition of "multipart/newsgroupinfo" The MIME content type definition of "multipart/news-groupinfo"
is: is:
MIME type name: multipart MIME type name: multipart
MIME subtype name: newsgroupinfo MIME subtype name: news-groupinfo
Required parameters: boundary (see [MIME2]) Required parameters: boundary (see [MIME2])
Optional parameters: none Optional parameters: none
Encoding considerations: "7bit" or "8bit" is sufficient and Encoding considerations: "7bit" or "8bit" is sufficient and
MUST be used to maintain compatibility. MUST be used to maintain compatibility.
Security considerations: to be added Security considerations: to be added
A "multipart/newsgroupinfo" body part contains the following A "multipart/news-groupinfo" body part contains the following
subparts: subparts:
1. An "application/newsgroupinfo" part (section 6.6.1.2) 1. An "application/news-groupinfo" part (section 6.6.1.2)
containing the name and description line of the group(s). This containing the name and description line of the group(s). This
part is mandatory. part is mandatory.
2. Other parts containing useful information about the 2. Other parts containing useful information about the
backgrounds of newsgroup message. backgrounds of newsgroup message.
3. Parts containing initial named articles for the 3. Parts containing initial named articles for the
newsgroup. See section 6.6.1.3 for details. newsgroup. See section 6.6.1.3 for details.
6.6.1.2 application/newsgroupinfo 6.6.1.2 application/news-groupinfo
The "application/newsgroupinfo" body part contains a short The "application/news-groupinfo" body part contains a short
information on a newsgroup, i.e. the group's name, it's information on a newsgroup, i.e. the group's name, it's
description and the moderation flag. description and the moderation flag.
NOTE: This part has a format that makes the whole NOTE: This part has a format that makes the whole
"multipart/newsgroupinfo" structure compatible with [1036BIS]. "multipart/news-groupinfo" structure compatible with [1036BIS].
The MIME content type definition of "application/newsgroupinfo" The MIME content type definition of "application/news-groupinfo"
is: is:
MIME type name: application MIME type name: application
MIME subtype name: newsgroupinfo MIME subtype name: news-groupinfo
Optional parameters: none Optional parameters: none
Encoding considerations: "7bit" or "8bit" is sufficient and Encoding considerations: "7bit" or "8bit" is sufficient and
MUST be used to maintain compatibility. MUST be used to maintain compatibility.
Note that the descriptions may use [MIME3]. Note that the descriptions may use [MIME3].
Security considerations: to be added Security considerations: to be added
The content of the "application/newsgroupinfo" body part is The content of the "application/news-groupinfo" body part is
defined as: defined as:
groupinfo-body = descriptor-tag CRLF 1*( description-line CRLF ) groupinfo-body = descriptor-tag CRLF 1*( description-line CRLF )
descriptor-tag = %x46.6F.72 SP %x79.6F.75.72 SP descriptor-tag = %x46.6F.72 SP %x79.6F.75.72 SP
%x6E.65.77.73.67.72.6F.75.70.73 SP %x6E.65.77.73.67.72.6F.75.70.73 SP
%x66.69.6C.6E.3A %x66.69.6C.6E.3A
; case sensitive "For your newsgroups file:" ; case sensitive "For your newsgroups file:"
description-line = newsgroup-name [ 1*WSP description description-line = newsgroup-name [ 1*WSP description ]
[ 1*SP group-flags ] ] description = nonblank-text
description = nonblank-text / encoded-word
moderation-flags = [ moderated-literal ] moderation-flags = [ moderated-literal ]
moderated-literal = %x28.4D.6F.64.65.72.61.74.65.64.29 moderated-literal = %x28.4D.6F.64.65.72.61.74.65.64.29
; case sensitive "(Moderated)" ; case sensitive "(Moderated)"
group-flags = [ "<" addr-spec ">" 1*SP ] "(Moderated)" The "application/news-groupinfo" is used in conjunction with the
The "application/newsgroupinfo" is used in conjunction with the
"newgroup" (section 6.6.1) and "mvgroup" control messages (section "newgroup" (section 6.6.1) and "mvgroup" control messages (section
6.6.3) as part of a "multipart/newsgroupinfo" (section 6.6.1) MIME 6.6.3) as part of a "multipart/news-groupinfo" (section 6.6.1) MIME
structure. structure.
Moderated newsgroups SHOULD be marked by appending the case Moderated newsgroups MUST be marked by appending the case
sensitive text " (Moderated)" at the end. sensitive text " (Moderated)" at the end. It is NOT recommended
that the moderator's email address be included in the description.
NOTE: Due to the line lenght limit in [MAIL], [NEWS] and
[NNTP], a description line can have a maximum length of 998
octets.
NOTE: In some hierarchies, there exist conventions that set a
far lower limit, often in characters.
NOTE: Usually, the description length is limited in a way that Although, in accordance with [NNTP], [MESSFOR] and 4.6 of this
the newsgroup name, the tab (interpreted as an 8-character tab document, a description line could have a maximum length of 998
that takes one at least to column 24) and the description octets, as a matter of policy a far lower limit, expressed in
without flags fit into the first 79 characters. characters, SHOULD be set. By default, in the absence of
explicit policies, the description length SHOULD be limited in
such a way that the newsgroup name, the tab (interpreted as an
8-character tab that takes one at least to column 24) and the
description (excluding flags) fit into the first 79 characters.
NOTE: Servers that use an "newsgroups" file will store the NOTE: Servers that use an "newsgroups" file will store the
group descritpions there as is, i.e. without any conversion of group descritpions there as is, i.e. without any conversion of
charsets or encoding. charsets or encoding.
NOTE: The descriptions will also be used with the [NNTP] LIST NOTE: The descriptions will also be used with the [NNTP] LIST
NEWSGROUPS command. The descriptions will be sent as is, i.e. NEWSGROUPS command. The descriptions will be sent as is, i.e.
without any conversion of charsets or encoding. without any conversion of charsets or encoding.
6.6.1.3 Initial Named Articles 6.6.1.3 Initial Named Articles
Some parts of a multipart/newsgroupinfo structure MAY contain Some parts of a multipart/news-groupinfo structure MAY contain
an initial set of named articles. These parts are identified by an initial set of named articles. These parts are identified by
the Article-Name header just like normal named article the Article-Name header just like normal named article
postings. The named articles are filed separately as single postings. The named articles are filed separately as single
postings, where the headers of the enclosing control message postings, where the headers of the enclosing control message
are copied to every part that contains a named article except are copied to every part that contains a named article except
that: that:
Content-* and Article-* headers MUST be taken from the body part. Content-* and Article-* headers MUST be taken from the body part.
The message id MUST be changed by inserting /partX before the @ The message id MUST be changed by inserting /partX before the @
skipping to change at line 1972 skipping to change at line 2071
mvgroup-ctrl = "mvgroup" FWS ( mvgrp-groups / mvgrp-hrchy) mvgroup-ctrl = "mvgroup" FWS ( mvgrp-groups / mvgrp-hrchy)
mvgrp-groups = groupname [ FWS groupname ] mvgrp-groups = groupname [ FWS groupname ]
mvgrp-hrchy = groupnamepart ".*" FWS groupnamepart mvgrp-hrchy = groupnamepart ".*" FWS groupnamepart
groupnamepart = groupname ; syntactically groupnamepart = groupname ; syntactically
6.6.3.1 Single group 6.6.3.1 Single group
The "mvgroup" control message requests the first specified The "mvgroup" control message requests the first specified
group to be moved to the second group. The message contains a group to be moved to the second group. The message contains a
"multipart/newsgroupinfo" (section 6.6.1.2) body part containing "multipart/news-groupinfo" (section 6.6.1.2) body part containing
machine- and human-readable information about the new group. machine- and human-readable information about the new group.
When this message is received, the new group SHOULD be created When this message is received, the new group SHOULD be created
and all articles, including named articles, SHOULD be copied or and all articles, including named articles, SHOULD be copied or
moved to the new group, then the old, now empty group SHOULD be moved to the new group, then the old, now empty group SHOULD be
deleted. deleted.
NOTE: For servers that use a file system directory structure to NOTE: For servers that use a file system directory structure to
organize message storage, this operation is quite efficiently organize message storage, this operation is quite efficiently
implemented as a single directory rename operation. implemented as a single directory rename operation.
skipping to change at line 2011 skipping to change at line 2110
group is created just as for a "newgroup" message. group is created just as for a "newgroup" message.
If both groups exist, the groups MAY be "merged". If this is If both groups exist, the groups MAY be "merged". If this is
done, it MUST be done correctly, i.e. implementations MUST take done, it MUST be done correctly, i.e. implementations MUST take
care that the messages in the group being deleted are care that the messages in the group being deleted are
renumbered accordingly to avoid overwriting articles in one renumbered accordingly to avoid overwriting articles in one
group with those of the other and that crossposted articles group with those of the other and that crossposted articles
don't appear twice. Otherwise, the old group is just deleted. don't appear twice. Otherwise, the old group is just deleted.
In all cases, information transported in the In all cases, information transported in the
"multipart/newsgroupinfo" body part is applied to the new group. "multipart/news-groupinfo" body part is applied to the new group.
Named articles are taken from the mvgroup message, the new Named articles are taken from the mvgroup message, the new
group (if already existent) and the old group in this group (if already existent) and the old group in this
precedence. precedence.
As a special case, the second name, i.e. the one of the new As a special case, the second name, i.e. the one of the new
group MAY be omitted. In this case, only the information of the group MAY be omitted. In this case, only the information of the
group is updated according to the contained group is updated according to the contained
"multipart/newsgroupinfo". "multipart/news-groupinfo".
Until most relay agents conform to this document, whenever a mvgroup
control message for a single group is issued, a corresponding pair of
rmgroup and newgroup control messages SHOULD be issued a few days later.
6.6.3.2 Multiple Groups 6.6.3.2 Multiple Groups
If the first name ends with the character sequence ".*", the If the first name ends with the character sequence ".*", the
newgroup message requests a whole (sub)hierarchy to be moved. newgroup message requests a whole (sub)hierarchy to be moved.
The same procedure as for single groups (section 6.6.3.1) applies The same procedure as for single groups (section 6.6.3.1) applies
to every matched group; however, some systems might be able to to every matched group; however, some systems might be able to
optimize the process. optimize the process.
NOTE: For servers that use a file system directory structure to NOTE: For servers that use a file system directory structure to
organize message storage, this process can be optimized by organize message storage, this process can be optimized by
renaming the parent directory instead of every group's renaming the parent directory instead of every group's
directory. directory.
To avoid recursion, the new groups' names MUST NEVER match the To avoid recursion, the new groups' names MUST NEVER match the
old groups name pattern; i.e. moving a whole (sub)hierarchy to old groups name pattern; i.e. moving a whole (sub)hierarchy to
a subhierarchy of the original hierarchy is explicitly a subhierarchy of the original hierarchy is explicitly
disallowed. disallowed.
Until a critical mass of relay agents are in compliance, whenever
a mvgroup control message for multiple groups is issued, a
corresponding set of rmgroup and newgroup control messages for all
the affected groups SHOULD be issued a few days later.
6.6.4 The "checkgroups" Control Message 6.6.4 The "checkgroups" Control Message
The "checkgroups" control message contains a list of all valid The "checkgroups" control message contains a list of all valid
groups in a complete hierarchy. The "Control:" header has the groups in a complete hierarchy. The "Control:" header has the
following format: following format:
checkgroup-ctrl = "checkgroups" [ FWS chkscope ] [ FWS chksernr ] checkgroup-ctrl = "checkgroups" [ FWS chkscope ] [ FWS chksernr ]
chkscope = 1*( ["!"] newsgroup-name-part ) chkscope = 1*( ["!"] newsgroup-name-part )
chksernr = "#" 1*DIGIT chksernr = "#" 1*DIGIT
The chkscope parameter(s) specifies the (sub)hierarchy(s) for The chkscope parameter(s) specifies the (sub)hierarchy(s) for
which this "checkgroups" message applies. which this "checkgroups" message applies.
6.6.4.1 Example: 6.6.4.1 Example:
Control: checkgroups de !de.alt #248 Control: checkgroups de !de.alt #248
NOTE: "Old" software is known to ignore this parameter. Thus a NOTE: "Old" software is known to ignore the "chkscope"
"checkgroups" message SHOULD also contain the groups of other parameter. Thus a "checkgroups" message SHOULD also contain
subhierarchies the sender is not responsible for. "New" the groups of other subhierarchies the sender is not
software MUST ignore groups which don't fall into the scope of responsible for. "New" software MUST ignore groups which don't
the "checkgroups" message. fall into the scope of the "checkgroups" message.
If no scope for the checkgroups message is given, it applies to If no scope for the checkgroups message is given, it applies to
all hierarchies for which group statements appear in the all hierarchies for which group statements appear in the
message. message.
"Checkgroups" messages MAY also contain a serial number, which "Checkgroups" messages MAY also contain a serial number, which
can be any positive integer (i.e. just numbered or the date in can be any positive integer (i.e. just numbered or the date in
YYYYMMDD). It SHOULD increase by an arbitrary value with every YYYYMMDD). It SHOULD increase by an arbitrary value with every
change to the group list and MUST NOT ever decrease. change to the group list 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 can not be signed. situations where the Date header can not be signed.
The body of the message is an "application/newscheckgroups" part The body of the message is an "application/news-checkgroups" part
containing the list of ALL valid groups (and MAYbe deletion containing the list of ALL valid groups (and MAYBE deletion
confirmations) for the specified hierarchies. confirmations) for the specified hierarchies.
6.6.5 application/newscheckgroups 6.6.5 application/news-checkgroups
The "application/newscheckgroups" body part contains a complete The "application/news-checkgroups" body part contains a complete
list of all newsgroups in a top level hierarchy, their list of all newsgroups in a top level hierarchy, their
description lines and moderation status. description lines and moderation status.
The MIME content type definition of The MIME content type definition of
"application/newscheckgroups:" is: "application/news-checkgroups:" is:
MIME type name: application MIME type name: application
MIME subtype name: newscheckgroups MIME subtype name: news-checkgroups
Optional parameters: none Optional parameters: none
Encoding considerations: "7bit" or "8bit" is sufficient and Encoding considerations: "7bit" or "8bit" is sufficient and
MUST be used to maintain compatibility. MUST be used to maintain compatibility.
Note that the descriptions may use [MIME3]. Note that the descriptions may use [MIME3].
Security considerations: to be added Security considerations: to be added
The content of the "application/newscheckgroups" body part is The content of the "application/news-checkgroups" body part is
defined as: defined as:
checkgroups-body = *( invalidation CRLF ) 1*( valid-group CRLF ) checkgroups-body = *( invalidation CRLF ) 1*( valid-group CRLF )
invalidation = "!" groupname *( "," *WSP groupname ) invalidation = "!" groupname *( "," *WSP groupname )
valid-group = description-line valid-group = description-line
description-line ; see section 6.6.1.2 description-line ; see section 6.6.1.2
The "application/newscheckgroups" content type is used in The "application/news-checkgroups" content type is used in
conjunction with the "checkgroups" control message (section conjunction with the "checkgroups" control message (section
6.6.1.3.1). 6.6.1.3.1).
6.6.5.1 Examples 6.6.5.1 Examples
A "newgroup" with bilingual charter and policy information: A "newgroup" with bilingual charter and policy information:
From: admin@example.invalid (example.all Administrator) From: admin@example.invalid (example.all Administrator)
Newsgroups: example.admin.groups,example.admin.announce Newsgroups: example.admin.groups,example.admin.announce
Date: 27 Feb 1997 12:50:22 +14:00 (EST) Date: 27 Feb 1997 12:50:22 +14:00 (EST)
Subject: Group example.admin.info created. Subject: Group example.admin.info created.
Approved: admin@example.invalid Approved: admin@example.invalid
Control: newgroup example.admin.info moderated Control: newgroup example.admin.info moderated
Message-ID: <newgroup-example.admin.info-19970227@example.invalid> Message-ID: <newgroup-example.admin.info-19970227@example.invalid>
Content-Type: multipart/newsgroupinfo; boundary="nxtprt" Content-Type: multipart/news-groupinfo; boundary="nxtprt"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
This is a MIME control message. This is a MIME control message.
--nxtprt --nxtprt
Content-Type: application/newsgroupinfo Content-Type: application/news-groupinfo
For your newsgroups file: For your newsgroups file:
example.admin.info Information on the example.* hierarchy <info@news.org> example.admin.info Information on the example.* hierarchy <info@news.org>
(Moderated) (Moderated)
--nxtprt --nxtprt
Content-Type: multipart/alternative ; Content-Type: multipart/alternative ;
differences = content-language ; differences = content-language ;
boundary = nxtlang boundary = nxtlang
Article-Name: example.admin.info: charter Article-Name: example.admin.info: charter
skipping to change at line 2174 skipping to change at line 2282
plain "mvgroup": plain "mvgroup":
From: admin@example.invalid (example.all Administrator) From: admin@example.invalid (example.all Administrator)
Newsgroups: example.admin.groups, example.admin.announce Newsgroups: example.admin.groups, example.admin.announce
Date: 30 Jul 1997 22:04 +02:00 (CEST) Date: 30 Jul 1997 22:04 +02:00 (CEST)
Subject: Moving example.oldgroup to example.newgroup Subject: Moving example.oldgroup to example.newgroup
Message-ID: <mvgroup-example.oldgroup-19970730@example.invalid> Message-ID: <mvgroup-example.oldgroup-19970730@example.invalid>
Approved: admin@example.invalid Approved: admin@example.invalid
Control: mvgroup example.oldgroup example.newgroup Control: mvgroup example.oldgroup example.newgroup
Content-Type: multipart/newsgroupinfo; boundary=nxt Content-Type: multipart/news-groupinfo; boundary=nxt
--nxt --nxt
Content-Type: application/newgroupinfo Content-Type: application/newgroupinfo
For your newsgroups file: For your newsgroups file:
example.newgroup The new replacement group. example.newgroup The new replacement group.
--nxt --nxt
The group example.oldgroup is replaced by example.newgroup. The group example.oldgroup is replaced by example.newgroup.
Please update your configuration. Please update your configuration.
skipping to change at line 2200 skipping to change at line 2308
example.talk.jokes.d, which is also being moved. So the charter is example.talk.jokes.d, which is also being moved. So the charter is
updated. updated.
From: admin@example.invalid (example.all Administrator) From: admin@example.invalid (example.all Administrator)
Newsgroups: example.admin.groups, example.admin.announce Newsgroups: example.admin.groups, example.admin.announce
Date: 30 Jul 1997 22:04 +02:00 (PST) Date: 30 Jul 1997 22:04 +02:00 (PST)
Subject: Deletion of example.admin.obsolete Subject: Deletion of example.admin.obsolete
Message-ID: <mvgroup-example.talk-19970730@example.invalid> Message-ID: <mvgroup-example.talk-19970730@example.invalid>
Approved: admin@example.invalid Approved: admin@example.invalid
Control: mvgroup example.talk.* example.conversation Control: mvgroup example.talk.* example.conversation
Content-Type: multipart/newsgroupinfo; boundary=nxt; chartas=1 Content-Type: multipart/news-groupinfo; boundary=nxt; chartas=1
--nxt --nxt
Content-Type: application/newgroupinfo Content-Type: application/newgroupinfo
For your newsgroups file: For your newsgroups file:
example.conversation.boring Boring conversations. example.conversation.boring Boring conversations.
example.conversation.interesting Interesting conversations. example.conversation.interesting Interesting conversations.
example.conversation.jokes Jokes and funny stuff. example.conversation.jokes Jokes and funny stuff.
example.conversation.jokes.d Discussion about example.conversation.jokes. example.conversation.jokes.d Discussion about example.conversation.jokes.
skipping to change at line 2320 skipping to change at line 2428
The following forms of control messages are declared obsolete The following forms of control messages are declared obsolete
by this document: by this document:
sendsys sendsys
version version
whogets whogets
senduuname senduuname
6.7. Distribution 6.7. Distribution
6.7.1 Historical Note
The original Distribution header provided a means to limit
the distribution of articles to a subset of the sites which
received the newsgroups it was posted to. It was designed
to control a feed. Each site feeding other sites would, for
each feed, configure the list of distributions appropriate
to send to that site. If an article had a Distribution
header, a check would be made to see if any of the
distributions in the header matched the distribution list
for the feed.
Sadly, this list was often configured in the form "all
distributions except the following" where the local
distributions would be listed.
This mean an unknown distribution, leaked from an external
site, would match the "all distributions" and get fed out.
This meant that once an article leaked out from a
distribution's subnet, it flooded the entire net, or at
least the very large subset that used "all but these" style
of configuring the feed.
Indeed, many sites deliberately wanted this flood. Hub
sites at national and multinational ISPs wanted to receive
all the local distributions, for the use of their users in
the individual geographic regions. This assured netwide
propagation of all distributions, defeating the purpose of
the header. It became close to valueless.
6.7.1.1 New Semantics
While distributions SHOULD still control feeds as they do,
they SHOULD also be associated with the site. Each site
SHOULD maintain a list of the distributions to which it is a
"member." Newsreaders SHOULD also allow the user to
maintain a list of distributions to which the user is a
member.
Newsreaders MAY also keep track of distributions the user
wishes to belong to. In this event, they should examine the
Distribution headers of articles to be presented to the
user, and SHOULD not display them if the user does not
belong to any of the distributions named.
6.7.1.2 Planned Uses
Distributions can now be used to define rigid subsets of the
net that sites can "subscribe" to. For example, say a party
wishes to issue 3rd party cancel messages that delete spam
or net abuse at sites which wish to listen to that
canceller. These messages would now be posted to a specific
distribution. They might still reach the entire net, and
would make it to hubs, but they would only have effect at
sites which explicitly took membership in the distribution,
even without authentication.
However, as these might be very high volume messages --
especially if there are many such 3rd party cancel services
-- it remains possible for sites to ask their feeders to not
even feed articles in this distribution, thus making the
system efficient.
6.7.2 Definition
The Distribution header specifies geographical or The Distribution header specifies geographical or
organizational limits to an article's propagation: organizational limits to an article's propagation:
Distribution-content = distribution *( dist-delim distribution) Distribution-content = distribution *( dist-delim distribution)
dist-delim = "," dist-delim = ","
distribution = positive-distribution / negative-distribution distribution = positive-distribution / negative-distribution
positive-distribution = *FWS distribution-name *FWS positive-distribution = *FWS distribution-name *FWS
negative-distribution = *FWS "!" distribution-name *FWS negative-distribution = *FWS "!" distribution-name *FWS
distribution-name = 1*letter distribution-name = 1*letter
skipping to change at line 2424 skipping to change at line 2597
Lines-content = 1*digit Lines-content = 1*digit
The line count includes all body lines, including the The line count includes all body lines, including the
signature if any, including empty lines (if any) at beginning signature if any, including empty lines (if any) at beginning
or end of the body. (The single empty separator line between or end of the body. (The single empty separator line between
the headers and the body is not part of the body) . The "body" the headers and the body is not part of the body) . The "body"
here is the body as found in the posted article as transmitted here is the body as found in the posted article as transmitted
by the posting agent. by the posting agent.
Reading agents SHOULD NOT rely on the presence of this header, Software SHOULD NOT use the value of Lines for any purpose other
since it is optional (and some posting agents do not supply than to display an estimate to humans. This header will be
it). They MUST NOT rely on it being precise, since it deprecated in a future RFC.
frequently is not.
6.12. Xref 6.12 Xref
The Xref header content indicates where an article was filed The Xref header content indicates where an article was filed
by the last server to process it: by the last server to process it:
Xref-content = server 1*( CFWS location ) Xref-content = server 1*( CFWS location )
server = server-name server = server-name
location = newsgroup-name ":" article-locator location = newsgroup-name ":" article-locator
article-locator = 1* article-locator = 1*
The serving agent's name is included so that software can The serving agent's name is included so that software can
skipping to change at line 2464 skipping to change at line 2636
any previous Xref header(s). A relaying agent MUST only create any previous Xref header(s). A relaying agent MUST only create
and/or relay an Xref header if it correct on all the receiving and/or relay an Xref header if it correct on all the receiving
agents the article is forwarded to. Serving agents SHOULD agents the article is forwarded to. Serving agents SHOULD
insert this header unless the information in it (apart from insert this header unless the information in it (apart from
the serving name) is correct in which case it should be left the serving name) is correct in which case it should be left
unchanged. unchanged.
An agent MUST use the same name in Xref headers as it uses in An agent MUST use the same name in Xref headers as it uses in
Path headers. Path headers.
6.13. Organization 6.13 Organization
The Organization header content is a short phrase identifying The Organization header content is a short phrase identifying
the author's organization: the author's organization:
organization-content = nonblank-text CRLF organization-content = nonblank-text CRLF
NOTE: Posting and injection agents are discouraged from NOTE: Posting and injection agents are discouraged from
providing a default value for this header unless it is providing a default value for this header unless it is
acceptable to all posters using these agents. Unless this acceptable to all posters using these agents. Unless this
header contains useful information ( including some indication header contains useful information ( including some indication
of the authors physical location) posters are discouraged from of the authors physical location) posters are discouraged from
including it. including it.
6.14. User-Agent 6.14 User-Agent
The User-Agent header contains information about the user The User-Agent header contains information about the user
agent (typically a newsreader) generating the article. This is agent (typically a newsreader) generating the article. This is
for statistical purposes and tracing of standards violations for statistical purposes and tracing of standards violations
to specific software needing correction. Although OPTIONAL, to specific software needing correction. Although OPTIONAL,
user agents SHOULD include this header with the articles they user agents SHOULD include this header with the articles they
generate. generate.
The field MAY contain multiple product tokens and comments The field MAY contain multiple product tokens and comments
identifying the agent and any subproducts which form a identifying the agent and any subproducts which form a
skipping to change at line 2591 skipping to change at line 2763
format to the User-Agent header as noted, but headers in format to the User-Agent header as noted, but headers in
strict, common-sense compliance with RFC 1945 are compliant to strict, common-sense compliance with RFC 1945 are compliant to
this specification. The syntax from RFC 1945 is preferred, this specification. The syntax from RFC 1945 is preferred,
including the requirement that products and comments be including the requirement that products and comments be
separated by a space. separated by a space.
6.15 MIME headers 6.15 MIME headers
6.15.1 Syntax 6.15.1 Syntax
The following headers, as defined within [RFC 2045] and its The following headers, as defined within [RFC-2045] and its
extensions, may be used within articles conforming to this extensions, may be used within articles conforming to this
document. Document.
MIME-Version: MIME-Version:
Content-Type: Content-Type:
Content-Transfer-Encoding: Content-Transfer-Encoding:
Content-ID: Content-ID:
Content-Description: Content-Description:
Content-Disposition: Content-Disposition:
Content-MD5: Content-MD5:
Insofar as the syntax for these headers as given in [RFC 2045] Insofar as the syntax for these headers, as given in [RFC-
does not specify precisely where whitespace and comments may 2045], does not specify precisely where whitespace and
occur (whether in the form of WS, FWS or CFWS), the usage comments may occur (whether in the form of WS, FWS or CFWS),
defined in this Standard, and failing that in [MESSFOR], and the usage defined in this Document, and failing that in
failing that in [RFC 822] MUST be followed. In particular, [MESSFOR], and failing that in [RFC-822] MUST be followed. In
there MUST NOT be any WS between a header-name and the particular, there MUST NOT be any WS between a header-name and
following colon and there MUST be a SPACE following that the following colon and there MUST be a SPACE following that
colon. colon.
The meaning of the various MIME headers is as defined in [RFC The meaning of the various MIME headers is as defined in [RFC-
2045] and [RFC 2046], and in extensions registered in 2045] and [RFC-2046], and in extensions registered in
accordance with [RFC 2048]. However, their usage is restricted accordance with [RFC-2048]. However, their usage is restricted
as described in the following sections. as described in the following sections.
6.15.2 Content-Transfer-Encoding 6.15.2 Content-Transfer-Encoding
Posting agents SHOULD specify "Content-Transfer-Encoding: Posting agents SHOULD specify "Content-Transfer-Encoding:
8bit" for all articles not written in pure ASCII or whose 8bit" for all articles not written in pure ASCII and not
content type implies binary. They MAY use "8bit" encoding even requiring full binary. They MAY use "8bit" encoding even when
when "7bit" encoding would have sufficed. They SHOULD specify "7bit" encoding would have sufficed. They SHOULD specify
"base64" when the content type implies binary (i.e. content "base64" when the content type implies binary (i.e. content
intended for machine, rather than human, consumption). intended for machine, rather than human, consumption).
NOTE: If a future extension to the MIME standards were to
provide a more compact encoding of binary suited to transport
over an 8bit channel, it could be considered as an alternative
to base64 once it had gained widespread acceptance.
Posting agents SHOULD NOT specify encoding "quoted-printable", Posting agents SHOULD NOT specify encoding "quoted-printable",
but reading agents MUST interpret that encoding correctly. but reading agents MUST interpret that encoding correctly.
Encoding "binary" MUST NOT be used because this Standard does Encoding "binary" MUST NOT be used (except in closed networks
not mandate a transport mechanism that could support it with alternative transport arrangements) because this Document
(exceptions might be made in closed networks with alternative does not mandate a transport mechanism that could support it.
transport arrangements).
Injecting and relaying agents MUST NOT change the encoding of Injecting and relaying agents MUST NOT change the encoding of
articles passed to them. Gateways SHOULD ONLY change the articles passed to them. Gateways SHOULD ONLY change the
encoding if absolutely necessary. encoding if absolutely necessary.
6.15.3 Content-Type 6.15.3 Content-Type
Network news is primarily a means of sharing textual There exist many content types which, whilst being technically
information amongst a wide audience in a timely manner. The unexceptionable, are politically undesirable. It is therefore
network is largely self regulating and operates by the anticipated that agencies having the proper authority will, as
consensus of its membership rather than by the dictate of any a matter of policy, place restrictions upon the content types
central authority (indeed, this lack of centralised control is to be used within particular hierarchies or particular groups.
seen as one of the overall strengths of the system). There are In the absence of such explicit policies, the following
practices which, whilst being technically unexceptionable, are defaults are provided as an indication of current best
politically undesirable (or contrary to established practice.
"netiquette").
Insofar as there exist authorities empowered (by common The Content-Type: "text/plain" is the default type for any
consent or otherwise) to define what is and is not proper in news article. Other text types (such as "HTML") are thus
various hierarchies or newsgroups or cooperating subnets, inappropriate unless and until policy or custom has
those authorities ought to establish, by means of rules, established otherwise.
guidelines, charters or whatever else, the practices
considered acceptable within their domains. In particular they
ought to establish which of the more exotic content types are
likely to be inappropriate. In the absence of such specific
guidance, the following default recommendations are offered
as an indication of best practice at the present time.
6.15.3.1 Text In the event that such other text types do get used then, for
the benefit of readers who see it only in its transmitted
form, the material SHOULD be "pretty-printed" so as to keep it
(including any sequences which control its layout or style)
within the recommendations and limits on line lengths set out
in section 4.6, and so as to keep such sequences, as far as is
possible, separate from the meaningful text.
"Content-Type: text/plain" is the expected type for any news Content-Types requiring special processing for their display,
article. Attention is drawn to the recommendations and limits such as "application", "image", "audio", "video" and
on line lengths set out in section 4.6. Indeed, in any "text" "multipart/related" are deprecated except in groups
content type the lines as transmitted (i.e. including any specifically intended (by policy or custom) to include them.
formatting instructions) ought to observe the recommendations Exceptionally, those application types defined in [RFC-2015]
set out in that section for the benefit of readers who can and elsewhere for use within "multipart/signed" articles, and
only see it in its transmitted form. the type "application/pgp-keys" (or other similar types
containing digital certificates) may be used freely.
While "Content-Type: text/enriched" [RFC 1896] can be Reading agents SHOULD NOT, unless explicitly configured
considered acceptable in news articles, "Content-Type: otherwise, act automatically on Application types which could
text/HTML" is not appropriate since it relies on protocols change the state of that agent (e.g. by writing or modifying
currently unavailable to many reading agents. files), except in the case of those prescribed for use in
control messages (6.5).
6.15.3.2 Application The Content-Type "message/partial" MAY be used to split a long
news article into several smaller ones, but this usage is
deprecated on the grounds that modern transport agents should
have no difficulty in handling articles of arbitrary length.
Generally speaking, the application content types are IF this feature is used, then the "id" parameter SHOULD be in
inappropriate for use outside of specialised newsgroups and the form of a unique message-id (but different from the
subnets, especially where vendor-specific application Message-ID of any of the parts). Contrary to the requirements
subtypes are involved. specified in [RFC-2046], the Transfer-Encoding SHOULD be set
to 8bit at least in each part that requires it. The second
and subsequent parts SHOULD contain References headers
referring to all the previous parts, thus enabling reading
agents with threading capabilities to present them in the
correct order. Reading agents MAY then provide a facility to
recombine the parts into a single article (but this document
does not require them to do so).
"Application/octet-stream" is only appropriate in newsgroups The Content-Type "message/external-body" could be apropriate
where binaries are customarily accepted. for texts which it would be uneconomic (in view of the likely
readership) to distribute to the entire network.
6.15.3.4 Image, Audio and Video The Content-Type: "multipart/mixed" (also
"multipart/parallel") may be used freely in news articles.
Likewise, these content types are only appropriate in By default, the use of the Content-Type:
newsgroups where binaries are customarily accepted. "multipart/alternative" is deprecated (on account of the extra
bandwidth consumed and the difficulty of quoting in
followups).
6.15.3.5 Multipart The Content-Type: "multipart/digest" is commended for any
article composed of multiple messages more conveniently viewed
as separate entities. The "boundary" should be composed of 28
hyphens (ASCII 45) (which makes each boundary delimiter 30
hyphens, or 32 for the final one) so as to accord with current
practice for digests [RFC-1153].
[Actually, this conflicts with some present digest usage (such as the
news.answers rules), but should still be the right way to go. I
suggest this is left in for now (just to stake a claim), while we
discuss the matter with the news.answers moderators and the faq-
maintainers.]
"Content-Type: multipart/mixed" (also "multipart/parallel") The Content-Type: "multipart/signed" [RFC-1847, RFC-2015] is
may be used freely in news articles. the preferred method for the bodies of news articles that are
to be digitally signed. However, encryption (as in
"multipart/encrypted") is deprecated.
The use of "Content-Type: multipart/alternative" is deprecated 6.15.4 Character Sets
(on account of the extra bandwidth consumed and the difficulty
of quoting in followups).
"Content-Type: multipart/digest" is recommended for any article In principle, any character set may be specified in the
composed of multiple messages more conveniently viewed as "charset=" parameter of a content type. However, character
separate entities. The "boundary" should be composed of 28 sets other than "us-ascii", "iso-8859-1" (and the
hyphens (ASCII 45) (which makes each boundary delimiter 30 corresponding parts of UTF-8) ought only to be used in
hyphens, or 32 for the final one) so as to accord with current hierarchies where the language customarily used so requires
practice for digests [RFC 1153]. (and whose readers could be expected to possess agents capable
of displaying them).
"Content-Type: multipart/signed" [RFC 1847, RFC 2015] is the 6.15.5 Definition of some new Content-Types
preferred method for the bodies of news articles that are to
be digitally signed. However, encryption (as in
"multipart/encrypted") is unlikely to be appropriate in a
medium normally directed at such a wide readership.
6.15.3.6 Message This document defines (or redefines) several new Content-
Types, which require to be registered with IANA as provided
for in [RFC-2048]. For "multipart/news-groupinfo" see 6.6.1.1,
for "application/news-groupinfo" see 6.6.1.2, for
"application/news-checkgroups" see 6.6.5, and for the
remainder see this present section.
The Content Types "message/rfc822" and "message/news" are 6.15.5.1 Application/news-transmission
unlikely to be of much use within news articles, but attention
is drawn to the benefits of using "message/news" in gatewaying The Content-Type "application/news-transmission" is intended
from mail to news and vice versa. In particular, news articles for the encapsulation of complete news articles where the
mailed to moderators SHOULD be totally encapsulated within an intention is that the recipient should then inject them into
email message using "message/news". Moreover, use of Netnews. This Application type SHOULD be used when mailing
"message/news" in conjunction with a suitable Transfer articles to moderators and to mail-to-news gateways.
Encoding forms a convenient way of "tunnelling" a news article [The remarks about sending articles to moderators should perhaps be
made in a more appropriate place in our standard.]
NOTE: The benefit of such encapsulation is that it removes
possible conflict between news and email headers and it
provides a convenient way of "tunnelling" a news article
through a transport medium that does not support 8bit through a transport medium that does not support 8bit
characters. characters.
[This paragraph needs further work. Both message/news and The MIME content type definition of "application/news-
application/news-transmission are recognised by IANA, but the transmission" is:
distinction between them is not clear and their present
definitions are out of date and omit to state that base 64 etc
encodings are permitted (RFC 2046 is silent on that issue). We
should take the opportunity to rewrite those specifications
and include them (or at least one of them) in the present
standard.]
"Content-Type: message/partial" MAY be used to split a long MIME type name: application
news article into several smaller ones, but this usage is MIME subtype name: news-transmission
deprecated on the grounds that modern transport agents should Required parameters: none
have no difficulty in handling articles of arbitrary length. Optional parameters: moderate; inject; relay
If this feature is used, then the "id" parameter should be in Encoding considerations: A transfer-encoding (such as
the form of a unique message-id (but different from the Quoted-Printable or Base64) different
Message-ID of any of the partial articles). The second and from that of the article transmitted
subsequent partial articles should contain References headers MAY be supplied (perhaps en route) to
referring to all the previous parts (note that these headers ensure correct transmission over some
will be discarded upon reassembly of the parts). Contrary to 7bit transport medium.
the requirements specified in [RFC 2046], the Security considerations: A news article may be a "control
Transfer-Encoding should be set to 8bit at least in each part message", which could have effects on
that requires it. the recipient host's system beyond
just storage of the article. However,
such control messages also occur in
normal news flow, so most hosts will
already be suitably defended against
undesired effects.
Published specification: [USEFOR]
Body part: A complete article or proto-article,
ready for injection into Netnews, or a
batch of such articles.
"Content-Type: message/external-body" could be appropriate for NOTE: It is likely that the recipient of an
texts which it would be uneconomic (in view of the likely "application/news-transmission" will be a specialised gateway
reader- ship) to distribute to the entire network. (e.g. a moderator's submission address) able to accept
articles with only one of the three parameter types
"moderate", "inject" and "relay", hence the reason why they
are optional, being redundant in most situations.
Nevertheless, they MAY be used to signify the originator's
intention with regard to the transmission, so removing any
possible doubt.
6.15.3.7 Character Sets 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 following syntax MUST be used.
In principle, any character set may be specified in the batch = 1*( batch-header article )
"charset=" parameter of a content type. However, character batch-header = "#!" SPACE "rnews" SPACE article-size CRLF
sets other than "us-ascii", "iso-8859-1" (and the article-size = 1*digit
corresponding parts of UTF-8) ought only to be used in
hierarchies where the language customarily used so required
(and whose readers could be expected to possess agents capable
of displaying them).
6.15.4 MIME within headers where the "rnews" is case-sensitive. Thus a batch is a
sequence of articles, each prefixed by a header line that
includes its size. The article-size is a decimal count of the
octets in the article, counting each CRLF as one octet
regardless of how it is actually represented.
NOTE: Despite the similarity of this format to an executable
UNIX script, it is EXTREMELY unwise to feed such a batch into
a command interpreter in anticipation of it running a command
named "rnews"; the security implications of so doing would be
disastrous.
6.15.5.2 Application/news-message
[WARNING: The application/mews-message type as described here has been
subject to much adverse criticism. Thus it is liable to be replaced by
an alternative method of encapsulation in a future draft of this
document.]
The Content-Type "application/news-message" is intended for
the encapsulation of complete news articles which have already
been posted to Netnews and which are for the information of
the recipient, and do not constitute a request to repost them.
This Message type SHOULD be used when a courtesy copy of a
followup is mailed to the author of its precursor, and when
gatewaying from news-to-mail.
NOTE: The benefits of such encapsulation are
a) that it will be apparent to the recipient that what he sees
is a copy of a news article rather than an original email;
b) that it will survive tramsmission intact even when the
transport medium does not support 8bit characters and has to
employ some special Content-Transfer-Encoding;
c) likewise, that UTF-8 characters in headers will survive
transmission;
c) likewise, that any digital signature applied to it will
survive tramsmission intact.
The MIME content type definition of "application/news-message"
is:
MIME type name: application
MIME subtype name: news-message
Required parameters: none
Optional parameters: none
Encoding considerations: A transfer-encoding (such as
Quoted-Printable or Base64) different
from that of the article transmitted
MAY be supplied (perhaps en route) to
ensure correct transmission over some
7bit transport medium.
Disposition: By default, presentation agents SHOULD
display news-messages inline, except
where overriden by a
Content-Disposition header.
Published specification: [USEFOR]
Body part: A complete news article, as already
injected into Netnews.
6.15.5.3 Message/news obsoleted
[WARNING: In view pf the possible withdrawal of the proposed
application/news-message (see above), it should not be assumed that
the obsoletion of message/news will necessarily remain in future
drafts of this document.]
The Content-Type "message/news", as previously registered with
IANA, is hereby obsoleted and should be withdrawn. The reason
is that, according to RFC-2045, it is expressly forbidden for
any "message" type to use a transfer-encoding other than
"7bit", "8bit" or "binary", thus preventing a news article
which makes full use of UTF-8 characters in its headers, or
which uses (as it SHOULD) "8bit" as its own transfer-encoding,
from being passed through a 7bit transport medium (recall that
it is not permitted by this document for the transfer-encoding
of a news article to be changed).
6.15.6 MIME within headers
Since the headers of news articles are expected to use the Since the headers of news articles are expected to use the
UTF-8 character set, they SHOULD NOT normally be encoded using UTF-8 character set, they SHOULD NOT normally be encoded using
the MIME mechanism defined in RFC-2047 [RFC-2047]. the MIME mechanism defined in [RFC-2047]. Nevertheless,
Nevertheless, reading agents SHOULD support that usage. reading agents SHOULD support that usage.
It is to be noted, however, that RFC-2047 encoding would be It is to be noted, however, that RFC-2047 encoding would be
required were a news article to be transmitted as a mail required were a news article to be transmitted as a mail
message without first encapsulating in as a "message/news" as message without first encapsulating it as an
suggested above. "application/news-message" as suggested above.
6.15. Supersedes / Replaces 6.16 Supersedes / Replaces
These two headers take a list of message-ids (msgid-list) that These two headers take a list of message-ids (msgid-list) that
the current article is expected to replace or supersede. All the current article is expected to replace or supersede. All
listed articles MUST be treated as though a "cancel" control listed articles MUST be treated as though a "cancel" control
message had arrived for the message, except as detailed below. message had arrived for the message, except as detailed below.
These headers are essentially synonyms, with a change in These headers are essentially synonyms, with a change in
behavior - Replaces uses the old article's message-id for behavior - Replaces uses the old article's message-id for
the more recently arrived article, rather than creating a the more recently arrived article, rather than creating a
new article. new article.
The Supersedes header content specifies articles to be The Supersedes header content specifies articles to be
cancelled on arrival of this one: cancelled on arrival of this one:
Supersedes-content = message-id *( FWS message-id ) Supersedes-content = message-id *( FWS message-id )
NOTE: There is no "c" in "Supersedes". NOTE: There is no "c" in "Supersedes".
Older software supported only Supersedes, and with only one Older software supported only Supersedes, and with only one
Message-ID. Until Multi-Super-Date, software SHOULD generate Message-ID. Software MUST be aware of the possibility that
Supersedes with only one Message-ID, and cancel control the new-style of Supersedes may not be interpreted correctly,
messages SHOULD be issued if needed for other IDs. and MAY wish to generate Supersedes with only one Message-ID,
and cancel control messages SHOULD be issued if needed for other
IDs, until such time as a critical mass of compliant relay agents
exists.
If the header is "Replaces" the new successor article SHOULD If the header is "Replaces" the new successor article SHOULD
effectively over-write the predecessor(s) so that any attempt effectively over-write the predecessor(s) so that any attempt
to read them shows the successor. Newsreaders should not show to read them shows the successor. Newsreaders should not show
the article as an "unread" article unless the replaced the article as an "unread" article unless the replaced
articles were themselves all unread. A Replacement is articles were themselves all unread. A Replacement is
considered a minor change, unworthy of being brought to the considered a minor change, unworthy of being brought to the
attention of a person who read one of the predecessors. attention of a person who read one of the predecessors.
Newsreaders and database systems MAY provide access to Newsreaders and database systems MAY provide access to
predecessors of articles if they wish, but this should not be predecessors of articles if they wish, but this should not be
skipping to change at line 2835 skipping to change at line 3128
It is expected that "Replaces" will become the common header It is expected that "Replaces" will become the common header
for routine article changes and corrections, with Supersedes for routine article changes and corrections, with Supersedes
used for periodic postings (possibly every N periodic used for periodic postings (possibly every N periodic
postings) or updates that make major changes to an article. postings) or updates that make major changes to an article.
As with a cancel, systems MUST NOT delete or replace articles As with a cancel, systems MUST NOT delete or replace articles
unless the poster of the successor is authorized to cancel the unless the poster of the successor is authorized to cancel the
predecessor. predecessor.
6.15.1 Message-ID version numbers chain procedure. 6.16.1 Message-ID version numbers chain procedure.
NOTE: Sections 6.15.1 - 6.15.4 may be published as a separate NOTE: Sections 6.16.1 - 6.16.4 may be published as a separate
recommendations document. recommendations document.
Tools superseding or replacing messages should arrange so that Tools superseding or replacing messages should arrange so that
the Message-ID of a replacement follows the following set of the Message-ID of a replacement follows the following set of
rules, generating what are known as "version-number" rules, generating what are known as "version-number"
Message-IDs. Message-IDs.
1. If the Local-Part of the predecessor's Message-ID ends in 1. If the Local-Part of the predecessor's Message-ID ends in
"%v=<n>", where <n> is an integer version number, the new "%v=<n>", where <n> is an integer version number, the new
message-ID should replace the <n> with the integer <n+1>. message-ID should replace the <n> with the integer <n+1>.
skipping to change at line 2861 skipping to change at line 3154
<foo%v=4@example.invalid>. <foo%v=4@example.invalid>.
2. If the Local-Part of the predecessor's Message-ID does not 2. If the Local-Part of the predecessor's Message-ID does not
end in "%v=<n>", then the string "%v=1" should be appended to end in "%v=<n>", then the string "%v=1" should be appended to
the Local-Part to generate the successor Message-ID. the Local-Part to generate the successor Message-ID.
Example: Example:
Message-ID <foo@example.invalid> is replaced by Message-ID <foo@example.invalid> is replaced by
<foo%v=1@example.invalid>. <foo%v=1@example.invalid>.
6.15.2 Implementation and Use Note 6.16.2 Implementation and Use Note
Typically a news database will store a "pointer" of some sort Typically a news database will store a "pointer" of some sort
between replaced/superseded articles and their immediate between replaced/superseded articles and their immediate
successor or most recent successor. Such pointers may be successor or most recent successor. Such pointers may be
expired along with other records in a news system's message-id expired along with other records in a news system's message-id
lookup database. In addition, if a "version-number" Message-ID lookup database. In addition, if a "version-number" Message-ID
is found, and the "root" version (without the "%v=" tag, or is found, and the "root" version (without the "%v=" tag, or
with a "%v=0" tag) is not present on the server, a pointer with a "%v=0" tag) is not present on the server, a pointer
from that root to the most recent successor SHOULD also be from that root to the most recent successor SHOULD also be
stored, and kept so long as there is a current successor in stored, and kept so long as there is a current successor in
the system. (Systems should check for both root forms, trying the system. (Systems should check for both root forms, trying
the "%v=0" form first, and the tagless form 2nd.) the "%v=0" form first, and the tagless form 2nd.)
Thus when a request for an article comes in that is not Thus when a request for an article comes in that is not
present (due to superseding or replacement) a check can be present (due to superseding or replacement) a check can be
made for a pointer record for that Message-ID, or failing made for a pointer record for that Message-ID, or failing
that, if the ID has a version-number, for a pointer record for that, if the ID has a version-number, for a pointer record for
the root versionless ID. Such pointers can be followed to the the root versionless ID. Such pointers can be followed to the
most recent successor. most recent successor.
6.15.3 Transition 6.16.3 Transition
Prior to Multi-Super-Date, a message may contain both a Until a sufficient percentage of relay agents is compliant, a
Replaces field and a Supersedes field. This should be treated message may contain both a Replaces field and a Supersedes field.
as a Replaces, with the Supersedes added to assure that older This MUST be treated as a Replaces, with the Supersedes added
systems still at least remove the predecessor. to assure that older systems still at least remove the predecessor.
6.15.4 Replaced-by 6.16.4 Replaced-by
This header takes a message-id as argument. This header takes a message-id as argument.
Prior to Multi-Super-Date, if there is a need to Supersede by If there is a need to support older systems which only understand
use of a simple Cancel control message (due to inability to a single ID in Supersedes by use of a simple Cancel control message,
use multiple IDs in the Supersedes header) then such control then such control messages may contain a "Replaced-by" header
messages may contain a "Replaced-by" header indicating the indicating the Message-ID of the successor the message that was
Message-ID of the successor the message that was cancelled. cancelled. Systems maintaining pointers from predecessors to
Systems maintaining pointers from predecessors to successors successors should use this record to update their pointers.
should use this record to update their pointers.
Note this header goes only on the cancel control message, not Note this header goes only on the cancel control message, not
the successor. The successor should have a Replaces and/or the successor. The successor should have a Replaces and/or
Supersedes listing the most immediate predecessor. Supersedes listing the most immediate predecessor.
6.15.5.1 Examples 6.16.5.1 Examples
The first edition of an FAQ is posted with a Message-ID of the The first edition of an FAQ is posted with a Message-ID of the
form: <examplegroup-faq@example.invalid>. The next version, a week form: <examplegroup-faq@example.invalid>. The next version, a week
later, has: later, has:
Message-ID: <examplegroup-faq%v=1@example.invalid> Message-ID: <examplegroup-faq%v=1@example.invalid>
Supersedes: <examplegroup-faq@example.invalid> Supersedes: <examplegroup-faq@example.invalid>
The next one, another week later has: The next one, another week later has:
skipping to change at line 2938 skipping to change at line 3230
records at sites not using the version-number system for records at sites not using the version-number system for
message-ids. message-ids.
Under the above, requests for the root (original) message-ID Under the above, requests for the root (original) message-ID
will return the most recent FAQ. On systems using the will return the most recent FAQ. On systems using the
version-number system (which is optional) requests for any version-number system (which is optional) requests for any
Message-ID in the chain will return the most recent, for all Message-ID in the chain will return the most recent, for all
time. As such the URL "news:groupname-faq@faqsite.com" will time. As such the URL "news:groupname-faq@faqsite.com" will
always work, making it suitable to appear in HTML. always work, making it suitable to appear in HTML.
6.15.5.2 Example 6.16.5.2 Example
A user posts a message <myuniquepart@mysite.com> to the net. A user posts a message <myuniquepart@mysite.com> to the net.
She notices a typo, and 2 minutes later, posts with: She notices a typo, and 2 minutes later, posts with:
Message-ID: <myuniquepart%v=1@example.invalid> Message-ID: <myuniquepart%v=1@example.invalid>
Replaces: <myuniquepart@example.invalid> Replaces: <myuniquepart@example.invalid>
3 minutes later she sees another typo, and posts: 3 minutes later she sees another typo, and posts:
Message-ID: <myuniquepart%v=2@example.invalid> Message-ID: <myuniquepart%v=2@example.invalid>
skipping to change at line 2963 skipping to change at line 3255
site never sees the 2nd due to batching or feed problems, and site never sees the 2nd due to batching or feed problems, and
requests for the original will return the 3rd. requests for the original will return the 3rd.
During transition, she adds a Supersedes header to the 3rd During transition, she adds a Supersedes header to the 3rd
message, with the first (direct predecessor) ID. She issues a message, with the first (direct predecessor) ID. She issues a
Cancel message as well: Cancel message as well:
Control: cancel <myuniquepart@example.invalid> Replaced-by: Control: cancel <myuniquepart@example.invalid> Replaced-by:
<myuniquepart%v=2@example.invalid> <myuniquepart%v=2@example.invalid>
6.15.6 Dates 6.16.7 Issues
Multi-Super-Date ... in one year. (1036-spencer required
multiple-ID supersedes, so by now just about everybody should
already support it, is this true?) "Replaces" active --
whatever date we are putting for general compliance with this
spec by news database systems.
6.15.7 Issues
No syntax for the internals of message-ids has been declared [No syntax for the internals of message-ids has been declared
on the net. However, there is no harm if a conforming on the net. However, there is no harm if a conforming
message-id matches the syntax. The syntax has been designed so message-id matches the syntax. The syntax has been designed so
that additional flags may be added to a message-id if desired, that additional flags may be added to a message-id if desired,
in a general "%keyword=value" form prior to the at-sign. in a general "%keyword=value" form prior to the at-sign.
Permanent message-ids as created by this system may even be Permanent message-ids as created by this system may even be
implemented by smart NNTP servers which fetch old messages implemented by smart NNTP servers which fetch old messages
from other servers, increasing the availability of USENET from other servers, increasing the availability of USENET
messages considerably. messages considerably.
Unfortunately, it will be some time until any new feature is Unfortunately, it will be some time until any new feature is
widely deployed. widely deployed.]
6.16 Archive 6.17 Archive
This optional header is a signal to automatic archival agents This optional header is a signal to automatic archival agents
on whether this article is available for long-term storage. on whether this article is available for long-term storage.
Agents which see "Archive: no" MUST NOT keep the article past Agents which see "Archive: no" MUST NOT keep the article past
the Expires date. Any other text indicates conditions that an the Expires date. Any other text indicates conditions that an
agent SHOULD follow in order to archive the article. agent SHOULD follow in order to archive the article.
Archive-content = "no" | CFWS Archive-content = "no" | CFWS
6.17. Obsolete Headers 6.18. Obsolete Headers
Persons writing new agents SHOULD ignore any former meanings Persons writing new agents SHOULD ignore any former meanings
of these headers. of these headers.
Also-Control Also-Control
See-Also See-Also
Article-Names Article-Names
Article-Updates Article-Updates
7. Duties of Various Agents 7. Duties of Various Agents
skipping to change at line 3472 skipping to change at line 3756
Frederic SENIS (fs@caduceus.frmug.org) Frederic SENIS (fs@caduceus.frmug.org)
Fredric Logren (Fredric.Lonngren@uab.ericsson.se) Fredric Logren (Fredric.Lonngren@uab.ericsson.se)
Greg Berigan (gberigan@cse.unl.edu) Greg Berigan (gberigan@cse.unl.edu)
Harald Alvestrand (Harald.T.Alvestrand@uninett.no) Harald Alvestrand (Harald.T.Alvestrand@uninett.no)
Heiko Schlichting (heiko@cis.fu-berlin.de) Heiko Schlichting (heiko@cis.fu-berlin.de)
Heiko W.Rupp (hwr@pilhuhn.de) Heiko W.Rupp (hwr@pilhuhn.de)
Hrvoje Niksic (hniksic@srce.hr) Hrvoje Niksic (hniksic@srce.hr)
Ian Davis (iand@fdc.co.uk) Ian Davis (iand@fdc.co.uk)
Ian G Batten (I.G.Batten@batten.eu.org) Ian G Batten (I.G.Batten@batten.eu.org)
John Moreno (phenix@interpath.com) John Moreno (phenix@interpath.com)
John Stanley (stanley@oce.orst.edu) John Stanley (stanley@peak.org)
Jon Ribbens (jon@oaktree.co.uk) Jon Ribbens (jon@oaktree.co.uk)
Jonathan Grobe (grobe@netins.net) Jonathan Grobe (grobe@netins.net)
Kai Heingsen (kai@khms.westfalen.de) Kai Heingsen (kai@khms.westfalen.de)
Karl Kleinpaste (karl@jprc.com) Karl Kleinpaste (karl@jprc.com)
Keeth Herron (kherron@campus.mci.net) Keeth Herron (kherron@campus.mci.net)
Kent Landfield (kent@landfield.com) Kent Landfield (kent@landfield.com)
Kristian =?ISO-8859-1?Q?K=F6hntopp?= (KRIS@koehntopp.de) Kristian =?ISO-8859-1?Q?K=F6hntopp?= (KRIS@koehntopp.de)
Lars Magne Ingebrigtsen (lmi@gnus.org) Lars Magne Ingebrigtsen (lmi@gnus.org)
Leonid Yegoshin (egoshin@genesyslab.com) Leonid Yegoshin (egoshin@genesyslab.com)
Mark Hittinger (bugs@freebsd.netcom.com) Mark Hittinger (bugs@freebsd.netcom.com)
skipping to change at line 3514 skipping to change at line 3798
Stan Barber (sob@academ.com) Stan Barber (sob@academ.com)
Sylvan Butler (SBUTLER@hpbs2024.boi.hp.com) Sylvan Butler (SBUTLER@hpbs2024.boi.hp.com)
Terje Bless (link@tss.no) Terje Bless (link@tss.no)
Thomas Roessler (roessler+1036@sobolev.iam.uni-bo.de) Thomas Roessler (roessler+1036@sobolev.iam.uni-bo.de)
Tim Skirvin (tskirvin@math.uiuc.edu) Tim Skirvin (tskirvin@math.uiuc.edu)
Todd Michel McComb (mccomb@best.com) Todd Michel McComb (mccomb@best.com)
Tom Hughes (tom@compton.demon.co.uk) Tom Hughes (tom@compton.demon.co.uk)
Vera Heinau (heinau@cis.fu-berlin.de) Vera Heinau (heinau@cis.fu-berlin.de)
Wayne Davison (wayne@clari.net) Wayne Davison (wayne@clari.net)
Wolfgang Schelongowski (skaranyi@xivic.ruhr.de) Wolfgang Schelongowski (skaranyi@xivic.ruhr.de)
Expires 19990101
 End of changes. 

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