draft-ietf-usefor-article-00.txt   draft-ietf-usefor-article-01.txt 
News Article Format News Article Format
draft-ietf-usefor-article-00 draft-ietf-usefor-article-01
USEFOR Working Group USEFOR Working Group
Status of this Memo Status of this Memo
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
skipping to change at line 25 skipping to change at line 25
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."
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast). (US West Coast).
It is hoped that this Draft will obsolete RFC 1036 and will It is hoped that this document will obsolete RFC 1036 and will
become an Internet standard. become an Internet standard.
This Draft is a successor to Henry Spencer's "Son of 1036" This document is a successor to Henry Spencer's "Son of 1036"
Draft, and has been referred to as "Grandson of 1036". Draft, and has been referred to as "Grandson of 1036".
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
This Draft defines the format of network news articles, and This Draft defines the format of network news articles, and
defines roles and responsibilities for humans and software. defines roles and responsibilities for humans and software.
Network news articles resemble mail messages but are broadcast Network news articles resemble mail messages but are broadcast
skipping to change at line 61 skipping to change at line 61
themselves to an internally adopted set of standards concerning themselves to an internally adopted set of standards concerning
protocol details or implementations. When a cooperating subnet protocol details or implementations. When a cooperating subnet
does not exchange traffic with general Usenet hosts, then it does not exchange traffic with general Usenet hosts, then it
is no longer a part of Usenet, but a separate entity. is no longer a part of Usenet, but a separate entity.
Since then Usenet has grown explosively, and most Internet Since then Usenet has grown explosively, and most Internet
sites participate in it. In addition, the news technology sites participate in it. In addition, the news technology
is now in widespread use for other purposes, on the Internet is now in widespread use for other purposes, on the Internet
and elsewhere. and elsewhere.
This Draft 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 Draft and compatibility is a major goal, but where this document and
earlier documents or practices collide, this Draft should be earlier documents or practices collide, this document should be
used. used.
Table of Contents Table of Contents
needs TOC 1. Introduction
2. Definitions, Notations and Conventions
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
6.1 Followup-To
6.2 Expires
6.3. Reply-To
6.3.1 Examples:
6.4. References
6.4.1 Examples:
6.5. Control
6.6. Control Messages
6.6.1 The "newgroup" Control Message
6.6.1.1 multipart/newsgroupinfo
6.6.1.2 application/newsgroupinfo
6.6.1.3 Initial Named Articles
6.6.2 The "rmgroup" Control Message
6.6.3 The "mvgroup" Control Message
6.6.3.1 Single group
6.6.3.2 Multiple Groups
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
7.1 Duties of an Injecting Agent.
7.1.1 Proto-articles.
7.1.2 Procedure followed by Injecting Agents.
7.1.3 Headers added by Injecting Agents.
7.2 Duties of a Relaying Agent
7.2.1 Unwanted and Invalid articles
7.3 Duties of a Serving Agent
7.3.1 Unwanted articles
7.4 Duties of a Posting Agent.
7.5 Duties of a Followup Agent
7.6 Duties of a Gateway
8. Propagation and Processing
9. Security And Related Issues
9.1 Attacks
10. Security Considerations
11. References:
1. Introduction 1. Introduction
Network news articles resemble mail messages but are Network news articles resemble mail messages but are
broadcast to potentially-large audiences, using a flooding broadcast to potentially-large audiences, using a flooding
algorithm that propagates one copy to each interested host algorithm that propagates one copy to each interested host
(or groups thereof), typically stores only one copy per (or groups thereof), typically stores only one copy per
host, and does not require any central administration or host, and does not require any central administration or
systematic registration of interested users. Network news systematic registration of interested users. Network news
originated as the medium of communication for Usenet, circa originated as the medium of communication for Usenet, circa
skipping to change at line 97 skipping to change at line 230
vaguely resembling Internet mail was devised and used vaguely resembling Internet mail was devised and used
briefly. Both of those formats are completely obsolete; briefly. Both of those formats are completely obsolete;
they are documented in appendix A for historical reasons they are documented in appendix A for historical reasons
only. With publication of RFC 850 [rrr] in 1983, news only. With publication of RFC 850 [rrr] in 1983, news
articles came to closely resemble Internet mail messages, articles came to closely resemble Internet mail messages,
with some restrictions and some additional headers. RFC with some restrictions and some additional headers. RFC
1036 in 1987 updated RFC 850 without making major changes. 1036 in 1987 updated RFC 850 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" was written in
1992 by Henry Spencer. That document formed the original basis 1992 by Henry Spencer. That document formed the original basis
for this Draft. Much is taken directly from Son of 1036, and for this document. Much is taken directly from Son of 1036, and
it is hoped that we have followed its spirit and intentions. it is hoped that we have followed its spirit and intentions.
As in this Draft'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 [rrr] is the most common transmission method on the
Internet, but a number of others are in use, including the Internet, but a number of others are in use, including the
UUCP protocol [rrr] extensively used in the early days of UUCP protocol [rrr] extensively used in the early days of
Usenet, FTP, tape archives, and physically delivered magnetic Usenet, FTP, tape archives, and physically delivered magnetic
and optical media. and optical media.
Several of the mechanisms described in this Draft may seem Several of the mechanisms described in this document may seem
somewhat strange or even bizarre at first reading. As with somewhat strange or even bizarre at first reading. As with
Internet mail, there is no reasonable possibility of updating Internet mail, there is no reasonable possibility of updating
the entire installed base of news software promptly, so the entire installed base of news software promptly, so
interoperability with old software is crucial and will interoperability with old software is critical and will
remain so. Compatibility with existing practice and remain so. Compatibility with existing practice and
robustness in an imperfect world necessarily take priority robustness in an imperfect world necessarily take priority
over elegance. Elegance is left to the implementors. 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
is analogous to [MAIL]'s author(s). is analogous to [MAIL]'s author(s).
A "posting agent" is software that assists posters to prepare A "posting agent" is software that assists posters to prepare
articles, including adding required headers and determining articles, including adding required headers and determining
whether the final article is compliant to this standard. If whether the final article is compliant to this standard. If
the article is complient it passes the article on to an the article is compliant it passes the article on to an
injecting agent for final checking and injection into the news injecting agent for final checking and injection into the news
stream. If the article is not complient or rejected by the stream. If the article is not compliant or rejected by the
injecting agent the the posting agent informs the poster with injecting agent then the posting agent informs the poster with
an explanation of the error. an explanation of the error.
An "injecting agent" takes the finished article from the An "injecting agent" takes the finished article from the
posting agent (often via the NNTP "post" command ) performs posting agent (often via the NNTP "post" command ) performs
some final checks and passes it on to a relaying agent for some final checks and passes it on to a relaying agent for
general distribution. general distribution.
A "relaying agent" is software which receives allegedly A "relaying agent" is software which receives allegedly
compliant articles from injecting agents and/or other compliant articles from injecting agents and/or other
relaying agents, and possibly passes copies on to other relaying agents, and possibly passes copies on to other
skipping to change at line 196 skipping to change at line 329
identical copies of the same article even if they are not in identical copies of the same article even if they are not in
fact identical. fact identical.
A "gateway" is software which receives news articles and A "gateway" is software which receives news articles and
converts them to messages of some other kind (e.g. mail to a converts them to messages of some other kind (e.g. mail to a
mailing list), or vice versa; in essence it is a translating mailing list), or vice versa; in essence it is a translating
relaying agent that straddles boundaries between different relaying agent that straddles boundaries between different
methods of message exchange. The most common type of gateway methods of message exchange. The most common type of gateway
connects newsgroup(s) to mailing list(s), either connects newsgroup(s) to mailing list(s), either
unidirectionally or bidirectionally, but there are also unidirectionally or bidirectionally, but there are also
gateways between news networks using this Draft's news gateways between news networks using this document's news
format and those using other formats. format and those using other formats.
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 will (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 Draft, [MAIL] is short for "the current RFCs Throughout this document, [MAIL] is short for "the current RFCs
governing electronic mail formats, beginning with the governing electronic mail formats, beginning with the
historical RFC 822 and continuing to its modern successors. historical RFC 822 and continuing to its modern successors.
"ASCII" is short for "the ANSI X3.4 character set" [rrr]. "ASCII" is short for "the ANSI X3.4 character set" [rrr].
While "ASCII" is often misused to refer to various character While "ASCII" is often misused to refer to various character
sets somewhat similar to X3.4, in this Draft, "ASCII" means sets somewhat similar to X3.4, in this document, "ASCII" means
X3.4 and only X3.4. ASCII is a 7 bit character set. Please X3.4 and only X3.4. ASCII is a 7 bit character set. Please
note that this Draft requires that all agents be 8 bit clean; note that this document requires that all agents be 8 bit clean;
that is, they must accept and transmit data without changing that is, they must accept and transmit data without changing
or omitting the 8th bit. 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 same words followed by "NOT" should be read as having the the same words followed by "NOT" should be read as having the
same meaning as in RFC 2119. same meaning as in RFC 2119.
This Draft 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 the content of the specification. The purpose of the in the content of the specification. The purpose of the
notes is to explain why choices were made, to place them in notes is to explain why choices were made, to place them in
context, or to suggest possible implementation techniques. context, or 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 specification in cases where the wording is not entirely the specification in cases where the wording is not entirely
clear. clear.
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 purpose. Large numbers are written using the North this purpose.
American convention, in which "," separates groups of three
digits but otherwise has no significance. Through this document we will give examples of various
definitions, headers and other specifications. It MUST be
remembered that these samples are for the aid of the reader
only and do NOT define any specification themselves. In order
to prevent possible conflict with "Real World" entities and
people the top level domain of ".example" is used in all
sample domains and addresses. The hierarchy of example.* is
also used a sample hierarchy. Information on the ".example"
top level domain is in [TEST-TLDS] .
2.3. Syntax Notation 2.3. Syntax Notation
This Draft 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 [ABNF]. A discussion of this is outside the bounds of this
Draft, but it is expected that implementors will be able to document, but it is expected that implementors will be able to
quickly understand it with reference to the defining document. quickly understand it with reference to the defining document.
This Draft is intended to be self-contained; all syntax This document is intended to be self-contained; all syntax
rules used in it are defined within it, and a rule with the rules used in it are defined within it, and a rule with the
same name as one found in [MAIL] does not have the same same name as one found in [MAIL] does not have the same
definition. The lexical layer of [MAIL] is NOT, repeat NOT, definition. The lexical layer of [MAIL] is NOT, repeat NOT,
used in this Draft, and its presence must not be used in this document, and its presence must not be
assumed; notably, this Draft spells out all places where assumed; notably, this document spells out all places where
white space is permitted/required and all places where white space is permitted/required and all places where
constructs resembling [MAIL] comments can occur. 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.
Text in newsgroup names, header parameters, etc. is Text in newsgroup names, header parameters, etc. is
case-sensitive unless stated otherwise. case-sensitive unless stated otherwise.
NOTE: This is at variance with [MAIL], which is NOTE: This is at variance with [MAIL], which is
case-insensitive unless stated otherwise, but is case-insensitive unless stated otherwise, but is
consistent with news historical practice and consistent with news historical practice and
existing news software. See the comments on backward existing news software. See the comments on backward
compatibility in section 1. compatibility in section 1.
2.4. Language 2.4. Language
Various constant strings in this Draft, 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 Draft. MUST be the English-derived ones defined in this document.
3. Relation To [MAIL] (RFC 822 etc.) 3. Relation To [MAIL] (RFC 822 etc.)
The primary intent of this Draft is to completely describe The primary intent of this document is to completely describe
the news article format. News articles were once considered as the news article format. News articles were once considered as
a subset of [MAIL]'s message format augmented by some new a subset of [MAIL]'s message format augmented by some new
headers; this is no longer the case. News and [MAIL] have headers; this is no longer the case. News and [MAIL] have
diverged. It is the intention of this Draft that gateways diverged. It is the intention of this document that gateways
between [MAIL] and news still be capable of performing this between [MAIL] and news still be capable of performing this
function automatically. function automatically.
[MAIL] and news do follow some of the same standards, however. [MAIL] and news do follow some of the same standards, however.
In particular, the MIME standards apply equally to news In particular, the MIME standards apply equally to news
articles. articles.
4. Basic Format 4. Basic Format
4.1 Overall Syntax 4.1 Overall Syntax
skipping to change at line 318 skipping to change at line 459
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
US-ASCII characters, that it does not recognise the MIME US-ASCII characters, that it does not recognise the MIME
headers [RFC2045], and that it includes much syntax described headers [RFC2045], and that it includes much syntax described
as "obsolete". as "obsolete".
The following syntactic forms supersede the corresponding The following syntactic forms supersede the corresponding
rules given in [MESSFOR] and [RFC2045]: rules given in [MESSFOR] and [RFC2045]:
text = %d1-%d9 / ; all octets except text = %d1-9 / ; all octets except
%d11-%d12 / ; US-ASCII NUL, CR and LF %d11-12 / ; US-ASCII NUL, CR and LF
%d14-%d255 %d14-255
ctext = NO-WS-CTL / ; all of <text> except ctext = NO-WS-CTL / ; all of <text> except
%d33-%d39 / ; SP, HTAB, "(", ")" %d33-39 / ; SP, HTAB, "(", ")"
%d42-%d91 / ; and "\" %d42-91 / ; and "\"
%d93-%d255 %d93-255
qtext = NO-WS-CTL / ; all of <text> except qtext = NO-WS-CTL / ; all of <text> except
%d33 / ; SP, HTAB, "\" and <"> %d33 / ; SP, HTAB, "\" and <">
%d35-%d91 / %d35-91 /
%d93-%d255 %d93-255
ftext = %d33-%d57 / ; all octets except ftext = %d33-57 / ; all octets except
%d59-%d126 / ; CTL, SP and ":" %d59-126 / ; CTL, SP and ":"
%d128-%d255 %d128-255
token = 1*<any ftext except tspecials> token = 1*<any ftext except tspecials>
tspecials = "(" / ")" / "<" / ">" / "@" tspecials = "(" / ")" / "<" / ">" / "@"
"," / ";" / ":" / " "," / ";" / ":" / "
"/" / "[" / "]" / "?" / "=" "/" / "[" / "]" / "?" / "="
Wherever in this standard the syntax is stated to be taken Wherever in this standard the syntax is stated to be taken
from [MESSFOR], it is to be understood as the syntax defined from [MESSFOR], it is to be understood as the syntax defined
by [MESSFOR] after making the above changes, but NOT including by [MESSFOR] after making the above changes, but NOT including
any syntax defined in section 4 ("Obsolete syntax") of any syntax defined in section 4 ("Obsolete syntax") of
[MESSFOR]. Software compliant with this standard MUST NOT [MESSFOR]. Software compliant with this standard MUST NOT
generate any of the syntactic forms defined in that Obsolete generate any of the syntactic forms defined in that Obsolete
Syntax, although it MAY accept such syntactic forms. Certain Syntax, although it MAY accept such syntactic forms. Certain
syntax from the MIME specifications [RFC2045 et seq] is also syntax from the MIME specifications [RFC2045 et seq] is also
considered a part of this Standard (see ...). considered a part of this Standard (see ...).
The following syntactic forms, taken from [RFC2234] or from The following syntactic forms, taken from [RFC2234] or from
[MESSFOR], are repeated here for convenience only: [MESSFOR], are repeated here for convenience only:
ALPHA = %x41-%x5A / ; A-Z ALPHA = %x41-5A / ; A-Z
%x61-%x7A ; a-z %x61-7A ; a-z
CR = %x0D ; carriage return CR = %x0D ; carriage return
CRLF = CR LF CRLF = CR LF
DIGIT = %x30-%x39 ; 0-9 DIGIT = %x30-39 ; 0-9
HTAB = %x09 ; horizontal tab HTAB = %x09 ; horizontal tab
LF = %x0A ; line feed LF = %x0A ; line feed
SP = %x20 ; space SP = %x20 ; space
NO-WS-CTL = %d1-%d8 / ; US-ASCII control characters NO-WS-CTL = %d1-8 / ; US-ASCII control characters
%d11 / ; which do not include the %d11 / ; which do not include the
%d12 / ; carriage return, line feed, %d12 / ; carriage return, line feed,
%d14-%d41 / ; and whitespace characters %d14-41 / ; and whitespace characters
%d127 %d127
WSP = SP / HTAB ; Whitespace characters WSP = SP / HTAB ; Whitespace characters
FWS = ([*WSP CRLF] 1*WSP) ; Folding whitespace FWS = ([*WSP CRLF] 1*WSP) ; Folding whitespace
comment = "(" *([FWS] (ctext / quoted-pair / comment)) comment = "(" *([FWS] (ctext / quoted-pair / comment))
[FWS] ")" [FWS] ")"
CFWS = *([FWS] comment) (([FWS] comment) / FWS ) CFWS = *([FWS] comment) (([FWS] comment) / FWS )
<"> = %d34 ; quote mark <"> = %d34 ; quote mark
quoted-pair = "\" text quoted-pair = "\" text
quoted-string = *CFWS <"> *(FWS (qtext / quoted-pair)) <"> *CFWS quoted-string = *CFWS <"> *(FWS (qtext / quoted-pair)) <"> *CFWS
unstructured = *( [FWS] text ) unstructured = *( [FWS] text )
skipping to change at line 448 skipping to change at line 589
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.
4.3.2. White Space and Continuations 4.3.2 Header Classes
There are four special classes of headers that may be present
in an article: Experimental, Persistent, Comment, and
Variant. All other headers are ephemeral. These classes are
significant in how newsreaders and servers should treat them
when encountered.
4.3.3 Experimental Headers
Experimental headers are headers which begin with "X-". They
are to be used by newsreaders proposing new headers for some
utility or for comments to be propogated with the article.
There are no established headers that are considered
experimental headers; an established header cannot be
experimental.
Attempts to create new headers that are to be adopted as
standard headers MUST begin their lives as experimental
headers.
4.3.4 Persistent Headers
Persistent headers are headers which begin with "P-" (or
"X-P-", hereafter referred to simply as "P- headers") which
persist across followups either identically or by simple
modification. Headers with this behavior include:
Newsgroups
Content is carried over into all followups. Modified by
content of Followup-To header.
Subject
Content is carried over into all followups. Modified by
prefixing with "Re: " if not already present. Also modified by
user, often with a "(was: )" phrase preserving the previous
content.
References
Content is carried over into all followups. Modified by
appending content of Message-ID header.
NOTE: Though traditionally old newsreaders would treat
Keywords as a persistent header, it is not a persistent
header. More modern newsreaders do not treat it as such.
4.3.5. Variant Headers
Variant Headers are headers that are modified on articles when
they are propogated. Variant headers have a "V-" prefix.
Variant headers may be experimental ("X-V-"), persistent
("P-V-"), or both ("X-P-V-").
4.3.6. Header Classes
There are four special classes of headers that may be present
in an article: Experimental, Persistent, Comment, and
Variant. All other headers are ephemeral. These classes are
significant in how newsreaders and servers should treat them
when encountered.
4.3.6.1 Experimental Headers
Experimental headers are headers which begin with "X-". They
are to be used by newsreaders proposing new headers for some
utility or for comments to be propogated with the article.
There are no established headers that are considered
experimental headers; an established header cannot be
experimental.
Attempts to create new headers that are to be adopted as
standard headers MUST begin their lives as experimental
headers.
4.3.6.2 Persistent Headers
Persistent headers are headers which begin with "P-" (or
"X-P-", hereafter referred to simply as "P- headers") which
persist across followups either identically or by simple
modification. Headers with this behavior include:
Newsgroups
Content is carried over into all followups. Modified by
content of Followup-To header.
Subject
Content is carried over into all followups. Modified by
prefixing with "Re: " if not already present. Also modified by
user, often with a "(was: )" phrase preserving the previous
content.
References
Content is carried over into all followups. Modified by
appending content of Message-ID header.
NOTE: Though traditionally old newsreaders would treat
Keywords as a persistent header, it is not a persistent
header. More modern newsreaders do not treat it as such.
4.3.6.3 Examples
Newsgroups: alt.test
Subject: Persistent Header Example
Message-ID: <001@news.site.example>
P-Author-IDs: <johnsmith-site.example-unique>
User-Agent: experimental/0.1g (P-Author-ID Compliant)
From: jane@site.invalid (Jane Smith)
Newsgroups: alt.test
Followup-To: misc.test
Subject: Re: Persistent Header Example
Message-ID: <002@news.site.example>
References: <001@news.site.example>
P-Author-IDs: <johnsmith-site.example-unique>
User-Agent: modern/1.2 (Author-ID non-Compliant; P- header compliant)
Keywords: persistance, good ideas
From: andrew@isp.invalid
Newsgroups: misc.test
Subject: Further example (was: Re: Persistent Header Example)
Message-ID: <001@news.isp.example>
References: <001@news.site.example> <002@news.site.example>
P-Author-IDs: <johnsmith-site.example-unique> <andrew@isp.example>
User-Agent: codeveloper/2.0b (Author-ID Compliant)
4.3.6.4 Comment Headers
Comment headers are headers that are strictly local and MUST
NOT be propogated outside of a restricted subnet for local
testing purposes. Comment headers have a prefix of "C-". Due
to their limited scope, they MUST NOT be combined with any
other prefix, such as "X-C-" headers. Headers with this
behavior include:
Xref
Used by servers to keep track of crossposted articles' article
numbers in the crossposted-to news groups in the local news
spool as an aid to newsreaders marking such articles as read.
4.3.6.5. Variant Headers
Variant Headers are headers that are modified on articles when
they are propogated. Variant headers have a "V-" prefix.
Variant headers may be experimental ("X-V-"), persistent
("P-V-"), or both ("X-P-V-").
4.3.7. White Space and Continuations
[The following text is taken from [MESSFOR], adapted to the [The following text is taken from [MESSFOR], adapted to the
different terminology used for this standard.] different terminology used for this standard.]
Each header is logically a single line of characters Each header is logically a single line of characters
comprising the header-name, the colon with its following comprising the header-name, the colon with its following
SP, and the header-content. For convenience, however, the SP, and the header-content. For convenience, however, the
header-content can be split into a multiple line header-content can be split into a multiple line
representation; this is called "folding". The general rule is representation; this is called "folding". The general rule is
that wherever this standard allows for FWS (which includes that wherever this standard allows for FWS (which includes
skipping to change at line 507 skipping to change at line 798
white space is desired in headers (some existing software white space is desired in headers (some existing software
expects this), and MUST use SP immediately following the expects this), and MUST use SP immediately following the
colon after a header-name (this was an RFC 1036 requirement). colon after a header-name (this was an RFC 1036 requirement).
Relaying agents SHOULD accept HTAB in all such cases, however. Relaying agents SHOULD accept HTAB in all such cases, however.
Since the white space beginning a continuation line remains a Since the white space beginning a continuation line remains a
part of the logical line, headers can be "broken" into part of the logical line, headers can be "broken" into
multiple lines only at FWS or CFWS. Posting agents SHOULD not multiple lines only at FWS or CFWS. Posting agents SHOULD not
break headers unnecessarily (but see section 4.6). break headers unnecessarily (but see section 4.6).
4.3.3 Comments 4.3.8 Comments
Strings of characters which are treated as comments may be Strings of characters which are treated as comments may be
included in header contents wherever the syntactic element included in header contents wherever the syntactic element
CFWS occurs. They consist of characters enclosed in CFWS occurs. They consist of characters enclosed in
parentheses. Such strings are considered comments so long as parentheses. Such strings are considered comments so long as
they do not appear within a quoted-string. Comments may be they do not appear within a quoted-string. Comments may be
nested. nested.
A comment is normally used to provide some human readable A comment is normally used to provide some human readable
informational text, except at the end of an <address> which informational text, except at the end of an <address> which
skipping to change at line 545 skipping to change at line 836
appear as a quoted-pair. Semantically, the enclosing appear as a quoted-pair. Semantically, the enclosing
parentheses are not part of the comment token; the token is parentheses are not part of the comment token; the token is
what is contained between the two parentheses. what is contained between the two parentheses.
Since comments have not hitherto been permitted in news Since comments have not hitherto been permitted in news
articles, except in a few specified places, posters and articles, except in a few specified places, posters and
posting-agents SHOULD NOT insert them except in those places. posting-agents SHOULD NOT insert them except in those places.
However, compliant software MUST accept them in all places However, compliant software MUST accept them in all places
where they are syntactically allowed. where they are syntactically allowed.
4.3.4. Undesirable Headers 4.3.9. Undesirable Headers
A header whose content is empty is said to be an empty header. A header whose content is empty is said to be an empty header.
Relaying and reading agents SHOULD NOT consider presence or Relaying and reading agents SHOULD NOT consider presence or
absence of an empty header to alter the semantics of an absence of an empty header to alter the semantics of an
article (although syntactic rules, such as requirements that article (although syntactic rules, such as requirements that
certain header names appear at most once in an article, MUST certain header names appear at most once in an article, MUST
still be satisfied). Posting and injecting agents SHOULD still be satisfied). Posting and injecting agents SHOULD
delete empty headers from articles before posting them; delete empty headers from articles before posting them;
relaying agents MUST pass them untouched. relaying agents MUST pass them untouched.
skipping to change at line 594 skipping to change at line 885
end with a CRLF. However, relaying agents SHOULD treat the end with a CRLF. However, relaying agents SHOULD treat the
body of an article as an uninterpreted sequence of octets body of an article as an uninterpreted sequence of octets
(except as mandated by changes of CRLF representation and by (except as mandated by changes of CRLF representation and by
control-message processing) and SHOULD avoid imposing control-message processing) and SHOULD avoid imposing
constraints on it. See also section 4.6. constraints on it. See also section 4.6.
4.4.2. Body Conventions 4.4.2. Body Conventions
A body is by default an uninterpreted sequence of octets for A body is by default an uninterpreted sequence of octets for
most of the purposes of this standard. However, a MIME most of the purposes of this standard. However, a MIME
Content-Type header may impose some srtucture or intended Content-Type header may impose some structure or intended
interpretation upon it, and may also specify the character set interpretation upon it, and may also specify the character set
in accordance with which the octets are to be interpreted. in accordance with which the octets are to be interpreted.
NOTE: The syntax does not permit the NUL octet to appear in a NOTE: The syntax does not permit the NUL octet to appear in a
body, and the octets CR and LF MUST ONLY occur together as body, and the octets CR and LF MUST ONLY occur together as
CRLF. See also section 4.6 for limits on the length of a CRLF. See also section 4.6 for limits on the length of a
line. line.
It is a common practice for followup agents to enable the It is a common practice for followup agents to enable the
incorporation of the followed-up article (the "precursor") incorporation of the followed-up article (the "precursor")
skipping to change at line 694 skipping to change at line 985
NOTE: This strategy will do little harm. The target relaying NOTE: This strategy will do little harm. The target relaying
agent is unlikely to be able to make use of the article on its agent is unlikely to be able to make use of the article on its
own servers, and the usual flooding algorithm will likely find own servers, and the usual flooding algorithm will likely find
some alternative route to get the article to destinations some alternative route to get the article to destinations
where it is needed. where it is needed.
4.5.1. Character Sets within Article Headers 4.5.1. Character Sets within Article Headers
Within article headers, the CES is UTF-8 [ISO-10646 or Within article headers, the CES is UTF-8 [ISO-10646 or
RFC-2044] and hence the CCS is the Universal Multiple-Octet RFC-2279] and hence the CCS is the Universal Multiple-Octet
Coded Character Set (UCS) [ISO-10646] (which is essentially a Coded Character Set (UCS) [ISO-10646] (which is essentially a
superset of Unicode [UNICODE] and expected to remain so). superset of Unicode [UNICODE] and expected to remain so).
However, interpreting the octets directly as ASCII characters However, interpreting the octets directly as ASCII characters
should ensure correct behaviour in most situations. should ensure correct behaviour in most situations.
NOTE: UTF-8 is an encoding for 16bit (and even 32bit) NOTE: UTF-8 is an encoding for 16bit (and even 32bit)
character sets with the property that any octet less than 128 character sets with the property that any octet less than 128
immediately represents the corresponding ASCII character, thus immediately represents the corresponding ASCII character, thus
ensuring upwards compatibility with previous practice. ensuring upwards compatibility with previous practice.
Non-ASCII characters from UCS are represented by sequences of Non-ASCII characters from UCS are represented by sequences of
octets greater than 127. Only those octet sequences explicitly octets greater than 127. Only those octet sequences explicitly
permitted by [RFC 2044] shall be used. UCS includes all permitted by [RFC 2079] shall be used. UCS includes all
characters from the ISO-8859 series of characters sets characters from the ISO-8859 series of characters sets
[ISO-8859] (which includes all Greek and Arabic characters) as [ISO-8859] (which includes all Greek and Arabic characters) as
well as the more elaborate characters used in Japan and China. well as the more elaborate characters used in Japan and China.
See the following section for the appropriate treatment of UCS See the following section for the appropriate treatment of UCS
characters by reading agents. characters by reading agents.
Notwithstanding the great flexibility permitted by UTF-8, Notwithstanding the great flexibility permitted by UTF-8,
there is need for restraint in its use in order that the there is need for restraint in its use in order that the
essential components of headers may be discerned using essential components of headers may be discerned using
reading agents that cannot present the full UCS range. In reading agents that cannot present the full UCS range. In
skipping to change at line 840 skipping to change at line 1131
size of a single article, but neither does it forbid relaying size of a single article, but neither does it forbid relaying
agents from dropping articles of excessive length. It is, agents from dropping articles of excessive length. It is,
however, suggested that any limits thought appropriate by however, suggested that any limits thought appropriate by
particular agents would be more appropriately expressed in particular agents would be more appropriately expressed in
megabytes than in kilobytes. megabytes than in kilobytes.
4.7. Example 4.7. Example
Here is a sample article: Here is a sample article:
-cut-here--
Path: server.example,unknown.site2.example@site2.example, Path: server.example,unknown.site2.example@site2.example,
relay.site.example,site.example,injector.site.example%jsmith relay.site.example,site.example,injector.site.example%jsmith
Newsgroups: example.announce,example.chat Newsgroups: example.announce,example.chat
Message-ID: <9urrt98y53@site.example> Message-ID: <9urrt98y53@site.example>
From: Ann Example <a.example@site1.example> From: Ann Example <a.example@site1.invalid>
Subject: Announcing a new sample article. Subject: Announcing a new sample article.
Date: Fri, 27 Mar 1998 12:12:50 +1300 Date: Fri, 27 Mar 1998 12:12:50 +1300
Approved: example.announce moderator <jsmith@site.example> Approved: example.announce moderator <jsmith@site.invalid>
Followup-To: example.chat Followup-To: example.chat
Reply-To: Ann Example <a.example+replies@site1.example> Reply-To: Ann Example <a.example+replies@site1.example>
Expires: Wed, 22 Apr 1998 12:12:50 -0700 Expires: Wed, 22 Apr 1998 12:12:50 -0700
Organization: Site1, The Number one site for examples. Organization: Site1, The Number one site for examples.
User-Agent: ExampleNews/3.14 (Unix) User-Agent: ExampleNews/3.14 (Unix)
Keywords: example, announcement, standards, RFC 1036, Usefor Keywords: example, announcement, standards, RFC 1036, Usefor
Summary: The URL for the next standard. Summary: The URL for the next standard.
Just a quick announcemnt that a new standard example article has been Just a quick announcemnt that a new standard example article has been
released; it is in the new USEFOR draft obtainable from ftp.ietf.org. released; it is in the new USEFOR draft obtainable from ftp.ietf.org.
Ann. Ann.
-cut-here-- --
Ann Example <a.example@site1.invalid> Sample Poster to the Stars
"The opinions in this article are bloody good ones" - from J Clarke.
5. Mandatory Headers 5. Mandatory Headers
An article MUST have one, and only one, of each of the An article MUST have one, and only one, of each of the
following headers: Date, From, Message-ID, Subject, following headers: Date, From, Message-ID, Subject,
Newsgroups, Path. Newsgroups, Path.
NOTE: [MAIL] specifies (if read most carefully) that there NOTE: [MAIL] specifies (if read most carefully) that there
must be exactly one Date header and exactly one From header, must be exactly one Date header and exactly one From header,
but otherwise does not restrict multiple appearances of but otherwise does not restrict multiple appearances of
skipping to change at line 889 skipping to change at line 1181
Note also that there are situations, discussed in the Note also that there are situations, discussed in the
relevant parts of section 6, where References, Sender, relevant parts of section 6, where References, Sender,
or Approved headers are mandatory. In control articles, or Approved headers are mandatory. In control articles,
specific values are required for certain headers. specific values are required for certain headers.
In the discussions of the individual headers, the content of In the discussions of the individual headers, the content of
each is specified using the syntax notation. The convention each is specified using the syntax notation. The convention
used is that the content of, for example, the Subject header used is that the content of, for example, the Subject header
is defined as <Subject-content>. is defined as <Subject-content>.
NOTE: see also Section 7.1.1
5.1. Date 5.1. Date
The Date header contains the date and time that the article The Date header contains the date and time that the article
was submitted for transmission. The content syntax is was submitted for transmission. The content syntax is
defined in the Message Format Standard [MESSFOR]. defined in the Message Format Standard [MESSFOR].
Date-content = date-time Date-content = date-time
5.2. From 5.2. From
The From header contains the electronic address(es), and The From header contains the electronic address(es), and
possibly the full name, of the article's author(s) . The possibly the full name, of the article's author(s) . The
format of the From header is defined in the Message Format format of the From header is defined in the Message Format
Standard [MESSFOR]. Standard [MESSFOR].
All mailboxes in the "From: " field MUST either belong to the All mailboxes in the From-content field MUST either belong to the
posters(s) of the article ( or the poster(s) are authorized by posters(s) of the article ( or the poster(s) are authorized by
the owners to use the mailboxes) or end in the top level the owners to use the mailboxes) or end in the top level
domain of ".invalid". Software MAY offer the option to users domain of ".invalid".
of treating articles from ".invalid" addresses differently
from other articles (e.g. "killfiles").
From-content = <address> From-content = mailbox-list
5.2.1 Examples: 5.2.1 Examples:
From: John Smith <jsmith@site.example> From: John Smith <jsmith@site.example>
From: John Smith <jsmith@site.example>, dave@isp.example From: John Smith <jsmith@site.example>, dave@isp.example
From: John Smith <jsmith@site.example>, andrew@isp.example, From: John Smith <jsmith@site.example>, andrew@isp.example,
fred@site2.example fred@site2.example
From: Jan Jones <jan@please_setup_your_software_correctly.invalid>
From: Jan Jones <joe@anonymous.invalid>
From: dave@isp.example (Dave Smith) From: dave@isp.example (Dave Smith)
From: Joe Spamhater <joe@site.removethis.examplei.invalid>
From: Joe Spamhater <joe@null.invalid> NOTE: the last example is in an obsolete syntax.
5.3. Message-ID 5.3. Message-ID
The Message-ID header contains the article's message ID, a The Message-ID header contains the article's message ID, a
unique identifier distinguishing the article from every unique identifier distinguishing the article from every
other article. The format of the Message-ID header is defined other article. The format of the Message-ID header is defined
in the Message Format Standard [MESSFOR] . An article's in the Message Format Standard [MESSFOR] . An article's
message ID MUST be unique and MUST NEVER be reused. message ID MUST be unique and MUST NEVER be reused.
Message-ID-content = msg-id Message-ID-content = msg-id
5.4. Subject 5.4. Subject
The Subject field contains a short string identifying the The Subject field contains a short string identifying the
topic of the message. When used in a followup, the field body topic of the message. When used in a followup, the field body
SHOULD start with the string "Re: " ( a "back reference" ) SHOULD start with the string "Re: " ( a "back reference" )
followed by the contents of the pure-subject of the precursor. followed by the contents of the pure-subject of the precursor.
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 ": " ; "Re: " in case sensitive format back-reference = %x52.65.3A.20 ; which is a case-sensitive
"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 SHOULD 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
skipping to change at line 969 skipping to change at line 1264
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 ".
5.4.1 Examples: 5.4.1 Examples:
In the following examples, please note that only "Re: " is In the following examples, please note that only "Re: " is
mandated by this DRAFT. "was: " is a convention used by many mandated by this DRAFT. "was: " is a convention used by many
humans to signal a change in subject matter. Software should English-speaking posters to signal a change in subject matter.
be able to deduce this information from References. Software should be able to deduce this information from
References.
Subject: Film at 11. Subject: Film at 11.
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)
skipping to change at line 1356 skipping to change at line 1652
Sites are not strictly required to use a standard form for Sites are not strictly required to use a standard form for
their path entry, but if they don't, path lines out of that their path entry, but if they don't, path lines out of that
site get longer due to the adding of the identity. However, site get longer due to the adding of the identity. However,
groups of associated sites wanting a common identity may decide groups of associated sites wanting a common identity may decide
to use that and let the receiver add the specific site. to use that and let the receiver add the specific site.
6. Optional Headers 6. Optional Headers
The headers appearing in this section have established The headers appearing in this section have established
meanings. They MUST be interpreted according to the meanings. They MUST be interpreted according to the
definitions made in this Draft. None of them are required to definitions made in this document. None of them are required to
appear in every article. All of the headers appearing in this appear in every article. All of the headers appearing in this
Draft MUST NOT appear more than once in an article. Headers document MUST NOT appear more than once in an article. Headers
not appearing in this Draft (i.e. X-headers, headers defined not appearing in this document (i.e. X-headers, headers defined
by cooperating subnets) are exempt from this requirement. See by cooperating subnets) are exempt from this requirement. See
"Responsibilities of Agents" for a clear picture. "Responsibilities of Agents" for a clear picture.
6.1 Followup-To 6.1 Followup-To
The Followup-To header contents specify which newsgroup(s) The Followup-To header contents specify which newsgroup(s)
followups should be posted to: followups should be posted to:
Followup-To-content = Newsgroups-content / "poster" Followup-To-content = Newsgroups-content / "poster"
skipping to change at line 1489 skipping to change at line 1785
6.6. Control Messages 6.6. Control Messages
The following sections document the group control messages. The following sections document the group control messages.
"Message" is used herein as a synonym for "article" unless "Message" is used herein as a synonym for "article" unless
context indicates otherwise. Group control messages are a context indicates otherwise. Group control messages are a
special class of control messages, that request the group special class of control messages, that request the group
configuration on a server be updated. configuration on a server be updated.
All of the group control messages MUST have an Approved header All of the group control messages MUST have an Approved header
(section x.x.x). They SHOULD use one of the authentication (section 6.10). They SHOULD use one of the authentication
mechanisms defined in section x.x.x. mechanisms defined in section TBD.
The execution of the actions requested by control messages is The execution of the actions requested by control messages is
subject to local administrative restrictions, which MAY deny subject to local administrative restrictions, which MAY deny
requests or refer them to an administrator for approval. The requests or refer them to an administrator for approval. The
descriptions below are generally phrased in terms suggesting descriptions below are generally phrased in terms suggesting
mandatory actions, but any or all of these MAY be subject to mandatory actions, but any or all of these MAY be subject to
local administrative approval (either as a class or local administrative approval (either as a class or
case-by-case). Analogously, where the description below case-by-case). Analogously, where the description below
specifies that a message or portion thereof is to be ignored, specifies that a message or portion thereof is to be ignored,
this action MAY include reporting it to an administrator. this action MAY include reporting it to an administrator.
skipping to change at line 1586 skipping to change at line 1882
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/newsgroupinfo" 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 ":" %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 ] ] [ 1*SP group-flags ] ]
description = nonblank-text / encoded-word description = nonblank-text / encoded-word
moderation-flags = [ moderated-literal ] moderation-flags = [ moderated-literal ]
moderated-literal = "(" %x4D.6F.64.65.72.61.74.65.64 ")" 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)" group-flags = [ "<" addr-spec ">" 1*SP ] "(Moderated)"
The "application/newsgroupinfo" 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/newsgroupinfo" (section 6.6.1) MIME
structure. structure.
Moderated newsgroups SHOULD be marked by appending the case Moderated newsgroups SHOULD be marked by appending the case
skipping to change at line 1815 skipping to change at line 2111
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/newscheckgroups" 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@foonet.org (foo.all Administrator) From: admin@example.invalid (example.all Administrator)
Newsgroups: biling.admin.groups,biling.admin.announce Newsgroups: example.admin.groups,example.admin.announce
Date: 27 Feb 1997 12:61:22 +14:00 (NST) Date: 27 Feb 1997 12:50:22 +14:00 (EST)
Subject: Group foo.admin.info created. Subject: Group example.admin.info created.
Approved: admin@biling.org Approved: admin@example.invalid
Control: newgroup biling.admin.info moderated Control: newgroup example.admin.info moderated
Message-ID: <newgroup-biling.admin.info-19970227@biling.org> Message-ID: <newgroup-example.admin.info-19970227@example.invalid>
Content-Type: multipart/newsgroupinfo; boundary="nxtprt" Content-Type: multipart/newsgroupinfo; 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/newsgroupinfo
For your newsgroups file: For your newsgroups file:
news.admin.info Information on the news.all 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: biling.admin.info: charter Article-Name: example.admin.info: charter
--nxtlang --nxtlang
Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Content-Language: en Content-Language: en
The group biling.admin.info contains regularly posted information on The group example.admin.info contains regularly posted information on
the biling.* hierarchy. the example.* hierarchy.
--nxtlang --nxtlang
Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
Content-Language: de Content-Language: de
Die Gruppe biling.admin.info enthõlt regelmõ~Kig versandte Die Gruppe example.admin.info enthõlt regelmõ~Kig versandte
Informationen ³ber die biling.*-Hierarchie. Informationen ³ber die example.*-Hierarchie.
--nxtlang-- --nxtlang--
--nxtprt-- --nxtprt--
plain "rmgroup": plain "rmgroup":
From: admin@foonet.org (foo.all Administrator) From: admin@example.invalid (example.all Administrator)
Newsgroups: foo.admin.groups,foo.admin.announce Newsgroups: example.admin.groups, example.admin.announce
Date: 30 Jul 1997 22:04 +02:00 (CEST) Date: 4 Jul 1997 22:04 +02:00 (PST)
Subject: Deletion of foo.admin.obsolete Subject: Deletion of example.admin.obsolete
Message-ID: <rmgroup-foo.admin.obsolete-19970730@foonet.org> Message-ID: <rmgroup-example.admin.obsolete-19970730@example.invalid>
Approved: admin@foonet.org Approved: admin@example.invalid
Control: rmgroup foo.admin.obsolete Control: rmgroup example.admin.obsolete
The group foo.admin.obsolete is obsolete. Please remove it from The group example.admin.obsolete is obsolete. Please remove it from
your system. your system.
plain "mvgroup": plain "mvgroup":
From: admin@foonet.org (foo.all Administrator) From: admin@example.invalid (example.all Administrator)
Newsgroups: foo.admin.groups,foo.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 foo.oldgroup to newgroup Subject: Moving example.oldgroup to example.newgroup
Message-ID: <mvgroup-foo.oldgroup-19970730@foonet.org> Message-ID: <mvgroup-example.oldgroup-19970730@example.invalid>
Approved: admin@foonet.org Approved: admin@example.invalid
Control: mvgroup foo.oldgroup foo.newgroup Control: mvgroup example.oldgroup example.newgroup
Content-Type: multipart/newsgroupinfo; boundary=nxt Content-Type: multipart/newsgroupinfo; boundary=nxt
--nxt --nxt
Content-Type: application/newgroupinfo Content-Type: application/newgroupinfo
For your newsgroups file: For your newsgroups file:
foo.newgroup The new replacement group. example.newgroup The new replacement group.
--nxt --nxt
The group foo.oldgroup is replaced by foo.newgroup. The group example.oldgroup is replaced by example.newgroup.
Please update your configuration. Please update your configuration.
--nxt-- --nxt--
more complex "mvgroup" for a whole hierarchy: more complex "mvgroup" for a whole hierarchy:
The charter of the group foo.talk.jokes contained a reference to The charter of the group example.talk.jokes contained a reference to
foo.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@foonet.org (foo.all Administrator) From: admin@example.invalid (example.all Administrator)
Newsgroups: foo.admin.groups,foo.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 (PST)
Subject: Deletion of foo.admin.obsolete Subject: Deletion of example.admin.obsolete
Message-ID: <mvgroup-foo.talk-19970730@foonet.org> Message-ID: <mvgroup-example.talk-19970730@example.invalid>
Approved: admin@foonet.org Approved: admin@example.invalid
Control: mvgroup foo.talk.* foo.conversation Control: mvgroup example.talk.* example.conversation
Content-Type: multipart/newsgroupinfo; boundary=nxt; chartas=1 Content-Type: multipart/newsgroupinfo; boundary=nxt; chartas=1
--nxt --nxt
Content-Type: application/newgroupinfo Content-Type: application/newgroupinfo
For your newsgroups file: For your newsgroups file:
foo.conversation.boring Boring conversations. example.conversation.boring Boring conversations.
foo.conversation.interesting Interesting conversations. example.conversation.interesting Interesting conversations.
foo.conversation.jokes Jokes and funny stuff. example.conversation.jokes Jokes and funny stuff.
foo.conversation.jokes.d Discussion about de.conversation.jokes. example.conversation.jokes.d Discussion about example.conversation.jokes.
Article-Name: foo.conversation.jokes: charter Article-Name: example.conversation.jokes: charter
This group is to publish jokes and other funny stuff. This group is to publish jokes and other funny stuff.
Discussions about the articles posted here should be redirected Discussions about the articles posted here should be redirected
to foo.conversation.jokes.d; adding a Followup-to: header to example.conversation.jokes.d; adding a Followup-to: header
is recommended. is recommended.
--nxt-- --nxt--
6.6.6 Cancel 6.6.6 Cancel
The cancel message requests that one or more target articles be The cancel message requests that one or more target articles be
"canceled" ie be withdrawn from circulation or access. This "canceled" ie be withdrawn from circulation or access. This
message MAY be issued by entities which processed the target message MAY be issued by entities which processed the target
article(s) while it was still a proto-article (ie posters, article(s) while it was still a proto-article (ie posters,
posting agents, moderators and injecting agent. See also posting agents, moderators and injecting agent. See also
skipping to change at line 2109 skipping to change at line 2405
approving the article for posting: approving the article for posting:
Approved-content = From-content Approved-content = From-content
An Approved header is required in all postings to moderated An Approved header is required in all postings to moderated
newsgroups. If this header is not present then relaying and newsgroups. If this header is not present then relaying and
serving agents MUST reject the article. serving agents MUST reject the article.
An Approved header is also required in certain control An Approved header is also required in certain control
messages, to reduce the probability of accidental posting of messages, to reduce the probability of accidental posting of
same; see the relevant parts of section 6. same; see the relevant parts of section 6.6.
Please see section [6.6] on how injecting agents should treat Please see section 7.1 on how injecting agents should treat
posts to moderated groups that do not contain this header. posts to moderated groups that do not contain this header.
6.11 Lines 6.11 Lines
The Lines header content indicates the number of lines in the The Lines header content indicates the number of lines in the
body of the article: body of the article:
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, Reading agents SHOULD NOT rely on the presence of this header,
since it is optional (and some posting agents do not supply since it is optional (and some posting agents do not supply
it). They MUST not rely on it being precise, since it it). They MUST NOT rely on it being precise, since it
frequently is not. 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
skipping to change at line 2179 skipping to change at line 2475
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) it SHOULD not be included in of the authors physical location) posters are discouraged from
the article. 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.
skipping to change at line 2218 skipping to change at line 2514
User-Agent = "User-Agent:" SP User-Agent-content User-Agent = "User-Agent:" SP User-Agent-content
User-Agent-content = product *(CFWS product) [CFWS] User-Agent-content = product *(CFWS product) [CFWS]
At least one product MUST be present. The first token MUST NOT At least one product MUST be present. The first token MUST NOT
be a comment. Comments relate to the previously named product, be a comment. Comments relate to the previously named product,
not the product following it. not the product following it.
product = token ["/" product-version] product-version = token product = token ["/" product-version] product-version = token
Product tokens should be short and to the point -- they MUST Product tokens should be short and to the point -- they MUST
NOT be used for advertising beyond the canonical name of the NOT be used for information beyond the canonical name of the
product or other non-essential information. Although any token product and it's version. Although any token character MAY
character MAY appear in a product-version, this token SHOULD appear in a product-version, this token SHOULD be used only
be used only for a version identifier (i.e., successive for a version identifier (i.e., successive versions of the
versions of the same product SHOULD differ only in the same product SHOULD differ only in the product-version portion
product-version portion of the product value). Product tokens of the product value). Product tokens MUST identify products.
MUST identify products.
NOTE: Variations from RFC 1945: NOTE: Variations from RFC 1945:
1. product token is required and MUST be first, 1. product token is required and MUST be first,
2. use of other text in the syntactic usage of the product 2. use of other text in the syntactic usage of the product
token which is not a token is forbidden, token which is not a token is forbidden,
3. comment allows quoted-pair, 3. comment allows quoted-pair,
4. "{" and "}" are allowed in token (product and 4. "{" and "}" are allowed in token (product and
product-version) in news, product-version) in news,
5. octets from character sets other than ASCII are allowed. 5. octets from character sets other than ASCII are allowed.
NOTE: Comments should be restricted to information regarding NOTE: Comments should be restricted to information regarding
the product named to their left such as platform information the product named to their left such as platform information
and should be concise. It must not be used as an advertising and should be concise. Use as an advertising medium (in the
medium (in the mundane sense) by agents. mundane sense) is discouraged.
Recipients of header field TEXT containing octets outside the Recipients of header field TEXT containing octets outside the
US-ASCII character set may assume that they represent UTF-8 US-ASCII character set may assume that they represent UTF-8
characters. characters.
NOTE: Variation from RFC 1945: UTF-8 replaced ISO-8859-1 as NOTE: Variation from RFC 1945: UTF-8 replaced ISO-8859-1 as
charset assumption. charset assumption.
6.14.1 Examples: 6.14.1 Examples:
skipping to change at line 2298 skipping to change at line 2593
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
Draft. 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 2045]
skipping to change at line 2503 skipping to change at line 2798
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. Until Multi-Super-Date, software SHOULD generate
Supersedes with only one Message-ID, and cancel control Supersedes with only one Message-ID, and cancel control
messages SHOULD be issued if needed for other IDs. messages SHOULD be issued if needed for other IDs.
The first message-id is called the immediate "predecessor" and
other IDs are predecessors to it, in a chain. The new article
is the "successor." Additional IDs beyond the immediate
predecessor SHOULD be added to the list if their successor was
posted less than 2 days after their own posting date. If older
than that their addition is optional. These additional IDs
act as an advisory that these messages were replaced or
superseded, when their actual immediate successor may never
have arrived.
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
part of the course of normal newsreading, and is in fact part of the course of normal newsreading, and is in fact
discouraged. In addition, since articles MAY be updated to discouraged.
comply with laws (copyright violation, libel etc.) there may
be legal implications in providing access to predecessors.
Systems MAY treate Replaces as a synonym for Supersedes, if Systems MAY treat Replaces as a synonym for Supersedes, if
they do not implement the semantics of Replaces. they do not implement the semantics of Replaces.
If the header is "Supersedes" then the old articles SHOULD If the header is "Supersedes" then the old articles SHOULD
simply be deleted, as in a cancel, and the new article simply be deleted, as in a cancel, and the new article
inserted into the system like any new article. inserted into the system like any new article.
Attempts to fetch a replaced or superseded article either by Attempts to fetch a replaced or superseded article either by
number or by Message-ID SHOULD retrieve instead the most number or by Message-ID SHOULD retrieve instead the most
recent successor. Some indication that a newer version than recent successor. Some indication that a newer version than
was asked for has been delivered MAY be provided. It is was asked for has been delivered MAY be provided. It is
particularly encouraged that NNTP servers implement delivery particularly encouraged that NNTP servers implement delivery
of successor upon requests by message-IDs so that WWW "news:" of successor upon requests by message-IDs so that WWW "news:"
and "msg:" URLs continue to work even when an article has a and "msg:" URLs continue to work even when an article has a
successor. successor.
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.
Note that a Replaces or Supersedes MAY change any aspect of an
article, including the Newsgroups line. If a successor is not
in a newsgroup of its predecessor, then the predecessor should
simply be cancelled in that newsgroup, with no pointer to the
successor associated with it for any fetch by newsgroup and
article-number. While a system MAY be smart about multiple
replacements that restore an article back to a group, this is
not a requirement.
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.15.1 Message-ID version numbers chain procedure.
NOTE: Sections 6.15.1 - 6.15.4 may be published as a separate
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>.
Example: Message-ID <foo%v=3@site.com> is replaced by
<foo%v=4@site.com>. Example:
Message-ID <foo%v=3@example.invalid> is replaced by
<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. Example: the Local-Part to generate the successor Message-ID.
Message-ID <foo@site.com> is replaced by <foo%v=1@site.com>.
Example:
Message-ID <foo@example.invalid> is replaced by
<foo%v=1@example.invalid>.
6.15.2 Implementation and Use Note 6.15.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
skipping to change at line 2626 skipping to change at line 2908
Systems maintaining pointers from predecessors to successors Systems maintaining pointers from predecessors to 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.15.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: <groupname-faq@faqsite.com>. The next version, a week form: <examplegroup-faq@example.invalid>. The next version, a week
later, has: later, has:
Message-ID: <groupname-faq%v=1@faqsite.com> Message-ID: <examplegroup-faq%v=1@example.invalid>
Supersedes: <groupname-faq@faqsite.com> Supersedes: <examplegroup-faq@example.invalid>
The next one, another week later has: The next one, another week later has:
Message-ID: <groupname-faq%v=2@faqsite.com> Message-ID: <examplegroup-faq%v=2@example.invalid>
Supersedes: <groupname-faq%v=1@faqsite.com> <groupname-faq@faqsite.com> Supersedes: <examplegroup-faq%v=1@example.invalid>
<examplegroup-faq@faqsite.com>
The next one, another week later has: The next one, another week later has:
Message-ID: <groupname-faq%v=3@faqsite.com> Message-ID: <examplegroup-faq%v=3@example.invalid>
Supersedes: <groupname-faq%v=2@faqsite.com> <groupname-faq@faqsite.com> Supersedes: <examplegroup-faq%v=2@example.invalid>
<examplegroup-faq@example.invalid>
Note that the long spacing between issues means the Note that the long spacing between issues means the
multi-entry Supersedes is there primarily to preserve pointer multi-entry Supersedes is there primarily to preserve pointer
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.15.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@mysite.com> Message-ID: <myuniquepart%v=1@example.invalid>
Replaces: <myuniquepart@mysite.com> 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@mysite.com> Message-ID: <myuniquepart%v=2@example.invalid>
Replaces: <myuniquepart%v=1@mysite.com> <myuniquepart@mysite.com> Replaces: <myuniquepart%v=1@example.invalid>
<myuniquepart@example.invalid>
The two bad versions will be replaced with the 3rd, even if a The two bad versions will be replaced with the 3rd, even if a
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@mysite.com> Replaced-by: Control: cancel <myuniquepart@example.invalid> Replaced-by:
<myuniquepart%v=2@mysite.com> <myuniquepart%v=2@example.invalid>
6.15.6 Dates 6.15.6 Dates
Multi-Super-Date ... in one year. (1036-spencer required Multi-Super-Date ... in one year. (1036-spencer required
multiple-ID supersedes, so by now just about everybody should multiple-ID supersedes, so by now just about everybody should
already support it, is this true?) "Replaces" active -- already support it, is this true?) "Replaces" active --
whatever date we are putting for general compliance with this whatever date we are putting for general compliance with this
spec by news database systems. spec by news database systems.
6.15.7 Issues 6.15.7 Issues
skipping to change at line 2702 skipping to change at line 2987
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. Obsolete Headers 6.16 Archive
This optional header is a signal to automatic archival agents
on whether this article is available for long-term storage.
Agents which see "Archive: no" MUST NOT keep the article past
the Expires date. Any other text indicates conditions that an
agent SHOULD follow in order to archive the article.
Archive-content = "no" | CFWS
6.17. 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 2734 skipping to change at line 3029
An injection agent is responsible for taking a proto-article An injection agent is responsible for taking a proto-article
from a posting agent and either forwarding it to a moderator from a posting agent and either forwarding it to a moderator
of injecting it into the relaying system for access by of injecting it into the relaying system for access by
readers. readers.
As such a Injecting Agent is considered responsible for As such a Injecting Agent is considered responsible for
ensuring that any article it injects conform with the policies ensuring that any article it injects conform with the policies
and rules of this document and any newsgroups that an article and rules of this document and any newsgroups that an article
is posted to. is posted to.
To this end injection agenst MAY cancel articles which they To this end injection agents MAY cancel articles which they
have previously injected. have previously injected.
7.1.1 Proto-articles. 7.1.1 Proto-articles.
A proto-article is one that is created by a posting agent and A proto-article is one that is created by a posting agent and
has not been injected into the news system by an injecting has not been injected into the news system by an injecting
agent. Only one copy of a proto-article MUST exist. A agent. Only one copy of a proto-article MUST exist. A
proto-article has the same format as a normal article except proto-article has the same format as a normal article except
that some of the compulsory headers MAY be missing. A that some of the compulsory headers MAY be missing. A
proto-injected article MAY have the following headers missing: proto-injected article MAY have the following headers missing:
skipping to change at line 2942 skipping to change at line 3237
such is bound by all the Posting Agent's requirements plus such is bound by all the Posting Agent's requirements plus
additional ones. Followup Agents MUST create valid followups, additional ones. Followup Agents MUST create valid followups,
Followups have additional requirements from normal articles Followups have additional requirements from normal articles
for the syntax of the References and Subject headers and the for the syntax of the References and Subject headers and the
body format. body format.
Followup Agents MUST by default follow the FollowUp-To header Followup Agents MUST by default follow the FollowUp-To header
when deciding which newsgroups a followup is posted to, when deciding which newsgroups a followup is posted to,
however the poster MAY override the default if they wish. however the poster MAY override the default if they wish.
Followup Agents MUST NOT attempt to send email to any address
ending in ".invalid".
Followup Agents SHOULD NOT email copies of the followup to the Followup Agents SHOULD NOT email copies of the followup to the
author of the precursor (or any other person) unless this has author of the precursor (or any other person) unless this has
been explicitly requested. been explicitly requested.
7.6 Duties of a Gateway 7.6 Duties of a Gateway
NOT DONE NOT DONE
8. Propagation and Processing 8. Propagation and Processing
skipping to change at line 3019 skipping to change at line 3317
"forge" an email address, that is, to use a valid email address "forge" an email address, that is, to use a valid email address
which you are not entitled to use. All invalid email addresses which you are not entitled to use. All invalid email addresses
used in headers MUST end in the ".invalid" top-level-domain. used in headers MUST end in the ".invalid" top-level-domain.
This facility is provided primarily for those who wish to remain This facility is provided primarily for those who wish to remain
anonymous, but do not care to take the additional precautions of anonymous, but do not care to take the additional precautions of
using more sophisticated anonymity measures. using more sophisticated anonymity measures.
It is possible that legal penalties may apply to sending It is possible that legal penalties may apply to sending
unsolicited commercial email and/or news articles. Check with unsolicited commercial email and/or news articles. Check with
your local legal authorities. your local legal authorities.
--
10. Security Considerations 10. Security Considerations
Section 9 discusses security considerations. Section 9 discusses security considerations.
11. References: 11. References:
Originator-Info Message Header: [TEST-TLDS]
draft-newman-msgheader-originfo-x.txt Eastlake, D. ; Panitz A. Reserved Top Level DNS Names,
chris.newman@innosoft.com draft-ietf-dnsind-test-tlds-xx.txt, May 1998
[ANSI-X3.4] US-ASCII [ANSI-X3.4] US-ASCII
American National Standard for Information Systems - Coded American National Standard for Information Systems - Coded
Character Sets - 7-Bit American National Standard Code for Character Sets - 7-Bit American National Standard Code for
Information Interchange (7-Bit ASCII). ANSI X3.4, 1986. Information Interchange (7-Bit ASCII). ANSI X3.4, 1986.
[ISO-8859] [ISO-8859]
International Standard - Information Processing - 8-bit International Standard - Information Processing - 8-bit
Single-Byte Coded Graphic Character Sets - Part 1: Latin Single-Byte Coded Graphic Character Sets - Part 1: Latin
alphabet No. 1, ISO 8859-1, 1987. Part 2: Latin alphabet alphabet No. 1, ISO 8859-1, 1987. Part 2: Latin alphabet
skipping to change at line 3058 skipping to change at line 3355
[ISO-10646] [ISO-10646]
International Standard - Information technology - International Standard - Information technology -
Universal Multiple-Octet Coded Character Set (UCS) - Part Universal Multiple-Octet Coded Character Set (UCS) - Part
1: Architecture and Basic Multilingual Plane. ISO/IEC 1: Architecture and Basic Multilingual Plane. ISO/IEC
10646-1, 1993. 10646-1, 1993.
[MESSFOR] [MESSFOR]
[Originator-Info] [Originator-Info]
draft-newman-msgheader-originfo-x.txt
chris.newman@innosoft.com
[RFC-822] e-mail message format [RFC-822] e-mail message format
Crocker, David H.: Standard for the format of ARPA Crocker, David H.: Standard for the format of ARPA
Internet text messages. RFC 822, 1982-08-13. Internet text messages. RFC 822, 1982-08-13.
[RFC-850] netnews message format (obsolete) [RFC-850] netnews message format (obsolete)
Horton, Mark R.: Standard for interchange of Usenet Horton, Mark R.: Standard for interchange of Usenet
messages. RFC 850, 1983-06. messages. RFC 850, 1983-06.
[RFC-976] UUCP mail interchange [RFC-976] UUCP mail interchange
skipping to change at line 3121 skipping to change at line 3420
[RFC-2279] UTF-8 [RFC-2279] UTF-8
Yergeau, Francois: UTF-8, a transformation format of ISO Yergeau, Francois: UTF-8, a transformation format of ISO
10646. RFC 2279, 1998-01. 10646. RFC 2279, 1998-01.
[UNICODE] Unicode [UNICODE] Unicode
The Unicode Consortium: The Unicode Standard - Version 2.0. The Unicode Consortium: The Unicode Standard - Version 2.0.
Addison-Wesley, 1996. Addison-Wesley, 1996.
Author's Address Author's Address
The Usenet Format Working Group usenet-format@clari.net The Usenet Format Working Group (usenet-format@clari.net)
Deliberations were archived at Deliberations were archived at
http://www.landfield.com/usefor/ http://www.landfield.com/usefor/
Chair: Simon Lyall, simon@darkmere.gen.nz Editor: Chair: Simon Lyall, simon@darkmere.gen.nz
Dan Ritter, dsr@bbn.com Editor: Dan Ritter, dsr@bbn.com
Members (alphabetical): Members (alphabetical):
A. Deckers (Alain.Deckers@man.ac.uk) A. Deckers (Alain.Deckers@man.ac.uk)
Ade Lovett (ade@demon.net) Ade Lovett (ade@demon.net)
Andrew Gierth (andrew@erlenstar.demon.co.uk) Andrew Gierth (andrew@erlenstar.demon.co.uk)
Bill Davidsen (davidsen@prodigy.com) Bill Davidsen (davidsen@prodigy.com)
Bill McQuillan (mcquillan@mpa15ab.mv.unisys.com) Bill McQuillan (mcquillan@mpa15ab.mv.unisys.com)
Brad Templeton (brad@clari.net) Brad Templeton (brad@clari.net)
Brian Hernacki (bhern@netscape.com) Brian Hernacki (bhern@netscape.com)
Brian Kelly (bkelly@sulaco.com) Brian Kelly (bkelly@sulaco.com)
Bryan Ford (baford@sleepless.com) Bryan Ford (baford@sleepless.com)
Buddha Buck (bmbuck@acsu.buffalo.edu) Buddha Buck (bmbuck@acsu.buffalo.edu)
Charles Lindsey (chl@clw.cs.man.ac.uk) Charles Lindsey (chl@clw.cs.man.ac.uk)
Chris Newman (chris+ietf-usenet@iosoft.com)
Chris Newman (chris+ietf-usenet@innosoft.com)
Christian Weisgerber (naddy@mips.rhein-neckar.de) Christian Weisgerber (naddy@mips.rhein-neckar.de)
Christopher Sedore (cmsedore@maxwell.syr.edu) Christopher Sedore (cmsedore@maxwell.syr.edu)
Claus Andre Farber (lists/usenet-format/clari.net@faerber.muc.de) Claus Andre Farber (lists/usenet-format/clari.net@faerber.muc.de)
Clive D.W. Feather (clive@demon.net) Clive D.W. Feather (clive@demon.net)
Curt Welch (curt@kcwc.com) Curt Welch (curt@kcwc.com)
D. J. Bernstein (djb@koobera.math.uic.edu) D. J. Bernstein (djb@koobera.math.uic.edu)
Dave Barr (barr@math.psu.edu) Dave Barr (barr@math.psu.edu)
Dave Hayes (dave@kachina.jetcafe.org) Dave Hayes (dave@kachina.jetcafe.org)
Dave Mack (dmack@corp.webtv.net) Dave Mack (dmack@corp.webtv.net)
David C Lawrence (tale@isc.org) David C Lawrence (tale@isc.org)
David desJardins (desj@rt.com) David desJardins (desj@rt.com)
Denis McKeon (DMckeon@swcp.com) Denis McKeon (DMckeon@swcp.com)
Dirk Nimmich (dirk@roxel.ms.sub.org) Dirk Nimmich (dirk@roxel.ms.sub.org)
Doug Royer [N6AAW] (dougr@basilisk.Eng.Sun.COM) Doug Royer [N6AAW] (dougr@basilisk.Eng.Sun.COM)
Egil Kvaleberg (egil@kvaleberg.no) Egil Kvaleberg (egil@kvaleberg.no)
Eivind Tagseth (eivindt@multinet.no) Eivind Tagseth (eivindt@multinet.no)
Erik van der Poel (erik@netscape.com) Erik van der Poel (erik@netscape.com)
Erland Sommarskog (sommar@algonet.se) Erland Sommarskog (sommar@algonet.se)
Evan Champion (evanc@synapse.net) Evan Champion (evanc@synapse.net)
Fergus Henderson (fjh@cs.mu.oz.au) Fergus Henderson (fjh@cs.mu.oz.au)
Frederic SENIS (fs@caduceus.frmug.org) Frederic SENIS (fs@caduceus.frmug.org)
Fredric Logren (Fredric.Lonngren@uab.ericsson.se)
Fredric Lonngren (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)
Jacob Palme (jpalme@dsv.su.se)
Jamie Zawinski (jwz@netscape.com)
John Moreno (phenix@interpath.com) John Moreno (phenix@interpath.com)
John Stanley (stanley@oce.orst.edu) John Stanley (stanley@oce.orst.edu)
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 Henningsen (kai@khms.westfalen.de)
Karl Kleinpaste (karl@jprc.com) Karl Kleinpaste (karl@jprc.com)
Keeth Herron (kherron@campus.mci.net)
Kenneth 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)
Mark Sidell (Mark.Sidell@forteinc.com) Mark Sidell (Mark.Sidell@forteinc.com)
Martin Forssen (maf@math.chalmers.se) Martin Forssen (maf@math.chalmers.se)
Martin J. Duerst (mduerst@ifi.unizh.ch) Martin J. Duerst (mduerst@ifi.unizh.ch)
Maurizio Codogno (mau@beatles.cselt.it) Maurizio Codogno (mau@beatles.cselt.it)
Mick Brown (Mick.Brown@worldnet.att.net) Mick Brown (Mick.Brown@worldnet.att.net)
Mustafa Soysal MS57 (msoysal@mistik.express.net) Mustafa Soysal MS57 (msoysal@mistik.express.net)
Oo Hovers (onno@surfer.xs4all.nl)
Onno Hovers (onno@surfer.xs4all.nl)
Paul Eggert (eggert@twinsun.com) Paul Eggert (eggert@twinsun.com)
Paul Overell (richard@pillar.turnpike.com) Paul Overell (richard@pillar.turnpike.com)
Per Abrahamsen (abraham@dina.kvl.dk) Per Abrahamsen (abraham@dina.kvl.dk)
Pete Resnick (presnick@qualcomm.com) Pete Resnick (presnick@qualcomm.com)
Peter =?ISO-8859-1?Q?Br=FClls?= (pb@Ecce-Terram.DE) Peter =?ISO-8859-1?Q?Br=FClls?= (pb@Ecce-Terram.DE)
Peter Heirich (peter@heirich.in-berlin.de) Peter Heirich (peter@heirich.in-berlin.de)
Ralph Babel <rbabel@babylon.pfm-mainz.de> Ralph Babel <rbabel@babylon.pfm-mainz.de>
Richard Clayton (richard@pillar.turnpike.com) Richard Clayton (richard@pillar.turnpike.com)
Robert Elz (kre@muari.OZ.AU)
Robert Elz (kre@munnari.OZ.AU)
Russ Allbery (rra@stanford.edu) Russ Allbery (rra@stanford.edu)
R. Kelley Cook (kcook@ibm.net)
Seth Breidbart (sethb@panix.com) Seth Breidbart (sethb@panix.com)
Shmuel Metz (shmuel@os2bbs.com) Shmuel Metz (shmuel@os2bbs.com)
Simon Fraser (smfr@santafe.edu) Simon Fraser (smfr@santafe.edu)
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-bonn.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 19981101 Expires 19990101
 End of changes. 

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