draft-ietf-usefor-usefor-04.txt   draft-ietf-usefor-usefor-05.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: November 25, 2005 University of Manchester Expires: January 9, 2006 University of Manchester
D. Kohn D. Kohn
Skymoon Ventures Skymoon Ventures
May 24, 2005 July 8, 2005
Netnews Article Format Netnews Article Format
draft-ietf-usefor-usefor-04 draft-ietf-usefor-usefor-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 25, 2005. This Internet-Draft will expire on January 9, 2006.
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.
Note to the RFC Editor
The normative reference to RFC 2234 may be replaced by
draft-crocker-abnf-rfc2234bis should it reach RFC status before this
one.
Changes since draft-ietf-usefor-usefor-04
o Resolved ticket #1002 (updated references).
o Applied text from ticket #1003 (ABNF cleanup for msg-id).
o Resolved ticket #1004 (deprecate X- headers).
o Resolved ticket #1008 (followups & References header field).
o Applied text from ticket #1021 (Newsgroups ABNF and description).
o Resolved ticket #1022 (obs-phrase).
o Applied text from ticket #1028 (GMT timezone for Date).
o Applied text from ticket #1042 (Newsgroups folding).
o Resolved ticket #1043 (RFC 2822 terms for header fields).
o Starting to resolve ticket #1052 (differences from RFC 2822).
o Miscellaneous editorial changes.
Changes since draft-ietf-usefor-usefor-03 Changes since draft-ietf-usefor-usefor-03
o Reworked ABNFs of several headers. o Reworked ABNFs of several headers.
o Used Charles' ABNF for <msg-id>. o Used Charles' ABNF for <msg-id>.
o Disallowed comments in Supersedes header. o Disallowed comments in Supersedes header.
o Disallowed comments in Xref header. o Disallowed comments in Xref header.
skipping to change at page 3, line 33 skipping to change at page 4, line 18
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.
o Miscellaneous editorial changes 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 Disallowed comments in Control header.
o Xref header allows for non-digit "locations".
o Only allow for a single message-id in Supersedes header.
o Changes to the References header.
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
o Decide which definitions should go in this document and in o MIME boundary security considerations.
[USEPRO].
o Do we want to discuss message/partial? o Path header field delimiters and components.
o Add appendixes for changes from RFC 1036 and differences from RFC o Complete appendixes for changes from RFC 1036 and differences from
2822. RFC 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 7 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 7 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 6
1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Structure of This Document . . . . . . . . . . . . . . . . 9 1.6 Structure of This Document . . . . . . . . . . . . . . . . 8
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 Header Fields . . . . . . . . . . . . . . . . . . . . . . 9
2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 11 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10
3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 12 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . 11
3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 12 3.1 Mandatory Header Fields . . . . . . . . . . . . . . . . . 11
3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 16 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 15
3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 17 3.2 Optional Header Fields . . . . . . . . . . . . . . . . . . 17
3.2.1 Injection-Date . . . . . . . . . . . . . . . . . . . . 18 3.2.1 Injection-Date . . . . . . . . . . . . . . . . . . . . 18
3.2.2 References . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 References . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Followup-To . . . . . . . . . . . . . . . . . . . . . 19 3.2.3 Followup-To . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Expires . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.4 Expires . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.5 Control . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.5 Control . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.6 Supersedes . . . . . . . . . . . . . . . . . . . . . . 20 3.2.6 Supersedes . . . . . . . . . . . . . . . . . . . . . . 20
3.2.7 Distribution . . . . . . . . . . . . . . . . . . . . . 20 3.2.7 Distribution . . . . . . . . . . . . . . . . . . . . . 20
3.2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.9 Approved . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.9 Approved . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.10 Organization . . . . . . . . . . . . . . . . . . . . 21 3.2.10 Organization . . . . . . . . . . . . . . . . . . . . 21
3.2.11 Xref . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.11 Xref . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.12 Archive . . . . . . . . . . . . . . . . . . . . . . 22 3.2.12 Archive . . . . . . . . . . . . . . . . . . . . . . 22
3.2.13 User-Agent . . . . . . . . . . . . . . . . . . . . . 23 3.2.13 User-Agent . . . . . . . . . . . . . . . . . . . . . 23
3.2.14 Injection-Info . . . . . . . . . . . . . . . . . . . 23 3.2.14 Injection-Info . . . . . . . . . . . . . . . . . . . 23
3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 25 3.3 Obsolete Header Fields . . . . . . . . . . . . . . . . . . 25
3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Internationalization Considerations . . . . . . . . . . . . 27 4. Internationalization Considerations . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Normative References . . . . . . . . . . . . . . . . . . . 29 6.1 Normative References . . . . . . . . . . . . . . . . . . . 29
6.2 Informative References . . . . . . . . . . . . . . . . . . 29 6.2 Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 33 B. Differences from RFC 1036 . . . . . . . . . . . . . . . . . 33
C. Differences from RFC 2822 . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . 35
1. Introduction 1. Introduction
1.1 Basic Concepts 1.1 Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing and
retrieving news "articles" (whose format is a subset of that for retrieving news "articles" (whose format is a subset of that for
Email messages) and for exchanging them amongst a readership which is Email messages) and for exchanging them amongst a readership which is
potentially widely distributed. It is organized around "newsgroups", potentially widely distributed. It is organized around "newsgroups",
with the expectation that each reader will be able to see all with the expectation that each reader will be able to see all
skipping to change at page 8, line 7 skipping to change at page 7, line 7
1.3 Requirements Notation 1.3 Requirements Notation
This document uses terms that appear in capital letters. The key This document uses terms that appear in capital letters. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 Header fields defined in this specification use the Augmented Backus-
Form (ABNF) notation (including the Core Rules) specified in Naur 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.3 updates the [RFC2822] definition of <msg-id>.
<zone> and <msg-id> respectively.
The following constructs referenced by this document are defined in The following constructs referenced by this document are defined in
[RFC2822]: <mailbox-list>, <mailbox>, <date-time>, <phrase>, [RFC2822]: <mailbox-list>, <mailbox>, <date-time>, <phrase>,
<address-list>, <utext>, <dot-atom-text>, <dot-atom>, <FWS>, <CFWS> <address-list>, <utext>, <dot-atom-text>, <dot-atom>, <FWS>, <CFWS>
and <CRLF>. and <CRLF>.
The following constructs referenced by this document are defined in The following constructs referenced by this document are defined in
[RFC2045] (as amended by [RFC2231]): <token>, <parameter>, <value>. [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 header fields.
A "message identifier" Section 3.1.3 is a unique identifier for an A "message identifier" (Section 3.1.3) is a unique identifier for an
article, usually supplied by the "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 header.
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
skipping to change at page 9, line 14 skipping to change at page 8, line 13
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" indicated in the an earlier article, its "precursor". Every followup includes a
"References" header). "References" header field identifying that precursor (but note that
non-followup articles may also use a References header field).
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 9, line 43 skipping to change at page 8, line 43
1.6 Structure of This Document 1.6 Structure of This Document
This document uses a cite by reference methodology, rather than This document uses a cite by reference methodology, rather than
repeating the contents of other standards, which could otherwise repeating the contents of other standards, which could otherwise
result in subtle differences and interoperability challenges. result in subtle differences and interoperability challenges.
Although this document is as a result rather short, it requires Although this document is as a result rather short, it requires
complete understanding and implementation of the normative references complete understanding and implementation of the normative references
to be compliant. to be compliant.
Section 2 defines the format of 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 header fields 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]. Netnews agents MAY also accept the obsolete syntax [RFC2822]. Netnews agents MAY also accept the obsolete syntax
specified in Section 4 of [RFC2822], but they MUST NOT generate specified in Section 4 of [RFC2822], but they MUST NOT generate
productions of such syntax. productions of such syntax.
This specification uses the terms "header", "header name", and Agents MUST accept the obs-phrase construct (use of a phrase like
"header content" which are synonymous with the [RFC2822] terms "John Q. Public" without the use of quotes, see [RFC2822] section
"header field", "field name", and "field body" respectively. 4.1) but they MUST NOT generate productions of such syntax.
2.2 Headers NOTE: Older Netnews specifications used the term "header" as a
synonym for what [RFC2822] calls "header field". This document
follows the terminology in Section 2 of [RFC2822] in using the
terms "line", "header field", "header field name", "header field
body", and "folding", based on a belief that consistent
terminology among specifications that depend on each other makes
the specifications easier to use in the long run.
All headers in a news article are compliant with [RFC2822], however 2.2 Header Fields
this specification is less permissive in what can be generated and
accepted by news agents. The syntax allowed for news articles is a
strict subset of the "Internet Message Format", making all messages
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 All header fields in a news article are compliant with [RFC2822],
[RFC2822] and [RFC2045]) are listed below and those that apply to however this specification is less permissive in what can be
specific headers are described in the relevent sections of this generated and accepted by news agents. The syntax allowed for news
articles is a strict subset of the "Internet Message Format", making
all messages 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 header fields (even those documented
in [RFC2822] and [RFC2045]) are listed below and those that apply to
specific header fields are described in the relevent sections of this
document. document.
o All agents MUST generate headers so that at least one space o All agents MUST generate header fields so that at least one space
immediately follows the ':' separating the header name and the immediately follows the ':' separating the header field name and
header contents (for compatibility with deployed software). News the header field body (for compatibility with deployed software).
agents MAY accept headers which do not contain the required space. News agents MAY accept header fields which do not contain the
required space.
o The header contents of every header line (including the first and o Every line of a header field body (including the first and any
any that are subsequently folded) MUST contain at least one non- that are subsequently folded) MUST contain at least one non-
whitespace character. whitespace character.
NOTE: This means that no header content defined by or NOTE: This means that no header field body defined by or
referenced by this document can be empty. As a result, this referenced by this document can be empty. As a result, this
document updates the <unstructured> construct from Section document updates the <unstructured> construct from Section
3.2.6 of [RFC2822] as follows: 3.2.6 of [RFC2822] as follows:
unstructured = 1*( [FWS] utext ) [FWS] unstructured = 1*( [FWS] utext ) [FWS]
o Compliant software MUST NOT generate (but MAY accept) headers of o Compliant software MUST NOT generate (but MAY accept) header
more than 998 octets. This is the only limit on the length of a fields of more than 998 octets. This is the only limit on the
header line prescribed by this standard. However, specific rules length of a header field prescribed by this standard. However,
to the contrary may apply in particular cases (for example, specific rules to the contrary may apply in particular cases (for
according to [RFC2047] header lines containing encoded-words are example, according to [RFC2047] lines of a header field containing
limited to 76 octets). [USEAGE] includes suggested limits for encoded-words are limited to 76 octets). [USEAGE] includes
convenience of display by user agents. suggested limits for convenience of display by user agents.
NOTE: There is NO restriction on the number of lines into which 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 a header field may be split, and hence there is NO restriction
total length of a header (in particular it may, by suitable on the total length of a header field (in particular it may, by
folding, be made to exceed the 998 octets restriction suitable folding, be made to exceed the 998 octets restriction
pertaining to a single header line). pertaining to a single header line).
o The character set for headers is US-ASCII. Where the use of non- o The character set for header fields is US-ASCII. Where the use of
ASCII characters is required, they MUST be encoded using the MIME non-ASCII characters is required, they MUST be encoded using the
mechanisms defined in [RFC2047] and [RFC2231]. MIME mechanisms defined in [RFC2047] and [RFC2231].
2.3 MIME Conformance 2.3 MIME Conformance
User agents MUST meet the definition of MIME-conformance in [RFC2049] User agents MUST meet the definition of MIME-conformance in [RFC2049]
and MUST also support [RFC2231]. This level of MIME Conformance and MUST also support [RFC2231]. This level of MIME Conformance
provides support for internationalization and multimedia in message provides support for internationalization and multimedia in message
bodies ([RFC2045], [RFC2046], [RFC2231]), and support for bodies ([RFC2045], [RFC2046], [RFC2231]), and support for
internationalization of headers ([RFC2047], [RFC2231]). Note that internationalization of header fields ([RFC2047], [RFC2231]). Note
[Errata] currently exist for [RFC2046] and [RFC2231]. that [Errata] currently exist for [RFC2046] and [RFC2231].
For the purposes of Section 5 of [RFC2047], all headers defined in For the purposes of Section 5 of [RFC2047], all header fields defined
Section 3 of this standard are to be considered as "extension message in Section 3 of this standard are to be considered as "extension
header fields" (insofar as they are not already considered under the message header fields" (insofar as they are not already considered
existing Email standards), permitting the use of [RFC2047] encodings under the existing Email standards), permitting the use of [RFC2047]
within any <unstructured> header, or within any <comment> or <phrase> encodings within any <unstructured> header field, or within any
permittted within any structured header. <comment> or <phrase> permittted within any structured header field.
User agents MAY accept and generate other MIME extension headers, and User agents MAY accept and generate other MIME extension header
in particular SHOULD accept Content-Disposition [RFC2183] and fields, and in particular SHOULD accept Content-Disposition [RFC2183]
Content-Language [RFC3282]. and Content-Language [RFC3282].
3. News Headers 3. News Header Fields
The following news headers extend those defined in section 3.6 of The following news header fields extend those defined in section 3.6
[RFC2822]: of [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 /
approved / approved /
organization / organization /
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 header fields may occur at most once in a news article.
3.1 Mandatory Headers 3.1 Mandatory Header Fields
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 header fields: From, Date,
Subject, Newsgroups, Path. Message-ID, 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 field is the same as that specified in Section 3.6.2
[RFC2822] with the added restrictions detailed in Section 2.2. of [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
The Date header is the same as that specified in Sections 3.3 and The Date header field is the same as that specified in Sections 3.3
3.6.1 of [RFC2822] with the added restrictions detailed in and 3.6.1 of [RFC2822] with the added restrictions detailed in
Section 2.2. However, the use of "UT" and "GMT" as time zones (part Section 2.2. However, the use of "GMT" as a time zone (part of <obs-
of <obs-zone>), although deprecated, is widespread in news articles zone>), although deprecated, is widespread in news articles today.
today. Therefore, agents MUST accept <date-time> constructs which Therefore, agents MUST accept <date-time> constructs which use the
include the updated <zone> construct below. "GMT" zone.
orig-date = "Date:" SP date-time CRLF from = "Date:" SP date-time CRLF
zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" NOTE: This specification does not change [RFC2822], which says that
agents MUST NOT generate <date-time> constructs which include any
zone names defined by <obs-zone>.
Note that agents SHOULD NOT generate <date-time> constructs which Software that accepts dates with unknown timezones SHOULD treat such
include either "UT" or "GMT" and MUST NOT generate <date-time> timezones as equivalent to "-0000" when comparing dates, as specified
constructs which include any other zone names defined by <obs-zone>, in [RFC2822] section 4.3.
some of which have ambiguous interpretations and would have adverse
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.2.1 and including Injection-Date and Expires in Section 3.2.1 and
Section 3.2.4 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 field contains a single unique message
This document updates the <msg-id> construct from Section 3.6.4 of identifier. Netnews is more dependent on message identifier
[RFC2822] so as to ensure that Internet Message Format Message-IDs uniqueness and fast comparison than Email is, and some news software
are usable in widely deployed news software. The global uniqueness might have trouble with the full range of possible <msg-id>s
requirement for <msg-id> in [RFC2822] is to be understood as applying permitted by [RFC2822]; this section therefore restricts the syntax
across all protocols using such message identifiers, and across both of <msg-id> as compared to Section 3.6.4 of [RFC2822]. The global
Email and Netnews in particular. A revised syntax for <msg-id> is uniqueness requirement for <msg-id> in [RFC2822] is to be understood
given below, but the requirements and descriptive text from Section as applying across all protocols using such message identifiers, and
3.6.4 of [RFC2822] still apply. across both Email and Netnews in particular.
message-id = "Message-ID:" SP [FWS] msg-id [FWS] CRLF message-id = "Message-ID:" SP [FWS] msg-id [FWS] CRLF
msg-id = "<" 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 / ( "." *mqtext /
*mqtext "." / *mqtext "." /
*mqtext mqspecial *mqtext ) *mqtext mqspecial *mqtext )
DQUOTE DQUOTE
mqtext = atext / "." / mqspecial mqtext = atext / "." / mqspecial
mqspecial = "(" / ")" / ; same as specials except mqspecial = "(" / ")" / ; same as specials except
"<" / ; "\" and DQUOTE quoted "<" / ; "\" and DQUOTE quoted
"[" / "]" / ; "." doubled and ">" omitted "[" / "]" / ; "." doubled and ">" omitted
":" / ";" / ":" / ";" /
skipping to change at page 14, line 43 skipping to change at page 13, line 43
%d94-126 ; ">", "[", "]", or "\" %d94-126 ; ">", "[", "]", or "\"
The msg-id MUST NOT be more than 250 octets in length. The msg-id MUST NOT be more than 250 octets in length.
NOTE: The length restriction ensures that systems 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 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 field in
[RFC2822]: [RFC2822]:
o the syntax does not allow comments within the Message-ID header, o the syntax does not allow comments within the Message-ID header
field,
o it ensures that no string of characters is quoted if it was o it ensures that no string of characters is quoted if it was
already a <dot-atom-text> (it MUST start or end with a ".", or already a <dot-atom-text> (it MUST start or end with a ".", or
contain at least one <mqspecial>), contain at least one <mqspecial>),
o it ensures that no single character is prefixed by a "\" in the o it ensures that no single character is prefixed by a "\" in the
form of a <quoted-pair> unless strictly necessary, form of a <quoted-pair> unless strictly necessary,
o it excludes all control characters, o it excludes all control characters,
o there is no possibility for ">" or WSP to occur inside a <msg-id>, o there is no possibility for ">" or WSP to occur inside a <msg-id>,
skipping to change at page 15, line 30 skipping to change at page 14, line 30
<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>s. determine the identity of two <msg-id>s.
Also note that this updated ABNF applies wherever <msg-id> is used, Also note that this updated ABNF applies wherever <msg-id> is used,
including the References header discussed in Section 3.2.2 and the including the References header field discussed in Section 3.2.2 and
Supersedes header discussed in Section 3.2.6. the Supersedes header field discussed in Section 3.2.6.
NOTE: It is RECOMMENDED in [RFC2822] that, for ensuring global Some software will try to match the <id-right> of a <msg-id> in a
uniqueness, the <id-right> be some domain identifier within whose case-insensitive fashion; some will match it in a case-sensitive
scope the uniqueness of the <id-left> can be guaranteed. When fashion. Implementations MUST NOT generate two Message-IDs where the
following this recommendation, any <dot-atom-text> or <no-fold- only difference is the case of characters in the <id-right> part.
literal> used for the <id-right> are to be interpreted as
<domain>s as described in Section 3.4.1 of [RFC2822]. If domain literals are used, the syntax found in Section 4.1.3 of
[RFC2821] is RECOMMENDED.
NOTE: Section 3.6.4 of [RFC2822] recommends that the <id-right>
should be a domain name or a domain literal. Domain literals are
troublesome since many IP addresses are not globally unique;
domain names are more likely to generate unique Message-IDs.
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 field is the same as that specified in Section
[RFC2822] with the added restrictions detailed in Section 2.2. 3.6.5 of [RFC2822] with the added restrictions detailed in
Further discussion of the content of the Subject header appears in Section 2.2. Further discussion of the content of the Subject header
[USEPRO] and [USEAGE]. field appears in [USEPRO] and [USEAGE].
subject = "Subject:" SP unstructured CRLF 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 field specifies the newsgroup(s) to which the
is posted. article 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] "," [FWS] newsgroup-name ) [FWS] *( [FWS] "," [FWS] newsgroup-name ) [FWS]
newsgroup-name = component *( "." component ) newsgroup-name = component *( "." component )
component = 1*component-char component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_" component-char = ALPHA / DIGIT / "+" / "-" / "_"
NOTE: Observe that the syntax does not allow comments within the NOTE: Observe that the syntax does not allow comments within the
Newsgroups header; this is to simplify processing by relaying and Newsgroups header field; this is to simplify processing by
serving agents which have a requirement to process this header relaying and serving agents which have a requirement to process
extremely rapidly. this header field extremely rapidly.
Folding the Newsgroups header field over several lines has been shown
to harm propagation significantly. Folded Newsgroups header fields
SHOULD NOT be generated, but MUST be accepted.
A newsgroup component SHOULD NOT consist of digits only, and SHOULD
NOT contain uppercase letters. Such components MAY be used only to
refer to existing groups that do not conform to this naming scheme.
NOTE: All-digit components conflict with one widely used storage
scheme for articles. Mixed case groups cause confusion between
systems with case sensitive matching and systems with case
insensitive matching of newsgroup names.
Components beginning with underline ("_") are reserved for use by Components beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT occur in <newsgroup- future versions of this standard and MUST NOT be generated by posting
name>s (whether in Newsgroups headers or in newgroup control messages agents (whether in Newsgroups header fields or in newgroup control
[USEPRO]). However, such names MUST be accepted. messages [USEPRO]). However, such names MUST be accepted by relaying
and serving agents.
The specific format and lengths of <newsgroup-name> and <component> Components beginning with "+" and "-" are reserved for private use
are discussed in [USEAGE]. and MUST NOT be generated by posting agents (whether in Newsgroups
header fields or in newgroup control messages [USEPRO]) without a
private prior agreement to do so. However, such names MUST be
accepted by relaying and serving agents.
The following newsgroup names are reserved, and MUST NOT be used as
the name of a newsgroup:
o Groups starting with the component "example"
o The group "poster"
The following newsgroup names have been used for specific purposes in
various implementations and protocols, and MUST therefore not be used
for the names of normal newsgroups. They MAY be used for their
specific purpose, or by local agreement.
Groups starting with the component "to"
Groups starting with the component "control"
Groups containing the component "all"
Groups containing the component "ctl"
The group "junk"
NOTE: The list above includes the groups "to", "control", "all",
and "ctl".
3.1.6 Path 3.1.6 Path
The Path header indicates the route taken by an article since its The Path header field indicates the route taken by an article since
injection into the Netnews system. Each agent that processes an its injection into the Netnews system. Each agent that processes an
article is required to prepend 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 field body. This is primarily to enable relaying agents to
articles to sites already known to have them, in particular the site avoid sending articles to sites already known to have them, in
they came from, and additionally to permit tracing the route articles particular the site they came from, and additionally to permit
take in moving over the network, and for gathering Usenet statistics. 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-list = [FWS]
*( ( path-identity / path-keyword ) [FWS] *( ( path-identity / path-keyword ) [FWS]
path-delimiter [FWS] ) path-delimiter [FWS] )
tail-entry [FWS] tail-entry [FWS]
path-identity = ( ALPHA / DIGIT ) path-identity = ( ALPHA / DIGIT )
*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
skipping to change at page 17, line 30 skipping to change at page 17, line 30
Each <path-identity> in the <path-list> (excluding the one in the Each <path-identity> in the <path-list> (excluding the one in the
<tail-entry>) indicates, from right to left, the successive agents <tail-entry>) indicates, from right to left, the successive agents
through which the article has passed. The <keyword> "POSTED" through which the article has passed. The <keyword> "POSTED"
indicates that the agent to its left injected the article. The use indicates that the agent to its left injected the article. The use
of the <path-delimiter> "!!" indicates that the agent to its left of the <path-delimiter> "!!" indicates that the agent to its left
claims that the agent to its right was the verified source of the claims that the agent to its right was the verified source of the
article (whereas the <path-delimiter> "!" implies no such claim). article (whereas the <path-delimiter> "!" implies no such claim).
The <keyword> "MISMATCH" indicates that the agent to its right failed The <keyword> "MISMATCH" indicates that the agent to its right failed
to be so verified. The full procedure for constructing a Path header 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- field as well as the specific format and use of <path-identity> and
entry> are discussed in [USEPRO]. <tail-entry> are discussed in [USEPRO].
NOTE: Historically, the <tail-entry> indicated the name of the NOTE: Historically, the <tail-entry> indicated the name of the
sender. If not used for this purpose, the string "not-for-mail" sender. If not used for this purpose, the string "not-for-mail"
is often used instead (since at one time the whole path could be is often used instead (since at one time the whole path could be
used as a mail address for the sender). used as a mail address for the sender).
NOTE: Although case-insensitive, it is intended that the <path- NOTE: Although case-insensitive, it is intended that the <path-
keyword>s "POSTED" and "MISMATCH" should be in upper case, to keyword>s "POSTED" and "MISMATCH" should be in upper case, to
distinguish them from the <path-identity>s which are traditionally distinguish them from the <path-identity>s which are traditionally
in lower case. in lower case.
3.2 Optional Headers 3.2 Optional Header Fields
None of the headers appearing in this section is required to appear None of the header fields appearing in this section is required to
in every article but some of them may be required in certain types of appear in every article but some of them may be required in certain
articles. Further discussion of these requirements appears in types of articles. Further discussion of these requirements appears
[USEPRO] and [USEAGE]. in [USEPRO] and [USEAGE].
The headers Reply-To, Sender, Comments, and Keywords are used in news The header fields Reply-To, Sender, Comments, and Keywords are used
articles in the same circumstances and with the same meaning as that in news articles in the same circumstances and with the same meaning
specified in [RFC2822] with the added restrictions detailed in as that specified in [RFC2822] with the added restrictions detailed
Section 2.2. Multiple occurances of the Keywords header are not in Section 2.2. Multiple occurances of the Keywords header field are
permitted. not 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
comments = "Comments:" SP unstructured CRLF comments = "Comments:" SP unstructured CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF keywords = "Keywords:" SP phrase *("," phrase) CRLF
The MIME headers MIME-Version, Content-Type, Content-Transfer- The MIME header fields MIME-Version, Content-Type, Content-Transfer-
Encoding, Content-Disposition, and Content-Language are used in 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 header fields are described below.
3.2.1 Injection-Date 3.2.1 Injection-Date
The Injection-Date header contains the date and time that the article The Injection-Date header field contains the date and time that the
was injected into the network. Its purpose is to prevent the article 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.
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 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.
NOTE: The date-time in this header would normally be expected to NOTE: The date-time in this header field would normally be
be later than the date-time in the Date header, but differences expected to be later than the date-time in the Date header field,
between the clocks on the various agents and other special but differences between the clocks on the various agents and other
circumstances might vitiate that; no provision is made for any special circumstances might vitiate that; no provision is made for
such discrepancy to be corrected - better that the injecting agent any such discrepancy to be corrected - better that the injecting
should just insert the correct time as it sees it. agent should just insert the correct time as it sees it.
This header is intended to replace the currently-used but This header field is intended to replace the currently-used but
undocumented "NNTP-Posting-Date" header, whose use is now deprecated. undocumented "NNTP-Posting-Date" header field, whose use is now
deprecated.
3.2.2 References 3.2.2 References
The References header is the same as that specified in Section 3.6.4 The References header field is the same as that specified in Section
of [RFC2822] with the added restrictions detailed in Section 2.2 and 3.6.4 of [RFC2822] with the added restrictions detailed in
those listed below: Section 2.2 and those listed below:
o The updated <msg-id> construct defined in Section 3.1.3 MUST be o The updated <msg-id> construct defined in Section 3.1.3 MUST be
used. used.
o Message identifiers MUST be separated with CFWS. o Message identifiers MUST be separated with CFWS.
o Comments in CFWS between message identifiers can cause o Comments in CFWS between message identifiers can cause
interoperability problems, so comments SHOULD NOT be generated, interoperability problems, so comments SHOULD NOT be generated,
but MUST be accepted. but MUST be accepted.
references = "References:" SP [CFWS] msg-id *(CFWS msg-id) references = "References:" SP [CFWS] msg-id *(CFWS msg-id)
[CFWS] CRLF [CFWS] CRLF
3.2.3 Followup-To 3.2.3 Followup-To
The Followup-To header specifies to which newsgroup(s) followups The Followup-To header field specifies to which newsgroup(s)
should be posted. The Followup-To header SHOULD NOT appear in a followups should be posted. The Followup-To header field SHOULD NOT
message, unless its content is different from the content of the appear in a message, unless its content is different from the content
Newsgroups header. of the Newsgroups header field.
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) followup-to = "Followup-To:" SP ( newsgroup-list / poster-text )
CRLF CRLF
poster-text = [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 field
(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.4 Expires 3.2.4 Expires
The Expires header specifies a date and time when the article is The Expires header field specifies a date and time when the article
deemed to be no longer relevant and could usefully be removed is 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.5 Control 3.2.5 Control
The Control header marks the article as a control message, and The Control header field marks the article as a control message, and
specifies the desired actions (additional to the usual ones of specifies the desired actions (additional to the usual ones of
storing and/or relaying the article). storing and/or relaying the article).
control = "Control:" SP [FWS] control-command [FWS] CRLF control = "Control:" SP [FWS] control-command [FWS] CRLF
control-command = 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 field MUST NOT also have a
header. Supersedes header field.
3.2.6 Supersedes 3.2.6 Supersedes
The Supersedes header contains a message identifier specifying an The Supersedes header field contains a message identifier specifying
article to be superseded upon the arrival of this one. An article an article to be superseded upon the arrival of this one. An article
containing a Supersedes header is equivalent to a "cancel" [USEPRO] containing a Supersedes header field is equivalent to a "cancel"
control message for the specified article, followed immediately by [USEPRO] control message for the specified article, followed
the new article without the Supersedes header. immediately by the new article without the Supersedes header field.
supersedes = "Supersedes:" SP [FWS] msg-id [FWS] 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 field defined here has no connection with
Supersedes header that sometimes appears in Email messages converted the Supersedes header field that sometimes appears in Email messages
from X.400 according to [RFC2156]; in particular, the syntax here converted from X.400 according to [RFC2156]; in particular, the
permits only one <msg-id> in contrast to the multiple <msg-id>s in syntax here permits only one <msg-id> in contrast to the multiple
that Email version. <msg-id>s in that Email version.
3.2.7 Distribution 3.2.7 Distribution
The Distribution header specifies geographic or organizational limits The Distribution header field specifies geographic or organizational
on an article's propagation. limits on an article's propagation.
distribution = "Distribution:" SP dist-list CRLF distribution = "Distribution:" SP dist-list CRLF
dist-list = [FWS] dist-name dist-list = [FWS] dist-name
*( [FWS] "," [FWS] dist-name ) [FWS] *( [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 field 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.8 Summary 3.2.8 Summary
The Summary header is a short phrase summarizing the article's The Summary header field is a short phrase summarizing the article's
content. content.
summary = "Summary:" SP unstructured CRLF summary = "Summary:" SP unstructured CRLF
3.2.9 Approved 3.2.9 Approved
The Approved header indicates the mailing addresses (and possibly the The Approved header field indicates the mailing addresses (and
full names) of the persons or entities approving the article for possibly the full names) of the persons or entities approving the
posting. 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 Each mailbox contained in the Approved header field MUST be that of
the person(s) or entity(ies) in question, and one of those mailboxes one of the person(s) or entity(ies) in question, and one of those
MUST be that of the actual sender of the article. Note that this mailboxes MUST be that of the actual sender of the article. Note
standard does not provide any means to enforce or verify this that this standard does not provide any means to enforce or verify
requirement, but future extensions or standards may provide such a this requirement, but future extensions or standards may provide such
facility (e.g. digitial signatures). a facility (e.g. digitial signatures).
3.2.10 Organization 3.2.10 Organization
The Organization header is a short phrase identifying the poster's The Organization header field is a short phrase identifying the
organization. poster's 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.11 Xref 3.2.11 Xref
The Xref header indicates where an article was filed by the last The Xref header field indicates where an article was filed by the
serving agent to process it. The article locations are used to keep last serving agent to process it. The article locations are used to
track of crossposted articles so that reading agents serviced by a keep track of crossposted articles so that reading agents serviced by
particular serving agent can mark such articles as read. a particular serving agent can mark such articles as read.
xref = "Xref:" SP [FWS] server-name xref = "Xref:" SP [FWS] server-name
1*( FWS location ) [FWS] 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 field. The locations specify what
newsgroups the article was filed under (which may differ from those newsgroups the article was filed under (which may differ from those
in the Newsgroups header) and where it was filed under them. The in the Newsgroups header field) and where it was filed under them.
exact form of an article-locator is implementation-specific. The exact form of an article-locator is implementation-specific.
NOTE: The traditional form of an article-locator (as required by NOTE: The traditional form of an article-locator (as required by
[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.12 Archive 3.2.12 Archive
The Archive header provides an indication of the poster's intent The Archive header field provides an indication of the poster's
regarding preservation of the article in publicly accessible long- intent regarding preservation of the article in publicly accessible
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 = parameter archive-param = parameter
The presence of an "Archive: no" header in an article indicates that The presence of an Archive header field in an article with a field
the poster does not permit redistribution from publicly accessible body of "no" indicates that the poster does not permit redistribution
long-term or permanent archives. The absence of this header, or an from publicly accessible long-term or permanent archives. The
explicit "Archive: yes", indicates that the poster is willing for absence of this header field, or the presence of this header field
with a field body of "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.13 User-Agent 3.2.13 User-Agent
The User-Agent header contains information about the user agent The User-Agent header field contains information about the user agent
(typically a newsreader) generating the article, for statistical (typically a newsreader) generating the article, for statistical
purposes and tracing of standards violations to specific software purposes and tracing of standards violations to specific software
needing correction. It is intended that this header be suitable for needing correction. It is intended that this header field be
use in Email. suitable for use in Email.
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ] product = [CFWS] token [ [CFWS] "/" product-version ]
product-version = [CFWS] token product-version = [CFWS] token
This header MAY contain multiple product-tokens identifying the agent This header field MAY contain multiple product-tokens identifying the
and any subproducts which form a significant part of the posting agent and any subproducts which form a significant part of the
agent, listed in order of their significance for identifying the posting agent, listed in order of their significance for identifying
application. the application.
NOTE: This header supersedes the role performed redundantly by NOTE: Some of this information has previously been sent in non-
experimental headers such as X-Newsreader, X-Mailer, X-Posting- standardized header fields such as X-Newsreader, X-Mailer,
Agent, X-Http-User-Agent, and other headers previously used on X-Posting-Agent, X-Http-User-Agent, and others. Once an agent
Usenet and in Email for this purpose. Use of these experimental uses User-Agent, it should have no need to send these non-standard
headers SHOULD be discontinued in favor of the single, standard header fields.
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.14 Injection-Info 3.2.14 Injection-Info
The Injection-Info header provides information as to how an article The Injection-Info header field provides information as to how an
entered the Netnews system and to assist in tracing its true origin. article entered the Netnews system and to assist in tracing its true
It can also specify one or more addresses where complaints concerning origin. It can also specify one or more addresses where complaints
the poster of the article may be sent. concerning the poster of the article may be sent.
injection-info = "Injection-Info:" SP [CFWS] path-identity injection-info = "Injection-Info:" SP [CFWS] path-identity
*( [CFWS] ";" [CFWS] inj-info-param ) *( [CFWS] ";" [CFWS] inj-info-param )
[CFWS] CRLF [CFWS] CRLF
inj-info-param = post-host-param / inj-info-param = post-host-param /
post-acct-param / post-acct-param /
sender-param / sender-param /
logging-param / logging-param /
complainto-param / complainto-param /
skipping to change at page 24, line 26 skipping to change at page 24, line 26
;; "post-acct-param", "sender-param", ;; "post-acct-param", "sender-param",
;; "logging-param" or "complainto-param" ;; "logging-param" or "complainto-param"
;; is allowed. ;; is allowed.
ext-param = parameter 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 3986]
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= "mail-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 field, it is RECOMMENDED that folding is
within any parameter (but only before or after the ";" separating not used within any parameter (but only before or after the ";"
those parameters), and that comments are only used following the last separating those parameters), and that comments are only used
parameter. following the last parameter.
This header is intended to replace various currently-used but NOTE: Some of this information has previously been sent in non-
undocumented headers such as "NNTP-Posting-Host", "X-Trace" and standardized header fields such as NNTP-Posting-Host, X-trace,
"X-Complaints-To". These headers are thus deprecated. X-Complaints-To, and others. Once an injecting agent uses
Injection-Info, it should have no need to send these non-standard
header fields.
The "posting-host" parameter specifies the FQDN and/or IP address The "posting-host" parameter specifies the FQDN and/or IP address
(IPv4address or IPv6address) of the host from which the injecting (IPv4address or IPv6address) of the host from which the injecting
agent received the article. agent received the article.
NOTE: If the "posting-host" parameter identifies a dial-up point- NOTE: If the "posting-host" parameter identifies a dial-up point-
of-presence, the "posting-account" or the "logging-data" parameter of-presence, the "posting-account" or the "logging-data" parameter
may provide additional information about true origin of the may provide additional information about true origin of the
article. article.
The "posting-account" parameter identifies the source from which the The "posting-account" parameter identifies the source from which the
injecting agent received the article. For security reasons, it injecting agent received the article. For security reasons, it
SHOULD be in a cryptic notation understandable only by the SHOULD be in a cryptic notation understandable only by the
administrator of the injecting agent. administrator of the injecting agent.
The "sender" parameter identifies the mailbox of the verified sender The "sender" parameter identifies the mailbox of the verified sender
of the article (alternatively, it uses the token "verified" to of the article (alternatively, it uses the token "verified" to
indicate that at least any addr-spec in the Sender header of the indicate that at least any addr-spec in the Sender header field of
article, or in the From header if the Sender header is absent, is the article, or in the From header field if the Sender header field
correct). If an injecting agent can verify sender of an article, it is absent, is correct). If an injecting agent can verify sender of
SHOULD use this parameter in favour of the "posting-account" an article, it SHOULD use this parameter in favour of the "posting-
parameter. account" 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 "mail-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 behavior of the poster of the article.
3.3 Obsolete Headers 3.3 Obsolete Header Fields
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 header fields 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
Relay-Version contained version information about the relaying agent Relay-Version contained version information about the relaying agent
that last processed the article. Posting-Version contained version that last processed the article. Posting-Version contained version
information about the posting agent that posted the article. Date- information about the posting agent that posted the article. Date-
Received contained the date when the last relaying agent to process Received contained the date when the last relaying agent to process
the article first saw it (in a slightly nonstandard format). the article first saw it (in a slightly nonstandard format).
In addition, this present standard obsoletes certain headers defined In addition, this present standard obsoletes certain header fields
in [Son-of-1036]: defined in [Son-of-1036]:
Also-Control: cancel <9urrt98y53@site.example> Also-Control: cancel <9urrt98y53@site.example>
See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example> See-Also: <i4g587y@site1.example> <kgb2231+ee@site2.example>
Article-Names: comp.foo:charter Article-Names: comp.foo:charter
Article-Updates: <i4g587y@site1.example> Article-Updates: <i4g587y@site1.example>
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 field. Article-Names indicated some special
of that article in relation to the indicated newsgroup. Article- significance of that article in relation to the indicated newsgroup.
Updates indicated that an earlier article was updated, without at the Article-Updates indicated that an earlier article was updated,
same time being superseded. without at the same time being superseded.
The headers listed above are documented for historical purposes only. The header fields listed above are documented for historical purposes
Articles containing these headers MUST NOT be generated. Persons only. Articles containing these header fields MUST NOT be generated.
writing new agents SHOULD ignore any former meanings of these Persons writing new agents SHOULD ignore any former meanings of these
headers. header fields.
3.3.1 Lines 3.3.1 Lines
The Lines header indicates the number of lines in the body of the The Lines header field indicates the number of lines in the body of
article. the article.
lines = "Lines" ":" SP [FWS] 1*DIGIT [FWS] 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 header fields and the body is not part of the body). The "body" here
the body as found in the posted article as transmitted by the posting is the body as found in the posted article as transmitted by the
agent. posting agent.
Historically, this header was used by the [NNTP] overview extension, Historically, this header field was used by the [NNTP] overview
but its use for this purpose is now deprecated. As a result, this extension, but its use for this purpose is now deprecated. As a
header is to be regarded as obsolescent, and it is likely to be result, this header field is to be regarded as obsolescent, and it is
removed entirely in a future version of this standard. Servers and likely to be removed entirely in a future version of this standard.
clients SHOULD ignore it, and SHOULD NOT generate it. 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 header fields and bodies is
using MIME mechanisms discussed in Section 2.3. Note that the provided using MIME mechanisms discussed in Section 2.3. Note that
generation of internationalized newsgroup names for use in headers is the generation of internationalized newsgroup names for use in header
not addressed in this document. fields is not addressed in this document.
5. Security Considerations 5. Security Considerations
The news article format specified in this document does not provide The 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 [RFC3851] 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 identifiers (Section 3.1.3) in news are required to be Message identifiers (Section 3.1.3) in news are required to be
unique; articles are refused (in server-to-server transfer) if the unique; articles are refused (in server-to-server transfer) if the
identifier has already been seen. So if you can predict the identifier has already been seen. So if you can predict the
identifier of a message, you can preempt it by posting a message identifier of a message, you can preempt it by posting a message
(possibly to a quite different group) with the same message (possibly to a quite different group) with the same message
skipping to change at page 29, line 41 skipping to change at page 29, line 41
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997. Continuations", RFC 2231, November 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002. May 2002.
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
skipping to change at page 30, line 22 skipping to change at page 30, line 29
USENET messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156, Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998. January 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
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.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[Son-of-1036] [Son-of-1036]
Spencer, H., "News Article Format and Transmission", Spencer, H., "News Article Format and Transmission",
June 1994. June 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.
skipping to change at page 33, line 5 skipping to change at page 33, line 5
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, Henry Spencer, Russ Allbery, and Alexey Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey
Melnikov. Melnikov.
Appendix B. Differences from RFC 1036
This appendix contains a list of changes that have been made in the
Netnews Article Format from earlier standards, specifically
[RFC1036].
Appendix C. Differences from RFC 2822
This appendix lists the differences between the syntax allowed by the
Netnews Article Format (this document) as compared to the Internet
Message Format, specifically [RFC2822].
A SP (space) is REQUIRED after the colon (':') following header
field name.
A more restricted syntax of msg-id (to be used by the Message-ID,
References, and Supersedes header fields).
Comments are not allowed in the Message-ID header field.
The CFWS between msg-ids in the References header field is not
optional.
An <unstructured> header field body MUST contain at least one non-
whitespace character (header fields such as Subject can not be
empty).
The <obs-phrase> construct MUST be accepted.
The obsolete timezone "GMT" MUST be accepted in the Date header
field.
The length of a msg-id MUST NOT exceed 250 octets.
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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

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