draft-ietf-usefor-usefor-06.txt   draft-ietf-usefor-usefor-07.txt 
Usenet Format Working Group K. Murchison, Ed. Usenet Format Working Group K. Murchison, Ed.
Internet-Draft Carnegie Mellon University Internet-Draft Carnegie Mellon University
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 (if approved) C. Lindsey
Expires: June 19, 2006 University of Manchester Expires: September 6, 2006 University of Manchester
D. Kohn D. Kohn
Skymoon Ventures Skymoon Ventures
December 16, 2005 March 5, 2006
Netnews Article Format Netnews Article Format
draft-ietf-usefor-usefor-06 draft-ietf-usefor-usefor-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 June 19, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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.
Note to the RFC Editor Changes since draft-ietf-usefor-usefor-06
The normative reference to RFC 2234 and the informative reference to o Reworked ABNF for Path header field delimiters and components
RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and (ticket #1047).
draft-ietf-nntpext-base respectively should one or both of those of
those documents reach RFC status before this one. o Imported ABNF elements from reference docs (ticket #1155).
o Added IANA registration for header fields per RFC 3864 (ticket
#1156).
o New ABNF for Control header field (ticket #1157).
o Better ABNF for <host-value> (ticket #1158).
o Added new definitions and advice on sender vs. posting-account in
Injection-Info header field (ticket #1159).
o New ABNF for Archive and Injection-Info header fields, including
note regarding CFWS and <parameter> (ticket #1177).
o Replaced leading/trailing [FWS] with *WSP in header field ANBF
(ticket #1179).
o Using RFC 4234 as a reference instead of RFC 2234.
o Removed reference to RFC 0977 -- using only
draft-ietf-nntpext-base.
o Added note about Expires being defined by RFC 2156.
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-05 Changes since draft-ietf-usefor-usefor-05
o Resolved ticket #1003 (msg-id). o Finalized ABNF for <msg-id> (ticket #1003).
o Resolved ticket #1021 (Newsgroups description and exceptions). o Further cleanup of description for Newsgroups header field (ticket
#1021).
o Resolved ticket #1028 (fixed ABNF for orig-date). o Fixed ABNF for <orig-date> (ticket #1028).
o Began adding text for ticket #1032 (diff from RFC 1036). o Began adding text for differences from RFC 1036 (ticket #1032).
o Resolved ticket #1046 (MIME boundary security considerations). o Added text regarding hard-to-parse MIME boundaries (ticket #1046).
o Addressed ticket #1047 (Path header field delimiters and o Reworked/redefined Path header field delimiters and components
components) using Harald's suggested text -- Still an open issue. (ticket #1047).
o Resolved ticket #1052 (diffs from RFC 2822). o Added more differences from RFC 2822 (ticket #1052).
o Resolved ticket #1053 (relationship to RFC 2822). o Added text for relationship to RFC 2822 (ticket #1053).
o Resolved ticket #1079 (header fields which don't permit CFWS). o Listed header fields which don't permit CFWS (ticket #1079).
o Applied text from ticket #1080 (Injection-Info MIME params). o Applied text from ticket #1080 (Injection-Info MIME params).
o Resolved ticket #1082 (Approved header field semantics). o Added more text Approved header field semantics (ticket #1082).
o Resolved ticket #1088 (Injection-Date mandatory/optional). o Added text regarding Injection-Date being mandatory/optional
(ticket #1088).
o Resolved ticket #1102 (Definition of "agents", etc). o Reworked definitions of "agents", etc (ticket #1102).
o Removed RFC 0821 as a normative reference. o Removed RFC 2821 as a normative reference.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-04 Changes since draft-ietf-usefor-usefor-04
o Resolved ticket #1002 (updated references). o Updated to newer references (ticket #1002).
o Applied text from ticket #1003 (ABNF cleanup for msg-id). o Cleaned up ABNF for <msg-id> (ticket #1003).
o Resolved ticket #1004 (deprecate X- headers). o Deprecated X- headers (ticket #1004).
o Resolved ticket #1008 (followups & References header field). o Clarified relationship between followups and References header
field (ticket #1008).
o Applied text from ticket #1021 (Newsgroups ABNF and description). o Cleaned up ABNF and description for Newsgroups header field
(ticket #1021).
o Resolved ticket #1022 (obs-phrase). o Tweaked language regarding the use of <obs-phrase> (ticket #1022).
o Applied text from ticket #1028 (GMT timezone for Date). o Tweaked language regarding GMT timezone and Date header field
(ticket #1028).
o Applied text from ticket #1042 (Newsgroups folding). o Added language warning against folding Newsgroups header field
(ticket #1042).
o Resolved ticket #1043 (RFC 2822 terms for header fields). o Use RFC 2822 term "header field" instead of "header" (ticket
#1043).
o Starting to resolve ticket #1052 (differences from RFC 2822). o Starting adding differences from RFC 2822 (ticket #1052).
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-03 Changes since draft-ietf-usefor-usefor-03
o Reworked ABNFs of several headers. o Reworked ABNFs of several headers.
o Used Charles' ABNF for <msg-id>. o Used Charles' ABNF for <msg-id>.
o Disallowed comments in Supersedes header. o Disallowed comments in Supersedes header.
skipping to change at page 5, line 18 skipping to change at page 5, line 48
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. o Complaints-To header is now an Injection-Info parameter.
Issues to be addressed Issues to be addressed
o Ticket #1047: Path header field delimiters and components. o Path header field delimiters and components ABNF (ticket #1047).
o IANA considerations (the Klyne message header registry is now
official as RFC 3864)?.
o Collected Syntax?
o Merge more security issues?
o Merge acknowledgments? o Whitespace in Path header field (ticket #1178). Editor isn't
clear on what the issue actually is.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 8
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 7 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 8
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Structure of This Document . . . . . . . . . . . . . . . . 9 1.6. Structure of This Document . . . . . . . . . . . . . . . . 10
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 12
2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 12 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 14
3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 13 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 15
3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 14 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 16
3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 17 3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 19
3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 20 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 22
3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 20 3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 23
3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 21 3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 21 3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 22 3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 25
3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 23 3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 25
3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 24 3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 26
3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 25 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 27
3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 25 3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 28
3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 27 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 30
3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 31
4. Internationalization Considerations . . . . . . . . . . . . . 29 4. Internationalization Considerations . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
6.1. Normative References . . . . . . . . . . . . . . . . . . . 31 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Informative References . . . . . . . . . . . . . . . . . . 31 7.1. Normative References . . . . . . . . . . . . . . . . . . . 39
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 7.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix B. Differences from RFC 1036 and its derivatives . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 35 Appendix B. Differences from RFC 1036 and its derivatives . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 46
1. Introduction 1. Introduction
1.1. Basic Concepts 1.1. Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing and
retrieving news "articles" (whose format is a subset of that for retrieving news "articles" (whose format is a subset of that for
Email messages) and for exchanging them amongst a readership which is Email messages) and for exchanging them amongst a readership which is
potentially widely distributed. It is organized around "newsgroups", potentially widely distributed. It is organized around "newsgroups",
with the expectation that each reader will be able to see all with the expectation that each reader will be able to see all
skipping to change at page 7, line 31 skipping to change at page 8, line 31
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. [I-D.ietf-usefor-usepro] is also a standards-track
the protocol issues of Netnews articles, independent of transport document, and describes the protocol issues of Netnews articles,
protocols such as [NNTP]. A best common practice document, [USEAGE], independent of transport protocols such as [I-D.ietf-nntpext-base].
describes implementation recommendations to improve interoperability A best common practice document, [I-D.ietf-usefor-useage], describes
and usability. implementation recommendations to improve 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
This document uses terms that appear in capital letters. The key This document uses terms that appear in capital letters. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
1.4. Syntax Notation 1.4. Syntax Notation
Header fields defined in this specification use the Augmented Backus- Header fields defined in this specification use the Augmented Backus-
Naur Form (ABNF) notation (including the Core Rules) specified in Naur Form (ABNF) notation (including the Core Rules) specified in
[RFC2234] and many constructs defined in [RFC2822] and [RFC2045]. [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as
Section 3.1.3 updates the [RFC2822] definition of <msg-id>. amended by [RFC2231], and [RFC3986], specifically:
The following constructs referenced by this document are defined in token = <see RFC2045 Section 5.1>
[RFC2822]: <mailbox-list>, <mailbox>, <date-time>, <phrase>, dot-atom-text = <see RFC2045 Section 5.1>
<address-list>, <utext>, <dot-atom-text>, <dot-atom>, <FWS>, <CFWS>
and <CRLF>.
The following constructs referenced by this document are defined in parameter = <see RFC2231 Section 7>
[RFC2045] (as amended by [RFC2231]): <token>, <parameter>, <value>. attribute = <see RFC2231 Section 7>
FWS = <see RFC2822 Section 3.2.3>
CFWS = <see RFC2822 Section 3.2.3>
atext = <see RFC2822 Section 3.2.4>
dot-atom-text = <see RFC2822 Section 3.2.4>
phrase = <see RFC2822 Section 3.2.6>
utext = <see RFC2822 Section 3.2.6>
date-time = <see RFC2822 Section 3.3>
mailbox = <see RFC2822 Section 3.4>
mailbox-list = <see RFC2822 Section 3.4>
address-list = <see RFC2822 Section 3.4>
fields = <see RFC2822 Section 3.6>
IPv6address = <see RFC3986 Section 3.2.2>
IPv4address = <see RFC3986 Section 3.2.2>
ALPHA = <see RFC4234 Appendix B.1>
CRLF = <see RFC4234 Appendix B.1>
DIGIT = <see RFC4234 Appendix B.1>
DQUOTE = <see RFC4234 Appendix B.1>
SP = <see RFC4234 Appendix B.1>
Additionally, Section 3.1.3 updates the [RFC2822] definition of
<msg-id>.
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. In constrast to an "article", a "proto- into the news system. In constrast to an "article", a "proto-
article" may lack some mandatory header fields. article" may lack some mandatory header fields.
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 "user agent" which posted it or, article, usually supplied by the "user agent" which posted it or,
skipping to change at page 10, line 10 skipping to change at page 12, line 10
Section 2 defines the format of news articles. Section 3 details the Section 2 defines the format of news articles. Section 3 details the
header fields necessary to make an article suitable for the Netnews header fields necessary to make an article suitable for the Netnews
environment. environment.
2. Format 2. Format
2.1. Base 2.1. Base
An article is said to be conformant to this specification if it An article is said to be conformant to this specification if it
conforms to the format specified in [RFC2822] section 3 and to the conforms to the format specified in [RFC2822] Section 3 and to the
additional requirements of this specification. additional requirements of this specification.
An article that uses the obsolete syntax specified in section 4 of An article that uses the obsolete syntax specified in Section 4 of
[RFC2822], except for the two exceptions mentioned below, is NOT [RFC2822], except for the two exceptions mentioned below, is NOT
conformant to this specification. conformant to this specification.
Articles are conformant if they use the <obs-phrase> construct (use Articles are conformant if they use the <obs-phrase> construct (use
of a phrase like "John Q. Public" without the use of quotes, see of a phrase like "John Q. Public" without the use of quotes, see
[RFC2822] section 4.1) but agents MUST NOT generate productions of [RFC2822] Section 4.1) but agents MUST NOT generate productions of
such syntax. such syntax.
Articles are conformant if they use the "GMT" <zone>, as specified in Articles are conformant if they use the "GMT" <zone>, as specified in
Section 3.1.2. Section 3.1.2.
This document, and specifications that build upon it, specifies how This document, and specifications that build upon it, specifies how
to handle conformant articles. Handling of non-conformant articles to handle conformant articles. Handling of non-conformant articles
is outside the scope of this specification. is outside the scope of this specification.
Agents conforming to this specification MUST generate only conformant Agents conforming to this specification MUST generate only conformant
skipping to change at page 10, line 41 skipping to change at page 12, line 41
The text below uses ABNF to specify restrictions on the syntax The text below uses ABNF to specify restrictions on the syntax
specified in [RFC2822]; this grammar is intended to be more specified in [RFC2822]; this grammar is intended to be more
restrictive than the [RFC2822] grammar. Articles must conform to the restrictive than the [RFC2822] grammar. Articles must conform to the
ABNF specified in [RFC2822]. ABNF specified in [RFC2822].
Articles must also conform to the restrictions specified here, both Articles must also conform to the restrictions specified here, both
those that are expressed as text and those that are expressed as those that are expressed as text and those that are expressed as
ABNF. ABNF.
NOTE: Older Netnews specifications used the term "header" as a NOTE: Other specifications use the term "header" as a synonym for
synonym for what [RFC2822] calls "header field". This document what [RFC2822] calls "header field". This document follows the
follows the terminology in Section 2 of [RFC2822] in using the terminology in Section 2 of [RFC2822] in using the terms "line",
terms "line", "header field", "header field name", "header field "header field", "header field name", "header field body", and
body", and "folding", based on a belief that consistent "folding", based on a belief that consistent terminology among
terminology among specifications that depend on each other makes specifications that depend on each other makes the specifications
the specifications easier to use in the long run. easier to use in the long run.
2.2. Header Fields 2.2. Header Fields
All header fields in a news article are compliant with [RFC2822], All header fields in a news article are compliant with [RFC2822],
however this specification is less permissive in what can be however this specification is less permissive in what can be
generated and accepted by news agents. The syntax allowed for news generated and accepted by news agents. The syntax allowed for news
articles is a strict subset of the "Internet Message Format", making articles is a strict subset of the "Internet Message Format", making
all messages compliant with this specification inherently compliant all messages compliant with this specification inherently compliant
with [RFC2822]. Note however that the converse is not guaranteed to with [RFC2822]. Note however that the converse is not guaranteed to
be true in all cases. be true in all cases.
General rules which apply to all header fields (even those documented General rules which apply to all header fields (even those documented
in [RFC2822] and [RFC2045]) are listed below and those that apply to in [RFC2822] and [RFC2045]) are listed below and those that apply to
specific header fields are described in the relevent sections of this specific header fields are described in the relevent sections of this
document. document.
o All agents MUST generate header fields so that at least one space o All agents MUST generate header fields so that at least one space
immediately follows the ':' separating the header field name and immediately follows the ':' separating the header field name and
the header field body (for compatibility with deployed software, the header field body (for compatibility with deployed software,
including [NNTP] servers). News agents MAY accept header fields including [I-D.ietf-nntpext-base] servers). News agents MAY
which do not contain the required space. accept header fields which do not contain the required space.
o Every line of a header field body (including the first and any o Every line of a header field body (including the first and any
that are subsequently folded) MUST contain at least one non- that are subsequently folded) MUST contain at least one non-
whitespace character. whitespace character.
NOTE: This means that no header field body defined by or NOTE: This means that no header field body 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 = *WSP utext *( [FWS] utext ) *WSP
NOTE: The [RFC2822] specification uses [FWS] at the beginning
of ABNF for header field content. This specification uses
*WSP. This is done for consistency with the restriction
described here, but the restriction applies to all header
fields, not just those where ABNF is defined in this document.
o Compliant software MUST NOT generate (but MAY accept) header o Compliant software MUST NOT generate (but MAY accept) header
fields of more than 998 octets. This is the only limit on the fields of more than 998 octets. This is the only limit on the
length of a header field prescribed by this standard. However, length of a header field prescribed by this standard. However,
specific rules to the contrary may apply in particular cases (for specific rules to the contrary may apply in particular cases (for
example, according to [RFC2047] lines of a header field containing example, according to [RFC2047] lines of a header field containing
encoded-words are limited to 76 octets). [USEAGE] includes encoded-words are limited to 76 octets). [I-D.ietf-usefor-useage]
suggested limits for convenience of display by user agents. includes suggested limits for 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 field may be split, and hence there is NO restriction a header field may be split, and hence there is NO restriction
on the total length of a header field (in particular it may, by on the total length of a header field (in particular it may, by
suitable folding, be made to exceed the 998 octets restriction suitable 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 header fields is US-ASCII. Where the use of o The character set for header fields is US-ASCII. Where the use of
non-ASCII characters is required, they MUST be encoded using the non-ASCII characters is required, they MUST be encoded using the
MIME mechanisms defined in [RFC2047] and [RFC2231]. MIME mechanisms defined in [RFC2047] and [RFC2231].
skipping to change at page 13, line 7 skipping to change at page 15, line 7
under the existing Email standards), permitting the use of [RFC2047] under the existing Email standards), permitting the use of [RFC2047]
encodings within any <unstructured> header field, or within any encodings within any <unstructured> header field, or within any
<comment> or <phrase> permittted within any structured header field. <comment> or <phrase> permittted within any structured header field.
User agents MAY accept and generate other MIME extension header User agents MAY accept and generate other MIME extension header
fields, and in particular SHOULD accept Content-Disposition [RFC2183] fields, and in particular SHOULD accept Content-Disposition [RFC2183]
and Content-Language [RFC3282]. and Content-Language [RFC3282].
3. News Header Fields 3. News Header Fields
The following news header fields extend those defined in section 3.6 The following news header fields extend those defined in Section 3.6
of [RFC2822]: of [RFC2822]:
fields =/ *( newsgroups / fields =/ *( newsgroups /
path / path /
injection-date / injection-date /
followup-to / followup-to /
expires / expires /
control / control /
supersedes / supersedes /
distribution / distribution /
summary / summary /
approved / approved /
organization / organization /
xref / xref /
archive / archive /
user-agent / user-agent /
injection-info ) injection-info /
lines )
Each of these header fields may occur at most once in a news article. Each of these header fields may occur at most once in a news article.
The following header fields defined in this document do not allow The following header fields defined in this document do not allow
comments (CFWS): comments (CFWS):
Newsgroups Newsgroups
Path Path
Followup-to Followup-to
Control Control
Supersedes Supersedes
Distribution Distribution
Xref Xref
Lines Lines
This also applies to the following header field defined in [RFC2822]: This also applies to the following header field defined in [RFC2822]:
Message-ID Message-ID
Several of these headers are mainly of interest to servers, and Most of these headers are mainly of interest to news servers, and
servers often need to process these fields very rapidly. news servers often need to process these fields very rapidly.
3.1. Mandatory Header Fields 3.1. Mandatory Header Fields
Each news article conformant with this specification MUST have Each news article conformant with this specification MUST have
exactly one of each of the following header fields: From, Date, exactly one of each of the following header fields: From, Date,
Message-ID, Subject, Newsgroups, Path. Message-ID, Subject, Newsgroups, Path.
3.1.1. From 3.1.1. From
The From header field is the same as that specified in Section 3.6.2 The From header field is the same as that specified in Section 3.6.2
skipping to change at page 14, line 29 skipping to change at page 16, line 29
"GMT" zone. "GMT" zone.
orig-date = "Date:" SP date-time CRLF orig-date = "Date:" SP date-time CRLF
NOTE: This specification does not change [RFC2822], which says NOTE: This specification does not change [RFC2822], which says
that agents MUST NOT generate <date-time> constructs which include that agents MUST NOT generate <date-time> constructs which include
any zone names defined by <obs-zone>. any zone names defined by <obs-zone>.
Software that accepts dates with unknown timezones SHOULD treat such Software that accepts dates with unknown timezones SHOULD treat such
timezones as equivalent to "-0000" when comparing dates, as specified timezones as equivalent to "-0000" when comparing dates, as specified
in [RFC2822] section 4.3. in [RFC2822] Section 4.3.
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.2.1 and including Injection-Date and Expires in Section 3.2.1 and
Section 3.2.4 respectively. Section 3.2.4 respectively.
3.1.3. Message-ID 3.1.3. Message-ID
The Message-ID header field contains a single unique message The Message-ID header field contains a single unique message
identifier. Netnews is more dependent on message identifier identifier. Netnews is more dependent on message identifier
uniqueness and fast comparison than Email is, and some news software uniqueness and fast comparison than Email is, and some news software
and standards [RFC0977] might have trouble with the full range of and standards [I-D.ietf-nntpext-base] might have trouble with the
possible <msg-id>s permitted by [RFC2822]; this section therefore full range of possible <msg-id>s permitted by [RFC2822]; this section
restricts the syntax of <msg-id> as compared to Section 3.6.4 of therefore restricts the syntax of <msg-id> as compared to Section
[RFC2822]. The global uniqueness requirement for <msg-id> in 3.6.4 of [RFC2822]. The global uniqueness requirement for <msg-id>
[RFC2822] is to be understood as applying across all protocols using in [RFC2822] is to be understood as applying across all protocols
such message identifiers, and across both Email and Netnews in using such message identifiers, and across both Email and Netnews in
particular. particular.
message-id = "Message-ID:" SP [FWS] msg-id [FWS] CRLF message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
msg-id = "<" id-left "@" id-right ">" msg-id = "<" 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 / ( "." *mqtext /
skipping to change at page 15, line 39 skipping to change at page 17, line 39
no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
mdtext = %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 MUST NOT be more than 250 octets in length. The msg-id 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. [I-D.ietf-nntpext-base]) can rely on a bounded length.
Observe that msg-id includes the < and >. Observe that msg-id includes the < and >.
Observe also that in contrast to the corresponding header field in Observe also that in contrast to the corresponding header field in
[RFC2822]: [RFC2822]:
o the syntax does not allow comments within the Message-ID header o the syntax does not allow comments within the Message-ID header
field, field,
o it ensures that no string of characters is quoted if it was o it ensures that no string of characters is quoted if it was
skipping to change at page 16, line 18 skipping to change at page 18, line 18
o there is no possibility for ">" or WSP to occur inside a <msg-id>, o there is no possibility for ">" or WSP to occur inside a <msg-id>,
whether quoted or not, and whether quoted or not, and
o even though commonly derived from <domain>s, <id-rights>s are o even though commonly derived from <domain>s, <id-rights>s are
case-sensitive (and thus, once created, are not to be altered case-sensitive (and thus, once created, are not to be altered
during subsequent transmission or copying) during subsequent transmission or copying)
This is to simplify processing by news servers and to ensure This is to simplify processing by news servers and to ensure
interoperability with existing implementations and compliance with interoperability with existing implementations and compliance with
[NNTP]. Thus, whereas under [RFC2822] the following <msg-id>s would [I-D.ietf-nntpext-base]. Thus, whereas under [RFC2822] the following
be considered semantically equivalent, <msg-id>s would be considered semantically equivalent,
<ab.cd@example.com> <ab.cd@example.com>
<"ab.cd"@example.com> <"ab.cd"@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>s. determine the identity of two <msg-id>s.
Also note that this updated ABNF applies wherever <msg-id> is used, Also note that this updated ABNF applies wherever <msg-id> is used,
skipping to change at page 16, line 51 skipping to change at page 18, line 51
NOTE: Section 3.6.4 of [RFC2822] recommends that the <id-right> NOTE: Section 3.6.4 of [RFC2822] recommends that the <id-right>
should be a domain name or a domain literal. Domain literals are should be a domain name or a domain literal. Domain literals are
troublesome since many IP addresses are not globally unique; troublesome since many IP addresses are not globally unique;
domain names are more likely to generate unique Message-IDs. domain names are more likely to generate unique Message-IDs.
3.1.4. Subject 3.1.4. Subject
The Subject header field is the same as that specified in Section The Subject header field is the same as that specified in Section
3.6.5 of [RFC2822] with the added restrictions detailed in 3.6.5 of [RFC2822] with the added restrictions detailed in
Section 2.2. Further discussion of the content of the Subject header Section 2.2. Further discussion of the content of the Subject header
field appears in [USEPRO] and [USEAGE]. field appears in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-
useage].
subject = "Subject:" SP unstructured CRLF subject = "Subject:" SP unstructured CRLF
3.1.5. Newsgroups 3.1.5. Newsgroups
The Newsgroups header field specifies the newsgroup(s) to which the The Newsgroups header field specifies the newsgroup(s) to which the
article is posted. article is posted.
newsgroups = "Newsgroups:" SP newsgroup-list CRLF newsgroups = "Newsgroups:" SP newsgroup-list CRLF
newsgroup-list = [FWS] newsgroup-name newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) [FWS] *( [FWS] "," [FWS] newsgroup-name ) *WSP
newsgroup-name = component *( "." component ) newsgroup-name = component *( "." component )
component = 1*component-char component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_" component-char = ALPHA / DIGIT / "+" / "-" / "_"
Folding the Newsgroups header field over several lines has been shown Folding the Newsgroups header field over several lines has been shown
to harm propagation significantly. Folded Newsgroups header fields to harm propagation significantly. Folded Newsgroups header fields
SHOULD NOT be generated, but MUST be accepted. SHOULD NOT be generated, but MUST be accepted.
skipping to change at page 17, line 39 skipping to change at page 19, line 40
refer to existing groups that do not conform to this naming scheme. refer to existing groups that do not conform to this naming scheme.
NOTE: All-digit components conflict with one widely used storage NOTE: All-digit components conflict with one widely used storage
scheme for articles. Mixed case groups cause confusion between scheme for articles. Mixed case groups cause confusion between
systems with case sensitive matching and systems with case systems with case sensitive matching and systems with case
insensitive matching of <newsgroup-name>s. insensitive matching of <newsgroup-name>s.
<component>s beginning with underline ("_") are reserved for use by <component>s beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT be generated by user future versions of this standard and MUST NOT be generated by user
agents (whether in Newsgroups header fields or in newgroup control agents (whether in Newsgroups header fields or in newgroup control
messages [USEPRO]). However, such names MUST be accepted by news messages [I-D.ietf-usefor-usepro]). However, such names MUST be
servers. accepted by news servers.
<component>s beginning with "+" and "-" are reserved for private use <component>s beginning with "+" and "-" are reserved for private use
and MUST NOT be generated by user agents (whether in Newsgroups and MUST NOT be generated by user agents (whether in Newsgroups
header fields or in newgroup control messages [USEPRO]) without a header fields or in newgroup control messages [I-D.ietf-usefor-
private prior agreement to do so. However, such names MUST be usepro]) without a private prior agreement to do so. However, such
accepted by news servers. names MUST be accepted by news servers.
The following <newsgroup-name>s are reserved, and MUST NOT be used as The following <newsgroup-name>s are reserved, and MUST NOT be used as
the name of a newsgroup: the name of a newsgroup:
o Groups whose first (or only) component is "example" o Groups whose first (or only) component is "example"
o The group "poster" o The group "poster"
The following <newsgroup-name&gts have been used for specific The following <newsgroup-name>s have been used for specific purposes
purposes in various implementations and protocols, and therefore MUST in various implementations and protocols, and therefore MUST NOT be
NOT be used for the names of normal newsgroups. They MAY be used for used for the names of normal newsgroups. They MAY be used for their
their specific purpose, or by local agreement. specific purpose, or by local agreement.
Groups whose first (or only) component is "to" o Groups whose first (or only) component is "to"
Groups whose first (or only) component is "control" o Groups whose first (or only) component is "control"
Groups which contain (or consist only of) the component "all" o Groups which contain (or consist only of) the component "all"
Groups which contain (or consist only of) the component "ctl" o Groups which contain (or consist only of) the component "ctl"
The group "junk" o The group "junk"
NOTE: "example.*" is reserved for examples in this and other NOTE: "example.*" is reserved for examples in this and other
standards; "poster" has a special meaning in the Followup-To standards; "poster" has a special meaning in the Followup-To
header field; "to.*" is reserved for certain point-to-point header field; "to.*" is reserved for certain point-to-point
communications in conjunction with the "ihave" control message communications in conjunction with the "ihave" control message
[USEPRO]; "control.*" and "junk" have special meanings in some [I-D.ietf-usefor-usepro]; "control.*" and "junk" have special
news-servers; "all" is used as a wildcard in some implementations; meanings in some news-servers; "all" is used as a wildcard in some
and "ctl" was formerly used to indicate a <control-command> within implementations; and "ctl" was formerly used to indicate a
the Subject header field. <control-command> within the Subject header field.
3.1.6. Path 3.1.6. Path
The Path header field indicates the route taken by an article since The Path header field indicates the route taken by an article since
its injection into the Netnews system. Each agent that processes an its 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 field body. This is primarily to enable news servers to avoid header field body. This is primarily to enable news servers to avoid
sending articles to sites already known to have them, in particular sending articles to sites already known to have them, in particular
the site they came from, and additionally to permit tracing the route the site they came from, and additionally to permit tracing the route
articles take in moving over the network, and for gathering Usenet articles take in moving over the network, and for gathering
statistics. statistics.
path = "Path:" SP path-list CRLF path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list = [FWS] path-list = *( path-identity [FWS] [path-diagnostic] "!" )
*( ( path-identity / path-keyword /
path-diagnostic ) [FWS]
path-delimiter [FWS] )
tail-entry [FWS]
path-identity = ( ALPHA / DIGIT ) path-diagnostic = diag-match / diag-mismatch / diag-seen /
*( ALPHA / DIGIT / "-" / "." / "_" ) diag-posted / diag-deprecated
path-keyword = "POSTED" / "MISMATCH" diag-match = "!" ; an additional "!"
path-diagnostic = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) diag-seen = "!.SEEN." diag-identity
tail-entry = path-identity diag-mismatch = "!.MISMATCH." diag-identity
path-delimiter = "!" / "!!" diag-posted = "!.POSTED" [ "." diag-identity ]
diag-deprecated = "!" 1*( path-nodot "." ) path-nodot
diag-identity = path-identity / IPv4address / IPv6address
tail-entry = path-nodot
; recommended to be "not-for-mail"
path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
label = alphanum [ *( alphanum / "-" ) alphanum ]
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
( label 1*( "-" ) label )
alphanum = ALPHA / DIGIT ; compare RFC3696
A <path-identity> is a name identifying a site. It takes the form of A <path-identity> is a name identifying a site. It takes the form of
a domain name having one or more components separated by dots. a domain name having one or more components separated by dots.
Each <path-identity> in the <path-list> (excluding the one in the Each <path-identity> in the <path-list> (excluding the one in the
<tail-entry>) indicates, from right to left, the successive agents <tail-entry>) indicates, from right to left, the successive agents
through which the article has passed. The <path-keyword> "POSTED" through which the article has passed. The <path-keyword> "POSTED"
indicates that the agent to its left injected the article. The use indicates that the agent to its left injected the article. The use
of the <path-delimiter> "!!" indicates that the agent to its left of the <path-delimiter> "!!" indicates that the agent to its left
claims that the agent to its right was the verified source of the verified the identity of the agent to its right before accepting the
article (whereas the <path-delimiter> "!" implies no such claim). article (whereas the <path-delimiter> "!" implies no such claim).
The <path-keyword> "MISMATCH" indicates that the agent to its right The <path-keyword> "MISMATCH" indicates that the agent to its right
failed to be so verified. failed to be so verified.
NOTE: Historically, the <tail-entry> indicated the name of the
sender. If not used for this purpose, the string "not-for-mail"
is often used instead (since at one time the whole path could be
used as a mail address for the sender).
NOTE: Although case-insensitive, it is intended that the <path- NOTE: Although case-insensitive, it is intended that the <path-
keyword>s "POSTED" and "MISMATCH" should be in upper case, to keyword>s "POSTED" and "MISMATCH" should be in upper case, to
distinguish them from the <path-identity>s which are traditionally distinguish them from the <path-identity>s which are traditionally
in lower case. in lower case.
A <path-diagnostic> is an item inserted into the Path header for A <path-diagnostic> is an item inserted into the Path header for
purposes other than to indicate the name of a site. One commonly purposes other than to indicate the name of a site. One commonly
observed usage is to insert an IP address. The colon (":") is observed usage is to insert an IP address. The colon (":") is
permitted in order to allow IPv6 addresses to be inserted; note that permitted in order to allow IPv6 addresses to be inserted; note that
this will cause interoperability problems at older sites that regard this will cause interoperability problems at older sites that regard
":" as a <path-delimiter> and have neighbors whose names have 4 or ":" as a <path-delimiter> and have neighbors whose names have 4 or
fewer characters, and where all the characters are valid HEX digits. fewer characters, and where all the characters are valid HEX digits.
3.2. Optional Header Fields 3.2. Optional Header Fields
None of the header fields appearing in this section is required to None of the header fields appearing in this section is required to
appear in every article but some of them may be required in certain appear in every article but some of them may be required in certain
types of articles. Further discussion of these requirements appears types of articles. Further discussion of these requirements appears
in [USEPRO] and [USEAGE]. in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage].
The header fields Reply-To, Sender, Comments, and Keywords are used The header fields Reply-To, Sender, Comments, and Keywords are used
in news articles in the same circumstances and with the same meaning in news articles in the same circumstances and with the same meaning
as that specified in [RFC2822] with the added restrictions detailed as that specified in [RFC2822] with the added restrictions detailed
in Section 2.2. Multiple occurances of the Keywords header field are in Section 2.2. Multiple occurances of the Keywords header field are
not permitted. not 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
skipping to change at page 20, line 48 skipping to change at page 23, line 19
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 news server. already expired by the time they arrive at some news server.
This header field MUST be inserted whenever an article is injected. This header field MUST be inserted whenever an article is injected.
However, software that predates this standard does not use this However, software that predates this standard does not use this
header, and therefore agents MUST accept articles without the header, and therefore agents MUST accept articles without the
Injection-Date header field. Injection-Date header field.
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 <date- See the remarks under Section 3.1.2 regarding the syntax of
time> and the requirements and recommendations to which it is <date-time> and the requirements and recommendations to which it is
subject. subject.
NOTE: The <date-time> in this header field would normally be NOTE: The <date-time> in this header field would normally be
expected to be later than the <date-time> in the Date header expected to be later than the <date-time> in the Date header
field, but differences between the clocks on the various agents field, but differences between the clocks on the various agents
and other special circumstances might vitiate that; no provision and other special circumstances might vitiate that; no provision
is made for any such discrepancy to be corrected - better that the is made for any such discrepancy to be corrected - better that the
news server should just insert the correct time as it sees it. news server should just insert the correct time as it sees it.
This header field is intended to replace the currently-used but This header field is intended to replace the currently-used but
skipping to change at page 21, line 44 skipping to change at page 24, line 15
3.2.3. Followup-To 3.2.3. Followup-To
The Followup-To header field specifies to which newsgroup(s) The Followup-To header field specifies to which newsgroup(s)
followups should be posted. The Followup-To header field SHOULD NOT followups should be posted. The Followup-To header field SHOULD NOT
appear in a message, unless its content is different from the content appear in a message, unless its content is different from the content
of the Newsgroups header field. of the Newsgroups header field.
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 = *WSP %d112.111.115.116.101.114 *WSP
; "poster" in lower-case ; "poster" in lower-case
The syntax is the same as that of the Newsgroups header field The syntax is the same as that of the Newsgroups header field
(Section 3.1.5, with the exception that the keyword "poster" (which (Section 3.1.5, with the exception that the keyword "poster" (which
is always lowercase) requests that followups should be mailed to the is always lowercase) requests that followups should be mailed to the
article's reply address rather than posted. Although the keyword article's reply address rather than posted. Although the keyword
"poster" is case-sensitive, user agents MAY choose to recognize case- "poster" is case-sensitive, user agents MAY choose to recognize case-
insensitive forms such as "Poster". insensitive forms such as "Poster".
3.2.4. Expires 3.2.4. Expires
The Expires header field specifies a date and time when the article The Expires header field specifies a date and time when the article
is deemed to be no longer relevant and could usefully be removed is 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 <date- See the remarks under Section 3.1.2 regarding the syntax of
time> and the requirements and recommendations to which it is <date-time> and the requirements and recommendations to which it is
subject. subject.
NOTE: The Expires header field is also sometimes used in Email
with a similar meaning [RFC2156].
3.2.5. Control 3.2.5. Control
The Control header field marks the article as a control message, and The Control header field 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-command [FWS] CRLF control = "Control:" SP *WSP control-command *WSP CRLF
control-command = verb *( [FWS] argument ) control-command = verb *( 1*WSP argument )
verb = token verb = token
argument = value argument = 1*( %x21-7E )
The verb indicates what action should be taken, and the argument(s) The verb indicates what action should be taken, and the argument(s)
(if any) supply details. In some cases, the body of the article may (if any) supply details. In some cases, the body of the article may
also contain details. The legal verbs and respective arguments are also contain details. The legal verbs and respective arguments are
discussed in the companion document, [USEPRO]. discussed in the companion document, [I-D.ietf-usefor-usepro].
An article with a Control header field MUST NOT also have a An article with a Control header field MUST NOT also have a
Supersedes header field. Supersedes header field.
3.2.6. Supersedes 3.2.6. Supersedes
The Supersedes header field contains a message identifier specifying The Supersedes header field contains a message identifier specifying
an article to be superseded upon the arrival of this one. An article an article to be superseded upon the arrival of this one. An article
containing a Supersedes header field is equivalent to a "cancel" containing a Supersedes header field is equivalent to a "cancel"
[USEPRO] control message for the specified article, followed [I-D.ietf-usefor-usepro] control message for the specified article,
immediately by the new article without the Supersedes header field. followed immediately by the new article without the Supersedes header
field.
supersedes = "Supersedes:" SP [FWS] msg-id [FWS] CRLF supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF
NOTE: There is no "c" in Supersedes. NOTE: There is no "c" in Supersedes.
NOTE: The Supersedes header field defined here has no connection with NOTE: The Supersedes header field defined here has no connection
the Supersedes header field that sometimes appears in Email messages with the Supersedes header field that sometimes appears in Email
converted from X.400 according to [RFC2156]; in particular, the messages converted from X.400 according to [RFC2156]; in
syntax here permits only one <msg-id> in contrast to the multiple particular, the syntax here permits only one <msg-id> in contrast
<msg-id>s in that Email version. to the multiple <msg-id>s in that Email version.
3.2.7. Distribution 3.2.7. Distribution
The Distribution header field specifies geographic or organizational The Distribution header field specifies geographic or organizational
limits on an article's propagation. limits on an article's propagation.
distribution = "Distribution:" SP dist-list CRLF distribution = "Distribution:" SP dist-list CRLF
dist-list = [FWS] dist-name dist-list = *WSP dist-name
*( [FWS] "," [FWS] dist-name ) [FWS] *( [FWS] "," [FWS] dist-name ) *WSP
dist-name = ALPHA / DIGIT dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" ) *( ALPHA / DIGIT / "+" / "-" / "_" )
The <dist-name>s "world" and "local" are predefined. However, The <dist-name>s "world" and "local" are predefined. However,
"world" SHOULD NOT be used explicitly, since it is the default when "world" SHOULD NOT be used explicitly, since it is the default when
the Distribution header field is absent entirely. the Distribution header field is absent entirely.
"All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain "All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain
at least three characters, except when they are two-letter country at least three characters, except when they are two-letter country
skipping to change at page 23, line 45 skipping to change at page 26, line 17
The Summary header field is a short phrase summarizing the article's The Summary header field is a short phrase summarizing the article's
content. content.
summary = "Summary:" SP unstructured CRLF summary = "Summary:" SP unstructured CRLF
3.2.9. Approved 3.2.9. Approved
The Approved header field indicates the mailing addresses (and The Approved header field indicates the mailing addresses (and
possibly the full names) of the persons or entities approving the possibly the full names) of the persons or entities approving the
article for posting. Its principal uses are in moderated articles article for posting. Its principal uses are in moderated articles
and in group control messages [USEPRO]. and in group control messages [I-D.ietf-usefor-usepro].
approved = "Approved:" SP mailbox-list CRLF approved = "Approved:" SP mailbox-list CRLF
Each mailbox contained in the Approved header field MUST be that of Each mailbox contained in the Approved header field MUST be that of
one of the person(s) or entity(ies) in question, and one of those one of the person(s) or entity(ies) in question, and one of those
mailboxes MUST be that of the actual sender of the article. Note mailboxes MUST be that of the actual sender of the article. Note
that this standard does not provide any means to enforce or verify that this standard does not provide any means to enforce or verify
this requirement, but future extensions or standards may provide such this requirement, but future extensions or standards may provide such
a facility (e.g. digitial signatures). a facility (e.g. digitial signatures).
skipping to change at page 24, line 23 skipping to change at page 26, line 44
There is no "s" in Organization. There is no "s" in Organization.
3.2.11. Xref 3.2.11. Xref
The Xref header field indicates where an article was filed by the The Xref header field indicates where an article was filed by the
last news server to process it. The article locations are used to last news server to process it. The article locations are used to
keep track of crossposted articles so that user agents serviced by a keep track of crossposted articles so that user agents serviced by a
particular news server can mark such articles as read. particular news server can mark such articles as read.
xref = "Xref:" SP [FWS] server-name xref = "Xref:" SP *WSP server-name
1*( FWS location ) [FWS] CRLF 1*( FWS location ) *WSP CRLF
server-name = path-identity server-name = path-identity
location = newsgroup-name ":" article-locator location = newsgroup-name ":" article-locator
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
news server generated the header field. The locations specify what news server generated the header field. 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 field) and where it was filed under them. in the Newsgroups header field) and where it was filed under them.
The exact form of an <article-locator> is implementation-specific. The exact form of an <article-locator> is implementation-specific.
NOTE: The traditional form of an <article-locator> (as required by NOTE: The traditional form of an <article-locator> (as required by
[NNTP]) is a decimal number, with articles in each newsgroup [I-D.ietf-nntpext-base]) is a decimal number, with articles in
numbered consecutively starting from 1. each newsgroup numbered consecutively starting from 1.
3.2.12. Archive 3.2.12. Archive
The Archive header field provides an indication of the poster's The Archive header field provides an indication of the poster's
intent regarding preservation of the article in publicly accessible intent regarding preservation of the article in publicly accessible
long-term or permanent storage. long-term or permanent storage.
archive = "Archive:" SP [CFWS] ("no" / "yes") archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" archive-param ) CRLF *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF
archive-param = parameter archive-param = parameter
The presence of an Archive header field in an article with a field The presence of an Archive header field in an article with a field
body of "no" indicates that the poster does not permit redistribution body of "no" indicates that the poster does not permit redistribution
from publicly accessible long-term or permanent archives. The from publicly accessible long-term or permanent archives. The
absence of this header field, or the presence of this header field absence of this header field, or the presence of this header field
with a field body of "yes", indicates that the poster is willing for with a field body of "yes", indicates that the poster is willing for
such redistribution to take place. Further extensions to this such redistribution to take place. Further extensions to this
standard may provide parameters for administration of the archiving standard may provide parameters for administration of the archiving
skipping to change at page 26, line 9 skipping to change at page 28, line 27
3.2.14. Injection-Info 3.2.14. Injection-Info
The Injection-Info header field contains information provided by the The Injection-Info header field contains information provided by the
injecting news server as to how an article entered the Netnews system injecting news server as to how an article entered the Netnews system
and to assist in tracing its true origin. It can also specify one or and to assist in tracing its true origin. It can also specify one or
more addresses where complaints concerning the poster of the article more addresses where complaints concerning the poster of the article
may be sent. may be sent.
injection-info = "Injection-Info:" SP [CFWS] path-identity injection-info = "Injection-Info:" SP [CFWS] path-identity
[CFWS] *(';' parameter) CRLF [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
NOTE: The syntax of <parameter> ([RFC2045] as amended by NOTE: The syntax of <parameter> ([RFC2045] as amended by
[RFC2231]), taken in conjunction with the folding rules of [RFC2231]), taken in conjunction with the folding rules of
[RFC0822], effectively allows [CFWS] to occur both before and [RFC0822], effectively allows [CFWS] to occur on either side of
after the <parameter>, and also on either side of its "=". the "=" inside a <parameter>.
The following table gives the <attribute> and the format of the The following table gives the <attribute> and the format of the
<value> for each <parameter> defined for use with this header field. <value> for each <parameter> defined for use with this header field.
At most one occurrence of each such <parameter> is allowed. At most one occurrence of each such <parameter> is allowed.
<attribute> format of <value> <attribute> format of <value>
-------------------- ----------------- -------------------- -----------------
"posting-host" a <host-value> "posting-host" a <host-value>
"posting-account" any <value> "posting-account" any <value>
"sender" a <sender-value> "sender" a <sender-value>
"logging-data" any <value> "logging-data" any <value>
"mail-complaints-to" an <address-list> "mail-complaints-to" an <address-list>
where where
host-value = dot-atom-text / [ dot-atom-text ":" ] host-value = dot-atom-text / IPv4address / IPv6address /
( IPv4address / IPv6address ) ; see [RFC 3986] (dot-atom-text ":" ( IPv4address / IPv6address ))
sender-value = mailbox / "verified" sender-value = mailbox / "verified"
NOTE: Since any such <host-value>>, <sender-value> or <address- NOTE: Since any such <host-value>>, <sender-value> or <address-
list> has also to be a syntactically correct <value>, it will list> has also to be a syntactically correct <value>, it will
usually be necessary to encapsulate is as a <quoted-string>, for usually be necessary to encapsulate it as a <quoted-string>, for
example: example:
posting-host = "posting@example.com:192.168.0.1"
sender = "\"Joe Q. Public\" <joe@example.com>" sender = "\"Joe Q. Public\" <joe@example.com>"
Additionally, any other <parameter> whose <attribute> starts with Additionally, any other <parameter> whose <attribute> starts with
"x-" MAY be used where the defined ones appear to be unsuitable, but "x-" MAY be used where the defined ones appear to be unsuitable, but
other unlisted <parameter>s SHOULD NOT be used unless defined in other unlisted <parameter>s SHOULD NOT be used unless defined in
extensions to this standard. extensions to this standard.
Although comments and folding of white space are permitted throughout Although comments and folding of white space are permitted throughout
the Injection-Info header field, it is RECOMMENDED that folding is the Injection-Info header field, it is RECOMMENDED that folding is
not used within any <parameter> (but only before or after the ";" not used within any <parameter> (but only before or after the ";"
skipping to change at page 27, line 17 skipping to change at page 29, line 36
X-Complaints-To, and others. Once a news server uses Injection- X-Complaints-To, and others. Once a news server uses Injection-
Info, it should have no need to send these non-standard header Info, it should have no need to send these non-standard header
fields. fields.
The "posting-host" <parameter> specifies the FQDN and/or IP address The "posting-host" <parameter> specifies the FQDN and/or IP address
(IPv4address or IPv6address) of the host from which the news server (IPv4address or IPv6address) of the host from which the news server
received the article. received the article.
NOTE: If the "posting-host" <parameter> identifies a dial-up NOTE: If the "posting-host" <parameter> identifies a dial-up
point-of-presence, the "posting-account" or the "logging-data" point-of-presence, the "posting-account" or the "logging-data"
<parameter> may provide additional information about true origin <parameter> may provide additional information about the true
of the article. origin of the article.
The "posting-account" <parameter> identifies the source from which The "posting-account" <parameter>> identifies the source from which
that news server received the article. For security reasons, it that news server received the article, in a notation that can be
SHOULD be in a cryptic notation understandable only by the interpreted by the news server administrator. This notation can
administrator of the news server. include any information the administrator deems pertinent, such as
the authorized and/or authenticated identity of the poster. In order
to limit the exposure of personal data, it SHOULD be given in a form
that can't be interpreted by other sites, but two messages posted
from the same account SHOULD have the same value of "posting-
account".
The "sender" <parameter> identifies the mailbox of the verified The "sender" <parameter>> identifies a mailbox that the news server
sender of the article (alternatively, it uses the token "verified" to configuration shows as one that can be used to reach the user posting
indicate that at least any addr-spec in the Sender header field of the article. There is no implied relationship between the "sender"
the article, or in the From header field if the Sender header field parameter and the "From" or "Sender" header fields of the article.
is absent, is correct). If a news server can verify the sender of an
article, it SHOULD use this <parameter> in favor of the "posting- It is a matter of local policy whether to include the "posting-
account" <parameter>. account" <parameter>>, the "sender" <parameter>, both, or neither.
The "logging-data" <parameter> contains information (typically a The "logging-data" <parameter> contains information (typically a
session number or other non-persistent means of identifying a posting session number or other non-persistent means of identifying a posting
account) which will enable the true origin of the article to be account) which will enable the true origin of the article to be
determined by reference to logging information kept by the news determined by reference to logging information kept by the news
server. server.
The "mail-complaints-to" <parameter> specifies mailbox(es) for The "mail-complaints-to" <parameter> specifies mailbox(es) for
sending complaints concerning the behavior of the poster of the sending complaints concerning the behavior of the poster of the
article. article.
skipping to change at page 28, line 9 skipping to change at page 30, line 34
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 news server Relay-Version contained version information about the news server
that last processed the article. Posting-Version contained version that last processed the article. Posting-Version contained version
information about the user agent that posted the article. Date- information about the user agent that posted the article. Date-
Received contained the date when the last news server to process the Received contained the date when the last news server to process the
article first saw it (in a slightly nonstandard format). article first saw it (in a slightly nonstandard format).
These header fields are mentioned for historical purposes only.
Agents MUST NOT generate articles containing these header fields.
In addition, this present standard obsoletes certain header fields In addition, this present standard obsoletes certain header fields
defined in [Son-of-1036]: defined 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
skipping to change at page 28, line 35 skipping to change at page 31, line 15
The header fields listed above are documented for historical purposes The header fields listed above are documented for historical purposes
only. Articles containing these header fields MUST NOT be generated. only. Articles containing these header fields MUST NOT be generated.
Persons writing new agents SHOULD ignore any former meanings of these Persons writing new agents SHOULD ignore any former meanings of these
header fields. header fields.
3.3.1. Lines 3.3.1. Lines
The Lines header field indicates the number of lines in the body of The Lines header field indicates the number of lines in the body of
the article. the article.
lines = "Lines" ":" SP [FWS] 1*DIGIT [FWS] CRLF lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF
The line count includes all body lines, including the signature if The line count includes all body lines, including the signature if
any, including empty lines (if any) at the beginning or end of the any, including empty lines (if any) at the beginning or end of the
body, and including the whole of all MIME message and multipart parts body, and including the whole of all MIME message and multipart parts
contained in the body (the single empty separator line between the contained in the body (the single empty separator line between the
header fields and the body is not part of the body). The "body" here header fields and the body is not part of the body). The "body" here
is the body as found in the posted article as transmitted by the user is the body as found in the posted article as transmitted by the user
agent. agent.
Historically, this header field was used by the [NNTP] overview Historically, this header field was used by the [I-D.ietf-nntpext-
extension, but its use for this purpose is now deprecated. As a base] Overview facility, but its use for this purpose is now
result, this header field is to be regarded as obsolescent, and it is deprecated. As a result, this header field is to be regarded as
likely to be removed entirely in a future version of this standard. obsolescent, and it is likely to be removed entirely in a future
Servers and clients SHOULD ignore it, and SHOULD NOT generate it. version of this standard. Servers and clients SHOULD ignore it, and
SHOULD NOT generate it.
4. Internationalization Considerations 4. Internationalization Considerations
Internationalization of news article header fields and bodies is Internationalization of news article header fields and bodies is
provided using MIME mechanisms discussed in Section 2.3. Note that provided using MIME mechanisms discussed in Section 2.3. Note that
the generation of internationalized <newsgroup name>s for use in the generation of internationalized <newsgroup-name>s for use in
header fields is not addressed in this document. header fields is not addressed in this document.
5. Security Considerations 5. Security Considerations
The news article format specified in this document does not provide The news article format specified in this document does not provide
any security services, such as confidentiality, authentication of any security services, such as confidentiality, authentication of
sender, or non-repudiation. Instead, such services need to be sender, or non-repudiation. Instead, such services need to be
layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME
[RFC3156], or below, using secure versions of news transport [RFC3156], or below, using secure versions of news transport
protocols. Additionally, several currently non-standardized protocols. Additionally, several currently non-standardized
skipping to change at page 31, line 5 skipping to change at page 34, line 5
correctly; examples of hard-to-parse constructs are: correctly; examples of hard-to-parse constructs are:
Content-Type: multipart/mixed Content-Type: multipart/mixed
(; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/digest; Content-Type: multipart/digest;
boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
Such differences in parsing may be used as part of an attack. Such differences in parsing may be used as part of an attack.
6. References 6. IANA Considerations
6.1. Normative References IANA is requested to register the following header fields in the
Permanent Message Header Field Repository, in accordance with the
procedures set out in [RFC3864].
Header field name: Also-Control
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.15)
Header field name: Approved
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.9)
Header field name: Archive
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.12)
Header field name: Article-Names
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.17)
Header field name: Article-Updates
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.18)
Header field name: Comments
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.5)
Header field name: Control
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.5)
Header field name: Date
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.2),
[RFC2822] (Section 3.6.1)
Header field name: Distribution
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.7)
Header field name: Expires
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.4)
Header field name: Followup-To
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.3)
Header field name: From
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.1),
[RFC2822] (Section 3.6.2)
Header field name: Injection-Date
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.1)
Header field name: Injection-Info
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.14)
Header field name: Keywords
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.5)
Header field name: Lines
Applicable protocol: netnews
Status: deprecated
Author/change controller: IETF
Specification document(s): This document (Section 3.3.1)
Related information: [I-D.ietf-nntpext-base] (Section 8.1)
Header field name: Message-ID
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.3)
Related information: [RFC2822] (Section 3.6.4)
Header field name: Newsgroups
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.5)
Header field name: NNTP-Posting-Date
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): none
Header field name: NNTP-Posting-Host
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): none
Header field name: Organization
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.10)
Header field name: Path
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.6)
Header field name: References
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.2),
[RFC2822] (Section 3.6.4)
Header field name: Reply-To
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.2)
Header field name: See-Also
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.16)
Header field name: Sender
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.2)
Header field name: Subject
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.4),
[RFC2822] (Section 3.6.5)
Header field name: Summary
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.8)
Header field name: Supersedes
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.6)
Header field name: User-Agent
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.13)
Header field name: Xref
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.11)
7. References
7.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.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
skipping to change at page 31, line 38 skipping to change at page 39, line 38
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., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002. May 2002.
6.2. Informative References [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
7.2. Informative References
[I-D.ietf-nntpext-base]
Feather, C., "Network News Transfer Protocol",
draft-ietf-nntpext-base-27 (work in progress), June 2005.
[I-D.ietf-usefor-useage]
Lindsey, C., "Usenet Best Practice",
draft-ietf-usefor-useage-01 (work in progress),
March 2005.
[I-D.ietf-usefor-usepro]
Lindsey, C., "News Article Architecture and Protocols",
draft-ietf-usefor-usepro-05 (work in progress),
January 2006.
[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",
draft-ietf-nntpext-base-*.txt.
[PGPVERIFY] [PGPVERIFY]
Lawrence, D., "PGPverify", June 1999. Lawrence, D., "PGPverify", June 1999.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[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, Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 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.
[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.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[Son-of-1036] [Son-of-1036]
Spencer, H., "News Article Format and Transmission", Spencer, H., "News Article Format and Transmission",
June 1994. June 1994.
[USEAGE] Lindsey, C., "Usenet Best Practice",
draft-ietf-usefor-useage-*.txt.
[USEPRO] Lindsey, C., "News Article Architecture and Protocols",
draft-ietf-usefor-usepro-*.txt.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Comments and/or text were provided by Mark Crispin, Claus Faerber, As this document is the result of an eight year effort, the number of
Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, people that have contributed to its content are too numerous to
Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey mention individually. Many thanks go out to all past and present
Melnikov. members of the USEFOR Working Group of the Internet Engineering Task
Force (IETF) and the accompanying mailing list.
Appendix B. Differences from RFC 1036 and its derivatives Appendix B. Differences from RFC 1036 and its derivatives
This appendix contains a list of changes that have been made in the This appendix contains a list of changes that have been made in the
Netnews Article Format from earlier standards, specifically Netnews Article Format from earlier standards, specifically
[RFC1036]. [RFC1036].
The [RFC2822] conventions for parenthesis-enclosed <comment>s in o The [RFC2822] conventions for parenthesis-enclosed <comment>s in
header fields are supported in all newly defined header fields and header fields are supported in all newly defined header fields and
in header fields inherited from [RFC2822]. They are, however, in header fields inherited from [RFC2822]. They are, however,
still disallowed for performance and/or compatibility reasons in still disallowed for performance and/or compatibility reasons in
the Message-ID, Newsgroups, Path, Followup-To, Control, the Message-ID, Newsgroups, Path, Followup-To, Control,
Supersedes, Distribution, Xref and Lines header fields. Supersedes, Distribution, Xref and Lines header fields.
Whitespace is permitted in Newsgroups header fields. o Whitespace is permitted in Newsgroups header fields.
An enhanced syntax for the Path header field enables the injection o An enhanced syntax for the Path header field enables the injection
point of, and the route taken by an article to be determined with point of, and the route taken by an article to be determined with
more precision. more precision.
MIME is recognized as an integral part of Netnews. o MIME is recognized as an integral part of Netnews.
There is a new Injection-Date header to make the rejection of o There is a new Injection-Date header to make the rejection of
stale articles more precise and to minimize spurious rejections. stale articles more precise and to minimize spurious rejections.
There are several new optional header fields defined, notably o There are several new optional header fields defined, notably
Archive, Injection-Info and User-Agent, leading to increased Archive, Injection-Info and User-Agent, leading to increased
functionality. functionality.
Certain header fields, notably Lines, have been made obsolete o Certain header fields, notably Lines, have been made obsolete
(Section 3.3). (Section 3.3).
There are numerous other small changes, clarifications and o The convention to interpret subjects starting with the word "cmsg"
as a control message was removed.
o There are numerous other small changes, clarifications and
enhancements. enhancements.
Appendix C. Differences from RFC 2822 Appendix C. Differences from RFC 2822
This appendix lists the differences between the syntax allowed by the This appendix lists the differences between the syntax allowed by the
Netnews Article Format (this document) as compared to the Internet Netnews Article Format (this document) as compared to the Internet
Message Format, as specified in [RFC2822]. Message Format, as specified in [RFC2822].
The Netnews article format is a strict subset of the Internet Message The Netnews article format is a strict subset of the Internet Message
Format; all Netnews articles conform to the syntax of [RFC2822]. Format; all Netnews articles conform to the syntax of [RFC2822].
The following restrictions are important: The following restrictions are important:
A SP (space) is REQUIRED after the colon (':') following header o A SP (space) is REQUIRED after the colon (':') following a header
field name. field name.
A more restricted syntax of <msg-id> (to be used by the o A more restricted syntax of <msg-id> (to be used by the
Message-ID, References, and Supersedes header fields) is defined. Message-ID, References, and Supersedes header fields) is defined.
The length of a msg-id MUST NOT exceed 250 octets. o The length of a <msg-id> MUST NOT exceed 250 octets.
Comments are not allowed in the Message-ID header field. o Comments are not allowed in the Message-ID header field.
The CFWS between <msg-id>s in the References header field is not o The CFWS between <msg-id>s in the References header field is not
optional. optional.
It is legal for a parser to not accept obsolete syntax, except o It is legal for a parser to reject obsolete syntax, except that:
that:
The <obs-phrase> construct MUST be accepted. * The <obs-phrase> construct MUST be accepted.
The obsolete <zone> "GMT" MUST be accepted within a <date- * The obsolete <zone> "GMT" MUST be accepted within a
time>. <date-time>.
Every line of a header field body (including the first and any o Every line of a header field body (including the first and any
that are subsequently folded) MUST contain at least one non- that are subsequently folded) MUST contain at least one non-
whitespace character. This means that an empty header field body whitespace character. This means that an empty header field body
is illegal. is illegal.
Authors' Addresses Authors' Addresses
Kenneth Murchison (editor) Kenneth Murchison (editor)
Carnegie Mellon University Carnegie Mellon University
5000 Forbes Avenue 5000 Forbes Avenue
Cyert Hall 285 Cyert Hall 285
skipping to change at page 37, line 41 skipping to change at page 46, 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 (2005). This document is subject Copyright (C) The Internet Society (2006). 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. 131 change blocks. 
263 lines changed or deleted 565 lines changed or added

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