draft-ietf-usefor-usefor-03.txt   draft-ietf-usefor-usefor-04.txt 
Usenet Format Working Group K. Murchison, Ed. Usenet Format Working Group K. Murchison, Ed.
Internet-Draft Oceana Matrix Ltd. Internet-Draft Oceana Matrix Ltd.
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 (if approved) C. Lindsey
Expires: October 8, 2005 University of Manchester Expires: November 25, 2005 University of Manchester
D. Kohn D. Kohn
Skymoon Ventures Skymoon Ventures
April 6, 2005 May 24, 2005
News Article Format Netnews Article Format
draft-ietf-usefor-usefor-03 draft-ietf-usefor-usefor-04
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 October 8, 2005. This Internet-Draft will expire on November 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies the syntax of network news (Netnews) articles This document specifies the syntax of network news (Netnews) articles
in the context of the "Internet Message Format" (RFC 2822) and in the context of the "Internet Message Format" (RFC 2822) and
"Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This
document supersedes RFC 1036, updating it to reflect current practice document supersedes RFC 1036, updating it to reflect current practice
and incorporating incremental changes specified in other documents. and incorporating incremental changes specified in other documents.
Changes since draft-ietf-usefor-usefor-03
o Reworked ABNFs of several headers.
o Used Charles' ABNF for <msg-id>.
o Disallowed comments in Supersedes header.
o Disallowed comments in Xref header.
o Disallowed comments in Message-Id header.
o CFWS between msg-ids in References header is not optional.
o Compatibility changes based on comments from Charles.
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-02 Changes since draft-ietf-usefor-usefor-02
o Changed to RFC 3978 boilerplate (xml2rfc v1.29) o Changed to RFC 3978 boilerplate (xml2rfc v1.29)
o Changed "network news" to "Netnews" throughout. o Changed "network news" to "Netnews" throughout.
o Prohibit NO-WS-CTL in msg-id-core. o Prohibit NO-WS-CTL in msg-id.
o Complaints-To header is now an Injection-Info parameter. o Complaints-To header is now an Injection-Info parameter.
o Added descriptions of Injection-Info parameters. o Added descriptions of Injection-Info parameters.
o Removed "filename" parameter from Archive header. o Removed "filename" parameter from Archive header.
o Added CFWS to User-Agent header. o Added CFWS to User-Agent header.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
skipping to change at page 2, line 37 skipping to change at page 3, line 9
o Added definitions of "proto-article", "posting agent", "followup", o Added definitions of "proto-article", "posting agent", "followup",
"followup-agent", "user-agent", and "injecting agent". "followup-agent", "user-agent", and "injecting agent".
o Removed discussion of message/partial MIME messages. o Removed discussion of message/partial MIME messages.
o Noted that the header contents in every line MUST NOT be empty. o Noted that the header contents in every line MUST NOT be empty.
o Merged MIME sections. o Merged MIME sections.
o Only allow "UT and "GMT" in Date header; disallow all other <obs- o Only allow "UT" and "GMT" in Date header; disallow all other <obs-
zone>. zone>.
o Used Charles' ABNF for <msg-id> and <unstructured>. o Used Charles' ABNF for <msg-id> and <unstructured>.
o Removed restrictions on length and start character for Newsgroups. o Removed restrictions on length and start character for Newsgroups.
o More verbose description of Path header. o More verbose description of Path header.
o Disallowed comments in Control header. o Disallowed comments in Control header.
o Specified that <control-message> is a verb optionally followed by o Specified that <control-command> is a verb optionally followed by
whitespace-separated arguments. whitespace-separated arguments.
o Noted that Supersedes header is different from [Son-of-1036]. o Noted that Supersedes header is different from [Son-of-1036].
o More exact ABNF for Archive and Injection-Info parameters. o More exact ABNF for Archive and Injection-Info parameters.
o Discussed meaning of "yes", "no" in Archive header. o Discussed meaning of "yes", "no" in Archive header.
o Added "Obsolete Headers" section. o Added "Obsolete Headers" section.
skipping to change at page 3, line 46 skipping to change at page 4, line 17
o Added required SP to ABNF of header definitions. o Added required SP to ABNF of header definitions.
o Disallowed comments in Control header. o Disallowed comments in Control header.
o Xref header allows for non-digit "locations". o Xref header allows for non-digit "locations".
o Only allow for a single message-id in Supersedes header. o Only allow for a single message-id in Supersedes header.
o Changes to the References header. o Changes to the References header.
o Compatibility changes based on comments from Charles o Disallowed comments in Xref header.
o Disallowed comments in Message-Id header.
o Compatibility changes based on comments from Charles.
Changes since draft-ietf-usefor-article-13 Changes since draft-ietf-usefor-article-13
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 Issues to be addressed
skipping to change at page 4, line 29 skipping to change at page 5, line 4
o Add appendixes for changes from RFC 1036 and differences from RFC o Add appendixes for changes from RFC 1036 and differences from RFC
2822. 2822.
o IANA considerations (the Klyne message header registry is now o IANA considerations (the Klyne message header registry is now
official as RFC 3864). official as RFC 3864).
o Collected Syntax. o Collected Syntax.
o Merge more security issues? o Merge more security issues?
o Merge acknowledgments? o Merge acknowledgments?
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 6 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 7
1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8
1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Structure of This Document . . . . . . . . . . . . . . . . 8 1.6 Structure of This Document . . . . . . . . . . . . . . . . 9
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 11
3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 11 3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 11 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 12
3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 12 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 14 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 16
3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 15 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 17
3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 Injection-Date . . . . . . . . . . . . . . . . . . . . 18
3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2 References . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 17 3.2.3 Followup-To . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.4 Expires . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.5 Control . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 18 3.2.6 Supersedes . . . . . . . . . . . . . . . . . . . . . . 20
3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 18 3.2.7 Distribution . . . . . . . . . . . . . . . . . . . . . 20
3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.9 Approved . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 19 3.2.10 Organization . . . . . . . . . . . . . . . . . . . . 21
3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.11 Xref . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 20 3.2.12 Archive . . . . . . . . . . . . . . . . . . . . . . 22
3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 20 3.2.13 User-Agent . . . . . . . . . . . . . . . . . . . . . 23
3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 21 3.2.14 Injection-Info . . . . . . . . . . . . . . . . . . . 23
3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 23 3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Internationalization Considerations . . . . . . . . . . . . 25 4. Internationalization Considerations . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Normative References . . . . . . . . . . . . . . . . . . . 27 6.1 Normative References . . . . . . . . . . . . . . . . . . . 29
6.2 Informative References . . . . . . . . . . . . . . . . . . 27 6.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . 33
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" (which are a subset of Email messages) and retrieving news "articles" (whose format is a subset of that for
for exchanging them amongst a readership which is potentially widely Email messages) and for exchanging them amongst a readership which is
distributed. It is organized around "newsgroups", with the potentially widely distributed. It is organized around "newsgroups",
expectation that each reader will be able to see all articles posted with the expectation that each reader will be able to see all
to each newsgroup in which he participates. These protocols most articles posted to each newsgroup in which he participates. These
commonly use a flooding algorithm which propagates copies throughout protocols most commonly use a flooding algorithm which propagates
a network of participating servers. Typically, only one copy is copies throughout a network of participating servers. Typically,
stored per server, and each server makes it available on demand to only one copy is stored per server, and each server makes it
readers able to access that server. available on demand to readers able to access that server.
1.2 Scope 1.2 Scope
This document specifies the syntax of network news (Netnews) articles This document specifies the syntax of network news (Netnews) articles
in the context of the "Internet Message Format" [RFC2822] and in the context of the "Internet Message Format" [RFC2822] and
"Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This
document supersedes [RFC1036], updating it to reflect current document supersedes [RFC1036], updating it to reflect current
practice and incorporating changes and clarifications specified in practice and incorporating changes and clarifications specified in
other documents such as [Son-of-1036]. other documents such as [Son-of-1036].
skipping to change at page 7, line 13 skipping to change at page 8, line 13
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
1.4 Syntax Notation 1.4 Syntax Notation
Headers defined in this specification use the Augmented Backus-Naur Headers defined in this specification use the Augmented Backus-Naur
Form (ABNF) notation (including the Core Rules) specified in Form (ABNF) notation (including the Core Rules) specified in
[RFC2234] and many constructs defined in [RFC2822] and [RFC2045]. [RFC2234] and many constructs defined in [RFC2822] and [RFC2045].
Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of
<zone> and <msg-id> respectively. <zone> and <msg-id> respectively.
The following constructs referenced by this document are defined in
[RFC2822]: <mailbox-list>, <mailbox>, <date-time>, <phrase>,
<address-list>, <utext>, <dot-atom-text>, <dot-atom>, <FWS>, <CFWS>
and <CRLF>.
The following constructs referenced by this document are defined in
[RFC2045] (as amended by [RFC2231]): <token>, <parameter>, <value>.
1.5 Definitions 1.5 Definitions
An "article" is the unit of news, synonymous with an [RFC2822] An "article" is the unit of news, synonymous with an [RFC2822]
"message". A "proto-article" is one that has not yet been injected "message". A "proto-article" is one that has not yet been injected
into the news system. In constrast to an "article", a "proto- into the news system. In constrast to an "article", a "proto-
article" may lack some mandatory headers. article" may lack some mandatory headers.
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 "posting agent" which posted it or, article, usually supplied by the "posting agent" which posted it or,
failing that, by the "injecting agent". It distinguishes the article failing that, by the "injecting agent". It distinguishes the article
skipping to change at page 8, line 6 skipping to change at page 9, line 14
is then passed on to an "injecting agent" for final checking and is then passed on to an "injecting agent" for final checking and
injection into the news stream. If the article is not compliant, or injection into the news stream. If the article is not compliant, or
is rejected by the injecting agent, then the posting agent informs is rejected by the injecting agent, then the posting agent informs
the poster with an explanation of the error. the poster with an explanation of the error.
A "reader" is the person or software reading news articles. A "reader" is the person or software reading news articles.
A "reading agent" is software which presents articles to a reader. A "reading agent" is software which presents articles to a reader.
A "followup" is an article containing a response to the contents of A "followup" is an article containing a response to the contents of
an earlier article (the followup's "precursor"). an earlier article (the followup's "precursor" indicated in the
"References" header).
A "followup agent" is a combination of reading agent and posting A "followup agent" is a combination of reading agent and posting
agent that aids in the preparation and posting of a followup. agent that aids in the preparation and posting of a followup.
Posting, reading and followup agents (which are usually just Posting, reading and followup agents (which are usually just
different services provided by the same piece of software) are known different services provided by the same piece of software) are known
collectively as "user agents". collectively as "user agents".
An "injecting agent" takes the finished article from the posting An "injecting agent" takes the finished article from the posting
agent (often via the [NNTP] "post" command) performs some final agent (often via the [NNTP] "post" command) performs some final
skipping to change at page 11, line 32 skipping to change at page 12, line 32
archive / archive /
user-agent / user-agent /
injection-info ) injection-info )
Each of these headers may occur at most once in a news article. Each of these headers may occur at most once in a news article.
3.1 Mandatory Headers 3.1 Mandatory Headers
Each news article conformant with this specification MUST have Each news article conformant with this specification MUST have
exactly one of each of the following headers: From, Date, Message-ID, exactly one of each of the following headers: From, Date, Message-ID,
Subject, Newsgroups, Path, and Injection-Date. Subject, Newsgroups, Path.
3.1.1 From 3.1.1 From
The From header is the same as that specified in Section 3.6.2 of The From header is the same as that specified in Section 3.6.2 of
[RFC2822] with the added restrictions detailed in Section 2.2. [RFC2822] with the added restrictions detailed in Section 2.2.
from = "From:" SP mailbox-list CRLF from = "From:" SP mailbox-list CRLF
3.1.2 Date 3.1.2 Date
skipping to change at page 12, line 13 skipping to change at page 13, line 13
orig-date = "Date:" SP date-time CRLF orig-date = "Date:" SP date-time CRLF
zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
Note that agents SHOULD NOT generate <date-time> constructs which Note that agents SHOULD NOT generate <date-time> constructs which
include either "UT" or "GMT" and MUST NOT generate <date-time> include either "UT" or "GMT" and MUST NOT generate <date-time>
constructs which include any other zone names defined by <obs-zone>, constructs which include any other zone names defined by <obs-zone>,
some of which have ambiguous interpretations and would have adverse some of which have ambiguous interpretations and would have adverse
effects on the Netnews protocols. effects on the Netnews protocols.
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.1.7 and including Injection-Date and Expires in Section 3.2.1 and
Section 3.2.3 respectively. Section 3.2.4 respectively.
3.1.3 Message-ID 3.1.3 Message-ID
The Message-ID header contains a single unique message identifier. The Message-ID header contains a single unique message identifier.
This document updates the <msg-id> construct from Section 3.6.4 of This document updates the <msg-id> construct from Section 3.6.4 of
[RFC2822] so as to ensure that Internet Message Format Message-IDs [RFC2822] so as to ensure that Internet Message Format Message-IDs
are usable in widely deployed news software. The global uniqueness are usable in widely deployed news software. The global uniqueness
requirement for <msg-id> in [RFC2822] is to be understood as applying requirement for <msg-id> in [RFC2822] is to be understood as applying
across all protocols using such message identifiers, and across both across all protocols using such message identifiers, and across both
Email and Netnews in particular. A revised syntax for <msg-id> is Email and Netnews in particular. A revised syntax for <msg-id> is
given below, but the requirements and descriptive text from Section given below, but the requirements and descriptive text from Section
3.6.4 of [RFC2822] still apply. 3.6.4 of [RFC2822] still apply.
message-id = "Message-ID:" SP msg-id CRLF message-id = "Message-ID:" SP [FWS] msg-id [FWS] CRLF
msg-id = [FWS] msg-id-core [FWS]
msg-id-core = "<" id-left "@" id-right ">" msg-id = "<" id-left "@" id-right ">"
; maximum length is 250 octets ; maximum length is 250 octets
id-left = dot-atom-text / no-fold-quote id-left = dot-atom-text / no-fold-quote
id-right = dot-atom-text / no-fold-literal id-right = dot-atom-text / no-fold-literal
no-fold-quote = DQUOTE no-fold-quote = DQUOTE
*( mqtext / mquoted-pair ) ( "." mqtext /
mqspecial *mqtext "." /
*( mqtext / mquoted-pair ) *mqtext mqspecial *mqtext )
DQUOTE DQUOTE
mqtext = %d33 / ; all of <text> except mqtext = atext / "." / mqspecial
%d35-61 / ; controls, SP, HTAB, "\", ">"
%d63-91 / ; and DQUOTE
%d93-126
mquoted-pair = "\\" / "\" DQUOTE
mqspecial = "(" / ")" / ; same as specials except mqspecial = "(" / ")" / ; same as specials except
"<" / ; "\" and DQUOTE quoted "<" / ; "\" and DQUOTE quoted
"[" / "]" / ; and ">" omitted "[" / "]" / ; "." doubled and ">" omitted
":" / ";" / ":" / ";" /
"@" / "," / "@" / "," /
"." / mquoted-pair ".." / "\\" / "\" DQUOTE
no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
[[Adjacent dots should not be allowed]]
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-core MUST NOT be more than 250 octets in length. The msg-id MUST NOT be more than 250 octets in length.
NOTE: The length restriction ensures that systems which accept NOTE: The length restriction ensures that systems which accept
message identifiers as a parameter when retrieving an article message identifiers as a parameter when retrieving an article
(e.g. [NNTP]) can rely on a bounded length. (e.g. [NNTP]) can rely on a bounded length.
Observe that msg-id-core includes the < and >. Observe that msg-id includes the < and >.
Observe also that in contrast to the corresponding header in Observe also that in contrast to the corresponding header in
[RFC2822], the syntax does not allow comments within the Message-ID [RFC2822]:
header, it ensures that no string of characters is quoted unless
strictly necessary (it must contain at least one mqspecial) and no o the syntax does not allow comments within the Message-ID header,
single character is prefixed by a "\" in the form of a quoted-pair
unless strictly necessary, and moreover there is no possibility for o it ensures that no string of characters is quoted if it was
">" or WSP to occur inside a msg-id-core, whether quoted or not. already a <dot-atom-text> (it MUST start or end with a ".", or
contain at least one <mqspecial>),
o it ensures that no single character is prefixed by a "\" in the
form of a <quoted-pair> unless strictly necessary,
o it excludes all control characters,
o there is no possibility for ">" or WSP to occur inside a <msg-id>,
whether quoted or not, and
o even though commonly derived from <domain>s, <id-rights>s are
case-sensitive (and thus, once created, are not to be altered
during subsequent transmission or copying)
This is to simplify processing by relaying and serving agents and to This is to simplify processing by relaying and serving agents and to
ensure interoperability with existing implementations. Thus, whereas ensure interoperability with existing implementations and compliance
under [RFC2822] the following <msg-id-core>s would be considered with [NNTP]. Thus, whereas under [RFC2822] the following <msg-id>s
semantically equivalent, would be considered semantically equivalent,
<abcd@example.com> <abcd@example.com>
<"abcd"@example.com> <"abcd"@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-core>s. determine the identity of two <msg-id>s.
Also note that this updated ABNF applies wherever <msg-id-core> is Also note that this updated ABNF applies wherever <msg-id> is used,
used, including the References header discussed in Section 3.2.1 and including the References header discussed in Section 3.2.2 and the
the Supersedes header discussed in Section 3.2.5. Supersedes header discussed in Section 3.2.6.
NOTE: It is RECOMMENDED in [RFC2822] that, for ensuring global
uniqueness, the <id-right> be some domain identifier within whose
scope the uniqueness of the <id-left> can be guaranteed. When
following this recommendation, any <dot-atom-text> or <no-fold-
literal> used for the <id-right> are to be interpreted as
<domain>s as described in Section 3.4.1 of [RFC2822].
3.1.4 Subject 3.1.4 Subject
The Subject header is the same as that specified in Section 3.6.5 of The Subject header is the same as that specified in Section 3.6.5 of
[RFC2822] with the added restrictions detailed in Section 2.2. [RFC2822] with the added restrictions detailed in Section 2.2.
Further discussion of the content of the Subject header appears in Further discussion of the content of the Subject header appears in
[USEPRO] and [USEAGE]. [USEPRO] and [USEAGE].
subject = "Subject:" SP unstructured CRLF subject = "Subject:" SP unstructured CRLF
skipping to change at page 15, line 30 skipping to change at page 17, line 8
injection into the Netnews system. Each agent that processes an injection into the Netnews system. Each agent that processes an
article is required to prepend one (or more) identities to this article is required to prepend one (or more) identities to this
header. This is primarily to enable relaying agents to avoid sending header. This is primarily to enable relaying agents to avoid sending
articles to sites already known to have them, in particular the site articles to sites already known to have them, in particular the site
they came from, and additionally to permit tracing the route articles they came from, and additionally to permit tracing the route articles
take in moving over the network, and for gathering Usenet statistics. take in moving over the network, and for gathering Usenet statistics.
path = "Path:" SP path-list CRLF path = "Path:" SP path-list CRLF
path-list = [FWS] path-list = [FWS]
*( path-identity [FWS] path-delimiter [FWS] ) *( ( path-identity / path-keyword ) [FWS]
path-delimiter [FWS] )
tail-entry [FWS] tail-entry [FWS]
path-identity = ( ALPHA / DIGIT ) path-identity = ( ALPHA / DIGIT )
*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
tail-entry = path-identity path-keyword = "POSTED" / "MISMATCH"
path-delimiter = "!" ; possible other delimiters TBD
The specific format and use of <path-identity> and <tail-entry> are
discussed in [USEPRO].
3.1.7 Injection-Date tail-entry = path-identity
The Injection-Date header contains the date and time that the article path-delimiter = "!" / "!!"
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 relaying or serving
agent.
injection-date = "Injection-Date:" SP date-time CRLF Each <path-identity> in the <path-list> (excluding the one in the
See the remarks under Section 3.1.2 regarding the syntax of date- <tail-entry>) indicates, from right to left, the successive agents
time and the requirements and recommendations to which it is subject. through which the article has passed. The <keyword> "POSTED"
indicates that the agent to its left injected the article. The use
of the <path-delimiter> "!!" indicates that the agent to its left
claims that the agent to its right was the verified source of the
article (whereas the <path-delimiter> "!" implies no such claim).
The <keyword> "MISMATCH" indicates that the agent to its right failed
to be so verified. The full procedure for constructing a Path header
as well as the specific format and use of <path-identity> and <tail-
entry> are discussed in [USEPRO].
NOTE: The date-time in this header would normally be expected to NOTE: Historically, the <tail-entry> indicated the name of the
be later than the date-time in the Date header, but differences sender. If not used for this purpose, the string "not-for-mail"
between the clocks on the various agents and other special is often used instead (since at one time the whole path could be
circumstances might vitiate that; no provision is made for any used as a mail address for the sender).
such discrepancy to be corrected - better that the injecting agent
should just insert the correct time as it sees it.
This header is intended to replace the currently-used but NOTE: Although case-insensitive, it is intended that the <path-
undocumented "NNTP-Posting-Date" header, whose use is now deprecated. keyword>s "POSTED" and "MISMATCH" should be in upper case, to
distinguish them from the <path-identity>s which are traditionally
in lower case.
3.2 Optional Headers 3.2 Optional Headers
None of the headers appearing in this section is required to appear None of the headers appearing in this section is required to appear
in every article but some of them are required in certain types of in every article but some of them may be required in certain types of
article, such as followups. Further discussion of these requirements articles. Further discussion of these requirements appears in
appears in [USEPRO] and [USEAGE]. [USEPRO] and [USEAGE].
The headers Reply-To, Sender, Comments, and Keywords are used in news The headers Reply-To, Sender, Comments, and Keywords are used in news
articles in the same circumstances and with the same meaning as that articles in the same circumstances and with the same meaning as that
specified in [RFC2822] with the added restrictions detailed in specified in [RFC2822] with the added restrictions detailed in
Section 2.2. Multiple occurances of the Keywords header are not Section 2.2. Multiple occurances of the Keywords header are not
permitted. permitted.
sender = "Sender:" SP mailbox CRLF sender = "Sender:" SP mailbox CRLF
reply-to = "Reply-To:" SP address-list CRLF reply-to = "Reply-To:" SP address-list CRLF
skipping to change at page 16, line 46 skipping to change at page 18, line 25
keywords = "Keywords:" SP phrase *("," phrase) CRLF keywords = "Keywords:" SP phrase *("," phrase) CRLF
The MIME headers MIME-Version, Content-Type, Content-Transfer- The MIME headers MIME-Version, Content-Type, Content-Transfer-
Encoding, Content-Disposition, and Content-Language are used in news Encoding, Content-Disposition, and Content-Language are used in news
articles in the same circumstances and with the same meanings as articles in the same circumstances and with the same meanings as
those specified in [RFC2045], [RFC2183], and [RFC3282] with the added those specified in [RFC2045], [RFC2183], and [RFC3282] with the added
restrictions detailed in Section 2.2. restrictions detailed in Section 2.2.
All remaining news headers are described below. All remaining news headers are described below.
3.2.1 References 3.2.1 Injection-Date
The Injection-Date header 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 relaying or serving
agent.
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: The date-time in this header would normally be expected to
be later than the date-time in the Date header, but differences
between the clocks on the various agents and other special
circumstances might vitiate that; no provision is made for any
such discrepancy to be corrected - better that the injecting agent
should just insert the correct time as it sees it.
This header is intended to replace the currently-used but
undocumented "NNTP-Posting-Date" header, whose use is now deprecated.
3.2.2 References
The References header is the same as that specified in Section 3.6.4 The References header is the same as that specified in Section 3.6.4
of [RFC2822] with the added restrictions detailed in Section 2.2 and of [RFC2822] with the added restrictions detailed in Section 2.2 and
those listed below: those listed below:
o The updated <msg-id-core> construct defined in Section 3.1.3 MUST o The updated <msg-id> construct defined in Section 3.1.3 MUST be
be used. used.
o Message identifiers MUST be separated with CFWS. o Message identifiers MUST be separated with CFWS.
o Comments in CFWS between message identifiers can cause o Comments in CFWS between message identifiers can cause
interoperability problems, so comments SHOULD NOT be generated, interoperability problems, so comments SHOULD NOT be generated,
but MUST be accepted. but MUST be accepted.
references = "References:" SP 1*( [CFWS] msg-id-core) [CFWS] references = "References:" SP [CFWS] msg-id *(CFWS msg-id)
CRLF [CFWS] CRLF
3.2.2 Followup-To 3.2.3 Followup-To
The Followup-To header specifies to which newsgroup(s) followups The Followup-To header specifies to which newsgroup(s) followups
should be posted. The Followup-To header SHOULD NOT appear in a should be posted. The Followup-To header SHOULD NOT appear in a
message, unless its content is different from the content of the message, unless its content is different from the content of the
Newsgroups header. Newsgroups header.
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) followup-to = "Followup-To:" SP ( newsgroup-list / poster-text )
CRLF CRLF
poster-text = [FWS] %d112.111.115.116.101.114 [FWS] poster-text = [FWS] %d112.111.115.116.101.114 [FWS]
; "poster" in lower-case ; "poster" in lower-case
The syntax is the same as that of the Newsgroups header The syntax is the same as that of the Newsgroups header
(Section 3.1.5, with the exception that the keyword "poster" (which (Section 3.1.5, with the exception that the keyword "poster" (which
is always lowercase) requests that followups should be mailed to the is always lowercase) requests that followups should be mailed to the
article's reply address rather than posted. Although the keyword article's reply address rather than posted. Although the keyword
"poster" is case-sensitive, followup agents MAY choose to recognize "poster" is case-sensitive, followup agents MAY choose to recognize
case-insensitive forms such as "Poster". case-insensitive forms such as "Poster".
3.2.3 Expires 3.2.4 Expires
The Expires header specifies a date and time when the article is The Expires header specifies a date and time when the article is
deemed to be no longer relevant and could usefully be removed deemed to be no longer relevant and could usefully be removed
("expired"). ("expired").
expires = "Expires:" SP date-time CRLF expires = "Expires:" SP date-time CRLF
See the remarks under Section 3.1.2 regarding the syntax of date- See the remarks under Section 3.1.2 regarding the syntax of date-
time and the requirements and recommendations to which it is subject. time and the requirements and recommendations to which it is subject.
3.2.4 Control 3.2.5 Control
The Control header marks the article as a control message, and The Control header marks the article as a control message, and
specifies the desired actions (additional to the usual ones of specifies the desired actions (additional to the usual ones of
storing and/or relaying the article). storing and/or relaying the article).
control = "Control:" SP [FWS] control-message [FWS] CRLF control = "Control:" SP [FWS] control-command [FWS] CRLF
control-message = verb *( [FWS] argument ) control-command = verb *( [FWS] argument )
verb = token verb = token
argument = value argument = value
The verb indicates what action should be taken, and the argument(s) The verb indicates what action should be taken, and the argument(s)
(if any) supply details. In some cases, the body of the article may (if any) supply details. In some cases, the body of the article may
also contain details. The legal verbs and respective arguments are also contain details. The legal verbs and respective arguments are
discussed in the companion document, [USEPRO]. discussed in the companion document, [USEPRO].
An article with a Control header MUST NOT also have a Supersedes An article with a Control header MUST NOT also have a Supersedes
header. header.
3.2.5 Supersedes 3.2.6 Supersedes
The Supersedes header contains a message identifier specifying an The Supersedes header contains a message identifier specifying an
article to be superseded upon the arrival of this one. An article article to be superseded upon the arrival of this one. An article
containing a Supersedes header is equivalent to a "cancel" [USEPRO] containing a Supersedes header is equivalent to a "cancel" [USEPRO]
control message for the specified article, followed immediately by control message for the specified article, followed immediately by
the new article without the Supersedes header. the new article without the Supersedes header.
supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF supersedes = "Supersedes:" SP [FWS] msg-id [FWS] CRLF
NOTE: There is no "c" in Supersedes. NOTE: There is no "c" in Supersedes.
NOTE: The Supersedes header defined here has no connection with the NOTE: The Supersedes header defined here has no connection with the
Supersedes header that sometimes appears in Email messages converted Supersedes header that sometimes appears in Email messages converted
from X.400 according to [RFC2156]; in particular, the syntax here from X.400 according to [RFC2156]; in particular, the syntax here
permits only one <msg-id-core> in contrast to the multiple <msg-id- permits only one <msg-id> in contrast to the multiple <msg-id>s in
core>s in that Email version. that Email version.
3.2.6 Distribution 3.2.7 Distribution
The Distribution header specifies geographic or organizational limits The Distribution header specifies geographic or organizational limits
on an article's propagation. on an article's propagation.
distribution = "Distribution:" SP distribution-list CRLF distribution = "Distribution:" SP dist-list CRLF
dist-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS] dist-list = [FWS] dist-name
*( [FWS] "," [FWS] dist-name ) [FWS]
dist-name = ALPHA / DIGIT dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" ) *( ALPHA / DIGIT / "+" / "-" / "_" )
The <dist-name>s "world" and "local" are predefined. However, The <dist-name>s "world" and "local" are predefined. However,
"world" SHOULD NOT be used explicitly, since it is the default when "world" SHOULD NOT be used explicitly, since it is the default when
the Distribution header is absent entirely. the Distribution header is absent entirely.
"All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain "All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain
at least three characters, except when they are two-letter country at least three characters, except when they are two-letter country
names as in [ISO.3166.1988]. <dist-name>s are case-insensitive (i.e. names as in [ISO.3166.1988]. <dist-name>s are case-insensitive (i.e.
"US", "Us", "uS", and "us" all specify the same distribution). "US", "Us", "uS", and "us" all specify the same distribution).
3.2.7 Summary 3.2.8 Summary
The Summary header is a short phrase summarizing the article's The Summary header is a short phrase summarizing the article's
content. content.
summary = "Summary:" SP unstructured CRLF summary = "Summary:" SP unstructured CRLF
3.2.8 Approved 3.2.9 Approved
The Approved header indicates the mailing addresses (and possibly the The Approved header indicates the mailing addresses (and possibly the
full names) of the persons or entities approving the article for full names) of the persons or entities approving the article for
posting. posting.
approved = "Approved:" SP mailbox-list CRLF approved = "Approved:" SP mailbox-list CRLF
Each mailbox contained in the Approved header MUST be that of one of Each mailbox contained in the Approved header MUST be that of one of
the person(s) or entity(ies) in question, and one of those mailboxes the person(s) or entity(ies) in question, and one of those mailboxes
MUST be that of the actual injector of the article. Note that this MUST be that of the actual sender of the article. Note that this
standard doesn't provide any means to enforce or verify this standard does not provide any means to enforce or verify this
requirement, but future extensions or standards may provide such a requirement, but future extensions or standards may provide such a
facility (e.g. digitial signatures). facility (e.g. digitial signatures).
3.2.9 Organization 3.2.10 Organization
The Organization header is a short phrase identifying the poster's The Organization header is a short phrase identifying the poster's
organization. organization.
organization = "Organization:" SP unstructured CRLF organization = "Organization:" SP unstructured CRLF
There is no "s" in Organization. There is no "s" in Organization.
3.2.10 Xref 3.2.11 Xref
The Xref header indicates where an article was filed by the last The Xref header indicates where an article was filed by the last
serving agent to process it. The article locations are used to keep serving agent to process it. The article locations are used to keep
track of crossposted articles so that reading agents serviced by a track of crossposted articles so that reading agents serviced by a
particular serving agent can mark such articles as read. particular serving agent can mark such articles as read.
xref = "Xref:" SP [CFWS] server-name xref = "Xref:" SP [FWS] server-name
1*( CFWS location ) [CFWS] CRLF 1*( FWS location ) [FWS] CRLF
server-name = path-identity server-name = path-identity
location = newsgroup-name ":" article-locator location = newsgroup-name ":" article-locator
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters ; US-ASCII printable characters
; except '(' and ';' ; except '(' and ';'
The <server-name> is included so that software can determine which The <server-name> is included so that software can determine which
serving agent generated the header. The locations specify what serving agent generated the header. The locations specify what
newsgroups the article was filed under (which may differ from those newsgroups the article was filed under (which may differ from those
in the Newsgroups header) and where it was filed under them. The in the Newsgroups header) and where it was filed under them. The
exact form of an article-locator is implementation-specific. exact form of an article-locator is implementation-specific.
NOTE: The traditional form of an article-locator (as required by NOTE: The traditional form of an article-locator (as required by
[NNTP]) is a decimal number, with articles in each newsgroup [NNTP]) is a decimal number, with articles in each newsgroup
numbered consecutively starting from 1. numbered consecutively starting from 1.
3.2.11 Archive 3.2.12 Archive
The Archive header provides an indication of the poster's intent The Archive header provides an indication of the poster's intent
regarding preservation of the article in publicly accessible long- regarding preservation of the article in publicly accessible long-
term or permanent storage. term or permanent storage.
archive = "Archive:" SP [CFWS] ("no" / "yes") archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" archive-param ) CRLF *( [CFWS] ";" archive-param ) CRLF
archive-param = parameter archive-param = parameter
The presence of an "Archive: no" header in an article indicates that The presence of an "Archive: no" header in an article indicates that
the poster does not permit redistribution from publicly accessible the poster does not permit redistribution from publicly accessible
long-term or permanent archives. The absence of this header, or an long-term or permanent archives. The absence of this header, or an
explicit "Archive: yes", indicates that the poster is willing for explicit "Archive: yes", indicates that the poster is willing for
such redistribution to take place. Further extensions to this such redistribution to take place. Further extensions to this
standard may provide parameters for administration of the archiving standard may provide parameters for administration of the archiving
process. process.
3.2.12 User-Agent 3.2.13 User-Agent
The User-Agent header contains information about the user agent The User-Agent header contains information about the user agent
(typically a newsreader) generating the article, for statistical (typically a newsreader) generating the article, for statistical
purposes and tracing of standards violations to specific software purposes and tracing of standards violations to specific software
needing correction. It is intended that this header be suitable for needing correction. It is intended that this header be suitable for
use in Email. use in Email.
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ] product = [CFWS] token [ [CFWS] "/" product-version ]
skipping to change at page 21, line 28 skipping to change at page 23, line 36
Agent, X-Http-User-Agent, and other headers previously used on Agent, X-Http-User-Agent, and other headers previously used on
Usenet and in Email for this purpose. Use of these experimental Usenet and in Email for this purpose. Use of these experimental
headers SHOULD be discontinued in favor of the single, standard headers SHOULD be discontinued in favor of the single, standard
User-Agent header. User-Agent header.
NOTE: [RFC2616] describes a similar facility for the HTTP NOTE: [RFC2616] describes a similar facility for the HTTP
protocol. This specification differs in that "{" and "}" are protocol. This specification differs in that "{" and "}" are
allowed in tokens (<product> and <product-version>) and comments allowed in tokens (<product> and <product-version>) and comments
are permitted wherever whitespace is allowed. are permitted wherever whitespace is allowed.
3.2.13 Injection-Info 3.2.14 Injection-Info
The Injection-Info header provides information as to how an article The Injection-Info header provides information as to how an article
entered the Netnews system and to assist in tracing its true origin. entered the Netnews system and to assist in tracing its true origin.
It can also specify one or more addresses where complaints concerning It can also specify one or more addresses where complaints concerning
the poster of the article may be sent. the poster of the article may be sent.
injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] injection-info = "Injection-Info:" SP [CFWS] path-identity
*( ";" inj-info-para ) CRLF *( [CFWS] ";" [CFWS] inj-info-param )
[CFWS] CRLF
inj-info-param = post-host-param / inj-info-param = post-host-param /
post-account-param / post-acct-param /
sender-param / sender-param /
logging-param / logging-param /
complainto-param complainto-param /
ext-param
[[Each parameter is allowed only once?]] ;; At most one of "post-host-param",
;; "post-acct-param", "sender-param",
;; "logging-param" or "complainto-param"
;; is allowed.
ext-param = parameter
[[Should also allow for x-attributes?]] [[Should also allow for x-attributes?]]
post-host-param = "posting-host" "=" host-value post-host-param = "posting-host" "=" host-value
host-value = dot-atom / [ dot-atom ":" ] host-value = dot-atom / [ dot-atom ":" ]
( IPv4address / IPv6address ) ; see [RFC 2373] ( IPv4address / IPv6address ) ; see [RFC 2373]
post-acct-param = "posting-account" "=" value post-acct-param = "posting-account" "=" value
sender-param = "sender" "=" sender-value sender-param = "sender" "=" sender-value
sender-value = mailbox / "verified" sender-value = mailbox / "verified"
logging-param = "logging-data" "=" value logging-param = "logging-data" "=" value
complainto-param= "complaints-to" "=" address-list complainto-param= "mail-complaints-to" "=" address-list
Although comments and folding of white space are permitted throughout Although comments and folding of white space are permitted throughout
the Injection-Info header, it is RECOMMENDED that folding is not used the Injection-Info header, it is RECOMMENDED that folding is not used
within any parameter (but only before or after the ";" separating within any parameter (but only before or after the ";" separating
those parameters), and that comments are only used following the last those parameters), and that comments are only used following the last
parameter. parameter.
This header is intended to replace various currently-used but This header is intended to replace various currently-used but
undocumented headers such as "NNTP-Posting-Host", "X-Trace" and undocumented headers such as "NNTP-Posting-Host", "X-Trace" and
"X-Complaints-To". These headers are thus deprecated. "X-Complaints-To". These headers are thus deprecated.
skipping to change at page 23, line 24 skipping to change at page 25, line 29
correct). If an injecting agent can verify sender of an article, it correct). If an injecting agent can verify sender of an article, it
SHOULD use this parameter in favour of the "posting-account" SHOULD use this parameter in favour of the "posting-account"
parameter. parameter.
The "logging-data" parameter contains information (typically a The "logging-data" parameter contains information (typically a
session number or other non-persistent means of identifying a posting session number or other non-persistent means of identifying a posting
account) which will enable the true origin of the article to be account) which will enable the true origin of the article to be
determined by reference to logging information kept by the injecting determined by reference to logging information kept by the injecting
agent. agent.
The "complaints-to" parameter specifies mailbox(es) for sending The "mail-complaints-to" parameter specifies mailbox(es) for sending
complaints concerning the behaviour of the poster of the article. complaints concerning the behaviour of the poster of the article.
3.3 Obsolete Headers 3.3 Obsolete Headers
Early versions of news software following the modern format sometimes Early versions of news software following the modern format sometimes
generated headers like the following: generated headers like the following:
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Date-Received: Friday, 19-Nov-82 16:59:30 EST Date-Received: Friday, 19-Nov-82 16:59:30 EST
skipping to change at page 24, line 11 skipping to change at page 26, line 16
Also-Control indicated a control message that was also intended to be Also-Control indicated a control message that was also intended to be
filed as a normal article. See-Also listed related articles, but filed as a normal article. See-Also listed related articles, but
without the specific relationship with followups that pertains to the without the specific relationship with followups that pertains to the
References-header. Article-Names indicated some special significance References-header. Article-Names indicated some special significance
of that article in relation to the indicated newsgroup. Article- of that article in relation to the indicated newsgroup. Article-
Updates indicated that an earlier article was updated, without at the Updates indicated that an earlier article was updated, without at the
same time being superseded. same time being superseded.
The headers listed above are documented for historical purposes only. The headers listed above are documented for historical purposes only.
Articles containing these headers MUST NOT be generated. Persons Articles containing these headers MUST NOT be generated. Persons
writing new agents SHOULD ignore any former meanings these headers. writing new agents SHOULD ignore any former meanings of these
headers.
3.3.1 Lines 3.3.1 Lines
The Lines header indicates the number of lines in the body of the The Lines header indicates the number of lines in the body of the
article. article.
lines = "Lines" ":" SP [CFWS] 1*DIGIT [CFWS] CRLF lines = "Lines" ":" SP [FWS] 1*DIGIT [FWS] CRLF
The line count includes all body lines, including the signature if The line count includes all body lines, including the signature if
any, including empty lines (if any) at the beginning or end of the any, including empty lines (if any) at the beginning or end of the
body, and including the whole of all MIME message and multipart parts body, and including the whole of all MIME message and multipart parts
contained in the body (the single empty separator line between the contained in the body (the single empty separator line between the
headers and the body is not part of the body). The "body" here is headers 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 posting the body as found in the posted article as transmitted by the posting
agent. agent.
Historically, this header was used by the [NNTP] overview extension, Historically, this header was used by the [NNTP] overview extension,
but its use for this purpose is now deprecated. As a result, this but its use for this purpose is now deprecated. As a result, this
header is to be regarded as obsolete, and it will likely be removed header is to be regarded as obsolescent, and it is likely to be
entirely in a future version of this standard. removed entirely in a future version of this standard. Servers and
clients SHOULD ignore it, and SHOULD NOT generate it.
4. Internationalization Considerations 4. Internationalization Considerations
Internationalization of news article headers and bodies is provided Internationalization of news article headers and bodies is provided
using MIME mechanisms discussed in Section 2.3. Note that the using MIME mechanisms discussed in Section 2.3. Note that the
generation of internationalized newsgroup names for use in headers is generation of internationalized newsgroup names for use in headers is
not addressed in this document. not addressed in this document.
5. Security Considerations 5. Security Considerations
The news article format specified in this document does not provide The news article format specified in this document does not provide
any security services, such as confidentiality, authentication of any security services, such as confidentiality, authentication of
sender, or non-repudiation. Instead, such services need to be sender, or non-repudiation. Instead, such services need to be
layered above, using such protocols as S/MIME [RFC2633] or PGP/MIME layered above, using such protocols as S/MIME [RFC2633] or PGP/MIME
[RFC3156], or below, using secure versions of news transport [RFC3156], or below, using secure versions of news transport
protocols. Additionally, several currently non-standardized protocols. Additionally, several currently non-standardized
protocols [PGPVERIFY] will hopefully be standardized in the near protocols [PGPVERIFY] will hopefully be standardized in the near
future. future.
Message-IDs (Section 3.1.3) in news are required to be unique; Message identifiers (Section 3.1.3) in news are required to be
articles are refused (in server-to-server transfer) if the ID has unique; articles are refused (in server-to-server transfer) if the
already been seen. So if you can predict the ID of a message, you identifier has already been seen. So if you can predict the
can preempt it by posting a message (possibly to a quite different identifier of a message, you can preempt it by posting a message
group) with the same ID, stopping your target message from (possibly to a quite different group) with the same message
propagating. Agents that generate message-ids for news articles identifier, stopping your target message from propagating. Agents
SHOULD ensure that they are unpredictable. that generate message identifiers for news articles SHOULD ensure
that they are unpredictable.
6. References 6. References
6.1 Normative References 6.1 Normative References
[Errata] "RFC Editor Errata". [Errata] "RFC Editor Errata".
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
skipping to change at page 29, line 9 skipping to change at page 31, line 9
Orchard Park, NY 14127 Orchard Park, NY 14127
US US
Phone: +1 716 662 8973 Phone: +1 716 662 8973
Email: ken@oceana.com Email: ken@oceana.com
Charles H. Lindsey Charles H. Lindsey
University of Manchester University of Manchester
5 Clerewood Avenue 5 Clerewood Avenue
Heald Green Heald Green
Cheadle Cheadle
Chesire SK8 3JU Cheshire SK8 3JU
GB GB
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clw.cs.man.ac.uk Email: chl@clw.cs.man.ac.uk
Dan Kohn Dan Kohn
Skymoon Ventures Skymoon Ventures
3045 Park Boulevard 3045 Park Boulevard
Palo Alto, CA 94306 Palo Alto, CA 94306
US US
 End of changes. 

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