draft-ietf-usefor-usefor-01.txt   draft-ietf-usefor-usefor-02.txt 
Usenet Format Working Group C. Lindsey Usenet Format Working Group K. Murchison, Ed.
Internet-Draft University of Manchester Internet-Draft Oceana Matrix Ltd.
Obsoletes: 1036 (if approved) K. Murchison Obsoletes: 1036 (if approved) C. Lindsey
Expires: March 15, 2005 Oceana Matrix Ltd. Expires: May 24, 2005 University of Manchester
D. Kohn D. Kohn
Skymoon Ventures Skymoon Ventures
September 14, 2004 November 23, 2004
News Article Format News Article Format
draft-ietf-usefor-usefor-01.txt draft-ietf-usefor-usefor-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 15, 2005. This Internet-Draft will expire on May 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document specifies the syntax of network news articles in the This document specifies the syntax of network news (Netnews) articles
context of the "Internet Message Format" (RFC 2822) and "Multipurpose in the context of the "Internet Message Format" (RFC 2822) and
Internet Mail Extensions (MIME)" (RFC 2045). This document "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This
supersedes RFC 1036, updating it to reflect current practice and document supersedes RFC 1036, updating it to reflect current practice
incorporating incremental changes specified in other documents. and incorporating incremental changes specified in other documents.
Changes since draft-ietf-usefor-usefor-00 Changes since draft-ietf-usefor-usefor-01
o Rewrote/reorganized Abstract and Introduction. o Removed half-hearted discussion of internal format and 8-bit clean
transport.
o Added definitions of "proto-article", "posting agent", "followup",
"followup-agent", "user-agent", and "injecting agent".
o Removed discussion of message/partial MIME messages.
o Noted that the header contents in every line MUST NOT be empty.
o Merged MIME sections.
o Only allow "UT and "GMT" in Date header; disallow all other
<obs-zone>.
o Used Charles' ABNF for <msg-id> and <unstructured>.
o Removed restrictions on length and start character for Newsgroups.
o More verbose description of Path header.
o Disallowed comments in Control header.
o Specified that <control-message> is a verb optionally followed by
whitespace-separated arguments.
o Noted that Supersedes header is different from [Son-of-1036].
o More exact ABNF for Archive and Injection-Info parameters.
o Discussed meaning of "yes", "no", and "filename" in Archive
header.
o Added "Obsolete Headers" section.
o Miscellaneous editorial changes
Changes since draft-kohn-news-article-03
o Document is now a work product of USEFOR
o Added new co-authors
o Added some definitions from draft-ietf-usefor-article-13
o Removed discussion of message/partial MIME messages.
o Removed text that belongs in [USEPRO]
o Reorganized header sections
o Added Archive, User-Agent, Injection-Date, and Injection-Info
headers.
o Used Charles' ABNF for <msg-id> and <unstructured>.
o Removed restrictions on length and start character for Newsgroups.
o Added required SP to ABNF of header definitions. o Added required SP to ABNF of header definitions.
o Reorganized header sections. o Disallowed comments in Control header.
o Compatibility changes based on comments from Charles. o Xref header allows for non-digit "locations".
o Added Injection-Date and Injection-Info headers. o Only allow for a single message-id in Supersedes header.
o Changes to the References 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 and Complaints-To headers o The Mail-Copies-To, Posted-And-Mailed and Complaints-To headers
have been moved to other documents. have been moved to 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.
Issues to be addressed Issues to be addressed
o Decide which definitions should go in this document and in o Decide which definitions should go in this document and in
[USEPRO]. [USEPRO].
o Decide how much (if any) discussion of Injection-Info content o Decide how much (if any) discussion of Injection-Info content
belongs in this document vs. [USEPRO]. belongs in this document vs. [USEPRO].
o Do we want to discuss message/partial? o Do we want to discuss message/partial?
o Add appendixes for obsolete headers, changes from RFC 1036 and o Add appendixes for changes from RFC 1036 and differences from RFC
differences from RFC 2822. 2822.
o IANA considerations (the Klyne message header registry is now
official as RFC 3864).
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Structure of This Document . . . . . . . . . . . . . . . . 5 1.6 Structure of This Document . . . . . . . . . . . . . . . . 7
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Header Fields . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 8 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 9
2.4 Additional MIME Support . . . . . . . . . . . . . . . . . 8 3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 10
3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 10
3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 9 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Subject . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 Date . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4 Message-ID . . . . . . . . . . . . . . . . . . . . . . 10 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 13
3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 11 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 14
3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 12 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 15
3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 13 3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 17
3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 14 3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 17
3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 14 3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 18
3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 15 3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 19
3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 15 3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 19
3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 16 3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 20
3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 16 3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 21
4. Internationalization Considerations . . . . . . . . . . . . 18 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . 19 4. Internationalization Considerations . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . 24
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Informative References . . . . . . . . . . . . . . . . . . . 20 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 6.2 Informative References . . . . . . . . . . . . . . . . . . . 25
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . 24 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 29
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 resemble email messages) and for retrieving news "articles" (which are a subset of Email messages) and
exchanging them amongst a readership which is potentially widely for exchanging them amongst a readership which is potentially widely
distributed. It is organized around "newsgroups", with the distributed. It is organized around "newsgroups", with the
expectation that each reader will be able to see all articles posted expectation that each reader will be able to see all articles posted
to each newsgroup in which he participates. These protocols most to each newsgroup in which he participates. These protocols most
commonly use a flooding algorithm which propagates copies throughout commonly use a flooding algorithm which propagates copies throughout
a network of participating servers. Typically, only one copy is a network of participating servers. Typically, only one copy is
stored per server, and each server makes it available on demand to stored per server, and each server makes it available on demand to
readers able to access that server. readers able to access that server.
1.2 Scope 1.2 Scope
This document specifies the syntax of network news articles in the This document specifies the syntax of network news (Netnews) articles
context of the "Internet Message Format" [RFC2822] and "Multipurpose in the context of the "Internet Message Format" [RFC2822] and
Internet Mail Extensions (MIME)" [RFC2045]. This document supersedes "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This
[RFC1036], updating it to reflect current practice and incorporating document supersedes [RFC1036], updating it to reflect current
incremental changes specified in other documents such as practice and incorporating changes and clarifications specified in
[Son-of-1036]. other documents such as [Son-of-1036].
This is the first in a set of documents that obsolete [RFC1036]. This is the first in a set of documents that obsolete [RFC1036].
This document focuses on the syntax and semantics of network news This document focuses on the syntax and semantics of Netnews
articles. [USEPRO] is also a standards-track document, and describes articles. [USEPRO] is also a standards-track document, and describes
the protocol issues of network news articles, independent of the protocol issues of network news articles, independent of
transmission protocols such as NNTP [RFC0977]. An informational transport protocols such as [NNTP]. An best common practice
document, [USEAGE], describes implementation recommendations to document, [USEAGE], describes implementation recommendations to
improve interoperability and usability. improve interoperability and usability.
This specification is intended as a definition of what article This specification is intended as a definition of what article
content format is to be passed between systems. Though some news content format is to be passed between systems. Though some news
systems locally store articles in this format (which eliminates the systems locally store articles in this format (which eliminates the
need for translation between formats) and others use formats that need for translation between formats) and others use formats that
differ from the one specified in this standard, local storage is differ from the one specified in this standard, local storage is
outside of the scope of this standard. outside of the scope of this standard.
Note: This standard is not intended to dictate the internal formats
used by sites, the specific news system features that they are
expected to support, or any of the characteristics of user interface
programs that create or read articles. In addition, this standard
does not specify an encoding of the characters for either transport
or storage; that is, it does not specify the number of bits used or
how those bits are specifically transferred over the wire or stored
on disk.
1.3 Requirements Notation 1.3 Requirements Notation
This document occasionally uses terms that appear in capital letters. This document uses terms that appear in capital letters. The key
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
document are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
1.4 Syntax Notation 1.4 Syntax Notation
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]. Section 3.1.4 [RFC2234] and many constructs defined in [RFC2822] and [RFC2045].
updates the [RFC2822] definition of <msg-id>. Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of
<zone> and <msg-id> respectively.
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". "message". A "proto-article" is one that has not yet been injected
into the news system.
A "message identifier" Section 3.1.4 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
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 headers. regardless of any differences in the body or headers.
A "newsgroup" is a single news forum, a logical bulletin board, A "newsgroup" is a single news forum, a logical bulletin board,
having a name and nominally intended for articles on a specific having a name and nominally intended for articles on a specific
topic. An article is "posted to" a single newsgroup or several topic. An article is "posted to" a single newsgroup or several
newsgroups. When an article is posted to more than one newsgroup, it newsgroups. When an article is posted to more than one newsgroup, it
is said to be "crossposted"; note that this differs from posting the is said to be "crossposted"; note that this differs from posting the
same text as part of each of several articles, one per newsgroup. same text as part of each of several articles, one per newsgroup.
A newsgroup may be "moderated", in which case submissions are not A newsgroup may be "moderated", in which case submissions are not
posted directly, but mailed to a "moderator" for consideration and posted directly, but mailed to a "moderator" for consideration and
possible posting. Moderators are typically human but may be possible posting. Moderators are typically human but may be
implemented partially or entirely in software. implemented partially or entirely in software.
A "poster" is the person or software that composes and submits a
possibly compliant article to a "posting agent". The poster is
analogous to [RFC2822]'s author.
A "posting agent" is the software that assists posters to prepare
proto-articles, in compliance with this standard. The proto-article
is then passed on to an "injecting agent" for final checking and
injection into the news stream. If the article is not compliant, or
is rejected by the injecting agent, then the posting agent informs
the poster with an explanation of the error.
A "reader" is the person or software reading news articles.
A "reading agent" is software which presents articles to a reader.
A "followup" is an article containing a response to the contents of
an earlier article (the followup's "precursor").
A "followup agent" is a combination of reading agent and posting
agent that aids in the preparation and posting of a followup.
Posting, reading and followup agents (which are usually just
different services provided by the same piece of software) are known
collectively as "user agents".
An "injecting agent" takes the finished article from the posting
agent (often via the [NNTP] "post" command) performs some final
checks and passes it on to a relaying agent for general distribution.
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 relaying or serving agent receiving such an control information; a relaying or serving agent receiving such an
article may (subject to the policies observed at that site) take article may (subject to the policies observed at that site) take
actions beyond just filing and passing on the article. actions beyond just filing and passing on the article.
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.
skipping to change at page 7, line 10 skipping to change at page 8, line 10
Section 2 defines the format of news articles. Section 3 details the Section 2 defines the format of news articles. Section 3 details the
headers necessary to make an article suitable for the netnews headers necessary to make an article suitable for the netnews
environment. environment.
2. Format 2. Format
2.1 Base 2.1 Base
News articles MUST conform to the syntax specified in Section 3 of News articles MUST conform to the syntax specified in Section 3 of
[RFC2822]. News agents MAY also accept the obsolete syntax specified [RFC2822]. Netnews agents MAY also accept the obsolete syntax
in Section 4 of [RFC2822], but they MUST NOT generate such syntax. specified in Section 4 of [RFC2822], but they MUST NOT generate such
syntax.
2.2 Header Fields This specification uses the terms "header", "header name", and
"header content" which are synonymous with the [RFC2822] terms
"header field", "field name", and "field body" respectively.
All headers fields in a news article are compliant with [RFC2822], 2.2 Headers
however this specification is more restrictive in what can be
generated and accepted by news agents. The syntax allowed for news All headers in a news article are compliant with [RFC2822], however
articles is a strict subset of the "Internet Message Format", making this specification is less permissive in what can be generated and
all messages compliant with this specification inherently compliant accepted by news agents. The syntax allowed for news articles is a
with [RFC2822]. Note however that the converse is not guaranteed to strict subset of the "Internet Message Format", making all messages
be true. compliant with this specification inherently compliant with
[RFC2822]. Note however that the converse is not guaranteed to be
true in all cases.
General rules which apply to all headers (even those documented in General rules which apply to all headers (even those documented in
[RFC2822] and [RFC2045]) are listed below and those that apply to [RFC2822] and [RFC2045]) are listed below and those that apply to
specific headers are described in the relevent sections of this specific headers are described in the relevent sections of this
document. document.
User agents MUST generate headers so that at least one space o All agents MUST generate headers so that at least one space
immediately follows the ':' separating the header name and the header immediately follows the ':' separating the header name and the
contents. As a result, an <unstructured> header as defined in header contents (for compatibility with deployed software). News
Section 3.2.6 of [RFC2822] MUST NOT be empty (it will always contain agents MAY accept headers which do not contain the required space.
at least a single space). News agents MAY accept headers which do o The header contents of every header line (including the first and
not contain the required space. any that are subsequently folded) MUST contain at least one
non-whitespace character.
NOTE: This means that no header content defined by or
referenced by this document can be empty. As a result, this
document updates the <unstructured> construct from Section
3.2.6 of [RFC2822] as follows:
Compliant software MUST support headers of at least 998 octets. This unstructured = 1*( [FWS] utext ) [FWS]
is the only limit on the length of a header line prescribed by this
standard. However, specific rules to the contrary may apply in
particular cases (for example, according to [RFC2047] header lines
containing encoded-words are limited to 76 octets).
NOTE: There is NO restriction on the number of lines into which a o Compliant software MUST NOT generate (but MAY accept) headers of
header may be split, and hence there is NO restriction on the more than 998 octets. This is the only limit on the length of a
header line prescribed by this standard. However, specific rules
to the contrary may apply in particular cases (for example,
according to [RFC2047] header lines containing encoded-words are
limited to 76 octets). [USEAGE] includes suggested limits for
convenience of display by user agents.
NOTE: There is NO restriction on the number of lines into which
a header may be split, and hence there is NO restriction on the
total length of a header (in particular it may, by suitable total length of a header (in particular it may, by suitable
folding, be made to exceed the 998 octets restriction pertaining folding, be made to exceed the 998 octets restriction
to a single header line). pertaining to a single header line).
o The character set for headers is US-ASCII. Where the use of
The character set for headers 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 MIME mechanisms defined in [RFC2045] and [RFC2231].
mechanisms defined in [RFC2045] and [RFC2231].
2.3 MIME Conformance 2.3 MIME Conformance
User agents MUST meet the definition of MIME-conformance in User agents MUST meet the definition of MIME-conformance in [RFC2049]
[RFC2049]. This level of MIME Conformance provides support for and MUST also support [RFC2231]. This level of MIME Conformance
internationalization and multimedia in message bodies [RFC2045], and provides support for internationalization and multimedia in message
support for internationalization of headers [RFC2047]. Note that bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
internationalization of headers ([RFC2047], [RFC2231]). Note that
[Errata] currently exist for [RFC2046] and [RFC2231]. [Errata] currently exist for [RFC2046] and [RFC2231].
2.4 Additional MIME Support For the purposes of Section 5 of [RFC2047], all headers defined in
Section 3 of this standard are to be considered as "extension message
User agents conformant with this document MAY support reassembly of header fields" (insofar as they are not already considered under the
message/partial MIME messages, as specified in Section 5.2.2 of existing Email standards), permitting the use of [RFC2047] encodings
[RFC2046] and MAY support generation of message/partial articles for within any <unstructured> header, or within any <comment> or <phrase>
excessively large articles. permittted within any structured header.
User agents SHOULD accept and MAY generate MIME extension header User agents MAY accept and generate other MIME extension headers, and
fields, including but not limited to Content-Disposition [RFC2183] in particular SHOULD accept Content-Disposition [RFC2183] and
and Content-Language [RFC3282]. Content-Language [RFC3282].
3. News Headers 3. News Headers
The following news headers (also known as header fields) extend the The following news headers extend those defined in section 3.6 of
fields defined in section 3.6 of [RFC2822] as follows: [RFC2822]:
fields =/ *( newsgroups / fields =/ *( newsgroups /
path / path /
injection-date / injection-date /
followup-to / followup-to /
expires / expires /
control / control /
supersedes / supersedes /
distribution / distribution /
summary / summary /
skipping to change at page 9, line 31 skipping to change at page 10, line 31
xref / xref /
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, Subject, Date, exactly one of each of the following headers: From, Date, Message-ID,
Message-ID, Newsgroups, Path, and Injection-Date. Subject, Newsgroups, Path, and Injection-Date.
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.
3.1.2 Subject from = "From:" SP mailbox-list CRLF
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.
Further discussion of the content of the Subject header is discussed
in [USEPRO] and [USEAGE].
3.1.3 Date 3.1.2 Date
The Date header is the same as that specified in Sections 3.3 and The Date header is the same as that specified in Sections 3.3 and
3.6.1 of [RFC2822] with the added restrictions detailed in Section 3.6.1 of [RFC2822] with the added restrictions detailed in Section
2.2. However, the use of "GMT" and "UT" as time zones, which are 2.2. However, the use of "UT" and "GMT" as time zones (part of
part of <obs-zone>, is widespread in news articles today. Therefore, <obs-zone>), although deprecated, is widespread in news articles
agents MUST accept, but MUST NOT generate, <date-time> constructs today. Therefore, agents MUST accept <date-time> constructs which
which include <obs-zone>. As stated in Section 2.1, support for include the updated <zone> construct below.
<obs-zone> would otherwise have been SHOULD accept, MUST NOT
generate. Note that these requirements apply wherever <date-time> is
used, including Injection-Date and Expires in Section 3.1.7 and
Section 3.2.3 respectively.
3.1.4 Message-ID orig-date = "Date:" SP date-time CRLF
zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
Note that agents SHOULD NOT generate <date-time> constructs which
include either "UT" or "GMT" and MUST NOT generate <date-time>
constructs which include any other zone names defined by <obs-zone>,
some of which have ambiguous interpretations and would have adverse
effects on Netnews protocols.
Also note that these requirements apply wherever <date-time> is used,
including Injection-Date and Expires in Section 3.1.7 and Section
3.2.3 respectively.
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 ABNF should be used are usable in widely deployed news software. The global uniqueness
as below, but the requirements and descriptive text from Section requirement for <msg-id> in [RFC2822] is to be understood as applying
3.6.4 of [RFC2822] still apply. across all protocols using such message identifiers, and across both
Email and Netnews in particular. The ABNF should be used as below,
but the requirements and descriptive text from Section 3.6.4 of
[RFC2822] still apply.
message-id = "Message-ID:" SP msg-id CRLF message-id = "Message-ID:" SP msg-id CRLF
msg-id = [FWS] msg-id-core [FWS] msg-id = [FWS] msg-id-core [FWS]
msg-id-core = "<" id-left "@" id-right ">" msg-id-core = "<" id-left "@" id-right ">"
; maximum length is 250 octets ; maximum length is 250 octets
id-left = dot-atom-text / no-fold-quote / obs-id-left id-left = dot-atom-text / no-fold-quote
id-right = dot-atom-text / no-fold-literal / obs-id-right id-right = dot-atom-text / no-fold-literal
no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE no-fold-quote = DQUOTE
*( mqtext / "\\" / "\" DQUOTE )
mqspecial
*( mqtext / "\\" / "\" DQUOTE )
DQUOTE
no-fold-literal = "[" *( htext / no-space-qp ) "]" mqtext = NO-WS-CTL / ; all of <text> except
%d33 / ; SP, HTAB, "\", ">"
%d35-61 / ; and DQUOTE
%d63-91 /
%d93-126
no-space-qp = ( "\" ptext ) / obs-qp mqspecial = "(" / ")" / ; same as specials except
"<" / ; "\" and DQUOTE quoted
"[" / "]" / ; and ">" omitted
":" / ";" /
"@" / "\\" /
"," / "." /
"\" DQUOTE
ptext = %d33-61 / ; Printable characters excluding ">" no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
%d63-126 /
obs-text
htext = HEXDIG / ; hexadecimal digits, case-insensitive mdtext = NO-WS-CTL / ; Non white space controls
"." / ; IPv4 separator %d33-61 / ; The rest of the US-ASCII
":" ; IPv6 separator %d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\"
The msg-id-core MUST NOT be more than 250 octets in length. The msg-id-core 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 [RFC0977]) can rely on a bounded length. Observe that (e.g. [NNTP]) can rely on a bounded length.
msg-id-core includes the < and >.
Observe that in contrast to the corresponding header in [RFC2822], Observe that msg-id-core includes the < and >.
the syntax does not allow comments within the Message-ID header; this
is to simplify processing by relaying and serving agents and to
ensure interoperability with existing implementations.
Also note that this updated ABNF applies wherever <msg-id> is used, Observe also that in contrast to the corresponding header in
including the References header discussed in Section 3.2.1. [RFC2822], the syntax does not allow comments within the Message-ID
header, it ensures that no string of characters is quoted unless
strictly necessary (it must contain at least one mqspecial) and no
single character is prefixed by a "\" in the form of a quoted-pair
unless strictly necessary, and moreover there is no possibility for
">" or WSP to occur inside a msg-id-core, whether quoted or not.
This is to simplify processing by relaying and serving agents and to
ensure interoperability with existing implementations. Thus, whereas
under [RFC2822] the following <msg-id-core> would be considered
semantically equivalent,
<abcd@example.com>
<"abcd"@example.com>
<"ab\cd"@example.com>
only the first of them is syntactically permitted by this standard,
and hence a simple comparison of octets will always suffice to
determine the identity of two <msg-id-core>.
Also note that this updated ABNF applies wherever <msg-id-core> are
used, including the References header discussed in Section 3.2.1 and
the Supersedes header discussed in Section 3.2.5.
3.1.4 Subject
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.
Further discussion of the content of the Subject header appears in
[USEPRO] and [USEAGE].
subject = "Subject:" SP unstructured CRLF
3.1.5 Newsgroups 3.1.5 Newsgroups
The Newsgroups header specifies the newsgroup(s) to which the article The Newsgroups header specifies the newsgroup(s) to which the article
is posted. is posted.
newsgroups = "Newsgroups:" SP newsgroup-list CRLF newsgroups = "Newsgroups:" SP newsgroup-list CRLF
newsgroup-list = [FWS] newsgroup-name newsgroup-list = [FWS] newsgroup-name
*( "," [FWS] newsgroup-name ) [FWS] *( [FWS] "," [FWS] newsgroup-name ) [FWS]
newsgroup-name = component *( "." component ) ; 66 character max
component = plain-component newsgroup-name = component *( "." component )
plain-component = component-start *29component-rest component = 1*component-char
component-start = ALPHA / DIGIT component-char = ALPHA / DIGIT / "+" / "-" / "_"
NOTE: Observe that the syntax does not allow comments within the
Newsgroups header; this is to simplify processing by relaying and
serving agents which have a requirement to process this header
extremely rapidly.
component-rest = ALPHA / DIGIT / "+" / "-" / "_" Components beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT occur in
<newsgroup-name>s (whether in Newsgroups headers or in newgroup
control messages [USEPRO]). However, such names MUST be accepted.
A newsgroup name consists of one or more components separated by The specific format and lengths of <newsgroup-name> and <component>
periods, with no more than 66 characters total. Each component are discussed in [USEAGE].
consists of less than 30 or less letters and digits. These limits
are discussed further in Section 7.2 of [USEAGE].
3.1.6 Path 3.1.6 Path
The Path header indicates the route taken by an article since its The Path header indicates the route taken by an article since its
entry into the Netnews system, so that unnecessary redundant injection into the Netnews system. Each agent that processes an
transmission can be avoided. article is required to prepend one (or more) identities to this
header. This is primarily to enable relaying agents to avoid sending
articles to sites already known to have them, in particular the site
they came from, and additionally to permit tracing the route articles
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-identity path-list = [FWS]
*( path-delimiter [FWS] path-identity ) [FWS] *( path-identity [FWS] path-delimiter [FWS] )
tail-entry [FWS]
path-identity = ( ALPHA / DIGIT ) path-identity = ( ALPHA / DIGIT )
*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
path-delimiter = "!" tail-entry = path-identity
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 3.1.7 Injection-Date
The Injection-Date header contains the date and time that the article The Injection-Date header contains the date and time that the article
was injected into the network. Its purpose is to prevent the was injected into the network. Its purpose is to prevent the
reinjection into the news stream of "stale" articles which have reinjection into the news stream of "stale" articles which have
already expired by the time they arrive at some relaying or serving already expired by the time they arrive at some relaying or serving
agent. agent.
This header is mandatory for new clients, but all agents SHOULD use
the Date header for this purpose if Injection-Date is not present.
injection-date = "Injection-Date:" SP date-time CRLF injection-date = "Injection-Date:" SP date-time CRLF
See the remarks under Section 3.1.2 regarding the syntax of
See the remarks under Section 3.1.3 regarding the syntax of
date-time and the requirements and recommendations to which it is date-time and the requirements and recommendations to which it is
subject. subject.
NOTE: The date-time in this header would normally be expected to NOTE: The date-time in this header would normally be expected to
be later than the date-time in the Date header, but differences be later than the date-time in the Date header, but differences
between the clocks on the various agents and other special between the clocks on the various agents and other special
circumstances might vitiate that; no provision is made for any circumstances might vitiate that; no provision is made for any
such discrepancy to be corrected - better that the injecting agent such discrepancy to be corrected - better that the injecting agent
should just insert the correct time as it sees it. should just insert the correct time as it sees it.
This header is intended to replace the currently-used but This header is intended to replace the currently-used but
undocumented "NNTP-Posting-Date" header, whose use is now deprecated. undocumented "NNTP-Posting-Date" header, whose use is now deprecated.
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 are required in certain types of
article, such as followups. Further discussion of these requirements article, such as followups. Further discussion of these requirements
is discussed in [USEPRO] and [USEAGE]. appears in [USEPRO] and [USEAGE].
The headers Reply-To, Sender, Comments, and Keywords are often used The headers Reply-To, Sender, Comments, and Keywords are used in news
in news articles and have the identical meaning as that specified in articles in the same circumstances and with the same meaning as that
[RFC2822] with the added restrictions detailed in Section 2.2. specified in [RFC2822] with the added restrictions detailed in
Section 2.2. Multiple occurances of the Keywords header are not
permitted.
The MIME headers Content-Type and Content-Transfer-Encoding are often sender = "Sender:" SP mailbox CRLF
used in news articles and have the identical meaning as that
specified in [RFC2045] with the added restrictions detailed in
Section 2.2.
All other commonly used news headers are described below. reply-to = "Reply-To:" SP address-list CRLF
comments = "Comments:" SP unstructured CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF
The MIME headers MIME-Version, Content-Type,
Content-Transfer-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 headers are described below.
3.2.1 References 3.2.1 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> construct defined in Section 3.1.4 MUST be o The updated <msg-id-core> construct defined in Section 3.1.3 MUST
used. be used.
o Message IDs MUST be separated with CFWS. o Message identifiers MUST be separated with CFWS.
o Comments in CFWS between Message IDs can cause interoperability o Comments in CFWS between message identifiers can cause
problems, so comments SHOULD NOT be generated, but MUST be interoperability problems, so comments SHOULD NOT be generated,
accepted. but MUST be accepted.
references = "References:" SP 1*( [CFWS] msg-id-core) [CFWS]
CRLF
3.2.2 Followup-To 3.2.2 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. should be posted. The Followup-To header SHOULD NOT appear in a
message, unless its content is different from the content of the
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 (Section The syntax is the same as that of the Newsgroups header (Section
3.1.5, with the exception that the magic word "poster" (which is 3.1.5, with the exception that the keyword "poster" (which is always
always lowercase) means that followups should be mailed to the lowercase) requests that followups should be mailed to the article's
article's reply address rather than posted. In order to improve reply address rather than posted. Although the keyword "poster" is
interoperability with deployed clients, followup agents MAY choose to case-sensitive, followup agents MAY choose to recognize
recognize case-insensitive forms such as "Poster". case-insensitive forms such as "Poster".
3.2.3 Expires 3.2.3 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 useful 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.3 regarding the syntax of See the remarks under Section 3.1.2 regarding the syntax of
date-time and the requirements and recommendations to which it is date-time and the requirements and recommendations to which it is
subject. subject.
3.2.4 Control 3.2.4 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 [CFWS] control-message [CFWS] CRLF control = "Control:" SP [FWS] control-message [FWS] CRLF
control-message = <empty> control-message = verb *( [FWS] argument )
The control-message indicates what action should be taken. The exact verb = token
syntax for control-message is specified in the companion document,
[USEPRO]. argument = value
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
also contain details. The legal verbs and respective arguments are
discussed in the companion document, [USEPRO].
An article with a Control header MUST NOT also have a Supersedes
header.
3.2.5 Supersedes 3.2.5 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. The specified article to be superseded upon the arrival of this one. An article
article MUST be treated as though a "cancel" [USEPRO] control message containing a Supersedes header is equivalent to a "cancel" [USEPRO]
had arrived for the article (but observe that a site MAY choose not control message for the specified article, followed immediately by
to honor a "cancel" message, especially if its authenticity is in the new article without the Supersedes header.
doubt).
supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] 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
Supersedes header that sometimes appears in Email messages converted
from X.400 according to [RFC2156]; in particular, the syntax here
permits only one <msg-id-core> in contrast to the multiple
<msg-id-core>s in that Email version.
3.2.6 Distribution 3.2.6 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 dist-list CRLF distribution = "Distribution:" SP distribution-list CRLF
list-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS] dist-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS]
dist-name = ALPHA / DIGIT dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" ) *( ALPHA / DIGIT / "+" / "-" / "_" )
"All" MUST NOT be used as a distribution-name. Distribution-names The <dist-name>s "world" and "local" are predefined. However,
SHOULD contain at least three characters, except when they are "world" SHOULD NOT be used explicitly, since it is the default when
two-letter country names as in [ISO.3166.1988]. Distribution-names the Distribution header is absent entirely.
are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify
the same distribution). "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
names as in [ISO.3166.1988]. <dist-name>s are case-insensitive (i.e.
"US", "Us", "uS", and "us" all specify the same distribution).
3.2.7 Summary 3.2.7 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.8 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 moderators approving the article for posting. full names) of the persons or entities approving the article for
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
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
standard doesn't 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.9 Organization 3.2.9 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.10 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. serving agent to process it. The article locations are used to keep
track of crossposted articles so that reading agents serviced by a
particular serving agent can mark such articles as read.
xref = "Xref:" SP [CFWS] server-name xref = "Xref:" SP [CFWS] server-name
1*( CFWS location ) [CFWS] CRLF 1*( CFWS location ) [CFWS] 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 used by NNTP) is NOTE: The traditional form of an article-locator (as used by
a decimal number, with articles in each newsgroup numbered [NNTP]) is a decimal number, with articles in each newsgroup
consecutively starting from 1. numbered consecutively starting from 1.
3.2.11 Archive 3.2.11 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 regarding preservation of the article in publicly accessible
long-term or permanent storage. long-term or permanent storage.
archive = "Archive:" SP [CFWS] ("no" / "yes") archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" archive-param ) CRLF *( [CFWS] ";" archive-param ) CRLF
archive-param = <a parameter with attribute "filename" archive-param = "filename=" value
and any value>
The presence of an "Archive: no" header in an article indicates that
the poster does not permit redistribution from publicly accessible
long-term or permanent archives. The absence of this header, or an
explicit "Archive: yes", indicates that the poster is willing for
such redistribution to take place. The optional "filename" parameter
can then be used to suggest a filename under which the article should
be stored. Further extensions to this standard may provide
additional parameters for administration of the archiving process.
3.2.12 User-Agent 3.2.12 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. Although not one of the mandatory headers, needing correction. It is intended that this header be suitable for
posting agents SHOULD normally include it. It is also intended that use in Email.
this header be suitable for use in Email.
user-agent = "User-Agent:" SP 1*product CRLF user-agent = "User-Agent:" SP 1*product CRLF
product = [CFWS] token [CFWS] [ "/" product-version ] product = [CFWS] token [CFWS] [ "/" product-version ]
product-version = [CFWS] token [CFWS] product-version = [CFWS] token [CFWS]
This header MAY contain multiple product-tokens identifying the agent
and any subproducts which form a significant part of the posting
agent, listed in order of their significance for identifying the
application.
NOTE: This header supersedes the role performed redundantly by
experimental headers such as X-Newsreader, X-Mailer,
X-Posting-Agent, X-Http-User-Agent, and other headers previously
used on Usenet and in Email for this purpose. Use of these
experimental headers SHOULD be discontinued in favor of the
single, standard User-Agent header.
NOTE: [RFC2616] describes a similar facility for the HTTP
protocol. This specification differs in that "{" and "}" are
allowed in tokens (<product> and <product-version>) and comments
are permitted wherever whitespace is allowed.
3.2.13 Injection-Info 3.2.13 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.
injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS]
*( ";" injection-info-parameter ) *( ";" inj-info-para ) CRLF
injection-info-parameter inj-info-param = post-host-param /
= posting-host-parameter / post-account-param /
posting-account-parameter / sender-param /
posting-sender-parameter / logging-param
posting-logging-parameter
posting-host-parameter post-host-param = "posting-host=" host-value
= <a parameter with attribute "posting-host"
and value some host-value>
host-value = dot-atom / [ dot-atom ":" ] host-value = dot-atom / [ dot-atom ":" ]
( IPv4address / IPv6address ) ; see [RFC 2373] ( IPv4address / IPv6address ) ; see [RFC 2373]
posting-account-parameter post-acct-param = "posting-account=" value
= <a parameter with attribute "posting-account"
and any value>
posting-sender-parameter sender-param = "sender=" sender-value
= <a parameter with attribute "sender"
and value some sender-value>
sender-value = mailbox / "verified" sender-value = mailbox / "verified"
posting-logging-parameter logging-param = "logging-data=" value
= <a parameter with attribute "logging-data"
and any value>
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. It is also RECOMMENDED that such parameters as are parameter. It is also RECOMMENDED that such parameters as are
present are included in the order in which they have been defined in present are included in the order in which they have been defined in
the syntax above. the syntax above.
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" and "X-Trace". undocumented headers such as "NNTP-Posting-Host" and "X-Trace".
These headers are now deprecated. These headers are now deprecated.
3.3 Obsolete Headers
Early versions of news software following the modern format sometimes
generated headers like the following:
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
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 relaying agent
that last processed the article. Posting-Version contained version
information about the posting agent that posted the article.
Date-Received contained the date when the last relaying agent to
process the article first saw it (in a slightly nonstandard format).
In addition, this present standard obsoletes certain headers defined
in [Son-of-1036]:
Also-Control: cancel <9urrt98y53@site.example>
See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example>
Article-Names: comp.foo:charter
Article-Updates: <i4g587y@site1.example>
Also-Control indicated a control message that was also intended to be
filed as a normal article. See-Also listed related articles, but
without the specific relationship with followups that pertains to the
References-header. 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 headers listed above are documented for historical purposes only.
Articles containing these headers MUST NOT be generated. Persons
writing new agents SHOULD ignore any former meanings these headers.
3.3.1 Lines
The Lines header indicates the number of lines in the body of the
article.
lines = "Lines" ":" SP [CFWS] 1*DIGIT [CFWS] CRLF
The line count includes all body lines, including the signature if
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
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
agent.
Historically, this header was used by the [NNTP] overview extension,
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
entirely in a future version of this standard.
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.4) in news are required to be unique; Message-IDs (Section 3.1.3) in news are required to be unique;
articles are refused (in server-to-server transfer) if the ID has articles are refused (in server-to-server transfer) if the ID has
already been seen. So if you can predict the ID of a message, you already been seen. So if you can predict the ID of a message, you
can preempt it by posting a message (possibly to a quite different can preempt it by posting a message (possibly to a quite different
group) with the same ID, stopping your target message from group) with the same ID, stopping your target message from
propagating. Agents that generate message-ids for news articles propagating. Agents that generate message-ids for news articles
SHOULD ensure that they are unpredictable. SHOULD ensure that they are unpredictable.
The filename parameter of the Archive-header (Section 3.2.11) can be The filename parameter of the Archive-header (Section 3.2.11) can be
used to attempt to store archived articles in inappropriate used to attempt to store archived articles in inappropriate
locations. Archiving sites should be suspicious of absolute filename locations. Archiving sites should be suspicious of absolute filename
skipping to change at page 21, line 5 skipping to change at page 26, line 5
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May
2002. 2002.
6.2 Informative References 6.2 Informative References
[ISO.3166.1988] [ISO.3166.1988]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries, 3rd edition", the representation of names of countries, 3rd edition",
ISO Standard 3166, August 1988. ISO Standard 3166, August 1988.
[NNTP] Feather, C., "Network News Transfer Protocol",
draft-ietf-nntpext-base-*.txt.
[PGPVERIFY] [PGPVERIFY]
Lawrence, D., "PGPverify", June 1999. Lawrence, D., "PGPverify", June 1999.
[RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[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):
Mapping between X.400 and RFC 822/MIME", RFC 2156, January
1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[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.
[Son-of-1036] [Son-of-1036]
Spencer, H., "News Article Format and Transmission", June Spencer, H., "News Article Format and Transmission", June
1994. 1994.
[USEAGE] Lindsey, C., "Usenet Best Practice", [USEAGE] Lindsey, C., "Usenet Best Practice",
draft-ietf-usefor-useage-*.txt. draft-ietf-usefor-useage-*.txt.
[USEPRO] Lindsey, C., "News Article Architecture and Protocols", [USEPRO] Lindsey, C., "News Article Architecture and Protocols",
draft-ietf-usefor-usepro-*.txt. draft-ietf-usefor-usepro-*.txt.
Authors' Addresses Authors' Addresses
Kenneth Murchison (editor)
Oceana Matrix Ltd.
21 Princeton Place
Orchard Park, NY 14127
US
Phone: +1 716 662 8973
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 Chesire 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
Kenneth Murchison
Oceana Matrix Ltd.
21 Princeton Place
Orchard Park, NY 14127
US
Phone: +1 716 662 8973
EMail: ken@oceana.com
Dan Kohn Dan Kohn
Skymoon Ventures Skymoon Ventures
3045 Park Boulevard 3045 Park Boulevard
Palo Alto, CA 94306 Palo Alto, CA 94306
US US
Phone: +1 650 327 2600 Phone: +1 650 327 2600
EMail: dan@dankohn.com EMail: dan@dankohn.com
Appendix A. Acknowledgements Appendix A. Acknowledgements
Comments and/or text were provided by Mark Crispin, Claus Faerber, Comments and/or text were provided by Mark Crispin, Claus Faerber,
Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson,
Bruce Lilly, Pete Resnick, and Henry Spencer. Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey
Melnikov.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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