draft-ietf-usefor-usefor-09.txt   draft-ietf-usefor-usefor-10.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 1, 2007 D. Kohn Expires: March 21, 2007 D. Kohn
FlyDash, Inc. FlyDash, Inc.
August 28, 2006 September 17, 2006
Netnews Article Format Netnews Article Format
draft-ietf-usefor-usefor-09 draft-ietf-usefor-usefor-10
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 1, 2007. This Internet-Draft will expire on March 21, 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.
Note to RFC Editor
Please remove all of the "Changes since ..." sections before
publication.
Changes since draft-ietf-usefor-usefor-08
o Removed "Issues to be addressed" section.
o Header fields are now listed and described in alphabetical order
(as suggested by Richard Clayton).
o Consistently use "Netnews article(s)" throughout document.
o Clarified that the 998 octet limit is for header field lines, not
the entire header field.
o Added <comment> to ABNF imports.
o Added header fields specified in RFC 850 and RFC 2980 to IANA
section. Also rewrote Obsolete Header Fields section to reference
RFC 850 and RFC 2980 instead of listing and describing obsolete
header fields (ticket #1156).
o Added definitions for "generate" and "accept" (ticket #1299).
o Added note explaining <diag-deprecated> in Path header field
(ticket #1305).
o Noted that agents MUST NOT (rather than SHOULD NOT) alter the Date
header field when adding an Injection-Date header field (ticket
#1306).
o Replaced reference to ISO3166 with ISO3166-1. Also refined
description of "world" and "local" in Distribution header field.
(ticket #1309)
o Removed restriction on mailbox-list in Approved header field
(ticket #1310).
o Refined discussion of Archive header field body (ticket #1311).
o Changed definition of Line count to number of CRLF in <body>
(ticket #1312).
o Changed wording in Header Fields section 2.2 to discuss only
headers, not entire messages (ticket #1313).
o Reworded text regarding use of special chars in newsgroups names
(ticket #1314).
o Removed analogy to RFC 2822 article from "poster" definition
(ticket #1315).
o Reworded the purpose of Injection-Date header field (ticket
#1335).
o Reworded the description of Expires header field (ticket #1336).
o Clarified to which Email addresses followups to "poster" are sent.
o Numerous editorial changes from Ralph Babel, Richard Clayton, and
Charles Lindsey.
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
o Reworked ABNF for Path header field delimiters and components
(ticket #1047).
o Imported ABNF elements from reference docs (ticket #1155).
o Added IANA registration for header fields per RFC 3864 (ticket
#1156).
o New ABNF for Control header field (ticket #1157).
o Better ABNF for <host-value> (ticket #1158).
o Added new definitions and advice on sender vs. posting-account in
Injection-Info header field (ticket #1159).
o New ABNF for Archive and Injection-Info header fields, including
note regarding CFWS and <parameter> (ticket #1177).
o Replaced leading/trailing [FWS] with *WSP in header field ANBF
(ticket #1179).
o Using RFC 4234 as a reference instead of RFC 2234.
o Removed reference to RFC 0977 -- using only
draft-ietf-nntpext-base.
o Added note about Expires being defined by RFC 2156.
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-05
o Finalized ABNF for <msg-id> (ticket #1003).
o Further cleanup of description for Newsgroups header field (ticket
#1021).
o Fixed ABNF for <orig-date> (ticket #1028).
o Began adding text for differences from RFC 1036 (ticket #1032).
o Added text regarding hard-to-parse MIME boundaries (ticket #1046).
o Reworked/redefined Path header field delimiters and components
(ticket #1047).
o Added more differences from RFC 2822 (ticket #1052).
o Added text for relationship to RFC 2822 (ticket #1053).
o Listed header fields which don't permit CFWS (ticket #1079).
o Applied text from ticket #1080 (Injection-Info MIME params).
o Added more text Approved header field semantics (ticket #1082).
o Added text regarding Injection-Date being mandatory/optional
(ticket #1088).
o Reworked definitions of "agents", etc (ticket #1102).
o Removed RFC 2821 as a normative reference.
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-04
o Updated to newer references (ticket #1002).
o Cleaned up ABNF for <msg-id> (ticket #1003).
o Deprecated X- headers (ticket #1004).
o Clarified relationship between followups and References header
field (ticket #1008).
o Cleaned up ABNF and description for Newsgroups header field
(ticket #1021).
o Tweaked language regarding the use of <obs-phrase> (ticket #1022).
o Tweaked language regarding GMT timezone and Date header field
(ticket #1028).
o Added language warning against folding Newsgroups header field
(ticket #1042).
o Use RFC 2822 term "header field" instead of "header" (ticket
#1043).
o Starting adding differences from RFC 2822 (ticket #1052).
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-03
o Reworked ABNFs of several headers.
o Used Charles' ABNF for <msg-id>.
o Disallowed comments in Supersedes header.
o Disallowed comments in Xref header.
o Disallowed comments in Message-Id header.
o CFWS between msg-ids in References header is not optional.
o Compatibility changes based on comments from Charles.
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-02
o Changed to RFC 3978 boilerplate (xml2rfc v1.29)
o Changed "network news" to "Netnews" throughout.
o Prohibit NO-WS-CTL in msg-id.
o Complaints-To header is now an Injection-Info parameter.
o Added descriptions of Injection-Info parameters.
o Removed "filename" parameter from Archive header.
o Added CFWS to User-Agent header.
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-01
o Removed half-hearted discussion of internal format and 8-bit clean
transport.
o Added definitions of "proto-article", "posting agent", "followup",
"followup-agent", "user-agent", and "injecting agent".
o Removed discussion of message/partial MIME messages.
o Noted that the header contents in every line MUST NOT be empty.
o Merged MIME sections.
o Only allow "UT" and "GMT" in Date header; disallow all other <obs-
zone>.
o Used Charles' ABNF for <msg-id> and <unstructured>.
o Removed restrictions on length and start character for Newsgroups.
o More verbose description of Path header.
o Disallowed comments in Control header.
o Specified that <control-command> is a verb optionally followed by
whitespace-separated arguments.
o Noted that Supersedes header is different from [Son-of-1036].
o More exact ABNF for Archive and Injection-Info parameters.
o Discussed meaning of "yes", "no" in Archive header.
o Added "Obsolete Headers" section.
o Miscellaneous editorial changes
Changes since draft-ietf-usefor-article-13
o The Mail-Copies-To, Posted-And-Mailed headers have been moved to
other documents.
o Dropped MIME parameters, as there is no WG consensus (per Chair).
o More exact ABNF for Archive and Injection-Info parameters.
o Complaints-To header is now an Injection-Info parameter.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 15 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 15 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 16 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 16 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.6. Structure of This Document . . . . . . . . . . . . . . . . 18 1.6. Structure of This Document . . . . . . . . . . . . . . . . 7
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8
2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 21 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10
3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 22 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 11
3.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 23 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 26 3.1.4. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.6. Subject . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.6. Subject . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 29 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 18
3.2.1. Approved . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.1. Approved . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3. Control . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.3. Control . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4. Distribution . . . . . . . . . . . . . . . . . . . . . 31 3.2.4. Distribution . . . . . . . . . . . . . . . . . . . . . 20
3.2.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.6. Followup-To . . . . . . . . . . . . . . . . . . . . . 32 3.2.6. Followup-To . . . . . . . . . . . . . . . . . . . . . 21
3.2.7. Injection-Date . . . . . . . . . . . . . . . . . . . . 33 3.2.7. Injection-Date . . . . . . . . . . . . . . . . . . . . 22
3.2.8. Injection-Info . . . . . . . . . . . . . . . . . . . . 33 3.2.8. Injection-Info . . . . . . . . . . . . . . . . . . . . 22
3.2.9. Organization . . . . . . . . . . . . . . . . . . . . . 35 3.2.9. Organization . . . . . . . . . . . . . . . . . . . . . 24
3.2.10. References . . . . . . . . . . . . . . . . . . . . . . 35 3.2.10. References . . . . . . . . . . . . . . . . . . . . . . 24
3.2.11. Summary . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.11. Summary . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.12. Supersedes . . . . . . . . . . . . . . . . . . . . . . 36 3.2.12. Supersedes . . . . . . . . . . . . . . . . . . . . . . 25
3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 36 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 25
3.2.14. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.14. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 37 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 26
3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 27
4. Internationalization Considerations . . . . . . . . . . . . . 39 4. Internationalization Considerations . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Normative References . . . . . . . . . . . . . . . . . . . 46 7.1. Normative References . . . . . . . . . . . . . . . . . . . 35
7.2. Informative References . . . . . . . . . . . . . . . . . . 47 7.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 49 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 38
Appendix B. Differences from RFC 1036 and its derivatives . . . . 50 Appendix B. Differences from RFC 1036 and its derivatives . . . . 39
Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 51 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 53 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
skipping to change at page 17, line 25 skipping to change at page 6, line 25
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
potentially compliant article to a "user agent". potentially compliant article to a "user agent".
A "reader" is the person or software reading Netnews articles. A "reader" is the person or software reading Netnews articles.
A "follow-up" 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
(subject to the policies observed at that site) take actions beyond (subject to the policies observed at that site) take actions beyond
just filing and passing on the article. just filing and passing on the article.
A "news server" is software that may accept articles from a "user A "news server" is software that may accept articles from a "user
skipping to change at page 19, line 35 skipping to change at page 8, line 35
This document, and specifications that build upon it, specify how to This document, and specifications that build upon it, specify how to
handle conformant articles. Handling of non-conformant articles is handle conformant articles. Handling of non-conformant articles 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] and also to the restrictions specified
here, both those that are expressed as text and those that are
Articles must also conform to the restrictions specified here, both expressed as ABNF.
those that are expressed as text and those that are 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
skipping to change at page 25, line 37 skipping to change at page 14, line 37
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,
including the References header field discussed in Section 3.2.10 and including the References header field discussed in Section 3.2.10 and
the Supersedes header field discussed in Section 3.2.12. the Supersedes header field discussed in Section 3.2.12.
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 a Message-ID where the
only difference is the case of characters in the <id-right> part. only difference from another Message-ID is the case of characters in
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
skipping to change at page 26, line 26 skipping to change at page 15, line 26
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 [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. [FWS] in the
<newsgroup-list> SHOULD NOT be generated, but MUST be accepted. <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
A newsgroup component SHOULD NOT consist of digits only and SHOULD A <component> SHOULD NOT consist solely of digits and SHOULD NOT
NOT contain uppercase letters. Such components 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 components 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.
<component>s beginning with underline ("_") are reserved for use by <component>s beginning with underline ("_") are reserved for use by
future versions of this standard and SHOULD NOT be generated by user future versions of this standard and SHOULD NOT be generated by user
agents (whether in header fields or in newgroup control messages as agents (whether in header fields or in newgroup control messages as
defined by [I-D.ietf-usefor-usepro]). However, such names MUST be defined by [I-D.ietf-usefor-usepro]). However, such names MUST be
accepted by news servers. accepted by news servers.
skipping to change at page 29, line 6 skipping to change at page 18, line 6
which appears as "!!", indicates that the agent to its left verified which appears as "!!", indicates that the agent to its left verified
the identity of the agent to its right before accepting the article the identity of the agent to its right before accepting the article
(whereas the <path-delimiter> "!" implies no such claim). (whereas the <path-delimiter> "!" implies no such claim).
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 often used instead (since at one time the whole path could be is often used instead (since at one time the whole path could be
used as a mail address for the sender). used as a mail address for the sender).
NOTE: Although case-insensitive, it is intended that the <diag- NOTE: Although case-insensitive, it is intended that the <diag-
keyword>s should be in upper-case, to distinguish them from the keyword>s should be in uppercase, to distinguish them from the
<path-identity>s which are traditionally in lower case. <path-identity>s which are traditionally in lower case.
A <path-diagnostic> is an item inserted into the Path header field A <path-diagnostic> is an item inserted into the Path header field
for purposes other than to indicate the name of a site. The use of for purposes other than to indicate the name of a site. The use of
these is described in [I-D.ietf-usefor-usepro]. these is described in [I-D.ietf-usefor-usepro].
NOTE: One usage of a <path-diagnostic> is to record an IP address. NOTE: One usage of a <path-diagnostic> is to record an IP address.
The fact that <IPv6address>es are allowed means that the colon (:) The fact that <IPv6address>es are allowed means that the colon (:)
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
skipping to change at page 30, line 47 skipping to change at page 19, line 47
*( [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 content of the Archive header ignored. Further discussion of the use of the Archive header field
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 )
skipping to change at page 31, line 49 skipping to change at page 20, line 49
*( ALPHA / DIGIT / "+" / "-" / "_" ) *( ALPHA / DIGIT / "+" / "-" / "_" )
The <dist-name>s "world" and "local" are reserved. "world" indicates The <dist-name>s "world" and "local" are reserved. "world" indicates
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
names 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 [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").
skipping to change at page 33, line 25 skipping to change at page 22, line 25
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.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: 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 may not be synchronized, the <date-time> in this header field might not be a
later than the Date header field, as be expected. 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
skipping to change at page 34, line 37 skipping to change at page 23, line 37
MUST begin with an "x-". MUST begin with an "x-".
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, folding SHOULD NOT be used within the Injection-Info header field, folding SHOULD NOT be used within
any <parameter>. Folding SHOULD only occur before or after the ";" any <parameter>. Folding SHOULD only occur before or after the ";"
separating <parameter>s, and comments SHOULD only be used following separating <parameter>s, and comments SHOULD only be used 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 generates an
Info, it should have no need to send these non-standard header Injection-Info header field, it should have no need to send these
fields. non-standard header 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> fails to deterministically
point-of-presence, the "posting-account" or the "logging-data" identify the host (e.g. dynamic IP address allocation), the
<parameter> may provide additional information about the true "posting-account" or the "logging-data" <parameter> may provide
origin of the article. additional information about the true 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. In order include any information the administrator deems pertinent. 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 cannot be interpreted by other sites. However, to make it that cannot be interpreted by other sites. However, to make it
useful for rate limiting and abuse detection, two messages posted useful for rate limiting and abuse detection, two messages posted
from the same source SHOULD have the same value of "posting-account", from the same source SHOULD have the same value of "posting-account",
and two messages from different sources SHOULD have differing values and two messages from different sources SHOULD have differing values
skipping to change at page 37, line 8 skipping to change at page 26, line 8
product-version = [CFWS] token product-version = [CFWS] token
This header field MAY contain multiple <product> tokens identifying This header field MAY contain multiple <product> tokens identifying
the user agent and any subproducts which form a significant part of the user agent and any subproducts which form a significant part of
it, listed in order of their significance for identifying the it, listed in order of their significance for identifying the
application. application.
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 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
uses User-Agent, it should have no need to send these non-standard generates a User-Agent header field, it should have no need to
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
skipping to change at page 40, line 15 skipping to change at page 29, line 15
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 news are required to be Message identifiers (Section 3.1.3) in Netnews articles are required
unique; articles may be refused (in server-to-server transfer) if the to be unique; articles may be refused (in server-to-server transfer)
identifier has already been seen. So if you can predict the if the identifier has already been seen. If a malicious agent can
identifier of a message, you can preempt it by posting a message predict the identifier of an article, it can preempt the article by
(possibly to a quite different group) with the same message posting its own article (possibly to a quite different group) with
identifier, stopping your target message from propagating. Agents the same message identifier, thereby preventing the target article
that generate message identifiers for Netnews articles SHOULD ensure from propagating. Therefore, agents that generate message
that they are unpredictable. identifiers for Netnews articles SHOULD ensure that they are
unpredictable.
MIME security considerations are discussed in [RFC2046]. Note that MIME security considerations are discussed in [RFC2046]. Note that
the full range of encodings allowed for parameters in [RFC2046] and the full range of encodings allowed for parameters in [RFC2046] and
[RFC2231] permits constructs that simple parsers may fail to parse [RFC2231] permits constructs that simple parsers may fail to parse
correctly; examples of hard-to-parse constructs are: correctly; examples of hard-to-parse constructs are:
Content-Type: multipart/mixed Content-Type: multipart/mixed
(; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/digest; Content-Type: multipart/digest;
skipping to change at page 48, line 5 skipping to change at page 37, line 5
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, [RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980,
October 2000. October 2000.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001. "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3696] Klensin, J., "Application Techniques for Checking and
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.
[Son-of-1036] [Son-of-1036]
Spencer, H., "News Article Format and Transmission", Spencer, H., "News Article Format and Transmission",
skipping to change at page 50, line 18 skipping to change at page 39, line 18
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,
Newsgroups, Path, Supersedes, and Xref header fields. Newsgroups, Path, Supersedes, and Xref header fields.
o Multiple addreses are allowed in the From header field. o Multiple addresses are allowed in the From header field.
o [FWS] is permitted in Newsgroups header fields. o [FWS] is permitted in Newsgroups header fields.
o An enhanced syntax for the Path header field enables the injection o An enhanced syntax for the Path header field enables the injection
point of, and the route taken by, an article to be determined with point of, and the route taken by, an article to be determined with
more precision. more precision.
o Only one (1) message identifier is allowed in the Supersedes o Only one (1) message identifier is allowed in the Supersedes
header field. header field.
 End of changes. 21 change blocks. 
349 lines changed or deleted 89 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/