draft-ietf-usefor-usefor-08.txt   draft-ietf-usefor-usefor-09.txt 
Usenet Format Working Group K. Murchison, Ed. Usenet Format Working Group K. Murchison, Ed.
Internet-Draft Carnegie Mellon University Internet-Draft Carnegie Mellon University
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 (if approved) C. Lindsey
Expires: November 23, 2006 University of Manchester Intended status: Standards Track University of Manchester
D. Kohn Expires: March 1, 2007 D. Kohn
FlyDash, Inc. FlyDash, Inc.
May 22, 2006 August 28, 2006
Netnews Article Format Netnews Article Format
draft-ietf-usefor-usefor-08 draft-ietf-usefor-usefor-09
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 November 23, 2006. This Internet-Draft will expire on March 1, 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 Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes
supersedes RFC 1036, updating it to reflect current practice and RFC 1036, providing an updated specification to reflect current
incorporating incremental changes specified in other documents. practice and incorporating incremental changes specified in other
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 Changes since draft-ietf-usefor-usefor-07
o Reworked ABNF for Path header field keywords (ticket #1047). o Reworked ABNF for Path header field keywords (ticket #1047).
o Removed definition of "sender" in Injection-Info header field o Removed definition of "sender" in Injection-Info header field
(ticket #1159). (ticket #1159).
o Reworded description of "posting-account" in Injection-Info header o Reworded description of "posting-account" in Injection-Info header
field (ticket #1159). field (ticket #1159).
skipping to change at page 6, line 22 skipping to change at page 13, line 16
o The Mail-Copies-To, Posted-And-Mailed headers have been moved to o The Mail-Copies-To, Posted-And-Mailed headers have been moved to
other documents. other documents.
o Dropped MIME parameters, as there is no WG consensus (per Chair). o Dropped MIME parameters, as there is no WG consensus (per Chair).
o More exact ABNF for Archive and Injection-Info parameters. o More exact ABNF for Archive and Injection-Info parameters.
o Complaints-To header is now an Injection-Info parameter. o Complaints-To header is now an Injection-Info parameter.
Issues to be addressed
o Path header field delimiters and components ABNF (ticket #1047).
o Whitespace in Path header field (ticket #1178). Editor isn't
clear on what the issue actually is.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 15
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 9 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 15
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 16
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 16
1.6. Structure of This Document . . . . . . . . . . . . . . . . 11 1.6. Structure of This Document . . . . . . . . . . . . . . . . 18
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 15 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 21
3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 16 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 16 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 22
3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 17 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 23
3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.4. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 26
3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 20 3.1.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.6. Subject . . . . . . . . . . . . . . . . . . . . . . . 29
3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 23 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 29
3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 23 3.2.1. Approved . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 24 3.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 24 3.2.3. Control . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.4. Distribution . . . . . . . . . . . . . . . . . . . . . 31
3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 26 3.2.6. Followup-To . . . . . . . . . . . . . . . . . . . . . 32
3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 26 3.2.7. Injection-Date . . . . . . . . . . . . . . . . . . . . 33
3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.8. Injection-Info . . . . . . . . . . . . . . . . . . . . 33
3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.9. Organization . . . . . . . . . . . . . . . . . . . . . 35
3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 27 3.2.10. References . . . . . . . . . . . . . . . . . . . . . . 35
3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.11. Summary . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.12. Supersedes . . . . . . . . . . . . . . . . . . . . . . 36
3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 28 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 36
3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 29 3.2.14. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 31 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 37
3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 38
4. Internationalization Considerations . . . . . . . . . . . . . 33 4. Internationalization Considerations . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1. Normative References . . . . . . . . . . . . . . . . . . . 40 7.1. Normative References . . . . . . . . . . . . . . . . . . . 46
7.2. Informative References . . . . . . . . . . . . . . . . . . 41 7.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 43 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 49
Appendix B. Differences from RFC 1036 and its derivatives . . . . 44 Appendix B. Differences from RFC 1036 and its derivatives . . . . 50
Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 45 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 53
1. Introduction 1. Introduction
1.1. Basic Concepts 1.1. Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing and
retrieving news "articles" (whose format is a subset of that for retrieving news "articles" (whose format is a subset of that for
Email messages) and for exchanging them amongst a readership which is Email messages), and for exchanging them amongst a readership 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 supersedes Mail Extensions (MIME)" [RFC2045]. This document obsoletes
[RFC1036], updating it to reflect current practice and incorporating [RFC1036], updating the syntax of Netnews articles to reflect current
changes and clarifications specified in other documents such as [Son- practice and incorporating changes and clarifications specified in
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 [I-D.ietf-nntpext-base].
A best common practice document, [I-D.ietf-usefor-useage], describes A best-common-practice document, [I-D.ietf-usefor-useage], describes
implementation recommendations to improve interoperability and implementation recommendations to improve interoperability and
usability. usability.
This specification is intended as a definition of what article This specification is intended as a definition of what article
content format is to be passed between systems. Although some 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>
dot-atom-text = <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>
FWS = <see RFC2822 Section 3.2.3> FWS = <see RFC2822 Section 3.2.3>
comment = <see RFC2822 Section 3.2.3>
CFWS = <see RFC2822 Section 3.2.3> CFWS = <see RFC2822 Section 3.2.3>
atext = <see RFC2822 Section 3.2.4> atext = <see RFC2822 Section 3.2.4>
dot-atom-text = <see RFC2822 Section 3.2.4> dot-atom-text = <see RFC2822 Section 3.2.4>
phrase = <see RFC2822 Section 3.2.6> phrase = <see RFC2822 Section 3.2.6>
utext = <see RFC2822 Section 3.2.6> utext = <see RFC2822 Section 3.2.6>
date-time = <see RFC2822 Section 3.3> date-time = <see RFC2822 Section 3.3>
mailbox = <see RFC2822 Section 3.4> mailbox = <see RFC2822 Section 3.4>
mailbox-list = <see RFC2822 Section 3.4> mailbox-list = <see RFC2822 Section 3.4>
address-list = <see RFC2822 Section 3.4> address-list = <see RFC2822 Section 3.4>
body = <see RFC2822 Section 3.5>
fields = <see RFC2822 Section 3.6> fields = <see RFC2822 Section 3.6>
IPv6address = <see RFC3986 Section 3.2.2> IPv6address = <see RFC3986 Section 3.2.2>
IPv4address = <see RFC3986 Section 3.2.2> IPv4address = <see RFC3986 Section 3.2.2>
ALPHA = <see RFC4234 Appendix B.1> ALPHA = <see RFC4234 Appendix B.1>
CRLF = <see RFC4234 Appendix B.1> CRLF = <see RFC4234 Appendix B.1>
DIGIT = <see RFC4234 Appendix B.1> DIGIT = <see RFC4234 Appendix B.1>
DQUOTE = <see RFC4234 Appendix B.1> DQUOTE = <see RFC4234 Appendix B.1>
SP = <see RFC4234 Appendix B.1> SP = <see RFC4234 Appendix B.1>
skipping to change at page 11, line 5 skipping to change at page 17, line 8
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
same message identifier are treated as if they are the same article same message identifier are treated as if they are the same article
regardless of any differences in the body or header fields. regardless of any differences in the body or header fields.
A "newsgroup" is a single forum having a name and intended for A "newsgroup" is a forum having a name and intended for articles on a
articles on a specific topic. An article is "posted to" a single specific topic. An article is "posted to" a single newsgroup or
newsgroup or several newsgroups. When an article is posted to more several newsgroups. When an article is posted to more than one
than one newsgroup, it is said to be "crossposted"; note that this newsgroup, it is said to be "crossposted"; note that this differs
differs from posting the same text as part of each of several from posting the same text as part of each of several articles, one
articles, one per newsgroup. per newsgroup.
A newsgroup may be "moderated", in which case submissions are not A newsgroup may be "moderated", in which case submissions are not
posted directly, but mailed to a "moderator" for consideration and posted directly, but mailed to a "moderator" for consideration and
possible posting. Moderators are typically human but may be possible posting. Moderators are typically human but may be
implemented partially or entirely in software. implemented partially or entirely in software.
A "poster" is the person or software that composes and submits a A "poster" is the person or software that composes and submits a
possibly compliant article to a "user agent". The poster is potentially compliant article to a "user agent".
analogous to an [RFC2822] author.
A "reader" is the person or software reading news articles. A "reader" is the person or software reading Netnews articles.
A "followup" is an article containing a response to the contents of A "follow-up" 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 11, line 45 skipping to change at page 17, line 47
exchange articles with other news servers. exchange articles with other news servers.
A "user agent" is software that may help posters submit proto- A "user agent" is software that may help posters submit proto-
articles to a news server, and/or fetch articles from a news server articles to a news server, and/or fetch articles from a news server
and present them to a reader, and/or assist the reader in creating and present them to a reader, and/or assist the reader in creating
articles and followups. articles and followups.
The generic term "agent" is used when describing requirements that The generic term "agent" is used when describing requirements that
apply to both user agents and news servers. apply to both user agents and news servers.
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
message from text and addressing information supplied by a user, or
when a news server creates an "Injection-Info" header field for a
newly posted message.
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
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 [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
(use of a phrase like "John Q. Public" without the use of quotes, (use of a phrase like "John Q. Public" without the use of quotes,
see [RFC2822] Section 4.1) but agents MUST NOT generate see [RFC2822] Section 4.1) but agents MUST NOT generate
productions of such syntax. productions of such syntax.
o Articles are conformant if they use the "GMT" <zone>, as specified o Articles are conformant if they use the "GMT" <zone>, as specified
in Section 3.1.2. in Section 3.1.1.
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
skipping to change at page 13, line 51 skipping to change at page 20, line 7
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 news article are compliant with [RFC2822], All header fields in a Netnews article are compliant with [RFC2822];
however this specification is less permissive in what can be this specification, however, is less permissive in what can be
generated and accepted by news agents. The syntax allowed for news generated and accepted by agents. The syntax allowed for Netnews
articles is a strict subset of the "Internet Message Format", making article headers is a strict subset of the "Internet Message Format"
all messages compliant with this specification inherently compliant headers, making all headers compliant with this specification
with [RFC2822]. Note however that the converse is not guaranteed to inherently compliant with [RFC2822]. Note however that the converse
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 [I-D.ietf-nntpext-base] servers). News agents MAY including NNTP [I-D.ietf-nntpext-base] servers). News agents MAY
accept header fields which do not contain the required space. accept header fields which do not contain the required space.
o Every line of a header field body (including the first and any o Every line of a header field body (including the first and any
that are subsequently folded) MUST contain at least one non- that are subsequently folded) MUST contain at least one non-
whitespace character. whitespace character.
NOTE: This means that no header field body defined by or NOTE: This means that no header field body defined by or
referenced by this document can be empty. As a result, 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 14, line 40 skipping to change at page 20, line 45
unstructured = *WSP utext *( [FWS] utext ) *WSP unstructured = *WSP utext *( [FWS] utext ) *WSP
NOTE: The [RFC2822] specification sometimes uses [FWS] at the NOTE: The [RFC2822] specification sometimes uses [FWS] at the
beginning or end of ABNF describing header field content. This beginning or end of ABNF describing header field content. This
specification uses *WSP in such cases, also in cases where this specification uses *WSP in such cases, also in cases where this
specification redefines constructs from [RFC2822]. This is specification redefines constructs from [RFC2822]. This is
done for consistency with the restriction described here, but done for consistency with the restriction described here, but
the restriction applies to all header fields, not just those the restriction applies to all header fields, not just those
where ABNF is defined in this document. where ABNF is defined in this document.
o Compliant software MUST NOT generate (but MAY accept) header o Compliant software MUST NOT generate (but MAY accept) header field
fields of more than 998 octets. This is the only limit on the lines of more than 998 octets. This is the only limit on the
length of a header field prescribed by this standard. However, length of a header field line prescribed by this standard.
specific rules to the contrary may apply in particular cases (for However, specific rules to the contrary may apply in particular
example, according to [RFC2047] lines of a header field containing cases (for example, according to [RFC2047], lines of a header
encoded-words are limited to 76 octets). [I-D.ietf-usefor-useage] field containing encoded-words are limited to 76 octets).
includes suggested limits for convenience of display by user [I-D.ietf-usefor-useage] includes suggested limits for convenience
agents. of display by user agents.
NOTE: There is NO restriction on the number of lines into which NOTE: As stated in [RFC2822], there is NO restriction on the
a header field may be split, and hence there is NO restriction number of lines into which a header field may be split, and
on the total length of a header field (in particular it may, by hence there is NO restriction on the total length of a header
suitable folding, be made to exceed the 998 octets restriction field (in particular it may, by suitable folding, be made to
pertaining to a single header line). exceed the 998 octets restriction pertaining to a single header
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 =/ *( newsgroups / fields =/ *( approved /
path / archive /
injection-date /
followup-to /
expires /
control / control /
supersedes /
distribution / distribution /
summary / expires /
approved / followup-to /
injection-date /
injection-info /
lines /
newsgroups /
organization / organization /
xref / path /
archive / summary /
supersedes /
user-agent / user-agent /
injection-info / xref )
lines )
Each of these header fields may occur at most once in a news article. Each of these header fields may occur at most once in a news article.
The following header fields defined in this document do not allow The following header fields defined in this document do not allow
comments (CFWS): comments (CFWS):
Control
Distribution
Newsgroups Newsgroups
Path
Followup-To Followup-To
Control Lines
Path
Supersedes Supersedes
Distribution
Xref Xref
Lines
This also applies to the following header field defined in [RFC2822]: This also applies to the following header field defined in [RFC2822]:
Message-ID Message-ID
Most of these 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 comments. Thus some header fields prohibit <comment>s.
3.1. Mandatory Header Fields 3.1. Mandatory Header Fields
Each news 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: From, Date, exactly one of each of the following header fields: Date, From,
Message-ID, Subject, Newsgroups, Path. Message-ID, Newsgroups, Path, Subject.
3.1.1. From
The From header field is the same as that specified in Section 3.6.2
of [RFC2822] with the added restrictions detailed in Section 2.2.
from = "From:" SP mailbox-list CRLF
3.1.2. 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 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 news 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
NOTE: This specification does not change [RFC2822], which says NOTE: This specification does not change [RFC2822], which says
that agents MUST NOT generate <date-time> constructs which include that agents MUST NOT generate <date-time> constructs which include
any zone names defined by <obs-zone>. any zone names defined by <obs-zone>.
Software that accepts dates with unknown timezones SHOULD treat such Software that accepts dates with unknown timezones SHOULD treat such
timezones as equivalent to "-0000" when comparing dates, as specified timezones as equivalent to "-0000" when comparing dates, as specified
in [RFC2822] Section 4.3. in [RFC2822] Section 4.3.
Also note that these requirements apply wherever <date-time> is used, Also note that these requirements apply wherever <date-time> is used,
including Injection-Date and Expires in Section 3.2.1 and including Injection-Date and Expires in Section 3.2.7 and
Section 3.2.4 respectively. Section 3.2.5, respectively.
3.1.2. From
The From header field is the same as that specified in Section 3.6.2
of [RFC2822] with the added restrictions detailed above in
Section 2.2.
from = "From:" SP mailbox-list CRLF
3.1.3. Message-ID 3.1.3. Message-ID
The Message-ID header field contains a single unique message The Message-ID header field contains a unique message identifier.
identifier. Netnews is more dependent on message identifier Netnews is more dependent on message identifier uniqueness and fast
uniqueness and fast comparison than Email is, and some news software comparison than Email is, and some news software and standards
and standards [I-D.ietf-nntpext-base] might have trouble with the [I-D.ietf-nntpext-base] might have trouble with the full range of
full range of possible <msg-id>s permitted by [RFC2822]. This possible <msg-id>s permitted by [RFC2822]. This section therefore
section therefore restricts the syntax of <msg-id> as compared to restricts the syntax of <msg-id> as compared to Section 3.6.4 of
Section 3.6.4 of [RFC2822]. The global uniqueness requirement for [RFC2822]. The global uniqueness requirement for <msg-id> in
<msg-id> in [RFC2822] is to be understood as applying across all [RFC2822] is to be understood as applying across all protocols using
protocols using such message identifiers, and across both Email and such message identifiers, and across both Email and Netnews in
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 = "<" id-left "@" id-right ">" msg-id = "<" msg-id-core ">"
; maximum length is 250 octets ; maximum length is 250 octets
msg-id-core = id-left "@" id-right
id-left = dot-atom-text / no-fold-quote id-left = dot-atom-text / no-fold-quote
id-right = dot-atom-text / no-fold-literal id-right = dot-atom-text / no-fold-literal
no-fold-quote = DQUOTE no-fold-quote = DQUOTE
( "." *mqtext / ( "." *mqtext /
*mqtext "." / *mqtext "." /
*mqtext mqspecial *mqtext ) *mqtext mqspecial *mqtext )
DQUOTE DQUOTE
skipping to change at page 18, line 38 skipping to change at page 24, line 40
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 retrieving 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. [I-D.ietf-nntpext-base]) can rely on a bounded length.
Observe that msg-id includes the < and >. Observe that msg-id includes the < and >.
Observe also that in contrast to the corresponding header field in Observe also that in contrast to the corresponding header field in
[RFC2822]: [RFC2822]:
o the syntax does not allow comments within the Message-ID header o the syntax does not allow comments within the Message-ID header
field, field,
skipping to change at page 19, line 30 skipping to change at page 25, line 32
<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,
including the References header field discussed in Section 3.2.2 and including the References header field discussed in Section 3.2.10 and
the Supersedes header field discussed in Section 3.2.6. 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 two Message-IDs where the
only difference is the case of characters in the <id-right> part. only difference is the case of characters in the <id-right> part.
When 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. Subject 3.1.4. Newsgroups
The Subject header field is the same as that specified in Section
3.6.5 of [RFC2822] with the added restrictions detailed in
Section 2.2. Further discussion of the content of the Subject header
field appears in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-
useage].
subject = "Subject:" SP unstructured CRLF
3.1.5. Newsgroups
The Newsgroups header field specifies the newsgroup(s) to which the The Newsgroups header field specifies the newsgroup(s) to which the
article is posted. article is posted.
newsgroups = "Newsgroups:" SP newsgroup-list CRLF newsgroups = "Newsgroups:" SP newsgroup-list CRLF
newsgroup-list = *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 [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 newsgroup component SHOULD NOT consist of digits only and SHOULD
NOT contain uppercase letters. Such components MAY be used only to NOT contain uppercase letters. Such components MAY be used only to
refer to existing groups that do not conform to this naming scheme. refer to existing groups that do not conform to this naming scheme,
but MUST NOT be used otherwise.
NOTE: All-digit components conflict with one widely used storage NOTE: All-digit components conflict with one widely used storage
scheme for articles. Mixed case groups cause confusion between scheme for articles. Mixed-case groups cause confusion between
systems with case sensitive matching and systems with case systems with case-sensitive matching and systems with case-
insensitive matching of <newsgroup-name>s. insensitive matching of <newsgroup-name>s.
<component>s beginning with underline ("_") are reserved for use by <component>s beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT be generated by user future versions of this standard and SHOULD NOT be generated by user
agents (whether in Newsgroups header fields or in newgroup control agents (whether in header fields or in newgroup control messages as
messages [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.
<component>s beginning with "+" and "-" are reserved for private use <component>s beginning with "+" and "-" are reserved for private use
and MUST NOT be generated by user agents (whether in Newsgroups and SHOULD NOT be generated by user agents (whether in header fields
header fields or in newgroup control messages [I-D.ietf-usefor- or in newgroup control messages [I-D.ietf-usefor-usepro]) without a
usepro]) without a private prior agreement to do so. However, such private prior agreement to do so. However, such names MUST be
names MUST be accepted by news servers. accepted by news servers.
The following <newsgroup-name>s are reserved, and MUST NOT be used as The following <newsgroup-name>s are reserved and MUST NOT be used as
the name of a newsgroup: the name of a newsgroup:
o Groups whose first (or only) component is "example" o Groups whose first (or only) <component> is "example"
o The group "poster" o The group "poster"
The following <newsgroup-name>s have been used for specific purposes The following <newsgroup-name>s have been used for specific purposes
in various implementations and protocols, and therefore MUST NOT be in various implementations and protocols and therefore MUST NOT be
used for the names of normal newsgroups. They MAY be used for their used for the names of normal newsgroups. They MAY be used for their
specific purpose, or by local agreement. specific purpose or by local agreement.
o Groups whose first (or only) component is "to" o Groups whose first (or only) component is "to"
o Groups whose first (or only) component is "control" o Groups whose first (or only) component is "control"
o Groups which contain (or consist only of) the component "all" o Groups which contain (or consist only of) the component "all"
o Groups which contain (or consist only of) the component "ctl" o Groups which contain (or consist only of) the component "ctl"
o The group "junk" o The group "junk"
NOTE: "example.*" is reserved for examples in this and other NOTE: "example.*" is reserved for examples in this and other
standards; "poster" has a special meaning in the Followup-To standards; "poster" has a special meaning in the Followup-To
header field; "to.*" is reserved for certain point-to-point header field; "to.*" is reserved for certain point-to-point
communications in conjunction with the "ihave" control message communications in conjunction with the "ihave" control message as
[I-D.ietf-usefor-usepro]; "control.*" and "junk" have special defined in [I-D.ietf-usefor-usepro]; "control.*" and "junk" have
meanings in some news-servers; "all" is used as a wildcard in some special meanings in some news servers; "all" is used as a wildcard
implementations; and "ctl" was formerly used to indicate a in some implementations; and "ctl" was formerly used to indicate a
<control-command> within the Subject header field. <control-command> within the Newsgroups header field.
3.1.6. 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 to enable news servers to avoid header field body. This is primarily so that news servers are able
sending articles to sites already known to have them, in particular to avoid sending articles to sites already known to have them, in
the site they came from, and additionally to permit tracing the route particular the site they came from, and additionally to permit
articles take in moving over the network, and for gathering tracing the route articles take in moving over the network, and for
statistics. gathering statistics.
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list = *( path-identity [FWS] [path-diagnostic] "!" ) path-list = *( path-identity [FWS] [path-diagnostic] "!" )
path-diagnostic = diag-match / diag-other / diag-deprecated path-diagnostic = diag-match / diag-other / diag-deprecated
diag-match = "!" ; another "!" diag-match = "!" ; another "!"
diag-other = "!." diag-keyword [ "." diag-identity ] [FWS] diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]
diag-deprecated = "!" IPv4address [FWS] diag-deprecated = "!" IPv4address [FWS]
diag-keyword = 1*ALPHA ; see USEPRO diag-keyword = 1*ALPHA ; see [I-D.ietf-usefor-usepro]
diag-identity = path-identity / IPv4address / IPv6address diag-identity = path-identity / IPv4address / IPv6address
tail-entry = path-nodot tail-entry = path-nodot
; may be the string "not-for-mail" ; may be the string "not-for-mail"
path-identity = ( 1*( label "." ) toplabel ) / path-nodot path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
skipping to change at page 22, line 48 skipping to change at page 28, line 48
single name with no dots (<path-nodot>). single name with no dots (<path-nodot>).
Each <path-identity> in the <path-list> (which does not include the Each <path-identity> in the <path-list> (which does not include the
<tail-entry>) indicates, from right to left, the successive agents <tail-entry>) indicates, from right to left, the successive agents
through which the article has passed. The use of the <diag-match>, through which the article has passed. The use of the <diag-match>,
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" is sender. If not used for this purpose, the string "not-for-mail"
often used instead (since at one time the whole path could be used as is often used instead (since at one time the whole path could be
a mail address for the sender). used as a mail address for the sender).
NOTE: Although case-insensitive, it is intended that the <path- NOTE: Although case-insensitive, it is intended that the <diag-
keyword>s should be in upper case, to distinguish them from the keyword>s should be in upper-case, 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 IPv6 addresses are allowed means that the colon (:) is The fact that <IPv6address>es are allowed means that the colon (:)
permitted; note that this may cause interoperability problems at is permitted; note that this may cause interoperability problems
older sites that regard ":" as a <path-delimiter> and have neighbors at older sites that regard ":" as a <path-delimiter> and have
whose names have 4 or fewer characters, and where all the characters neighbors whose names have 4 or fewer characters, and where all
are valid HEX digits. the characters are valid HEX digits.
NOTE: Although <IPv4address>es have occasionally been used in the
past (usually with a diagnostic intent), their continued use is
deprecated (though it is still acceptable in the form of the
<diag-deprecated>).
3.1.6. Subject
The Subject header field is the same as that specified in Section
3.6.5 of [RFC2822] with the added restrictions detailed above in
Section 2.2. Further discussion of the content of the Subject header
field appears in [I-D.ietf-usefor-usepro] and
[I-D.ietf-usefor-useage].
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 articles. 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 Reply-To, Sender, Comments, and Keywords are used The header fields Comments, Keywords, Reply-To, and Sender are used
in news articles in the same circumstances and with the same meaning in Netnews articles in the same circumstances and with the same
as that specified in [RFC2822] with the added restrictions detailed meanings as those specified in [RFC2822] with the added restrictions
in Section 2.2. Multiple occurances of the Keywords header field are detailed above in Section 2.2. Multiple occurrences of the Keywords
not permitted. header field are not permitted.
sender = "Sender:" SP mailbox CRLF
reply-to = "Reply-To:" SP address-list CRLF
comments = "Comments:" SP unstructured CRLF comments = "Comments:" SP unstructured CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF keywords = "Keywords:" SP phrase *("," phrase) CRLF
The MIME header fields MIME-Version, Content-Type, Content-Transfer- reply-to = "Reply-To:" SP address-list CRLF
Encoding, Content-Disposition, and Content-Language are used in news
articles in the same circumstances and with the same meanings as
those specified in [RFC2045], [RFC2183], and [RFC3282] with the added
restrictions detailed in Section 2.2.
All remaining news header fields are described below.
3.2.1. Injection-Date
The Injection-Date header field contains the date and time that the
article was injected into the network. Its purpose is to prevent the
reinjection into the news stream of "stale" articles which have
already expired by the time they arrive at some news server.
This header field MUST be inserted whenever an article is injected.
However, software that predates this standard does not use this
header, and therefore agents MUST accept articles without the
Injection-Date header field.
injection-date = "Injection-Date:" SP date-time CRLF
See the remarks under Section 3.1.2 regarding the syntax of
<date-time> and the requirements and recommendations to which it is
subject.
NOTE: Since clocks on various agents may not be synchronized, the
<date-time> in this header field may not be later than the Date
header field, as would be expected. Agents SHOULD use the <date-
time> they believe is correct when adding Inject-Info but SHOULD
NOT alter the pre-existing Date header field.
This header field is intended to replace the currently-used but
undocumented "NNTP-Posting-Date" header field, whose use is now
deprecated.
3.2.2. References
The References header field is the same as that specified in Section
3.6.4 of [RFC2822] with the added restrictions detailed in
Section 2.2 and those listed below:
o The updated <msg-id> construct defined in Section 3.1.3 MUST be
used.
o Message identifiers MUST be separated with CFWS.
o Comments in CFWS between message identifiers can cause
interoperability problems, so comments SHOULD NOT be generated,
but MUST be accepted.
references = "References:" SP [CFWS] msg-id *(CFWS msg-id) sender = "Sender:" SP mailbox CRLF
[CFWS] CRLF
3.2.3. Followup-To The MIME header fields MIME-Version, Content-Type, Content-Transfer-
Encoding, Content-Disposition, and Content-Language are used in
Netnews articles in the same circumstances and with the same meanings
as those specified in [RFC2045], [RFC2183], and [RFC3282] with the
added restrictions detailed above in Section 2.2.
The Followup-To header field specifies to which newsgroup(s) All remaining news header fields are described below.
followups should be posted. The Followup-To header field SHOULD NOT
appear in a message, unless its content is different from the content
of the Newsgroups header field.
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 3.2.1. Approved
CRLF
poster-text = *WSP %d112.111.115.116.101.114 *WSP The Approved header field indicates the mailing addresses (and
; "poster" in lower-case possibly the full names) of the persons or entities approving the
article for posting. Its principal uses are in moderated articles
and in group control messages; see [I-D.ietf-usefor-usepro].
The syntax is the same as that of the Newsgroups (Section 3.1.5) approved = "Approved:" SP mailbox-list CRLF
header field, with the exception that the keyword "poster" requests
that followups should be mailed to the article's reply address rather
than posted. Agents MUST generate the keyword "poster" in lower-
case, but MAY choose to recognize case-insensitive forms such as
"Poster".
As in the Newsgroups (Section 3.1.5) header field, [FWS] in the 3.2.2. Archive
<newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
3.2.4. Expires The Archive header field provides an indication of the poster's
intent regarding preservation of the article in publicly accessible
long-term or permanent storage.
The Expires header field specifies a date and time when the article archive = "Archive:" SP [CFWS] ("no" / "yes")
is deemed to be no longer relevant and could usefully be removed *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF
("expired").
expires = "Expires:" SP date-time CRLF archive-param = parameter
See the remarks under Section 3.1.2 regarding the syntax of The presence of an Archive header field in an article with a field
<date-time> and the requirements and recommendations to which it is body of "no" indicates that the poster does not permit redistribution
subject. from publicly accessible long-term or permanent archives. A field
body of "yes" indicates that the poster permits such redistribution.
NOTE: The Expires header field is also sometimes used in Email No <parameter>s are currently defined; if present, they can be
with a similar meaning [RFC2156]. ignored. Further discussion of the content of the Archive header
field appears in [I-D.ietf-usefor-useage].
3.2.5. 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
argument = 1*( %x21-7E ) argument = 1*( %x21-7E )
The verb indicates what action should be taken, and the argument(s) The verb indicates what action should be taken, and the argument(s)
(if any) supply details. In some cases, the body of the article may (if any) supply details. In some cases, the <body> (as defined in
also contain details. The legal verbs and respective arguments are [RFC2822]) of the article may also contain details. The legal verbs
discussed in the companion document, [I-D.ietf-usefor-usepro]. and respective arguments are discussed in the companion document,
[I-D.ietf-usefor-usepro].
An article with a Control header field MUST NOT also have a An article with a Control header field MUST NOT also have a
Supersedes header field. Supersedes header field.
3.2.6. Supersedes 3.2.4. Distribution
The Supersedes header field contains a message identifier specifying
an article to be superseded upon the arrival of this one. An article
containing a Supersedes header field is equivalent to a "cancel"
[I-D.ietf-usefor-usepro] control message for the specified article,
followed immediately by the new article without the Supersedes header
field.
supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF
NOTE: There is no "c" in Supersedes.
NOTE: The Supersedes header field defined here has no connection
with the Supersedes header field that sometimes appears in Email
messages converted from X.400 according to [RFC2156]; in
particular, the syntax here permits only one <msg-id> in contrast
to the multiple <msg-id>s in that Email version.
3.2.7. Distribution
The Distribution header field specifies geographic or organizational The Distribution header field specifies geographic or organizational
limits on an article's propagation. limits on an article's propagation.
distribution = "Distribution:" SP dist-list CRLF distribution = "Distribution:" SP dist-list CRLF
dist-list = *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
*( ALPHA / DIGIT / "+" / "-" / "_" ) *( ALPHA / DIGIT / "+" / "-" / "_" )
The <dist-name>s "world" and "local" are predefined. However, The <dist-name>s "world" and "local" are reserved. "world" indicates
"world" SHOULD NOT be used explicitly, since it is the default when unlimited distribution and SHOULD NOT be used explicitly, since it is
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
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 [ISO.3166.1988]. <dist-name>s are case-insensitive names drawn from [ISO3166-1]. <dist-name>s are case-insensitive (i.e.
(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.8. Summary 3.2.5. Expires
The Summary header field is a short phrase summarizing the article's
content.
summary = "Summary:" SP unstructured CRLF
3.2.9. Approved
The Approved header field indicates the mailing addresses (and
possibly the full names) of the persons or entities approving the
article for posting. Its principal uses are in moderated articles
and in group control messages [I-D.ietf-usefor-usepro].
approved = "Approved:" SP mailbox-list CRLF
Each mailbox contained in the Approved header field MUST be that of
one of the person(s) or entity(ies) in question, and one of those
mailboxes MUST be that of the actual sender of the article. Note
that this standard does not provide any means to enforce or verify
this requirement, but future extensions or standards may provide such
a facility (e.g. digitial signatures).
3.2.10. Organization
The Organization header field is a short phrase identifying the
poster's organization.
organization = "Organization:" SP unstructured CRLF
NOTE: There is no "s" in Organization.
3.2.11. Xref
The Xref header field indicates where an article was filed by the
last news server to process it. The article locations are used to
keep track of crossposted articles so that user agents serviced by a
particular news server can mark such articles as read.
xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF
server-name = path-identity The Expires header field specifies a date and time when the poster
deems the article to be no longer relevant and could usefully be
removed ("expired").
location = newsgroup-name ":" article-locator NOTE: This header field is useful when the poster desires an
unusually long or an unusually short expiry time.
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) expires = "Expires:" SP date-time CRLF
; US-ASCII printable characters
; except '(' and ';'
The <server-name> is included so that software can determine which See the remarks under Section 3.1.1 regarding the syntax of
news server generated the header field. The locations specify what <date-time> and the requirements and recommendations to which it is
newsgroups the article was filed under (which may differ from those subject.
in the Newsgroups header field) and where it was filed under them.
The exact form of an <article-locator> is implementation-specific.
NOTE: The traditional form of an <article-locator> (as required by NOTE: The Expires header field is also sometimes used in Email
[I-D.ietf-nntpext-base]) is a decimal number, with articles in with a similar meaning; see [RFC2156].
each newsgroup numbered consecutively starting from 1.
3.2.12. Archive 3.2.6. Followup-To
The Archive header field provides an indication of the poster's The Followup-To header field specifies to which newsgroup(s) the
intent regarding preservation of the article in publicly accessible poster has requested that followups are to be posted. The
long-term or permanent storage. Followup-To header field SHOULD NOT appear in a message, unless its
content is different from the content of the Newsgroups header field.
archive = "Archive:" SP [CFWS] ("no" / "yes") followup-to = "Followup-To:" SP ( newsgroup-list / poster-text )
*( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF CRLF
archive-param = parameter poster-text = *WSP %d112.111.115.116.101.114 *WSP
; "poster" in lower-case
The presence of an Archive header field in an article with a field The syntax is the same as that of the Newsgroups (Section 3.1.4)
body of "no" indicates that the poster does not permit redistribution header field, with the exception that the keyword "poster" requests
from publicly accessible long-term or permanent archives. The that followups should be emailed directly to the article's poster
absence of this header field, or the presence of this header field (using the addresses contained in the Reply-To header field if one
with a field body of "yes", indicates that the poster is willing for exists, otherwise using the addresses contained in the From header
such redistribution to take place. Further extensions to this field) rather than posted to any newsgroups. Agents MUST generate
standard may provide parameters for administration of the archiving the keyword "poster" in lower-case, but MAY choose to recognize case-
process. insensitive forms such as "Poster".
3.2.13. User-Agent As in the Newsgroups (Section 3.1.4) header field, [FWS] in the
<newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
The User-Agent header field contains information about the user agent 3.2.7. Injection-Date
(typically a newsreader) generating the article, for statistical
purposes and tracing of standards violations to specific software
needing correction. It is intended that this header field be
suitable for use in Email.
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF The Injection-Date header field contains the date and time that the
article was injected into the network. Its purpose is to enable news
servers, when checking for "stale" articles, to use a <date-time>
that was added by a news server at injection time rather than one
added by the user agent at message composition time.
product = [CFWS] token [ [CFWS] "/" product-version ] This header field MUST be inserted whenever an article is injected.
However, software that predates this standard does not use this
header, and therefore agents MUST accept articles without the
Injection-Date header field.
product-version = [CFWS] token injection-date = "Injection-Date:" SP date-time CRLF
This header field MAY contain multiple product-tokens identifying the See the remarks under Section 3.1.1 regarding the syntax of
user agent and any subproducts which form a significant part of it, <date-time> and the requirements and recommendations to which it is
listed in order of their significance for identifying the subject.
application.
NOTE: Some of this information has previously been sent in non- NOTE: Since clocks on various agents are not necessarily
standardized header fields such as X-Newsreader, X-Mailer, synchronized, the <date-time> in this header field may not be
X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent later than the Date header field, as be expected. Agents MUST NOT
uses User-Agent, it should have no need to send these non-standard alter a pre-existing Date header field when adding an Injection-
header fields. Date header field.
NOTE: [RFC2616] describes a similar facility for the HTTP This header field is intended to replace the currently-used but
protocol. This specification differs in that "{" and "}" are undocumented "NNTP-Posting-Date" header field, whose use is now
allowed in tokens (<product> and <product-version>) and comments deprecated.
are permitted wherever whitespace is allowed.
3.2.14. 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 30, line 26 skipping to change at page 34, line 36
this standard. If non-standards-based <attribute>s are used, they this standard. If non-standards-based <attribute>s are used, they
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 uses Injection-
Info, it should have no need to send these non-standard header Info, it should have no need to send these non-standard header
fields. fields.
The "posting-host" <parameter> specifies the FQDN and/or IP address The "posting-host" <parameter> specifies the FQDN and/or IP address
(IPv4address or IPv6address) of the host from which the news server (IPv4address or IPv6address) of the host from which the news server
received the article. received the article.
NOTE: If the "posting-host" <parameter> identifies a dial-up NOTE: If the "posting-host" <parameter> identifies a dial-up
point-of-presence, the "posting-account" or the "logging-data" point-of-presence, the "posting-account" or the "logging-data"
<parameter> may provide additional information about the true <parameter> may provide additional information about the true
origin of the article. origin of the article.
The "posting-account" <parameter> identifies the source from which The "posting-account" <parameter> identifies the source from which
that news server received the article, in a notation that can be that news server received the article, in a notation that can be
interpreted by the news server administrator. This notation can interpreted by the news server administrator. This notation can
include any information the administrator deems pertinent. 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 can't be interpreted by other sites. However, to make it useful that cannot be interpreted by other sites. However, to make it
for rate limiting and abuse detection, two messages posted from the useful for rate limiting and abuse detection, two messages posted
same source SHOULD have the same value of "posting-account", and two from the same source SHOULD have the same value of "posting-account",
messages from different sources SHOULD have differing values of and two messages from different sources SHOULD have differing values
"posting-account". The exact definition of "source" is left to the of "posting-account". The exact definition of "source" is left to
discretion of the news server administrator. the discretion of the news server administrator.
The "logging-data" <parameter> contains information (typically a The "logging-data" <parameter> contains information (typically a
session number or other non-persistent means of identifying a posting session number or other non-persistent means of identifying a posting
account) that will enable the true origin of the article to be account) that will enable the true origin of the article to be
determined by reference to logging information kept by the news determined by reference to logging information kept by the news
server. server.
The "mail-complaints-to" <parameter> specifies 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 <parameter>s to include. Some It is a matter of local policy which of the above <parameter>s to
pieces of information have privacy implications; this is discussed in include. Some pieces of information have privacy implications; this
[I-D.ietf-usefor-useage]. is discussed in [I-D.ietf-usefor-useage].
3.3. Obsolete Header Fields 3.2.9. Organization
Early Netnews software sometimes generated header fields such as: The Organization header field is a short phrase identifying the
poster's organization.
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP organization = "Organization:" SP unstructured CRLF
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Date-Received: Friday, 19-Nov-82 16:59:30 EST
Relay-Version contained version information about the news server NOTE: There is no "s" in Organization.
that last processed the article. Posting-Version contained version
information about the user agent that posted the article. Date-
Received contained the date when the last news server to process the
article first saw it (in a slightly nonstandard format).
These header fields are mentioned for historical purposes only. 3.2.10. References
Agents MUST NOT generate articles containing these header fields.
In addition, this standard obsoletes certain header fields defined in The References header field is the same as that specified in Section
[Son-of-1036]: 3.6.4 of [RFC2822] with the added restrictions detailed above in
Section 2.2 and those listed below:
Also-Control: cancel <9urrt98y53@site.example> o The updated <msg-id> construct defined in Section 3.1.3 MUST be
See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example> used.
Article-Names: comp.foo:charter
Article-Updates: <i4g587y@site1.example>
Also-Control indicated a control message that was also intended to be o Message identifiers MUST be separated with CFWS.
filed as a normal article. See-Also listed related articles, but
without the specific relationship with followups that pertains to the
References header field. Article-Names indicated some special
significance of that article in relation to the indicated newsgroup.
Article-Updates indicated that an earlier article was updated,
without at the same time being superseded.
The header fields listed above are documented for historical purposes o Comments in CFWS between message identifiers can cause
only. These header fields MUST NOT be generated and SHOULD be interoperability problems, so comments SHOULD NOT be generated,
ignored. but MUST be accepted.
references = "References:" SP [CFWS] msg-id *(CFWS msg-id)
[CFWS] CRLF
3.2.11. Summary
The Summary header field is a short phrase summarizing the article's
content.
summary = "Summary:" SP unstructured CRLF
3.2.12. Supersedes
The Supersedes header field contains a message identifier specifying
an article to be superseded upon the arrival of this one. An article
containing a Supersedes header field is equivalent to a "cancel"
[I-D.ietf-usefor-usepro] control message for the specified article,
followed immediately by the new article without the Supersedes header
field.
supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF
NOTE: There is no "c" in Supersedes.
NOTE: The Supersedes header field defined here has no connection
with the Supersedes header field that sometimes appears in Email
messages converted from X.400 according to [RFC2156]; in
particular, the syntax here permits only one <msg-id> in contrast
to the multiple <msg-id>s in that Email version.
3.2.13. User-Agent
The User-Agent header field contains information about the user agent
(typically a newsreader) generating the article, for statistical
purposes and tracing of standards violations to specific software
needing correction. It is intended that this header field be
suitable for use in Email.
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ]
product-version = [CFWS] token
This header field MAY contain multiple <product> tokens identifying
the user agent and any subproducts which form a significant part of
it, listed in order of their significance for identifying the
application.
NOTE: Some of this information has previously been sent in non-
standardized header fields such as X-Newsreader, X-Mailer,
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
header fields.
NOTE: [RFC2616] describes a similar facility for the HTTP
protocol. The Netnews article format differs in that "{" and "}"
are allowed in tokens (<product> and <product-version>) and
comments are permitted wherever whitespace is allowed.
3.2.14. Xref
The Xref header field indicates where an article was filed by the
last news server to process it. User agents often use the
information in the Xref header field to avoid multiple processing of
crossposted articles.
xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF
server-name = path-identity
location = newsgroup-name ":" article-locator
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters
; except '(' and ';'
The <server-name> is included so that software can determine which
news server generated the header field. The locations specify what
newsgroups the article was filed under (which may differ from those
in the Newsgroups header field) and where it was filed under them.
The exact form of an <article-locator> is implementation-specific.
NOTE: The traditional form of an <article-locator> (as required by
[I-D.ietf-nntpext-base]) is a decimal number, with articles in
each newsgroup numbered consecutively starting from 1.
3.3. Obsolete Header Fields
The header fields Date-Received, Posting-Version, and Relay-Version
defined in [RFC0850], as well as Also-Control, Article-Names,
Article-Updates, and See-Also defined in [Son-of-1036] are declared
obsolete. See the cited specification documents for further
information on their original use.
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 of The Lines header field indicates the number of lines in the <body>
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 includes all body lines, including the signature if The line count is the number of CRLF separators in the <body>.
any, including empty lines (if any) at the beginning or end of the
body, and including the whole of all MIME message and multipart parts
contained in the body (the single empty separator line between the
header fields and the body is not part of the body). The "body" here
is the body as found in the posted article as transmitted by the user
agent.
Historically, this header field was used by the [I-D.ietf-nntpext- Historically, this header field was used by the
base] Overview facility, but its use for this purpose is now [I-D.ietf-nntpext-base] overview facility, but its use for this
deprecated. As a result, this header field is to be regarded as purpose is now deprecated. As a result, this header field is to be
obsolescent, and it is likely to be removed entirely in a future regarded as obsolescent, and it is likely to be removed entirely in a
version of this standard. Servers and clients SHOULD ignore it, and future version of this standard. All agents SHOULD ignore it and
SHOULD NOT generate it. SHOULD NOT generate it.
4. Internationalization Considerations 4. Internationalization Considerations
Internationalization of news 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 news article format specified in this document does not provide The Netnews article format specified in this document does not
any security services, such as confidentiality, authentication of provide any security services, such as confidentiality,
sender, or non-repudiation. Instead, such services need to be authentication of sender, or non-repudiation. Instead, such services
layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME need to be layered above, using such protocols as S/MIME [RFC3851] or
[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 [PGPVERIFY] will hopefully be standardized in the near protocols such as [PGPVERIFY] may be standardized in the near future.
future.
Message identifiers (Section 3.1.3) in news are required to be Message identifiers (Section 3.1.3) in news are required to be
unique; articles are refused (in server-to-server transfer) if the unique; articles may be refused (in server-to-server transfer) if the
identifier has already been seen. So if you can predict the identifier has already been seen. So if you can predict the
identifier of a message, you can preempt it by posting a message identifier of a message, you can preempt it by posting a message
(possibly to a quite different group) with the same message (possibly to a quite different group) with the same message
identifier, stopping your target message from propagating. Agents identifier, stopping your target message from propagating. Agents
that generate message identifiers for news articles SHOULD ensure that generate message identifiers for Netnews articles SHOULD ensure
that they are unpredictable. 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;
boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
Such differences in parsing may be used as part of an attack. Such deficiencies in parsing may be used as part of an attack.
Further security considerations are discussed in
[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)
Header field name: Approved Header field name: Approved
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.9) Specification document(s): This document (Section 3.2.1)
Header field name: Archive Header field name: Archive
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.12) Specification document(s): This document (Section 3.2.2)
Header field name: Article-Names Header field name: Article-Names
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.17) Specification document(s): [Son-of-1036] (Section 6.17)
Header field name: Article-Updates Header field name: Article-Updates
Applicable protocol: netnews Applicable protocol: netnews
Status: obsoleted Status: obsoleted
skipping to change at page 35, line 52 skipping to change at page 41, line 52
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), Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.5) [RFC2822] (Section 3.6.5)
Header field name: Control Header field name: Control
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.5) Specification document(s): This document (Section 3.2.3)
Header field name: Date Header field name: Date
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.2), Specification document(s): This document (Section 3.1.1),
[RFC2822] (Section 3.6.1) [RFC2822] (Section 3.6.1)
Header field name: Date-Received
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.2.4)
Header field name: Distribution Header field name: Distribution
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.7) Specification document(s): This document (Section 3.2.4)
Header field name: Expires Header field name: Expires
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.4) Specification document(s): This document (Section 3.2.5)
Header field name: Followup-To Header field name: Followup-To
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.3) Specification document(s): This document (Section 3.2.6)
Header field name: From Header field name: From
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.1), Specification document(s): This document (Section 3.1.2),
[RFC2822] (Section 3.6.2) [RFC2822] (Section 3.6.2)
Header field name: Injection-Date Header field name: Injection-Date
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.1) Specification document(s): This document (Section 3.2.7)
Header field name: Injection-Info Header field name: Injection-Info
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.8)
Header field name: Keywords Header field name: Keywords
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), 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
skipping to change at page 37, line 25 skipping to change at page 43, line 31
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
Status: standard Status: standard
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3.1.5) Specification document(s): This document (Section 3.1.4)
Header field name: NNTP-Posting-Date Header field name: NNTP-Posting-Date
Applicable protocol: netnews Applicable protocol: netnews
Status: obsoleted Status: obsoleted
Author/change controller: IETF Author/change controller: IETF
Specification document(s): none Specification document(s): none
Header field name: NNTP-Posting-Host Header field name: NNTP-Posting-Host
Applicable protocol: netnews Applicable protocol: netnews
Status: obsoleted Status: obsoleted
Author/change controller: IETF Author/change controller: IETF
Specification document(s): none Specification document(s): [RFC2980] (Section 3.4.1)
Header field name: Organization Header field name: Organization
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.10) Specification document(s): This document (Section 3.2.9)
Header field name: Path Header field name: Path
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.6) Specification document(s): This document (Section 3.1.5)
Header field name: Posting-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.2)
Header field name: References Header field name: References
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.2), Specification document(s): This document (Section 3.2.10),
[RFC2822] (Section 3.6.4) [RFC2822] (Section 3.6.4)
Header field name: Relay-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.1)
Header field name: Reply-To Header field name: Reply-To
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), Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.2) [RFC2822] (Section 3.6.2)
Header field name: See-Also Header field name: See-Also
Applicable protocol: netnews Applicable protocol: netnews
Status: obsoleted Status: obsoleted
skipping to change at page 38, line 35 skipping to change at page 45, line 5
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), Specification document(s): This document (Section 3.2),
[RFC2822] (Section 3.6.2) [RFC2822] (Section 3.6.2)
Header field name: Subject Header field name: Subject
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.4), Specification document(s): This document (Section 3.1.6),
[RFC2822] (Section 3.6.5) [RFC2822] (Section 3.6.5)
Header field name: Summary Header field name: Summary
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.8) Specification document(s): This document (Section 3.2.11)
Header field name: Supersedes Header field name: Supersedes
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.6) Specification document(s): This document (Section 3.2.12)
Header field name: User-Agent Header field name: User-Agent
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.13) Specification document(s): This document (Section 3.2.13)
Related information: [RFC2616] (Section 14.43)
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.11) 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". [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)
skipping to change at page 40, line 48 skipping to change at page 46, line 49
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002. May 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [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. 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] [I-D.ietf-nntpext-base]
Feather, C., "Network News Transfer Protocol", Feather, C., "Network News Transfer Protocol",
draft-ietf-nntpext-base-27 (work in progress), June 2005. draft-ietf-nntpext-base-27 (work in progress), June 2005.
[I-D.ietf-usefor-useage] [I-D.ietf-usefor-useage]
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.
[ISO.3166.1988] [ISO3166-1]
International Organization for Standardization, "Codes for International Organization for Standardization, "ISO 3166-
the representation of names of countries, 3rd edition", 1:1997. Codes for the representation of names of countries
ISO Standard 3166, August 1988. and their subdivisions -- Part 1: Country codes", 1997.
[PGPVERIFY] [PGPVERIFY]
Lawrence, D., "PGPverify", June 1999. Lawrence, D., "PGPverify",
ftp://ftp.isc.org/pub/pgpcontrol/README.html, June 1999.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC0850] Horton, M., "Standard for interchange of USENET messages",
RFC 850, June 1983.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156, Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998. January 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980,
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.
[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",
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 the 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 Message-ID, Newsgroups, Path, Followup-To, Control, the Control, Distribution, Followup-To, Lines, Message-ID,
Supersedes, Distribution, Xref and Lines header fields. Newsgroups, Path, Supersedes, and Xref header fields.
o Whitespace is permitted in Newsgroups header fields. o Multiple addreses are allowed in the From header field.
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
header field.
o MIME is recognized as an integral part of Netnews. o MIME is recognized as an integral part of Netnews.
o There is a new Injection-Date header to make the rejection of o There is a new Injection-Date header field to make the rejection
stale articles more precise and to minimize spurious rejections. of stale articles more precise and to minimize spurious
rejections.
o There are several new optional header fields defined, notably o There are several new optional header fields defined, notably
Archive, Injection-Info and User-Agent, leading to increased Archive, Injection-Info, and User-Agent, leading to increased
functionality. functionality.
o Certain header fields, notably Lines, have been 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].
skipping to change at page 46, line 12 skipping to change at page 52, line 12
whitespace character. This means that an empty header field body whitespace character. This means that an empty header field body
is illegal. is illegal.
Authors' Addresses Authors' Addresses
Kenneth Murchison (editor) Kenneth Murchison (editor)
Carnegie Mellon University Carnegie Mellon University
5000 Forbes Avenue 5000 Forbes Avenue
Cyert Hall 285 Cyert Hall 285
Pittsburgh, PA 15213 Pittsburgh, PA 15213
US U.S.A.
Phone: +1 412 268 2638 Phone: +1 412 268 2638
Email: murch@andrew.cmu.edu Email: murch@andrew.cmu.edu
Charles H. Lindsey Charles H. Lindsey
University of Manchester University of Manchester
5 Clerewood Avenue 5 Clerewood Avenue
Heald Green Heald Green
Cheadle Cheadle
Cheshire SK8 3JU Cheshire SK8 3JU
GB U.K.
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clw.cs.man.ac.uk Email: chl@clerew.man.ac.uk
Dan Kohn Dan Kohn
FlyDash, Inc. FlyDash, Inc.
425 Alma St. #411 425 Alma St. #411
Palo Alto, CA 94301 Palo Alto, CA 94301
US U.S.A.
Phone: +1 415 233 1000 Phone: +1 415 233 1000
Email: dan@dankohn.com Email: dan@dankohn.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 47, line 29 skipping to change at page 53, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 173 change blocks. 
537 lines changed or deleted 618 lines changed or added

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