draft-ietf-usefor-usefor-10.txt   draft-ietf-usefor-usefor-11.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
Intended status: Standards Track University of Manchester Intended status: Standards Track University of Manchester
Expires: March 21, 2007 D. Kohn Expires: April 4, 2007 D. Kohn
FlyDash, Inc. FlyDash, Inc.
September 17, 2006 October 2006
Netnews Article Format Netnews Article Format
draft-ietf-usefor-usefor-10 draft-ietf-usefor-usefor-11
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 March 21, 2007. This Internet-Draft will expire on April 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies the syntax of Netnews articles in the context This document specifies the syntax of Netnews articles in the context
of the "Internet Message Format" (RFC 2822) and "Multipurpose of the "Internet Message Format" (RFC 2822) and "Multipurpose
Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes
RFC 1036, providing an updated specification to reflect current RFC 1036, providing an updated specification to reflect current
practice and incorporating incremental changes specified in other practice and incorporating incremental changes specified in other
documents. documents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . . 4
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6. Structure of This Document . . . . . . . . . . . . . . . . 7 1.6 Structure of This Document . . . . . . . . . . . . . . . . 7
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Header Fields . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10
3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 11 3 News Header Fields . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 11 3.1 Mandatory Header Fields . . . . . . . . . . . . . . . . . . 11
3.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1 Date . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2 From . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 12 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 15 3.1.4 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.5 Path . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.6. Subject . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 18 3.2 Optional Header Fields . . . . . . . . . . . . . . . . . . 18
3.2.1. Approved . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1 Approved . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.2 Archive . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3. Control . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.3 Control . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4. Distribution . . . . . . . . . . . . . . . . . . . . . 20 3.2.4 Distribution . . . . . . . . . . . . . . . . . . . . . 20
3.2.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.5 Expires . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.6. Followup-To . . . . . . . . . . . . . . . . . . . . . 21 3.2.6 Followup-To . . . . . . . . . . . . . . . . . . . . . . 21
3.2.7. Injection-Date . . . . . . . . . . . . . . . . . . . . 22 3.2.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 22
3.2.8. Injection-Info . . . . . . . . . . . . . . . . . . . . 22 3.2.8 Injection-Info . . . . . . . . . . . . . . . . . . . . 22
3.2.9. Organization . . . . . . . . . . . . . . . . . . . . . 24 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 24
3.2.10. References . . . . . . . . . . . . . . . . . . . . . . 24 3.2.10 References . . . . . . . . . . . . . . . . . . . . . . 24
3.2.11. Summary . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.12. Supersedes . . . . . . . . . . . . . . . . . . . . . . 25 3.2.12 Supersedes . . . . . . . . . . . . . . . . . . . . . . 25
3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 25 3.2.13 User-Agent . . . . . . . . . . . . . . . . . . . . . . 25
3.2.14. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.14 Xref . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 26 3.3 Obsolete Header Fields . . . . . . . . . . . . . . . . . . 26
3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . . 27
4. Internationalization Considerations . . . . . . . . . . . . . 28 4 Internationalization Considerations . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 7.1 Normative References . . . . . . . . . . . . . . . . . . . 35
7.2. Informative References . . . . . . . . . . . . . . . . . . 36 7.2 Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 38 Appendix A Acknowledgments . . . . . . . . . . . . . . . . . . . 38
Appendix B. Differences from RFC 1036 and its derivatives . . . . 39 Appendix B Differences from RFC 1036 and its derivatives . . . . 39
Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 40 Appendix C Differences from RFC 2822 . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 42
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 that is Email messages), and for exchanging them amongst a readership that 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 Netnews articles in the context This document specifies the syntax of Netnews articles in the context
of the "Internet Message Format" [RFC2822] and "Multipurpose Internet of the "Internet Message Format" [RFC2822] and "Multipurpose Internet
Mail Extensions (MIME)" [RFC2045]. This document obsoletes Mail Extensions (MIME)" [RFC2045]. This document obsoletes
[RFC1036], updating the syntax of Netnews articles to reflect current [RFC1036], updating the syntax of Netnews articles 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. [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 [RFC3977]. A best-common-
A best-common-practice document, [I-D.ietf-usefor-useage], describes practice document, [I-D.ietf-usefor-useage], describes implementation
implementation recommendations to improve interoperability and 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. Although many news content format is to be passed between systems. Although many 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), local storage is outside of need for translation between formats), local storage is outside of
the scope of this standard. the scope of this standard.
1.3. Requirements Notation 1.3 Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document 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
updated by [RFC2231], and [RFC3986], specifically: updated by [RFC2231], and [RFC3986], specifically:
token = <see RFC2045 Section 5.1> token = <see RFC2045 Section 5.1>
value = <see RFC2045 Section 5.1> value = <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>
skipping to change at page 5, line 43 skipping to change at page 5, line 38
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 specifies a stricter definition of Additionally, Section 3.1.3 specifies a stricter definition of
<msg-id> than the syntax in [RFC2822] Section 3.6.4. <msg-id> than the syntax in [RFC2822] Section 3.6.4.
1.5. Definitions 1.5 Definitions
An "article" is the unit of Netnews, analogous to 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 contrast to an "article", a "proto-article" into the news system. In contrast to an "article", a "proto-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" that 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
skipping to change at page 7, line 9 skipping to change at page 7, line 5
An agent is said to "generate" a construct if it did not exist before An agent is said to "generate" a construct if it did not exist before
the agent created it. Examples are when a user agent creates a the agent created it. Examples are when a user agent creates a
message from text and addressing information supplied by a user, or message from text and addressing information supplied by a user, or
when a news server creates an "Injection-Info" header field for a when a news server creates an "Injection-Info" header field for a
newly posted message. newly posted message.
An agent is said to "accept" a construct if some other entity An agent is said to "accept" a construct if some other entity
generates it and passes it to the agent in question, and the agent generates it and passes it to the agent in question, and the agent
processes it without treating it as a format or protocol error. processes it without treating it as a format or protocol error.
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 Netnews articles. Section 3 details Section 2 defines the format of Netnews articles. Section 3 details
the header fields necessary to make an article suitable for the the header fields necessary to make an article suitable for the
Netnews 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] is NOT conformant to this specification, except for the [RFC2822] is NOT conformant to this specification, except for the
following two cases: following two cases:
o Articles are conformant if they use the <obs-phrase> construct o Articles are conformant if they use the <obs-phrase> construct
skipping to change at page 8, line 47 skipping to change at page 8, line 47
expressed as ABNF. expressed as ABNF.
NOTE: Other specifications use the term "header" as a synonym for NOTE: Other specifications use the term "header" as a synonym for
what [RFC2822] calls "header field". This document follows the what [RFC2822] calls "header field". This document follows the
terminology in Section 2 of [RFC2822] in using the terms "line", terminology in Section 2 of [RFC2822] in using the terms "line",
"header field", "header field name", "header field body", and "header field", "header field name", "header field body", and
"folding", based on a belief that consistent terminology among "folding", based on a belief that consistent terminology among
specifications that depend on each other makes the specifications specifications that depend on each other makes 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 Netnews article are compliant with [RFC2822]; All header fields in a Netnews article are compliant with [RFC2822];
this specification, however, is less permissive in what can be this specification, however, is less permissive in what can be
generated and accepted by agents. The syntax allowed for Netnews generated and accepted by agents. The syntax allowed for Netnews
article headers is a strict subset of the "Internet Message Format" article headers is a strict subset of the "Internet Message Format"
headers, making all headers compliant with this specification headers, making all headers compliant with this specification
inherently compliant with [RFC2822]. Note however that the converse inherently compliant with [RFC2822]. Note however that the converse
is not guaranteed to be true in all cases. is not guaranteed to 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 relevant 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 NNTP [I-D.ietf-nntpext-base] servers). News agents MAY including NNTP [RFC3977] servers). News agents MAY accept header
accept header fields which do not contain the required space. 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, rather referenced by this document can be empty. As a result, rather
than using the <unstructured> syntax from Section 3.2.6 of than using the <unstructured> syntax from Section 3.2.6 of
[RFC2822], this document uses a stricter definition: [RFC2822], this document uses a stricter definition:
skipping to change at page 10, line 10 skipping to change at page 10, line 10
number of lines into which a header field may be split, and number of lines into which a header field may be split, and
hence there is NO restriction on the total length of a header hence there is NO restriction on the total length of a header
field (in particular it may, by suitable folding, be made to field (in particular it may, by suitable folding, be made to
exceed the 998 octets restriction pertaining to a single header exceed the 998 octets restriction pertaining to a single header
field line). field 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].
2.3. MIME Conformance 2.3 MIME Conformance
User agents MUST meet the definition of MIME conformance in [RFC2049] User agents MUST meet the definition of MIME conformance in [RFC2049]
and MUST also support [RFC2231]. This level of MIME conformance and MUST also support [RFC2231]. This level of MIME conformance
provides support for internationalization and multimedia in message provides support for internationalization and multimedia in message
bodies ([RFC2045], [RFC2046], [RFC2231]), and support for bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
internationalization of 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", permitting the use of [RFC2047] encodings message header fields", permitting the use of [RFC2047] encodings
within any <unstructured> header field, or within any <comment> or within any <unstructured> header field, or within any <comment> or
<phrase> permitted within any structured header field. <phrase> permitted 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 =/ *( approved / fields =/ *( approved /
archive / archive /
control / control /
distribution / distribution /
expires / expires /
followup-to / followup-to /
skipping to change at page 11, line 49 skipping to change at page 11, line 49
Xref Xref
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 header fields are mainly of interest to news servers, Most of these header fields are mainly of interest to news servers,
and 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 <comment>s. Thus some header fields prohibit <comment>s.
3.1. Mandatory Header Fields 3.1 Mandatory Header Fields
Each Netnews article conformant with this specification MUST have Each Netnews article conformant with this specification MUST have
exactly one of each of the following header fields: Date, From, exactly one of each of the following header fields: Date, From,
Message-ID, Newsgroups, Path, Subject. Message-ID, Newsgroups, Path, Subject.
3.1.1. Date 3.1.1 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 above in and 3.6.1 of [RFC2822] with the added restrictions detailed above 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 Netnews articles today. zone>), although deprecated, is widespread in Netnews articles today.
Therefore, agents MUST accept <date-time> constructs that 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
skipping to change at page 12, line 29 skipping to change at page 12, line 29
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.7 and including Injection-Date and Expires in Section 3.2.7 and
Section 3.2.5, respectively. Section 3.2.5, respectively.
3.1.2. From 3.1.2 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 above in of [RFC2822] with the added restrictions detailed above in
Section 2.2. Section 2.2.
from = "From:" SP mailbox-list CRLF from = "From:" SP mailbox-list CRLF
3.1.3. Message-ID 3.1.3 Message-ID
The Message-ID header field contains a unique message identifier. The Message-ID header field contains a unique message identifier.
Netnews is more dependent on message identifier uniqueness and fast Netnews is more dependent on message identifier uniqueness and fast
comparison than Email is, and some news software and standards comparison than Email is, and some news software and standards
[I-D.ietf-nntpext-base] might have trouble with the full range of [RFC3977] might have trouble with the full range of possible
possible <msg-id>s permitted by [RFC2822]. This section therefore <msg-id>s permitted by [RFC2822]. This section therefore restricts
restricts the syntax of <msg-id> as compared to Section 3.6.4 of the syntax of <msg-id> as compared to Section 3.6.4 of [RFC2822].
[RFC2822]. The global uniqueness requirement for <msg-id> in The global uniqueness requirement for <msg-id> in [RFC2822] is to be
[RFC2822] is to be understood as applying across all protocols using understood as applying across all protocols using such message
such message identifiers, and across both Email and Netnews in identifiers, and across both Email and Netnews in particular.
particular.
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
msg-id = "<" msg-id-core ">" msg-id = "<" msg-id-core ">"
; maximum length is 250 octets ; maximum length is 250 octets
msg-id-core = id-left "@" id-right msg-id-core = id-left "@" id-right
id-left = dot-atom-text / no-fold-quote id-left = dot-atom-text / no-fold-quote
skipping to change at page 13, line 41 skipping to change at page 13, line 41
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 that accept NOTE: The length restriction ensures that systems that accept
message identifiers as a parameter when referencing an article message identifiers as a parameter when referencing an article
(e.g. [I-D.ietf-nntpext-base]) can rely on a bounded length. (e.g. [RFC3977]) 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 were o it ensures that no string of characters is quoted if it were
skipping to change at page 14, line 20 skipping to change at page 14, line 20
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
[I-D.ietf-nntpext-base]. Thus, whereas under [RFC2822] the following [RFC3977]. Thus, whereas under [RFC2822] the following <msg-id>s
<msg-id>s would be considered semantically equivalent, 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 15, line 5 skipping to change at page 15, line 5
the <id-right> part. the <id-right> part.
When generating 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. Newsgroups 3.1.4 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 = *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 / "+" / "-" / "_"
Not all servers support [FWS] in the list of newsgroups. In Not all servers support optional FWS in the list of newsgroups. In
particular, folding the Newsgroups header field over several lines particular, folding the Newsgroups header field over several lines
has been shown to harm propagation significantly. [FWS] in the has been shown to harm propagation significantly. Optional FWS in
<newsgroup-list> SHOULD NOT be generated, but MUST be accepted. the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
A <component> SHOULD NOT consist solely of digits and SHOULD NOT A <component> SHOULD NOT consist solely of digits and SHOULD NOT
contain uppercase letters. Such <component>s MAY be used only to contain uppercase letters. Such <component>s 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,
but MUST NOT be used otherwise. but MUST NOT be used otherwise.
NOTE: All-digit <component>s conflict with one widely used storage NOTE: All-digit <component>s 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 16, line 30 skipping to change at page 16, line 30
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 as communications in conjunction with the "ihave" control message as
defined in [I-D.ietf-usefor-usepro]; "control.*" and "junk" have defined in [I-D.ietf-usefor-usepro]; "control.*" and "junk" have
special meanings in some news servers; "all" is used as a wildcard special meanings in some news servers; "all" is used as a wildcard
in some implementations; and "ctl" was formerly used to indicate a in some implementations; and "ctl" was formerly used to indicate a
<control-command> within the Newsgroups header field. <control-command> within the Newsgroups header field.
3.1.5. Path 3.1.5 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 at least one <path-identity> to this article is required to prepend at least one <path-identity> to this
header field body. This is primarily so that news servers are able header field body. This is primarily so that news servers are able
to avoid sending articles to sites already known to have them, in to avoid sending articles to sites already known to have them, in
particular the site they came from, and additionally to permit particular the site they came from, and additionally to permit
tracing the route articles take in moving over the network, and for tracing the route articles take in moving over the network, and for
gathering statistics. gathering statistics.
skipping to change at page 18, line 25 skipping to change at page 18, line 25
is permitted; note that this may cause interoperability problems is permitted; note that this may cause interoperability problems
at older sites that regard ":" as a <path-delimiter> and have at older sites that regard ":" as a <path-delimiter> and have
neighbors whose names have 4 or fewer characters, and where all neighbors whose names have 4 or fewer characters, and where all
the characters are valid HEX digits. the characters are valid HEX digits.
NOTE: Although <IPv4address>es have occasionally been used in the NOTE: Although <IPv4address>es have occasionally been used in the
past (usually with a diagnostic intent), their continued use is past (usually with a diagnostic intent), their continued use is
deprecated (though it is still acceptable in the form of the deprecated (though it is still acceptable in the form of the
<diag-deprecated>). <diag-deprecated>).
3.1.6. Subject 3.1.6 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 above in 3.6.5 of [RFC2822] with the added restrictions detailed above 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 [I-D.ietf-usefor-usepro] and field appears in [I-D.ietf-usefor-usepro] and
[I-D.ietf-usefor-useage]. [I-D.ietf-usefor-useage].
subject = "Subject:" SP unstructured CRLF subject = "Subject:" SP unstructured CRLF
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 article. Further discussion of these requirements appears types of article. 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 Comments, Keywords, Reply-To, and Sender are used The header fields Comments, Keywords, Reply-To, and Sender are used
in Netnews articles in the same circumstances and with the same in Netnews articles in the same circumstances and with the same
meanings as those specified in [RFC2822] with the added restrictions meanings as those specified in [RFC2822] with the added restrictions
detailed above in Section 2.2. Multiple occurrences of the Keywords detailed above in Section 2.2. Multiple occurrences of the Keywords
skipping to change at page 19, line 21 skipping to change at page 19, line 21
sender = "Sender:" SP mailbox CRLF sender = "Sender:" SP mailbox CRLF
The MIME header fields MIME-Version, Content-Type, Content-Transfer- The MIME header fields MIME-Version, Content-Type, Content-Transfer-
Encoding, Content-Disposition, and Content-Language are used in Encoding, Content-Disposition, and Content-Language are used in
Netnews articles in the same circumstances and with the same meanings Netnews articles in the same circumstances and with the same meanings
as those specified in [RFC2045], [RFC2183], and [RFC3282] with the as those specified in [RFC2045], [RFC2183], and [RFC3282] with the
added restrictions detailed above in Section 2.2. added restrictions detailed above in Section 2.2.
All remaining news header fields are described below. All remaining news header fields are described below.
3.2.1. Approved 3.2.1 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; see [I-D.ietf-usefor-usepro]. and in group control messages; see [I-D.ietf-usefor-usepro].
approved = "Approved:" SP mailbox-list CRLF approved = "Approved:" SP mailbox-list CRLF
3.2.2. Archive 3.2.2 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] ";" [CFWS] archive-param ) [CFWS] 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. A field from publicly accessible long-term or permanent archives. A field
body of "yes" indicates that the poster permits such redistribution. body of "yes" indicates that the poster permits such redistribution.
No <parameter>s are currently defined; if present, they can be No <parameter>s are currently defined; if present, they can be
ignored. Further discussion of the use of the Archive header field ignored. Further discussion of the use of the Archive header field
appears in [I-D.ietf-usefor-useage]. appears in [I-D.ietf-usefor-useage].
3.2.3. Control 3.2.3 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 *WSP control-command *WSP CRLF control = "Control:" SP *WSP control-command *WSP CRLF
control-command = verb *( 1*WSP argument ) control-command = verb *( 1*WSP argument )
verb = token verb = token
skipping to change at page 20, line 28 skipping to change at page 20, line 28
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> (as defined in (if any) supply details. In some cases, the <body> (as defined in
[RFC2822]) of the article may also contain details. The legal verbs [RFC2822]) of the article may also contain details. The legal verbs
and respective arguments are discussed in the companion document, and respective arguments are discussed in the companion document,
[I-D.ietf-usefor-usepro]. [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.4. Distribution 3.2.4 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 = *WSP dist-name dist-list = *WSP dist-name
*( [FWS] "," [FWS] dist-name ) *WSP *( [FWS] "," [FWS] dist-name ) *WSP
dist-name = ALPHA / DIGIT dist-name = ALPHA / DIGIT
skipping to change at page 20, line 52 skipping to change at page 20, line 52
unlimited distribution and SHOULD NOT be used explicitly, since it is unlimited distribution and SHOULD NOT be used explicitly, since it is
the default when the Distribution header field is absent entirely. the default when the Distribution header field is absent entirely.
"local" is reserved for indicating distribution only to the local "local" is reserved for indicating distribution only to the local
site, as defined by local software configuration. site, as defined by local software configuration.
"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
codes drawn from [ISO3166-1]. <dist-name>s are case-insensitive (i.e. codes drawn from [ISO3166-1]. <dist-name>s are case-insensitive (i.e.
"US", "Us", "uS", and "us" all specify the same distribution). "US", "Us", "uS", and "us" all specify the same distribution).
[FWS] in the <dist-list> SHOULD NOT be generated, but MUST be Optional FWS in the <dist-list> SHOULD NOT be generated, but MUST be
accepted. accepted.
3.2.5. Expires 3.2.5 Expires
The Expires header field specifies a date and time when the poster The Expires header field specifies a date and time when the poster
deems the article to be no longer relevant and could usefully be deems the article to be no longer relevant and could usefully be
removed ("expired"). removed ("expired").
NOTE: This header field is useful when the poster desires an NOTE: This header field is useful when the poster desires an
unusually long or an unusually short expiry time. unusually long or an unusually short expiry time.
expires = "Expires:" SP date-time CRLF expires = "Expires:" SP date-time CRLF
See the remarks under Section 3.1.1 regarding the syntax of See the remarks under Section 3.1.1 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 Expires header field is also sometimes used in Email NOTE: The Expires header field is also sometimes used in Email
with a similar meaning; see [RFC2156]. with a similar meaning; see [RFC2156].
3.2.6. Followup-To 3.2.6 Followup-To
The Followup-To header field specifies to which newsgroup(s) the The Followup-To header field specifies to which newsgroup(s) the
poster has requested that followups are to be posted. The poster has requested that followups are to be posted. The
Followup-To header field SHOULD NOT appear in a message, unless its Followup-To header field SHOULD NOT appear in a message, unless its
content is different from the content of the Newsgroups header field. content is different from the content 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 lowercase
The syntax is the same as that of the Newsgroups (Section 3.1.4) The syntax is the same as that of the Newsgroups (Section 3.1.4)
header field, with the exception that the keyword "poster" requests header field, with the exception that the keyword "poster" requests
that followups should be emailed directly to the article's poster that followups should be emailed directly to the article's poster
(using the addresses contained in the Reply-To header field if one (using the addresses contained in the Reply-To header field if one
exists, otherwise using the addresses contained in the From header exists, otherwise using the addresses contained in the From header
field) rather than posted to any newsgroups. Agents MUST generate field) rather than posted to any newsgroups. Agents MUST generate
the keyword "poster" in lower-case, but MAY choose to recognize case- the keyword "poster" in lowercase, but MAY choose to recognize case-
insensitive forms such as "Poster". insensitive forms such as "Poster".
As in the Newsgroups (Section 3.1.4) header field, [FWS] in the As in the Newsgroups (Section 3.1.4) header field, optional FWS in
<newsgroup-list> SHOULD NOT be generated, but MUST be accepted. the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
3.2.7. Injection-Date 3.2.7 Injection-Date
The Injection-Date header field contains the date and time that the The Injection-Date header field contains the date and time that the
article was injected into the network. Its purpose is to enable news article was injected into the network. Its purpose is to enable news
servers, when checking for "stale" articles, to use a <date-time> servers, when checking for "stale" articles, to use a <date-time>
that was added by a news server at injection time rather than one that was added by a news server at injection time rather than one
added by the user agent at message composition time. added by the user agent at message composition time.
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
skipping to change at page 22, line 34 skipping to change at page 22, line 34
NOTE: Since clocks on various agents are not necessarily NOTE: Since clocks on various agents are not necessarily
synchronized, the <date-time> in this header field might not be a synchronized, the <date-time> in this header field might not be a
later value than that in the Date header field. Agents MUST NOT later value than that in the Date header field. Agents MUST NOT
alter a pre-existing Date header field when adding an Injection- alter a pre-existing Date header field when adding an Injection-
Date header field. Date header field.
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.8. Injection-Info 3.2.8 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] *( ";" [CFWS] parameter ) [CFWS] CRLF [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
skipping to change at page 24, line 27 skipping to change at page 24, line 27
server. server.
The "mail-complaints-to" <parameter> specifies one or more mailboxes The "mail-complaints-to" <parameter> specifies one or more mailboxes
for 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 of the above <parameter>s to It is a matter of local policy which of the above <parameter>s to
include. Some pieces of information have privacy implications; this include. Some pieces of information have privacy implications; this
is discussed in [I-D.ietf-usefor-useage]. is discussed in [I-D.ietf-usefor-useage].
3.2.9. Organization 3.2.9 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
NOTE: There is no "s" in Organization. NOTE: There is no "s" in Organization.
3.2.10. References 3.2.10 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 above in 3.6.4 of [RFC2822] with the added restrictions detailed above in
Section 2.2 and those listed below: Section 2.2 and those listed below:
o The updated <msg-id> construct defined in Section 3.1.3 MUST be o The updated <msg-id> construct defined in Section 3.1.3 MUST be
used. used.
o Message identifiers MUST be separated with CFWS. o Message identifiers MUST be separated with CFWS.
o Comments in CFWS between message identifiers can cause o Comments in CFWS between message identifiers can cause
interoperability problems, so comments SHOULD NOT be generated, interoperability problems, so comments SHOULD NOT be generated,
but MUST be accepted. but MUST be accepted.
references = "References:" SP [CFWS] msg-id *(CFWS msg-id) references = "References:" SP [CFWS] msg-id *(CFWS msg-id)
[CFWS] CRLF [CFWS] CRLF
3.2.11. Summary 3.2.11 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.12. Supersedes 3.2.12 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"
[I-D.ietf-usefor-usepro] control message for the specified article, [I-D.ietf-usefor-usepro] control message for the specified article,
followed immediately by the new article without the Supersedes header followed immediately by the new article without the Supersedes header
field. field.
supersedes = "Supersedes:" SP *WSP msg-id *WSP 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 NOTE: The Supersedes header field defined here has no connection
with the Supersedes header field that sometimes appears in Email with the Supersedes header field that sometimes appears in Email
messages converted from X.400 according to [RFC2156]; in messages converted from X.400 according to [RFC2156]; in
particular, the syntax here permits only one <msg-id> in contrast particular, the syntax here permits only one <msg-id> in contrast
to the multiple <msg-id>s in that Email version. to the multiple <msg-id>s in that Email version.
3.2.13. User-Agent 3.2.13 User-Agent
The User-Agent header field contains information about the user agent The User-Agent header field contains information about the user agent
(typically a newsreader) generating the article, for statistical (typically a newsreader) generating the article, for statistical
purposes and tracing of standards violations to specific software purposes and tracing of standards violations to specific software
needing correction. It is intended that this header field be needing correction. It is intended that this header field be
suitable for use in Email. suitable for use in Email.
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ] product = [CFWS] token [ [CFWS] "/" product-version ]
skipping to change at page 26, line 16 skipping to change at page 26, line 16
standardized header fields such as X-Newsreader, X-Mailer, standardized header fields such as X-Newsreader, X-Mailer,
X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent
generates a User-Agent header field, it should have no need to generates a User-Agent header field, it should have no need to
send these non-standard header fields. send these non-standard header fields.
NOTE: [RFC2616] describes a similar facility for the HTTP NOTE: [RFC2616] describes a similar facility for the HTTP
protocol. The Netnews article format differs in that "{" and "}" protocol. The Netnews article format differs in that "{" and "}"
are allowed in tokens (<product> and <product-version>) and are allowed in tokens (<product> and <product-version>) and
comments are permitted wherever whitespace is allowed. comments are permitted wherever whitespace is allowed.
3.2.14. Xref 3.2.14 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. User agents often use the last news server to process it. User agents often use the
information in the Xref header field to avoid multiple processing of information in the Xref header field to avoid multiple processing of
crossposted articles. crossposted articles.
xref = "Xref:" SP *WSP server-name xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF 1*( FWS location ) *WSP CRLF
server-name = path-identity server-name = path-identity
skipping to change at page 26, line 41 skipping to change at page 26, line 41
; 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
[I-D.ietf-nntpext-base]) is a decimal number, with articles in [RFC3977]) is a decimal number, with articles in each newsgroup
each newsgroup numbered consecutively starting from 1. numbered consecutively starting from 1.
3.3. Obsolete Header Fields 3.3 Obsolete Header Fields
The header fields Date-Received, Posting-Version, and Relay-Version The header fields Date-Received, Posting-Version, and Relay-Version
defined in [RFC0850], as well as Also-Control, Article-Names, defined in [RFC0850], as well as Also-Control, Article-Names,
Article-Updates, and See-Also defined in [Son-of-1036] are declared Article-Updates, and See-Also defined in [Son-of-1036] are declared
obsolete. See the cited specification documents for further obsolete. See the cited specification documents for further
information on their original use. information on their original use.
These header fields MUST NOT be generated and SHOULD be ignored. These header fields MUST NOT be generated and SHOULD be ignored.
3.3.1. Lines 3.3.1 Lines
The Lines header field indicates the number of lines in the <body> The Lines header field indicates the number of lines in the <body>
(as defined in [RFC2822]) of the article. (as defined in [RFC2822]) of the article.
lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF
The line count is the number of CRLF separators in the <body>. The line count is the number of CRLF separators in the <body>.
Historically, this header field was used by the Historically, this header field was used by the [RFC3977] overview
[I-D.ietf-nntpext-base] overview facility, but its use for this facility, but its use for this purpose is now deprecated. As a
purpose is now deprecated. As a result, this header field is to be result, this header field is to be regarded as obsolescent, and it is
regarded as obsolescent, and it is likely to be removed entirely in a likely to be removed entirely in a future version of this standard.
future version of this standard. All agents SHOULD ignore it and All agents SHOULD ignore it and SHOULD NOT generate it.
SHOULD NOT generate it.
4. Internationalization Considerations 4 Internationalization Considerations
Internationalization of Netnews article header fields and bodies is Internationalization of Netnews 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 Netnews article format specified in this document does not The Netnews article format specified in this document does not
provide any security services, such as confidentiality, provide any security services, such as confidentiality,
authentication of sender, or non-repudiation. Instead, such services authentication of sender, or non-repudiation. Instead, such services
need to be layered above, using such protocols as S/MIME [RFC3851] or need to be layered above, using such protocols as S/MIME [RFC3851] or
PGP/MIME [RFC3156], or below, using secure versions of news transport PGP/MIME [RFC3156], or below, using secure versions of news transport
protocols. Additionally, several currently non-standardized protocols. Additionally, several currently non-standardized
protocols such as [PGPVERIFY] may be standardized in the near future. protocols such as [PGPVERIFY] may be standardized in the near future.
Message identifiers (Section 3.1.3) in Netnews articles are required Message identifiers (Section 3.1.3) in Netnews articles are required
skipping to change at page 30, line 5 skipping to change at page 30, line 5
(; 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 deficiencies in parsing may be used as part of an attack. Such deficiencies in parsing may be used as part of an attack.
Further security considerations are discussed in Further security considerations are discussed in
[I-D.ietf-usefor-usepro]. [I-D.ietf-usefor-usepro].
6. IANA Considerations 6 IANA Considerations
IANA is requested to register the following header fields in the IANA is requested to register the following header fields in the
Permanent Message Header Field Repository, in accordance with the Permanent Message Header Field Repository, in accordance with the
procedures set out in [RFC3864]. procedures set out in [RFC3864].
Header field name: Also-Control Header field name: Also-Control
Applicable protocol: netnews Applicable protocol: netnews
Status: obsoleted Status: obsoleted
Author/change controller: IETF Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.15) Specification document(s): [Son-of-1036] (Section 6.15)
skipping to change at page 32, line 18 skipping to change at page 32, line 18
Status: standard Status: standard
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3.2), Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.5) [RFC2822] (Section 3.6.5)
Header field name: Lines Header field name: Lines
Applicable protocol: netnews Applicable protocol: netnews
Status: deprecated Status: deprecated
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3.3.1) Specification document(s): This document (Section 3.3.1)
Related information: [I-D.ietf-nntpext-base] (Section 8.1) Related information: [RFC3977] (Section 8.1)
Header field name: Message-ID Header field name: Message-ID
Applicable protocol: netnews Applicable protocol: netnews
Status: standard Status: standard
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3.1.3) Specification document(s): This document (Section 3.1.3)
Related information: [RFC2822] (Section 3.6.4) Related information: [RFC2822] (Section 3.6.4)
Header field name: Newsgroups Header field name: Newsgroups
Applicable protocol: netnews Applicable protocol: netnews
skipping to change at page 35, line 9 skipping to change at page 35, line 9
Header field name: Xref Header field name: Xref
Applicable protocol: netnews Applicable protocol: netnews
Status: standard Status: standard
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3.2.14) Specification document(s): This document (Section 3.2.14)
7. References 7. References
7.1. Normative References 7.1. Normative References
[Errata] "RFC Editor Errata",
http://www.rfc-editor.org/errata.html.
[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.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
skipping to change at page 36, line 7 skipping to change at page 35, line 51
[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.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. 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] [Errata] "RFC Editor Errata",
Feather, C., "Network News Transfer Protocol", http://www.rfc-editor.org/errata.html.
draft-ietf-nntpext-base-27 (work in progress), June 2005.
[I-D.ietf-usefor-useage] [I-D.ietf-usefor-useage]
Lindsey, C., "Usenet Best Practice", Lindsey, C., "Usenet Best Practice",
draft-ietf-usefor-useage-01 (work in progress), draft-ietf-usefor-useage-01 (work in progress),
March 2005. March 2005.
[I-D.ietf-usefor-usepro] [I-D.ietf-usefor-usepro]
Lindsey, C., "News Article Architecture and Protocols", Lindsey, C., "News Article Architecture and Protocols",
draft-ietf-usefor-usepro-05 (work in progress), draft-ietf-usefor-usepro-05 (work in progress),
January 2006. January 2006.
skipping to change at page 37, line 16 skipping to change at page 37, line 9
Transformation of Names", RFC 3696, February 2004. Transformation of Names", RFC 3696, February 2004.
[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.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006.
[Son-of-1036] [Son-of-1036]
Spencer, H., "News Article Format and Transmission", Spencer, H., "News Article Format and Transmission",
ftp://ftp.zoo.toronto.edu/pub/news.txt.Z, June 1994. ftp://ftp.zoo.toronto.edu/pub/news.txt.Z, June 1994.
Appendix A. Acknowledgments 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 its accompanying mailing list. Force (IETF) and its 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].
o 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 Control, Distribution, Followup-To, Lines, Message-ID, the Control, Distribution, Followup-To, Lines, Message-ID,
skipping to change at page 40, line 5 skipping to change at page 40, line 5
o Certain header fields, notably Lines, have been deprecated or made o Certain header fields, notably Lines, have been deprecated or made
obsolete (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
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:
skipping to change at page 41, line 30 skipping to change at page 41, line 30
Heald Green Heald Green
Cheadle Cheadle
Cheshire SK8 3JU Cheshire SK8 3JU
U.K. U.K.
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clerew.man.ac.uk Email: chl@clerew.man.ac.uk
Dan Kohn Dan Kohn
FlyDash, Inc. FlyDash, Inc.
425 Alma St. #411 1741 Sunset Dr.
Palo Alto, CA 94301 Pacific Grove, CA 93950
U.S.A. U.S.A.
Phone: +1 415 233 1000 Phone: +1 415 233 1000
Email: dan@dankohn.com Email: dan@dankohn.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
 End of changes. 66 change blocks. 
131 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/