draft-ietf-usefor-usefor-02.txt   draft-ietf-usefor-usefor-03.txt 
Usenet Format Working Group K. Murchison, Ed. Usenet Format Working Group K. Murchison, Ed.
Internet-Draft Oceana Matrix Ltd. Internet-Draft Oceana Matrix Ltd.
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 (if approved) C. Lindsey
Expires: May 24, 2005 University of Manchester Expires: October 8, 2005 University of Manchester
D. Kohn D. Kohn
Skymoon Ventures Skymoon Ventures
November 23, 2004 April 6, 2005
News Article Format News Article Format
draft-ietf-usefor-usefor-02.txt draft-ietf-usefor-usefor-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 24, 2005. This Internet-Draft will expire on October 8, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies the syntax of network news (Netnews) articles This document specifies the syntax of network news (Netnews) articles
in the context of the "Internet Message Format" (RFC 2822) and in the context of the "Internet Message Format" (RFC 2822) and
"Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This
document supersedes RFC 1036, updating it to reflect current practice document supersedes RFC 1036, updating it to reflect current practice
and incorporating incremental changes specified in other documents. and incorporating incremental changes specified in other documents.
Changes since draft-ietf-usefor-usefor-02
o Changed to RFC 3978 boilerplate (xml2rfc v1.29)
o Changed "network news" to "Netnews" throughout.
o Prohibit NO-WS-CTL in msg-id-core.
o Complaints-To header is now an Injection-Info parameter.
o Added descriptions of Injection-Info parameters.
o Removed "filename" parameter from Archive header.
o Added CFWS to User-Agent header.
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-01 Changes since draft-ietf-usefor-usefor-01
o Removed half-hearted discussion of internal format and 8-bit clean o Removed half-hearted discussion of internal format and 8-bit clean
transport. transport.
o Added definitions of "proto-article", "posting agent", "followup", o Added definitions of "proto-article", "posting agent", "followup",
"followup-agent", "user-agent", and "injecting agent". "followup-agent", "user-agent", and "injecting agent".
o Removed discussion of message/partial MIME messages. o Removed discussion of message/partial MIME messages.
o Noted that the header contents in every line MUST NOT be empty. o Noted that the header contents in every line MUST NOT be empty.
o Merged MIME sections. o Merged MIME sections.
o Only allow "UT and "GMT" in Date header; disallow all other
<obs-zone>. o Only allow "UT and "GMT" in Date header; disallow all other <obs-
zone>.
o Used Charles' ABNF for <msg-id> and <unstructured>. o Used Charles' ABNF for <msg-id> and <unstructured>.
o Removed restrictions on length and start character for Newsgroups. o Removed restrictions on length and start character for Newsgroups.
o More verbose description of Path header. o More verbose description of Path header.
o Disallowed comments in Control header. o Disallowed comments in Control header.
o Specified that <control-message> is a verb optionally followed by o Specified that <control-message> is a verb optionally followed by
whitespace-separated arguments. whitespace-separated arguments.
o Noted that Supersedes header is different from [Son-of-1036]. o Noted that Supersedes header is different from [Son-of-1036].
o More exact ABNF for Archive and Injection-Info parameters. o More exact ABNF for Archive and Injection-Info parameters.
o Discussed meaning of "yes", "no", and "filename" in Archive
header. o Discussed meaning of "yes", "no" in Archive header.
o Added "Obsolete Headers" section. o Added "Obsolete Headers" section.
o Miscellaneous editorial changes o Miscellaneous editorial changes
Changes since draft-kohn-news-article-03 Changes since draft-kohn-news-article-03
o Document is now a work product of USEFOR o Document is now a work product of USEFOR
o Added new co-authors o Added new co-authors
o Added some definitions from draft-ietf-usefor-article-13 o Added some definitions from draft-ietf-usefor-article-13
o Removed discussion of message/partial MIME messages. o Removed discussion of message/partial MIME messages.
o Removed text that belongs in [USEPRO] o Removed text that belongs in [USEPRO]
o Reorganized header sections o Reorganized header sections
o Added Archive, User-Agent, Injection-Date, and Injection-Info o Added Archive, User-Agent, Injection-Date, and Injection-Info
headers. headers.
o Used Charles' ABNF for <msg-id> and <unstructured>. o Used Charles' ABNF for <msg-id> and <unstructured>.
o Removed restrictions on length and start character for Newsgroups. o Removed restrictions on length and start character for Newsgroups.
o Added required SP to ABNF of header definitions. o Added required SP to ABNF of header definitions.
o Disallowed comments in Control header. o Disallowed comments in Control header.
o Xref header allows for non-digit "locations". o Xref header allows for non-digit "locations".
o Only allow for a single message-id in Supersedes header. o Only allow for a single message-id in Supersedes header.
o Changes to the References header. o Changes to the References header.
o Compatibility changes based on comments from Charles o Compatibility changes based on comments from Charles
Changes since draft-ietf-usefor-article-13 Changes since draft-ietf-usefor-article-13
o The Mail-Copies-To, Posted-And-Mailed and Complaints-To headers o The Mail-Copies-To, Posted-And-Mailed headers have been moved to
have been moved to other documents. other documents.
o Dropped MIME parameters, as there is no WG consensus (per Chair). o Dropped MIME parameters, as there is no WG consensus (per Chair).
o More exact ABNF for Archive and Injection-Info parameters. o More exact ABNF for Archive and Injection-Info parameters.
o Complaints-To header is now an Injection-Info parameter.
Issues to be addressed Issues to be addressed
o Decide which definitions should go in this document and in o Decide which definitions should go in this document and in
[USEPRO]. [USEPRO].
o Decide how much (if any) discussion of Injection-Info content
belongs in this document vs. [USEPRO].
o Do we want to discuss message/partial? o Do we want to discuss message/partial?
o Add appendixes for changes from RFC 1036 and differences from RFC o Add appendixes for changes from RFC 1036 and differences from RFC
2822. 2822.
o IANA considerations (the Klyne message header registry is now o IANA considerations (the Klyne message header registry is now
official as RFC 3864). official as RFC 3864).
o Collected Syntax. o Collected Syntax.
o Merge more security issues? o Merge more security issues?
o Merge acknowledgments? o Merge acknowledgments?
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 6
1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Structure of This Document . . . . . . . . . . . . . . . . 7 1.6 Structure of This Document . . . . . . . . . . . . . . . . 8
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 9 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10
3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 10 3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 10 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 11
3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 13 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 14
3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 14 3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 15
3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 15 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 16 3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 17 3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 18
3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 17 3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 18
3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 18 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 19
3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 19 3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 20
3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 19 3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 20
3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 20 3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 21
3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 21 3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 24
4. Internationalization Considerations . . . . . . . . . . . . 23 4. Internationalization Considerations . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 6.1 Normative References . . . . . . . . . . . . . . . . . . . 27
6.2 Informative References . . . . . . . . . . . . . . . . . . . 25 6.2 Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . 31
1. Introduction 1. Introduction
1.1 Basic Concepts 1.1 Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing and
retrieving news "articles" (which are a subset of Email messages) and retrieving news "articles" (which are a subset of Email messages) and
for exchanging them amongst a readership which is potentially widely for exchanging them amongst a readership which is potentially widely
distributed. It is organized around "newsgroups", with the distributed. It is organized around "newsgroups", with the
expectation that each reader will be able to see all articles posted expectation that each reader will be able to see all articles posted
skipping to change at page 5, line 32 skipping to change at page 6, line 32
This document specifies the syntax of network news (Netnews) articles This document specifies the syntax of network news (Netnews) articles
in the context of the "Internet Message Format" [RFC2822] and in the context of the "Internet Message Format" [RFC2822] and
"Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This
document supersedes [RFC1036], updating it to reflect current document supersedes [RFC1036], updating it to reflect current
practice and incorporating changes and clarifications specified in practice and incorporating changes and clarifications specified in
other documents such as [Son-of-1036]. other documents such as [Son-of-1036].
This is the first in a set of documents that obsolete [RFC1036]. This is the first in a set of documents that obsolete [RFC1036].
This document focuses on the syntax and semantics of Netnews This document focuses on the syntax and semantics of Netnews
articles. [USEPRO] is also a standards-track document, and describes articles. [USEPRO] is also a standards-track document, and describes
the protocol issues of network news articles, independent of the protocol issues of Netnews articles, independent of transport
transport protocols such as [NNTP]. An best common practice protocols such as [NNTP]. An best common practice document,
document, [USEAGE], describes implementation recommendations to [USEAGE], describes implementation recommendations to improve
improve interoperability and usability. interoperability and usability.
This specification is intended as a definition of what article This specification is intended as a definition of what article
content format is to be passed between systems. Though some news content format is to be passed between systems. Though some news
systems locally store articles in this format (which eliminates the systems locally store articles in this format (which eliminates the
need for translation between formats) and others use formats that need for translation between formats) and others use formats that
differ from the one specified in this standard, local storage is differ from the one specified in this standard, local storage is
outside of the scope of this standard. outside of the scope of this standard.
1.3 Requirements Notation 1.3 Requirements Notation
skipping to change at page 6, line 17 skipping to change at page 7, line 17
Headers defined in this specification use the Augmented Backus-Naur Headers defined in this specification use the Augmented Backus-Naur
Form (ABNF) notation (including the Core Rules) specified in Form (ABNF) notation (including the Core Rules) specified in
[RFC2234] and many constructs defined in [RFC2822] and [RFC2045]. [RFC2234] and many constructs defined in [RFC2822] and [RFC2045].
Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of
<zone> and <msg-id> respectively. <zone> and <msg-id> respectively.
1.5 Definitions 1.5 Definitions
An "article" is the unit of news, synonymous with an [RFC2822] An "article" is the unit of news, synonymous with an [RFC2822]
"message". A "proto-article" is one that has not yet been injected "message". A "proto-article" is one that has not yet been injected
into the news system. into the news system. In constrast to an "article", a "proto-
article" may lack some mandatory headers.
A "message identifier" Section 3.1.3 is a unique identifier for an A "message identifier" Section 3.1.3 is a unique identifier for an
article, usually supplied by the "posting agent" which posted it or, article, usually supplied by the "posting agent" which posted it or,
failing that, by the "injecting agent". It distinguishes the article failing that, by the "injecting agent". It distinguishes the article
from every other article ever posted anywhere. Articles with the from every other article ever posted anywhere. Articles with the
same message identifier are treated as if they are the same article same message identifier are treated as if they are the same article
regardless of any differences in the body or headers. regardless of any differences in the body or headers.
A "newsgroup" is a single news forum, a logical bulletin board, A "newsgroup" is a single news forum, a logical bulletin board,
having a name and nominally intended for articles on a specific having a name and nominally intended for articles on a specific
skipping to change at page 8, line 11 skipping to change at page 9, line 11
Section 2 defines the format of news articles. Section 3 details the Section 2 defines the format of news articles. Section 3 details the
headers necessary to make an article suitable for the netnews headers necessary to make an article suitable for the netnews
environment. environment.
2. Format 2. Format
2.1 Base 2.1 Base
News articles MUST conform to the syntax specified in Section 3 of News articles MUST conform to the syntax specified in Section 3 of
[RFC2822]. Netnews agents MAY also accept the obsolete syntax [RFC2822]. Netnews agents MAY also accept the obsolete syntax
specified in Section 4 of [RFC2822], but they MUST NOT generate such specified in Section 4 of [RFC2822], but they MUST NOT generate
syntax. productions of such syntax.
This specification uses the terms "header", "header name", and This specification uses the terms "header", "header name", and
"header content" which are synonymous with the [RFC2822] terms "header content" which are synonymous with the [RFC2822] terms
"header field", "field name", and "field body" respectively. "header field", "field name", and "field body" respectively.
2.2 Headers 2.2 Headers
All headers in a news article are compliant with [RFC2822], however All headers in a news article are compliant with [RFC2822], however
this specification is less permissive in what can be generated and this specification is less permissive in what can be generated and
accepted by news agents. The syntax allowed for news articles is a accepted by news agents. The syntax allowed for news articles is a
skipping to change at page 8, line 37 skipping to change at page 9, line 37
General rules which apply to all headers (even those documented in General rules which apply to all headers (even those documented in
[RFC2822] and [RFC2045]) are listed below and those that apply to [RFC2822] and [RFC2045]) are listed below and those that apply to
specific headers are described in the relevent sections of this specific headers are described in the relevent sections of this
document. document.
o All agents MUST generate headers so that at least one space o All agents MUST generate headers so that at least one space
immediately follows the ':' separating the header name and the immediately follows the ':' separating the header name and the
header contents (for compatibility with deployed software). News header contents (for compatibility with deployed software). News
agents MAY accept headers which do not contain the required space. agents MAY accept headers which do not contain the required space.
o The header contents of every header line (including the first and o The header contents of every header line (including the first and
any that are subsequently folded) MUST contain at least one any that are subsequently folded) MUST contain at least one non-
non-whitespace character. whitespace character.
NOTE: This means that no header content defined by or NOTE: This means that no header content defined by or
referenced by this document can be empty. As a result, this referenced by this document can be empty. As a result, this
document updates the <unstructured> construct from Section document updates the <unstructured> construct from Section
3.2.6 of [RFC2822] as follows: 3.2.6 of [RFC2822] as follows:
unstructured = 1*( [FWS] utext ) [FWS] unstructured = 1*( [FWS] utext ) [FWS]
o Compliant software MUST NOT generate (but MAY accept) headers of o Compliant software MUST NOT generate (but MAY accept) headers of
more than 998 octets. This is the only limit on the length of a more than 998 octets. This is the only limit on the length of a
header line prescribed by this standard. However, specific rules header line prescribed by this standard. However, specific rules
skipping to change at page 9, line 5 skipping to change at page 10, line 7
unstructured = 1*( [FWS] utext ) [FWS] unstructured = 1*( [FWS] utext ) [FWS]
o Compliant software MUST NOT generate (but MAY accept) headers of o Compliant software MUST NOT generate (but MAY accept) headers of
more than 998 octets. This is the only limit on the length of a more than 998 octets. This is the only limit on the length of a
header line prescribed by this standard. However, specific rules header line prescribed by this standard. However, specific rules
to the contrary may apply in particular cases (for example, to the contrary may apply in particular cases (for example,
according to [RFC2047] header lines containing encoded-words are according to [RFC2047] header lines containing encoded-words are
limited to 76 octets). [USEAGE] includes suggested limits for limited to 76 octets). [USEAGE] includes suggested limits for
convenience of display by user agents. convenience of display by user agents.
NOTE: There is NO restriction on the number of lines into which NOTE: There is NO restriction on the number of lines into which
a header may be split, and hence there is NO restriction on the a header may be split, and hence there is NO restriction on the
total length of a header (in particular it may, by suitable total length of a header (in particular it may, by suitable
folding, be made to exceed the 998 octets restriction folding, be made to exceed the 998 octets restriction
pertaining to a single header line). pertaining to a single header line).
o The character set for headers is US-ASCII. Where the use of
non-ASCII characters is required, they MUST be encoded using the o The character set for headers is US-ASCII. Where the use of non-
MIME mechanisms defined in [RFC2045] and [RFC2231]. ASCII characters is required, they MUST be encoded using the MIME
mechanisms defined in [RFC2047] and [RFC2231].
2.3 MIME Conformance 2.3 MIME Conformance
User agents MUST meet the definition of MIME-conformance in [RFC2049] User agents MUST meet the definition of MIME-conformance in [RFC2049]
and MUST also support [RFC2231]. This level of MIME Conformance and MUST also support [RFC2231]. This level of MIME Conformance
provides support for internationalization and multimedia in message provides support for internationalization and multimedia in message
bodies ([RFC2045], [RFC2046], [RFC2231]), and support for bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
internationalization of headers ([RFC2047], [RFC2231]). Note that internationalization of headers ([RFC2047], [RFC2231]). Note that
[Errata] currently exist for [RFC2046] and [RFC2231]. [Errata] currently exist for [RFC2046] and [RFC2231].
skipping to change at page 10, line 44 skipping to change at page 11, line 44
3.1.1 From 3.1.1 From
The From header is the same as that specified in Section 3.6.2 of The From header is the same as that specified in Section 3.6.2 of
[RFC2822] with the added restrictions detailed in Section 2.2. [RFC2822] with the added restrictions detailed in Section 2.2.
from = "From:" SP mailbox-list CRLF from = "From:" SP mailbox-list CRLF
3.1.2 Date 3.1.2 Date
The Date header is the same as that specified in Sections 3.3 and The Date header is the same as that specified in Sections 3.3 and
3.6.1 of [RFC2822] with the added restrictions detailed in Section 3.6.1 of [RFC2822] with the added restrictions detailed in
2.2. However, the use of "UT" and "GMT" as time zones (part of Section 2.2. However, the use of "UT" and "GMT" as time zones (part
<obs-zone>), although deprecated, is widespread in news articles of <obs-zone>), although deprecated, is widespread in news articles
today. Therefore, agents MUST accept <date-time> constructs which today. Therefore, agents MUST accept <date-time> constructs which
include the updated <zone> construct below. include the updated <zone> construct below.
orig-date = "Date:" SP date-time CRLF orig-date = "Date:" SP date-time CRLF
zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
Note that agents SHOULD NOT generate <date-time> constructs which Note that agents SHOULD NOT generate <date-time> constructs which
include either "UT" or "GMT" and MUST NOT generate <date-time> include either "UT" or "GMT" and MUST NOT generate <date-time>
constructs which include any other zone names defined by <obs-zone>, constructs which include any other zone names defined by <obs-zone>,
some of which have ambiguous interpretations and would have adverse some of which have ambiguous interpretations and would have adverse
effects on Netnews protocols. effects on the Netnews protocols.
Also note that these requirements apply wherever <date-time> is used, Also note that these requirements apply wherever <date-time> is used,
including Injection-Date and Expires in Section 3.1.7 and Section including Injection-Date and Expires in Section 3.1.7 and
3.2.3 respectively. Section 3.2.3 respectively.
3.1.3 Message-ID 3.1.3 Message-ID
The Message-ID header contains a single unique message identifier. The Message-ID header contains a single unique message identifier.
This document updates the <msg-id> construct from Section 3.6.4 of This document updates the <msg-id> construct from Section 3.6.4 of
[RFC2822] so as to ensure that Internet Message Format Message-IDs [RFC2822] so as to ensure that Internet Message Format Message-IDs
are usable in widely deployed news software. The global uniqueness are usable in widely deployed news software. The global uniqueness
requirement for <msg-id> in [RFC2822] is to be understood as applying requirement for <msg-id> in [RFC2822] is to be understood as applying
across all protocols using such message identifiers, and across both across all protocols using such message identifiers, and across both
Email and Netnews in particular. The ABNF should be used as below, Email and Netnews in particular. A revised syntax for <msg-id> is
but the requirements and descriptive text from Section 3.6.4 of given below, but the requirements and descriptive text from Section
[RFC2822] still apply. 3.6.4 of [RFC2822] still apply.
message-id = "Message-ID:" SP msg-id CRLF message-id = "Message-ID:" SP msg-id CRLF
msg-id = [FWS] msg-id-core [FWS] msg-id = [FWS] msg-id-core [FWS]
msg-id-core = "<" id-left "@" id-right ">" msg-id-core = "<" id-left "@" id-right ">"
; maximum length is 250 octets ; maximum length is 250 octets
id-left = dot-atom-text / no-fold-quote id-left = dot-atom-text / no-fold-quote
id-right = dot-atom-text / no-fold-literal id-right = dot-atom-text / no-fold-literal
no-fold-quote = DQUOTE no-fold-quote = DQUOTE
*( mqtext / "\\" / "\" DQUOTE ) *( mqtext / mquoted-pair )
mqspecial mqspecial
*( mqtext / "\\" / "\" DQUOTE ) *( mqtext / mquoted-pair )
DQUOTE DQUOTE
mqtext = NO-WS-CTL / ; all of <text> except mqtext = %d33 / ; all of <text> except
%d33 / ; SP, HTAB, "\", ">" %d35-61 / ; controls, SP, HTAB, "\", ">"
%d35-61 / ; and DQUOTE %d63-91 / ; and DQUOTE
%d63-91 /
%d93-126 %d93-126
mquoted-pair = "\\" / "\" DQUOTE
mqspecial = "(" / ")" / ; same as specials except mqspecial = "(" / ")" / ; same as specials except
"<" / ; "\" and DQUOTE quoted "<" / ; "\" and DQUOTE quoted
"[" / "]" / ; and ">" omitted "[" / "]" / ; and ">" omitted
":" / ";" / ":" / ";" /
"@" / "\\" / "@" / "," /
"," / "." / "." / mquoted-pair
"\" DQUOTE
no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
mdtext = NO-WS-CTL / ; Non white space controls [[Adjacent dots should not be allowed]]
%d33-61 / ; The rest of the US-ASCII
mdtext = %d33-61 / ; The rest of the US-ASCII
%d63-90 / ; characters not including %d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\" %d94-126 ; ">", "[", "]", or "\"
The msg-id-core MUST NOT be more than 250 octets in length. The msg-id-core MUST NOT be more than 250 octets in length.
NOTE: The length restriction ensures that systems which accept NOTE: The length restriction ensures that systems which accept
message identifiers as a parameter when retrieving an article message identifiers as a parameter when retrieving an article
(e.g. [NNTP]) can rely on a bounded length. (e.g. [NNTP]) can rely on a bounded length.
Observe that msg-id-core includes the < and >. Observe that msg-id-core includes the < and >.
Observe also that in contrast to the corresponding header in Observe also that in contrast to the corresponding header in
[RFC2822], the syntax does not allow comments within the Message-ID [RFC2822], the syntax does not allow comments within the Message-ID
header, it ensures that no string of characters is quoted unless header, it ensures that no string of characters is quoted unless
strictly necessary (it must contain at least one mqspecial) and no strictly necessary (it must contain at least one mqspecial) and no
single character is prefixed by a "\" in the form of a quoted-pair single character is prefixed by a "\" in the form of a quoted-pair
unless strictly necessary, and moreover there is no possibility for unless strictly necessary, and moreover there is no possibility for
">" or WSP to occur inside a msg-id-core, whether quoted or not. ">" or WSP to occur inside a msg-id-core, whether quoted or not.
This is to simplify processing by relaying and serving agents and to This is to simplify processing by relaying and serving agents and to
ensure interoperability with existing implementations. Thus, whereas ensure interoperability with existing implementations. Thus, whereas
under [RFC2822] the following <msg-id-core> would be considered under [RFC2822] the following <msg-id-core>s would be considered
semantically equivalent, semantically equivalent,
<abcd@example.com> <abcd@example.com>
<"abcd"@example.com> <"abcd"@example.com>
<"ab\cd"@example.com> <"ab\cd"@example.com>
only the first of them is syntactically permitted by this standard, only the first of them is syntactically permitted by this standard,
and hence a simple comparison of octets will always suffice to and hence a simple comparison of octets will always suffice to
determine the identity of two <msg-id-core>. determine the identity of two <msg-id-core>s.
Also note that this updated ABNF applies wherever <msg-id-core> are Also note that this updated ABNF applies wherever <msg-id-core> is
used, including the References header discussed in Section 3.2.1 and used, including the References header discussed in Section 3.2.1 and
the Supersedes header discussed in Section 3.2.5. the Supersedes header discussed in Section 3.2.5.
3.1.4 Subject 3.1.4 Subject
The Subject header is the same as that specified in Section 3.6.5 of The Subject header is the same as that specified in Section 3.6.5 of
[RFC2822] with the added restrictions detailed in Section 2.2. [RFC2822] with the added restrictions detailed in Section 2.2.
Further discussion of the content of the Subject header appears in Further discussion of the content of the Subject header appears in
[USEPRO] and [USEAGE]. [USEPRO] and [USEAGE].
skipping to change at page 14, line 10 skipping to change at page 15, line 10
component = 1*component-char component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_" component-char = ALPHA / DIGIT / "+" / "-" / "_"
NOTE: Observe that the syntax does not allow comments within the NOTE: Observe that the syntax does not allow comments within the
Newsgroups header; this is to simplify processing by relaying and Newsgroups header; this is to simplify processing by relaying and
serving agents which have a requirement to process this header serving agents which have a requirement to process this header
extremely rapidly. extremely rapidly.
Components beginning with underline ("_") are reserved for use by Components beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT occur in future versions of this standard and MUST NOT occur in <newsgroup-
<newsgroup-name>s (whether in Newsgroups headers or in newgroup name>s (whether in Newsgroups headers or in newgroup control messages
control messages [USEPRO]). However, such names MUST be accepted. [USEPRO]). However, such names MUST be accepted.
The specific format and lengths of <newsgroup-name> and <component> The specific format and lengths of <newsgroup-name> and <component>
are discussed in [USEAGE]. are discussed in [USEAGE].
3.1.6 Path 3.1.6 Path
The Path header indicates the route taken by an article since its The Path header indicates the route taken by an article since its
injection into the Netnews system. Each agent that processes an injection into the Netnews system. Each agent that processes an
article is required to prepend one (or more) identities to this article is required to prepend one (or more) identities to this
header. This is primarily to enable relaying agents to avoid sending header. This is primarily to enable relaying agents to avoid sending
skipping to change at page 15, line 4 skipping to change at page 16, line 4
3.1.7 Injection-Date 3.1.7 Injection-Date
The Injection-Date header contains the date and time that the article The Injection-Date header contains the date and time that the article
was injected into the network. Its purpose is to prevent the was injected into the network. Its purpose is to prevent the
reinjection into the news stream of "stale" articles which have reinjection into the news stream of "stale" articles which have
already expired by the time they arrive at some relaying or serving already expired by the time they arrive at some relaying or serving
agent. agent.
injection-date = "Injection-Date:" SP date-time CRLF injection-date = "Injection-Date:" SP date-time CRLF
See the remarks under Section 3.1.2 regarding the syntax of See the remarks under Section 3.1.2 regarding the syntax of date-
date-time and the requirements and recommendations to which it is time and the requirements and recommendations to which it is subject.
subject.
NOTE: The date-time in this header would normally be expected to NOTE: The date-time in this header would normally be expected to
be later than the date-time in the Date header, but differences be later than the date-time in the Date header, but differences
between the clocks on the various agents and other special between the clocks on the various agents and other special
circumstances might vitiate that; no provision is made for any circumstances might vitiate that; no provision is made for any
such discrepancy to be corrected - better that the injecting agent such discrepancy to be corrected - better that the injecting agent
should just insert the correct time as it sees it. should just insert the correct time as it sees it.
This header is intended to replace the currently-used but This header is intended to replace the currently-used but
undocumented "NNTP-Posting-Date" header, whose use is now deprecated. undocumented "NNTP-Posting-Date" header, whose use is now deprecated.
skipping to change at page 15, line 39 skipping to change at page 16, line 38
permitted. permitted.
sender = "Sender:" SP mailbox CRLF sender = "Sender:" SP mailbox CRLF
reply-to = "Reply-To:" SP address-list CRLF reply-to = "Reply-To:" SP address-list CRLF
comments = "Comments:" SP unstructured CRLF comments = "Comments:" SP unstructured CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF keywords = "Keywords:" SP phrase *("," phrase) CRLF
The MIME headers MIME-Version, Content-Type, The MIME headers MIME-Version, Content-Type, Content-Transfer-
Content-Transfer-Encoding, Content-Disposition, and Content-Language Encoding, Content-Disposition, and Content-Language are used in news
are used in news articles in the same circumstances and with the same articles in the same circumstances and with the same meanings as
meanings as those specified in [RFC2045], [RFC2183], and [RFC3282] those specified in [RFC2045], [RFC2183], and [RFC3282] with the added
with the added restrictions detailed in Section 2.2. restrictions detailed in Section 2.2.
All remaining news headers are described below. All remaining news headers are described below.
3.2.1 References 3.2.1 References
The References header is the same as that specified in Section 3.6.4 The References header is the same as that specified in Section 3.6.4
of [RFC2822] with the added restrictions detailed in Section 2.2 and of [RFC2822] with the added restrictions detailed in Section 2.2 and
those listed below: those listed below:
o The updated <msg-id-core> construct defined in Section 3.1.3 MUST o The updated <msg-id-core> construct defined in Section 3.1.3 MUST
skipping to change at page 16, line 28 skipping to change at page 17, line 30
should be posted. The Followup-To header SHOULD NOT appear in a should be posted. The Followup-To header SHOULD NOT appear in a
message, unless its content is different from the content of the message, unless its content is different from the content of the
Newsgroups header. Newsgroups header.
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) followup-to = "Followup-To:" SP ( newsgroup-list / poster-text )
CRLF CRLF
poster-text = [FWS] %d112.111.115.116.101.114 [FWS] poster-text = [FWS] %d112.111.115.116.101.114 [FWS]
; "poster" in lower-case ; "poster" in lower-case
The syntax is the same as that of the Newsgroups header (Section The syntax is the same as that of the Newsgroups header
3.1.5, with the exception that the keyword "poster" (which is always (Section 3.1.5, with the exception that the keyword "poster" (which
lowercase) requests that followups should be mailed to the article's is always lowercase) requests that followups should be mailed to the
reply address rather than posted. Although the keyword "poster" is article's reply address rather than posted. Although the keyword
case-sensitive, followup agents MAY choose to recognize "poster" is case-sensitive, followup agents MAY choose to recognize
case-insensitive forms such as "Poster". case-insensitive forms such as "Poster".
3.2.3 Expires 3.2.3 Expires
The Expires header specifies a date and time when the article is The Expires header specifies a date and time when the article is
deemed to be no longer relevant and could usefully be removed deemed to be no longer relevant and could usefully be removed
("expired"). ("expired").
expires = "Expires:" SP date-time CRLF expires = "Expires:" SP date-time CRLF
See the remarks under Section 3.1.2 regarding the syntax of See the remarks under Section 3.1.2 regarding the syntax of date-
date-time and the requirements and recommendations to which it is time and the requirements and recommendations to which it is subject.
subject.
3.2.4 Control 3.2.4 Control
The Control header marks the article as a control message, and The Control header marks the article as a control message, and
specifies the desired actions (additional to the usual ones of specifies the desired actions (additional to the usual ones of
storing and/or relaying the article). storing and/or relaying the article).
control = "Control:" SP [FWS] control-message [FWS] CRLF control = "Control:" SP [FWS] control-message [FWS] CRLF
control-message = verb *( [FWS] argument ) control-message = verb *( [FWS] argument )
skipping to change at page 17, line 36 skipping to change at page 18, line 38
control message for the specified article, followed immediately by control message for the specified article, followed immediately by
the new article without the Supersedes header. the new article without the Supersedes header.
supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF
NOTE: There is no "c" in Supersedes. NOTE: There is no "c" in Supersedes.
NOTE: The Supersedes header defined here has no connection with the NOTE: The Supersedes header defined here has no connection with the
Supersedes header that sometimes appears in Email messages converted Supersedes header that sometimes appears in Email messages converted
from X.400 according to [RFC2156]; in particular, the syntax here from X.400 according to [RFC2156]; in particular, the syntax here
permits only one <msg-id-core> in contrast to the multiple permits only one <msg-id-core> in contrast to the multiple <msg-id-
<msg-id-core>s in that Email version. core>s in that Email version.
3.2.6 Distribution 3.2.6 Distribution
The Distribution header specifies geographic or organizational limits The Distribution header specifies geographic or organizational limits
on an article's propagation. on an article's propagation.
distribution = "Distribution:" SP distribution-list CRLF distribution = "Distribution:" SP distribution-list CRLF
dist-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS] dist-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS]
skipping to change at page 19, line 22 skipping to change at page 20, line 22
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters ; US-ASCII printable characters
; except '(' and ';' ; except '(' and ';'
The <server-name> is included so that software can determine which The <server-name> is included so that software can determine which
serving agent generated the header. The locations specify what serving agent generated the header. The locations specify what
newsgroups the article was filed under (which may differ from those newsgroups the article was filed under (which may differ from those
in the Newsgroups header) and where it was filed under them. The in the Newsgroups header) and where it was filed under them. The
exact form of an article-locator is implementation-specific. exact form of an article-locator is implementation-specific.
NOTE: The traditional form of an article-locator (as used by NOTE: The traditional form of an article-locator (as required by
[NNTP]) is a decimal number, with articles in each newsgroup [NNTP]) is a decimal number, with articles in each newsgroup
numbered consecutively starting from 1. numbered consecutively starting from 1.
3.2.11 Archive 3.2.11 Archive
The Archive header provides an indication of the poster's intent The Archive header provides an indication of the poster's intent
regarding preservation of the article in publicly accessible regarding preservation of the article in publicly accessible long-
long-term or permanent storage. term or permanent storage.
archive = "Archive:" SP [CFWS] ("no" / "yes") archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" archive-param ) CRLF *( [CFWS] ";" archive-param ) CRLF
archive-param = "filename=" value archive-param = parameter
The presence of an "Archive: no" header in an article indicates that The presence of an "Archive: no" header in an article indicates that
the poster does not permit redistribution from publicly accessible the poster does not permit redistribution from publicly accessible
long-term or permanent archives. The absence of this header, or an long-term or permanent archives. The absence of this header, or an
explicit "Archive: yes", indicates that the poster is willing for explicit "Archive: yes", indicates that the poster is willing for
such redistribution to take place. The optional "filename" parameter such redistribution to take place. Further extensions to this
can then be used to suggest a filename under which the article should standard may provide parameters for administration of the archiving
be stored. Further extensions to this standard may provide process.
additional parameters for administration of the archiving process.
3.2.12 User-Agent 3.2.12 User-Agent
The User-Agent header contains information about the user agent The User-Agent header contains information about the user agent
(typically a newsreader) generating the article, for statistical (typically a newsreader) generating the article, for statistical
purposes and tracing of standards violations to specific software purposes and tracing of standards violations to specific software
needing correction. It is intended that this header be suitable for needing correction. It is intended that this header be suitable for
use in Email. use in Email.
user-agent = "User-Agent:" SP 1*product CRLF user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [CFWS] [ "/" product-version ] product = [CFWS] token [ [CFWS] "/" product-version ]
product-version = [CFWS] token [CFWS] product-version = [CFWS] token
This header MAY contain multiple product-tokens identifying the agent This header MAY contain multiple product-tokens identifying the agent
and any subproducts which form a significant part of the posting and any subproducts which form a significant part of the posting
agent, listed in order of their significance for identifying the agent, listed in order of their significance for identifying the
application. application.
NOTE: This header supersedes the role performed redundantly by NOTE: This header supersedes the role performed redundantly by
experimental headers such as X-Newsreader, X-Mailer, experimental headers such as X-Newsreader, X-Mailer, X-Posting-
X-Posting-Agent, X-Http-User-Agent, and other headers previously Agent, X-Http-User-Agent, and other headers previously used on
used on Usenet and in Email for this purpose. Use of these Usenet and in Email for this purpose. Use of these experimental
experimental headers SHOULD be discontinued in favor of the headers SHOULD be discontinued in favor of the single, standard
single, standard User-Agent header. User-Agent header.
NOTE: [RFC2616] describes a similar facility for the HTTP NOTE: [RFC2616] describes a similar facility for the HTTP
protocol. This specification differs in that "{" and "}" are protocol. This specification differs in that "{" and "}" are
allowed in tokens (<product> and <product-version>) and comments allowed in tokens (<product> and <product-version>) and comments
are permitted wherever whitespace is allowed. are permitted wherever whitespace is allowed.
3.2.13 Injection-Info 3.2.13 Injection-Info
The Injection-Info header provides information as to how an article The Injection-Info header provides information as to how an article
entered the Netnews system and to assist in tracing its true origin. entered the Netnews system and to assist in tracing its true origin.
It can also specify one or more addresses where complaints concerning
the poster of the article may be sent.
injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS]
*( ";" inj-info-para ) CRLF *( ";" inj-info-para ) CRLF
inj-info-param = post-host-param / inj-info-param = post-host-param /
post-account-param / post-account-param /
sender-param / sender-param /
logging-param logging-param /
complainto-param
post-host-param = "posting-host=" host-value [[Each parameter is allowed only once?]]
[[Should also allow for x-attributes?]]
post-host-param = "posting-host" "=" host-value
host-value = dot-atom / [ dot-atom ":" ] host-value = dot-atom / [ dot-atom ":" ]
( IPv4address / IPv6address ) ; see [RFC 2373] ( IPv4address / IPv6address ) ; see [RFC 2373]
post-acct-param = "posting-account=" value post-acct-param = "posting-account" "=" value
sender-param = "sender=" sender-value sender-param = "sender" "=" sender-value
sender-value = mailbox / "verified" sender-value = mailbox / "verified"
logging-param = "logging-data=" value logging-param = "logging-data" "=" value
complainto-param= "complaints-to" "=" address-list
Although comments and folding of white space are permitted throughout Although comments and folding of white space are permitted throughout
the Injection-Info header, it is RECOMMENDED that folding is not used the Injection-Info header, it is RECOMMENDED that folding is not used
within any parameter (but only before or after the ";" separating within any parameter (but only before or after the ";" separating
those parameters), and that comments are only used following the last those parameters), and that comments are only used following the last
parameter. It is also RECOMMENDED that such parameters as are parameter.
present are included in the order in which they have been defined in
the syntax above.
This header is intended to replace various currently-used but This header is intended to replace various currently-used but
undocumented headers such as "NNTP-Posting-Host" and "X-Trace". undocumented headers such as "NNTP-Posting-Host", "X-Trace" and
These headers are now deprecated. "X-Complaints-To". These headers are thus deprecated.
The "posting-host" parameter specifies the FQDN and/or IP address
(IPv4address or IPv6address) of the host from which the injecting
agent received the article.
NOTE: If the "posting-host" parameter identifies a dial-up point-
of-presence, the "posting-account" or the "logging-data" parameter
may provide additional information about true origin of the
article.
The "posting-account" parameter identifies the source from which the
injecting agent received the article. For security reasons, it
SHOULD be in a cryptic notation understandable only by the
administrator of the injecting agent.
The "sender" parameter identifies the mailbox of the verified sender
of the article (alternatively, it uses the token "verified" to
indicate that at least any addr-spec in the Sender header of the
article, or in the From header if the Sender header is absent, is
correct). If an injecting agent can verify sender of an article, it
SHOULD use this parameter in favour of the "posting-account"
parameter.
The "logging-data" parameter contains information (typically a
session number or other non-persistent means of identifying a posting
account) which will enable the true origin of the article to be
determined by reference to logging information kept by the injecting
agent.
The "complaints-to" parameter specifies mailbox(es) for sending
complaints concerning the behaviour of the poster of the article.
3.3 Obsolete Headers 3.3 Obsolete Headers
Early versions of news software following the modern format sometimes Early versions of news software following the modern format sometimes
generated headers like the following: generated headers like the following:
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Date-Received: Friday, 19-Nov-82 16:59:30 EST Date-Received: Friday, 19-Nov-82 16:59:30 EST
Relay-Version contained version information about the relaying agent Relay-Version contained version information about the relaying agent
that last processed the article. Posting-Version contained version that last processed the article. Posting-Version contained version
information about the posting agent that posted the article. information about the posting agent that posted the article. Date-
Date-Received contained the date when the last relaying agent to Received contained the date when the last relaying agent to process
process the article first saw it (in a slightly nonstandard format). the article first saw it (in a slightly nonstandard format).
In addition, this present standard obsoletes certain headers defined In addition, this present standard obsoletes certain headers defined
in [Son-of-1036]: in [Son-of-1036]:
Also-Control: cancel <9urrt98y53@site.example> Also-Control: cancel <9urrt98y53@site.example>
See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example> See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example>
Article-Names: comp.foo:charter Article-Names: comp.foo:charter
Article-Updates: <i4g587y@site1.example> Article-Updates: <i4g587y@site1.example>
Also-Control indicated a control message that was also intended to be Also-Control indicated a control message that was also intended to be
filed as a normal article. See-Also listed related articles, but filed as a normal article. See-Also listed related articles, but
without the specific relationship with followups that pertains to the without the specific relationship with followups that pertains to the
References-header. Article-Names indicated some special significance References-header. Article-Names indicated some special significance
of that article in relation to the indicated newsgroup. of that article in relation to the indicated newsgroup. Article-
Article-Updates indicated that an earlier article was updated, Updates indicated that an earlier article was updated, without at the
without at the same time being superseded. same time being superseded.
The headers listed above are documented for historical purposes only. The headers listed above are documented for historical purposes only.
Articles containing these headers MUST NOT be generated. Persons Articles containing these headers MUST NOT be generated. Persons
writing new agents SHOULD ignore any former meanings these headers. writing new agents SHOULD ignore any former meanings these headers.
3.3.1 Lines 3.3.1 Lines
The Lines header indicates the number of lines in the body of the The Lines header indicates the number of lines in the body of the
article. article.
skipping to change at page 24, line 24 skipping to change at page 27, line 5
future. future.
Message-IDs (Section 3.1.3) in news are required to be unique; Message-IDs (Section 3.1.3) in news are required to be unique;
articles are refused (in server-to-server transfer) if the ID has articles are refused (in server-to-server transfer) if the ID has
already been seen. So if you can predict the ID of a message, you already been seen. So if you can predict the ID of a message, you
can preempt it by posting a message (possibly to a quite different can preempt it by posting a message (possibly to a quite different
group) with the same ID, stopping your target message from group) with the same ID, stopping your target message from
propagating. Agents that generate message-ids for news articles propagating. Agents that generate message-ids for news articles
SHOULD ensure that they are unpredictable. SHOULD ensure that they are unpredictable.
The filename parameter of the Archive-header (Section 3.2.11) can be
used to attempt to store archived articles in inappropriate
locations. Archiving sites should be suspicious of absolute filename
parameters, as opposed to those relative to some location of the
archiver's choosing.
6. References 6. References
6.1 Normative References 6.1 Normative References
[Errata] "RFC Editor Errata". [Errata] "RFC Editor Errata".
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
skipping to change at page 25, line 30 skipping to change at page 27, line 30
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996. Examples", RFC 2049, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S. and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997. Continuations", RFC 2231, November 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
2001. April 2001.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
2002. May 2002.
6.2 Informative References 6.2 Informative References
[ISO.3166.1988] [ISO.3166.1988]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries, 3rd edition", the representation of names of countries, 3rd edition",
ISO Standard 3166, August 1988. ISO Standard 3166, August 1988.
[NNTP] Feather, C., "Network News Transfer Protocol", [NNTP] Feather, C., "Network News Transfer Protocol",
draft-ietf-nntpext-base-*.txt. draft-ietf-nntpext-base-*.txt.
[PGPVERIFY] [PGPVERIFY]
Lawrence, D., "PGPverify", June 1999. Lawrence, D., "PGPverify", June 1999.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156, January Mapping between X.400 and RFC 822/MIME", RFC 2156,
1998. January 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001. "MIME Security with OpenPGP", RFC 3156, August 2001.
[Son-of-1036] [Son-of-1036]
Spencer, H., "News Article Format and Transmission", June Spencer, H., "News Article Format and Transmission",
1994. June 1994.
[USEAGE] Lindsey, C., "Usenet Best Practice", [USEAGE] Lindsey, C., "Usenet Best Practice",
draft-ietf-usefor-useage-*.txt. draft-ietf-usefor-useage-*.txt.
[USEPRO] Lindsey, C., "News Article Architecture and Protocols", [USEPRO] Lindsey, C., "News Article Architecture and Protocols",
draft-ietf-usefor-usepro-*.txt. draft-ietf-usefor-usepro-*.txt.
Authors' Addresses Authors' Addresses
Kenneth Murchison (editor) Kenneth Murchison (editor)
Oceana Matrix Ltd. Oceana Matrix Ltd.
21 Princeton Place 21 Princeton Place
Orchard Park, NY 14127 Orchard Park, NY 14127
US US
Phone: +1 716 662 8973 Phone: +1 716 662 8973
EMail: ken@oceana.com Email: ken@oceana.com
Charles H. Lindsey Charles H. Lindsey
University of Manchester University of Manchester
5 Clerewood Avenue 5 Clerewood Avenue
Heald Green Heald Green
Cheadle Cheadle
Chesire SK8 3JU Chesire SK8 3JU
GB GB
Phone: +44 161 436 6131 Phone: +44 161 436 6131
EMail: chl@clw.cs.man.ac.uk Email: chl@clw.cs.man.ac.uk
Dan Kohn Dan Kohn
Skymoon Ventures Skymoon Ventures
3045 Park Boulevard 3045 Park Boulevard
Palo Alto, CA 94306 Palo Alto, CA 94306
US US
Phone: +1 650 327 2600 Phone: +1 650 327 2600
EMail: dan@dankohn.com Email: dan@dankohn.com
Appendix A. Acknowledgements Appendix A. Acknowledgements
Comments and/or text were provided by Mark Crispin, Claus Faerber, Comments and/or text were provided by Mark Crispin, Claus Faerber,
Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson,
Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey
Melnikov. Melnikov.
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 29, line 41 skipping to change at page 31, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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