draft-ietf-usefor-usefor-07.txt   draft-ietf-usefor-usefor-08.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: September 6, 2006 University of Manchester Expires: November 23, 2006 University of Manchester
D. Kohn D. Kohn
Skymoon Ventures FlyDash, Inc.
March 5, 2006 May 22, 2006
Netnews Article Format Netnews Article Format
draft-ietf-usefor-usefor-07 draft-ietf-usefor-usefor-08
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 September 6, 2006. This Internet-Draft will expire on November 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies the syntax of network news (Netnews) articles This document specifies the syntax of Netnews articles in the context
in the context of the "Internet Message Format" (RFC 2822) and of the "Internet Message Format" (RFC 2822) and "Multipurpose
"Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This Internet Mail Extensions (MIME)" (RFC 2045). This document
document supersedes RFC 1036, updating it to reflect current practice supersedes RFC 1036, updating it to reflect current practice and
and incorporating incremental changes specified in other documents. incorporating incremental changes specified in other documents.
Changes since draft-ietf-usefor-usefor-07
o Reworked ABNF for Path header field keywords (ticket #1047).
o Removed definition of "sender" in Injection-Info header field
(ticket #1159).
o Reworded description of "posting-account" in Injection-Info header
field (ticket #1159).
o Discussed the use of [FWS] in Newsgroups, Followup-To, and
Distribution header fields (ticket #1178).
o Further clarification of *WSP vs. [FWS] in Section 2.2 (ticket
#1179).
o Miscellaneous editorial changes from Dan Kohn.
Changes since draft-ietf-usefor-usefor-06 Changes since draft-ietf-usefor-usefor-06
o Reworked ABNF for Path header field delimiters and components o Reworked ABNF for Path header field delimiters and components
(ticket #1047). (ticket #1047).
o Imported ABNF elements from reference docs (ticket #1155). o Imported ABNF elements from reference docs (ticket #1155).
o Added IANA registration for header fields per RFC 3864 (ticket o Added IANA registration for header fields per RFC 3864 (ticket
#1156). #1156).
skipping to change at page 6, line 10 skipping to change at page 7, line 7
Issues to be addressed Issues to be addressed
o Path header field delimiters and components ABNF (ticket #1047). o Path header field delimiters and components ABNF (ticket #1047).
o Whitespace in Path header field (ticket #1178). Editor isn't o Whitespace in Path header field (ticket #1178). Editor isn't
clear on what the issue actually is. clear on what the issue actually is.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 8 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 9
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
1.6. Structure of This Document . . . . . . . . . . . . . . . . 10 1.6. Structure of This Document . . . . . . . . . . . . . . . . 11
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 13
2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 14 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 15
3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 15 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 15 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 16
3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 16 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 17
3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 19 3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 20
3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 22 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 23
3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 23 3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 23
3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 23 3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 24 3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 25 3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 26
3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 25 3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 26
3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 26 3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 27
3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 27 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 28
3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 28 3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 29
3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 30 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 31
3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 32
4. Internationalization Considerations . . . . . . . . . . . . . 32 4. Internationalization Considerations . . . . . . . . . . . . . 33
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . . 39 7.1. Normative References . . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . . 39 7.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 43
Appendix B. Differences from RFC 1036 and its derivatives . . . . 43 Appendix B. Differences from RFC 1036 and its derivatives . . . . 44
Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 44 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 47
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
articles posted to each newsgroup in which he participates. These articles posted to each newsgroup in which he participates. These
protocols most commonly use a flooding algorithm which propagates protocols most commonly use a flooding algorithm which propagates
copies throughout a network of participating servers. Typically, copies throughout a network of participating servers. Typically,
only one copy is stored per server, and each server makes it only one copy is stored per server, and each server makes it
available on demand to readers able to access that server. available on demand to readers able to access that server.
1.2. Scope 1.2. Scope
This document specifies the syntax of network news (Netnews) articles This document specifies the syntax of Netnews articles in the context
in the context of the "Internet Message Format" [RFC2822] and of the "Internet Message Format" [RFC2822] and "Multipurpose Internet
"Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This Mail Extensions (MIME)" [RFC2045]. This document supersedes
document supersedes [RFC1036], updating it to reflect current [RFC1036], updating it to reflect current practice and incorporating
practice and incorporating changes and clarifications specified in changes and clarifications specified in other documents such as [Son-
other documents such as [Son-of-1036]. 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. [I-D.ietf-usefor-usepro] is also a standards-track articles. [I-D.ietf-usefor-usepro] is also a standards-track
document, and describes the protocol issues of Netnews articles, document, and describes the protocol issues of Netnews articles,
independent of transport protocols such as [I-D.ietf-nntpext-base]. independent of transport protocols such as [I-D.ietf-nntpext-base].
A best common practice document, [I-D.ietf-usefor-useage], describes A best common practice document, [I-D.ietf-usefor-useage], describes
implementation recommendations to improve interoperability and implementation recommendations to improve interoperability and
usability. 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. Although 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), local storage is outside of
differ from the one specified in this standard, local storage is 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 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
[RFC4234] and many constructs defined in [RFC2822], [RFC2045] as [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as
amended by [RFC2231], and [RFC3986], specifically: updated by [RFC2231], and [RFC3986], specifically:
token = <see RFC2045 Section 5.1> token = <see RFC2045 Section 5.1>
dot-atom-text = <see RFC2045 Section 5.1> dot-atom-text = <see RFC2045 Section 5.1>
parameter = <see RFC2231 Section 7> parameter = <see RFC2231 Section 7>
attribute = <see RFC2231 Section 7> attribute = <see RFC2231 Section 7>
FWS = <see RFC2822 Section 3.2.3> FWS = <see RFC2822 Section 3.2.3>
CFWS = <see RFC2822 Section 3.2.3> CFWS = <see RFC2822 Section 3.2.3>
atext = <see RFC2822 Section 3.2.4> atext = <see RFC2822 Section 3.2.4>
skipping to change at page 9, line 39 skipping to change at page 10, line 35
IPv6address = <see RFC3986 Section 3.2.2> IPv6address = <see RFC3986 Section 3.2.2>
IPv4address = <see RFC3986 Section 3.2.2> IPv4address = <see RFC3986 Section 3.2.2>
ALPHA = <see RFC4234 Appendix B.1> ALPHA = <see RFC4234 Appendix B.1>
CRLF = <see RFC4234 Appendix B.1> CRLF = <see RFC4234 Appendix B.1>
DIGIT = <see RFC4234 Appendix B.1> DIGIT = <see RFC4234 Appendix B.1>
DQUOTE = <see RFC4234 Appendix B.1> DQUOTE = <see RFC4234 Appendix B.1>
SP = <see RFC4234 Appendix B.1> SP = <see RFC4234 Appendix B.1>
Additionally, Section 3.1.3 updates the [RFC2822] definition of Additionally, Section 3.1.3 specifies a stricter definition of
<msg-id>. <msg-id> than the syntax in [RFC2822] Section 3.6.4.
1.5. Definitions 1.5. Definitions
An "article" is the unit of news, synonymous with an [RFC2822] An "article" is the unit of Netnews, analogous to 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 contrast to an "article", a "proto-article"
article" may lack some mandatory header fields. 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" that posted it or,
failing that, by the "news server". It distinguishes the article failing that, by the "news server". It distinguishes the article
from every other article ever posted anywhere. Articles with the from every other article ever posted anywhere. Articles with the
same message identifier are treated as if they are the same article same message identifier are treated as if they are the same article
regardless of any differences in the body or header fields. regardless of any differences in the body or header fields.
A "newsgroup" is a single news forum, a logical bulletin board, A "newsgroup" is a single forum having a name and intended for
having a name and nominally intended for articles on a specific articles on a specific topic. An article is "posted to" a single
topic. An article is "posted to" a single newsgroup or several newsgroup or several newsgroups. When an article is posted to more
newsgroups. When an article is posted to more than one newsgroup, it than one newsgroup, it is said to be "crossposted"; note that this
is said to be "crossposted"; note that this differs from posting the differs from posting the same text as part of each of several
same text as part of each of several articles, one per newsgroup. articles, one per newsgroup.
A newsgroup may be "moderated", in which case submissions are not A newsgroup may be "moderated", in which case submissions are not
posted directly, but mailed to a "moderator" for consideration and posted directly, but mailed to a "moderator" for consideration and
possible posting. Moderators are typically human but may be possible posting. Moderators are typically human but may be
implemented partially or entirely in software. implemented partially or entirely in software.
A "poster" is the person or software that composes and submits a A "poster" is the person or software that composes and submits a
possibly compliant article to a "user agent". The poster is possibly compliant article to a "user agent". The poster is
analogous to [RFC2822]'s author. analogous to an [RFC2822] author.
A "reader" is the person or software reading news articles. A "reader" is the person or software reading news articles.
A "followup" is an article containing a response to the contents of A "followup" is an article containing a response to the contents of
an earlier article, its "precursor". Every followup includes a an earlier article, its "precursor". Every followup includes a
"References" header field identifying that precursor (but note that "References" header field identifying that precursor (but note that
non-followup articles may also use a References header field). non-followup articles may also use a References header field).
A "control message" is an article which is marked as containing A "control message" is an article which is marked as containing
control information; a news server receiving such an article may control information; a news server receiving such an article may
skipping to change at page 11, line 4 skipping to change at page 11, line 50
articles and followups. articles and followups.
The generic term "agent" is used when describing requirements that The generic term "agent" is used when describing requirements that
apply to both user agents and news servers. apply to both user agents and news servers.
1.6. Structure of This Document 1.6. Structure of This Document
This document uses a cite by reference methodology, rather than This document uses a cite by reference methodology, rather than
repeating the contents of other standards, which could otherwise repeating the contents of other standards, which could otherwise
result in subtle differences and interoperability challenges. result in subtle differences and interoperability challenges.
Although this document is as a result rather short, it requires Although this document is as a result rather short, it requires
complete understanding and implementation of the normative references complete understanding and implementation of the normative references
to be compliant. to be compliant.
Section 2 defines the format of news articles. Section 3 details the Section 2 defines the format of Netnews articles. Section 3 details
header fields necessary to make an article suitable for the Netnews the header fields necessary to make an article suitable for the
environment. Netnews 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] is NOT conformant to this specification, except for
conformant to this specification. following two cases:
Articles are conformant if they use the <obs-phrase> construct (use o Articles are conformant if they use the <obs-phrase> construct
of a phrase like "John Q. Public" without the use of quotes, see (use of a phrase like "John Q. Public" without the use of quotes,
[RFC2822] Section 4.1) but agents MUST NOT generate productions of see [RFC2822] Section 4.1) but agents MUST NOT generate
such syntax. productions of such syntax.
Articles are conformant if they use the "GMT" <zone>, as specified in o Articles are conformant if they use the "GMT" <zone>, as specified
Section 3.1.2. in Section 3.1.2.
This document, and specifications that build upon it, specifies how This document, and specifications that build upon it, specify how to
to handle conformant articles. Handling of non-conformant articles handle conformant articles. Handling of non-conformant articles is
is outside the scope of this specification. outside the scope of this specification.
Agents conforming to this specification MUST generate only conformant Agents conforming to this specification MUST generate only conformant
articles. articles.
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
skipping to change at page 13, line 12 skipping to change at page 14, line 12
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 relevant 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 [I-D.ietf-nntpext-base] servers). News agents MAY including [I-D.ietf-nntpext-base] servers). News agents MAY
accept header fields 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, rather
document updates the <unstructured> construct from Section than using the <unstructured> syntax from Section 3.2.6 of
3.2.6 of [RFC2822] as follows: [RFC2822], this document uses a stricter definition:
unstructured = *WSP utext *( [FWS] utext ) *WSP unstructured = *WSP utext *( [FWS] utext ) *WSP
NOTE: The [RFC2822] specification uses [FWS] at the beginning NOTE: The [RFC2822] specification sometimes uses [FWS] at the
of ABNF for header field content. This specification uses beginning or end of ABNF describing header field content. This
*WSP. This is done for consistency with the restriction specification uses *WSP in such cases, also in cases where this
described here, but the restriction applies to all header specification redefines constructs from [RFC2822]. This is
fields, not just those where ABNF is defined in this document. 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). [I-D.ietf-usefor-useage] encoded-words are limited to 76 octets). [I-D.ietf-usefor-useage]
includes suggested limits for convenience of display by user includes suggested limits for convenience of display by user
agents. agents.
skipping to change at page 14, line 20 skipping to change at page 15, line 22
User agents MUST meet the definition of MIME-conformance in [RFC2049] User agents MUST meet the definition of MIME-conformance in [RFC2049]
and MUST also support [RFC2231]. This level of MIME Conformance and MUST also support [RFC2231]. This level of MIME Conformance
provides support for internationalization and multimedia in message provides support for internationalization and multimedia in message
bodies ([RFC2045], [RFC2046], [RFC2231]), and support for bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
internationalization of header fields ([RFC2047], [RFC2231]). Note internationalization of header fields ([RFC2047], [RFC2231]). Note
that [Errata] currently exist for [RFC2046] and [RFC2231]. that [Errata] currently exist for [RFC2046] and [RFC2231].
For the purposes of Section 5 of [RFC2047], all header fields defined For the purposes of Section 5 of [RFC2047], all header fields defined
in Section 3 of this standard are to be considered as "extension in Section 3 of this standard are to be considered as "extension
message header fields" (insofar as they are not already so considered message header fields", permitting the use of [RFC2047] encodings
under the existing Email standards), permitting the use of [RFC2047] within any <unstructured> header field, or within any <comment> or
encodings within any <unstructured> header field, or within any <phrase> permitted 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]:
skipping to change at page 15, line 34 skipping to change at page 16, line 34
injection-info / injection-info /
lines ) 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
Most of these headers are mainly of interest to news servers, and Most of these header fields are mainly of interest to news servers,
news servers often need to process these fields very rapidly. and news servers often need to process these fields very rapidly.
Thus some header fields prohibit comments.
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
of [RFC2822] with the added restrictions detailed in Section 2.2. of [RFC2822] with the added restrictions detailed in Section 2.2.
from = "From:" SP mailbox-list CRLF from = "From:" SP mailbox-list CRLF
3.1.2. Date 3.1.2. Date
The Date header field is the same as that specified in Sections 3.3 The Date header field is the same as that specified in Sections 3.3
and 3.6.1 of [RFC2822] with the added restrictions detailed in and 3.6.1 of [RFC2822] with the added restrictions detailed in
Section 2.2. However, the use of "GMT" as a time zone (part of <obs- Section 2.2. However, the use of "GMT" as a time zone (part of <obs-
zone>), although deprecated, is widespread in news articles today. zone>), although deprecated, is widespread in news articles today.
Therefore, agents MUST accept <date-time> constructs which use the Therefore, agents MUST accept <date-time> constructs that use the
"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
skipping to change at page 16, line 41 skipping to change at page 17, line 42
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 [I-D.ietf-nntpext-base] might have trouble with the and standards [I-D.ietf-nntpext-base] might have trouble with the
full range of possible <msg-id>s permitted by [RFC2822]; this section full range of possible <msg-id>s permitted by [RFC2822]. This
therefore restricts the syntax of <msg-id> as compared to Section section therefore restricts the syntax of <msg-id> as compared to
3.6.4 of [RFC2822]. The global uniqueness requirement for <msg-id> Section 3.6.4 of [RFC2822]. The global uniqueness requirement for
in [RFC2822] is to be understood as applying across all protocols <msg-id> in [RFC2822] is to be understood as applying across all
using such message identifiers, and across both Email and Netnews in protocols using such message identifiers, and across both Email and
particular. Netnews in particular.
message-id = "Message-ID:" SP *WSP msg-id *WSP 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
skipping to change at page 17, line 37 skipping to change at page 18, line 37
".." / "\\" / "\" DQUOTE ".." / "\\" / "\" DQUOTE
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 that accept
message identifiers as a parameter when retrieving an article message identifiers as a parameter when retrieving an article
(e.g. [I-D.ietf-nntpext-base]) 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 were
already a <dot-atom-text> (it MUST start or end with a ".", or already a <dot-atom-text> (it MUST start or end with a ".", or
contain at least one <mqspecial>), contain at least one <mqspecial>),
o it ensures that no single character is prefixed by a "\" in the o it ensures that no single character is prefixed by a "\" in the
form of a <quoted-pair> unless strictly necessary, form of a <quoted-pair> unless strictly necessary,
o it excludes all control characters, o it excludes all control characters,
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
skipping to change at page 18, line 38 skipping to change at page 19, line 38
Also note that this updated ABNF applies wherever <msg-id> is used, Also note that this updated ABNF applies wherever <msg-id> is used,
including the References header field discussed in Section 3.2.2 and including the References header field discussed in Section 3.2.2 and
the Supersedes header field discussed in Section 3.2.6. the Supersedes header field discussed in Section 3.2.6.
Some software will try to match the <id-right> of a <msg-id> in a Some software will try to match the <id-right> of a <msg-id> in a
case-insensitive fashion; some will match it in a case-sensitive case-insensitive fashion; some will match it in a case-sensitive
fashion. Implementations MUST NOT generate two Message-IDs where the fashion. Implementations MUST NOT generate two Message-IDs where the
only difference is the case of characters in the <id-right> part. only difference is the case of characters in the <id-right> part.
When generationg a <msg-id>, implementations SHOULD use a domain name When generating a <msg-id>, implementations SHOULD use a domain name
as the <id-right>. as the <id-right>.
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
skipping to change at page 19, line 24 skipping to change at page 20, line 24
newsgroup-list = *WSP newsgroup-name newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) *WSP *( [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 Not all servers support [FWS] in the list of newsgroups. In
to harm propagation significantly. Folded Newsgroups header fields particular, folding the Newsgroups header field over several lines
SHOULD NOT be generated, but MUST be accepted. has been shown to harm propagation significantly. [FWS] in the
<newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
A newsgroup component SHOULD NOT consist of digits only, and SHOULD A newsgroup component SHOULD NOT consist of digits only, and SHOULD
NOT contain uppercase letters. Such components MAY be used only to NOT contain uppercase letters. Such components MAY be used only to
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.
skipping to change at page 20, line 37 skipping to change at page 21, line 37
communications in conjunction with the "ihave" control message communications in conjunction with the "ihave" control message
[I-D.ietf-usefor-usepro]; "control.*" and "junk" have special [I-D.ietf-usefor-usepro]; "control.*" and "junk" have special
meanings in some news-servers; "all" is used as a wildcard in some meanings in some news-servers; "all" is used as a wildcard in some
implementations; and "ctl" was formerly used to indicate a implementations; and "ctl" was formerly used to indicate a
<control-command> within 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 at least one <path-identity> 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 articles take in moving over the network, and for gathering
statistics. statistics.
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list = *( path-identity [FWS] [path-diagnostic] "!" ) path-list = *( path-identity [FWS] [path-diagnostic] "!" )
path-diagnostic = diag-match / diag-mismatch / diag-seen / path-diagnostic = diag-match / diag-other / diag-deprecated
diag-posted / diag-deprecated
diag-match = "!" ; an additional "!"
diag-seen = "!.SEEN." diag-identity diag-match = "!" ; another "!"
diag-mismatch = "!.MISMATCH." diag-identity diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]
diag-posted = "!.POSTED" [ "." diag-identity ] diag-deprecated = "!" IPv4address [FWS]
diag-deprecated = "!" 1*( path-nodot "." ) path-nodot diag-keyword = 1*ALPHA ; see USEPRO
diag-identity = path-identity / IPv4address / IPv6address diag-identity = path-identity / IPv4address / IPv6address
tail-entry = path-nodot tail-entry = path-nodot
; recommended to be "not-for-mail" ; may be the string "not-for-mail"
path-identity = ( 1*( label "." ) toplabel ) / path-nodot path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
label = alphanum [ *( alphanum / "-" ) alphanum ] label = alphanum [ *( alphanum / "-" ) alphanum ]
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
( label *( "-" ) ALPHA [ *( "-" ) label ] ) / ( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
( label 1*( "-" ) label ) ( label 1*( "-" ) label )
alphanum = ALPHA / DIGIT ; compare RFC3696 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 two or more components separated by dots, or a
single name with no dots (<path-nodot>).
Each <path-identity> in the <path-list> (excluding the one in the Each <path-identity> in the <path-list> (which does not include 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 use of the <diag-match>,
indicates that the agent to its left injected the article. The use which appears as "!!", indicates that the agent to its left verified
of the <path-delimiter> "!!" indicates that the agent to its left the identity of the agent to its right before accepting the article
verified the identity of the agent to its right before accepting the (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
failed to be so verified.
NOTE: Historically, the <tail-entry> indicated the name of the NOTE: Historically, the <tail-entry> indicated the name of the
sender. If not used for this purpose, the string "not-for-mail" sender. If not used for this purpose, the string "not-for-mail" is
is often used instead (since at one time the whole path could be often used instead (since at one time the whole path could be used as
used as a mail address for the sender). 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 should be in upper case, to distinguish them from the
distinguish them from the <path-identity>s which are traditionally <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 field
purposes other than to indicate the name of a site. One commonly for purposes other than to indicate the name of a site. The use of
observed usage is to insert an IP address. The colon (":") is these is described in [I-D.ietf-usefor-usepro].
permitted in order to allow IPv6 addresses to be inserted; note that
this will cause interoperability problems at older sites that regard NOTE: One usage of a <path-diagnostic> is to record an IP address.
":" as a <path-delimiter> and have neighbors whose names have 4 or The fact that IPv6 addresses are allowed means that the colon (:) is
fewer characters, and where all the characters are valid HEX digits. permitted; note that this may cause interoperability problems at
older sites that regard ":" as a <path-delimiter> and have neighbors
whose names have 4 or 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 [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-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
skipping to change at page 23, line 23 skipping to change at page 24, line 17
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 See the remarks under Section 3.1.2 regarding the syntax of
<date-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: Since clocks on various agents may not be synchronized, the
expected to be later than the <date-time> in the Date header <date-time> in this header field may not be later than the Date
field, but differences between the clocks on the various agents header field, as would be expected. Agents SHOULD use the <date-
and other special circumstances might vitiate that; no provision time> they believe is correct when adding Inject-Info but SHOULD
is made for any such discrepancy to be corrected - better that the NOT alter the pre-existing Date header field.
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
undocumented "NNTP-Posting-Date" header field, whose use is now undocumented "NNTP-Posting-Date" header field, whose use is now
deprecated. deprecated.
3.2.2. References 3.2.2. References
The References header field is the same as that specified in Section The References header field is the same as that specified in Section
3.6.4 of [RFC2822] with the added restrictions detailed in 3.6.4 of [RFC2822] with the added restrictions detailed in
Section 2.2 and those listed below: Section 2.2 and those listed below:
skipping to change at page 24, line 18 skipping to change at page 25, line 12
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 = *WSP %d112.111.115.116.101.114 *WSP 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 (Section 3.1.5)
(Section 3.1.5, with the exception that the keyword "poster" (which header field, with the exception that the keyword "poster" requests
is always lowercase) requests that followups should be mailed to the that followups should be mailed to the article's reply address rather
article's reply address rather than posted. Although the keyword than posted. Agents MUST generate the keyword "poster" in lower-
"poster" is case-sensitive, user agents MAY choose to recognize case- case, but MAY choose to recognize case-insensitive forms such as
insensitive forms such as "Poster". "Poster".
As in the Newsgroups (Section 3.1.5) header field, [FWS] in the
<newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
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 See the remarks under Section 3.1.2 regarding the syntax of
skipping to change at page 25, line 50 skipping to change at page 26, line 49
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
names as in [ISO.3166.1988]. <dist-name>s are case-insensitive (i.e. names drawn from [ISO.3166.1988]. <dist-name>s are case-insensitive
"US", "Us", "uS", and "us" all specify the same distribution). (i.e. "US", "Us", "uS", and "us" all specify the same distribution).
[FWS] in the <dist-list> SHOULD NOT be generated, but MUST be
accepted.
3.2.8. Summary 3.2.8. Summary
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
skipping to change at page 26, line 35 skipping to change at page 27, line 38
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).
3.2.10. Organization 3.2.10. Organization
The Organization header field is a short phrase identifying the The Organization header field is a short phrase identifying the
poster's organization. poster's organization.
organization = "Organization:" SP unstructured CRLF organization = "Organization:" SP unstructured CRLF
There is no "s" in Organization. NOTE: 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 *WSP server-name xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF 1*( FWS location ) *WSP CRLF
skipping to change at page 28, line 29 skipping to change at page 29, line 38
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] *( ";" [CFWS] parameter ) [CFWS] CRLF [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
NOTE: The syntax of <parameter> ([RFC2045] as amended by NOTE: The syntax of <parameter> ([RFC2045] Section 5.1 as amended
[RFC2231]), taken in conjunction with the folding rules of by [RFC2231]), taken in conjunction with the folding rules of
[RFC0822], effectively allows [CFWS] to occur on either side of [RFC0822], effectively allows [CFWS] to occur on either side of
the "=" inside a <parameter>. 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>
"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 / IPv4address / IPv6address / host-value = dot-atom-text / IPv4address / IPv6address /
(dot-atom-text ":" ( IPv4address / IPv6address )) (dot-atom-text ":" ( IPv4address / IPv6address ))
sender-value = mailbox / "verified" NOTE: Since any such <host-value> or <address-list> also has to be
NOTE: Since any such <host-value>>, <sender-value> or <address- a syntactically correct <value>, it will usually be necessary to
list> has also to be a syntactically correct <value>, it will encapsulate it as a <quoted-string>, for example:
usually be necessary to encapsulate it as a <quoted-string>, for
example:
posting-host = "posting@example.com:192.168.0.1" posting-host = "posting@example.com:192.168.0.1"
sender = "\"Joe Q. Public\" <joe@example.com>" Other <attribute>s SHOULD NOT be used unless defined in extensions to
this standard. If non-standards-based <attribute>s are used, they
Additionally, any other <parameter> whose <attribute> starts with MUST begin with an "x-".
"x-" MAY be used where the defined ones appear to be unsuitable, but
other unlisted <parameter>s SHOULD NOT be used unless defined in
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, folding SHOULD NOT be used within
not used within any <parameter> (but only before or after the ";" any <parameter>. Folding SHOULD only occur before or after the ";"
separating those <parameter>s), and that comments are only used separating <parameter>s, and comments SHOULD only be used following
following the last <parameter>. the last <parameter>.
NOTE: Some of this information has previously been sent in non- NOTE: Some of this information has previously been sent in non-
standardized header fields such as NNTP-Posting-Host, X-trace, standardized header fields such as NNTP-Posting-Host, X-trace,
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 the true <parameter> may provide additional information about the true
origin 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, in a notation that can be that news server received the article, in a notation that can be
interpreted by the news server administrator. This notation can interpreted by the news server administrator. This notation can
include any information the administrator deems pertinent, such as include any information the administrator deems pertinent. In order
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 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 that can't be interpreted by other sites. However, to make it useful
from the same account SHOULD have the same value of "posting- for rate limiting and abuse detection, two messages posted from the
account". same source SHOULD have the same value of "posting-account", and two
messages from different sources SHOULD have differing values of
The "sender" <parameter>> identifies a mailbox that the news server "posting-account". The exact definition of "source" is left to the
configuration shows as one that can be used to reach the user posting discretion of the news server administrator.
the article. There is no implied relationship between the "sender"
parameter and the "From" or "Sender" header fields of the article.
It is a matter of local policy whether to include the "posting-
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) that 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 one or more mailboxes
sending complaints concerning the behavior of the poster of the for sending complaints concerning the behavior of the poster of the
article. article.
It is a matter of local policy which <parameter>s to include. Some
pieces of information have privacy implications; this is discussed in
[I-D.ietf-usefor-useage].
3.3. Obsolete Header Fields 3.3. Obsolete Header Fields
Early versions of news software following the modern format sometimes Early Netnews software sometimes generated header fields such as:
generated header fields like the following:
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Date-Received: Friday, 19-Nov-82 16:59:30 EST Date-Received: Friday, 19-Nov-82 16:59:30 EST
Relay-Version contained version information about the 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. These header fields are mentioned for historical purposes only.
Agents MUST NOT generate articles containing these header fields. Agents MUST NOT generate articles containing these header fields.
In addition, this present standard obsoletes certain header fields In addition, this standard obsoletes certain header fields defined in
defined in [Son-of-1036]: [Son-of-1036]:
Also-Control: cancel <9urrt98y53@site.example> Also-Control: cancel <9urrt98y53@site.example>
See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example> See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example>
Article-Names: comp.foo:charter Article-Names: comp.foo:charter
Article-Updates: <i4g587y@site1.example> Article-Updates: <i4g587y@site1.example>
Also-Control indicated a control message that was also intended to be Also-Control indicated a control message that was also intended to be
filed as a normal article. See-Also listed related articles, but filed as a normal article. See-Also listed related articles, but
without the specific relationship with followups that pertains to the without the specific relationship with followups that pertains to the
References header field. Article-Names indicated some special References header field. Article-Names indicated some special
significance of that article in relation to the indicated newsgroup. significance of that article in relation to the indicated newsgroup.
Article-Updates indicated that an earlier article was updated, Article-Updates indicated that an earlier article was updated,
without at the same time being superseded. without at the same time being superseded.
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. These header fields MUST NOT be generated and SHOULD be
Persons writing new agents SHOULD ignore any former meanings of these ignored.
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 *WSP 1*DIGIT *WSP 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
skipping to change at page 39, line 44 skipping to change at page 40, line 44
[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.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
7.2. Informative References 7.2. Informative References
[I-D.ietf-nntpext-base] [I-D.ietf-nntpext-base]
Feather, C., "Network News Transfer Protocol", Feather, C., "Network News Transfer Protocol",
draft-ietf-nntpext-base-27 (work in progress), June 2005. draft-ietf-nntpext-base-27 (work in progress), June 2005.
[I-D.ietf-usefor-useage] [I-D.ietf-usefor-useage]
skipping to change at page 40, line 48 skipping to change at page 42, line 5
"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 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
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.
Appendix A. Acknowledgements Appendix A. Acknowledgments
As this document is the result of an eight year effort, the number of As this document is the result of an eight year effort, the number of
people that have contributed to its content are too numerous to people that have contributed to its content are too numerous to
mention individually. Many thanks go out to all past and present mention individually. Many thanks go out to all past and present
members of the USEFOR Working Group of the Internet Engineering Task members of the USEFOR Working Group of the Internet Engineering Task
Force (IETF) and the accompanying mailing list. 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
skipping to change at page 43, line 33 skipping to change at page 44, line 33
o MIME is recognized as an integral part of Netnews. o MIME is recognized as an integral part of Netnews.
o 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.
o 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.
o Certain header fields, notably Lines, have been made obsolete o Certain header fields, notably Lines, have been deprecated or made
(Section 3.3). obsolete (Section 3.3).
o The convention to interpret subjects starting with the word "cmsg" o The convention to interpret subjects starting with the word "cmsg"
as a control message was removed. as a control message was removed.
o There are numerous other small changes, clarifications and 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
skipping to change at page 45, line 29 skipping to change at page 46, line 29
5 Clerewood Avenue 5 Clerewood Avenue
Heald Green Heald Green
Cheadle Cheadle
Cheshire SK8 3JU Cheshire SK8 3JU
GB GB
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clw.cs.man.ac.uk Email: chl@clw.cs.man.ac.uk
Dan Kohn Dan Kohn
Skymoon Ventures FlyDash, Inc.
3045 Park Boulevard 425 Alma St. #411
Palo Alto, CA 94306 Palo Alto, CA 94301
US US
Phone: +1 650 327 2600 Phone: +1 415 233 1000
Email: dan@dankohn.com Email: dan@dankohn.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 76 change blocks. 
227 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/