draft-ietf-usefor-usefor-00.txt   draft-ietf-usefor-usefor-01.txt 
Usenet Format Working Group C. Lindsey Usenet Format Working Group C. Lindsey
Internet-Draft University of Manchester Internet-Draft University of Manchester
Updates: 2822 (if approved) D. Kohn Obsoletes: 1036 (if approved) K. Murchison
Obsoletes: 1036 (if approved) Skymoon Ventures Expires: March 15, 2005 Oceana Matrix Ltd.
Expires: January 9, 2005 K. Murchison D. Kohn
Oceana Matrix Ltd. Skymoon Ventures
July 11, 2004 September 14, 2004
News Article Format News Article Format
draft-ietf-usefor-usefor-00.txt draft-ietf-usefor-usefor-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 9, 2005. This Internet-Draft will expire on March 15, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document defines the format of network news articles. This document specifies the syntax of network news articles in the
context of the "Internet Message Format" (RFC 2822) and "Multipurpose
Internet Mail Extensions (MIME)" (RFC 2045). This document
supersedes RFC 1036, updating it to reflect current practice and
incorporating incremental changes specified in other documents.
Network news articles resemble mail messages but are broadcast to Changes since draft-ietf-usefor-usefor-00
potentially large audiences, using a flooding algorithm that
propagates one copy to each interested host (or group thereof),
typically stores only one copy per host, and does not require any
central administration or systematic registration of interested
users. Network news originated as the medium of communication for
Usenet, circa 1980. Since then Usenet has grown explosively, and
many Internet sites participate in it. In addition, the news
technology is now in widespread use for other purposes, on the
Internet and elsewhere.
This document defines the format of network news articles in the o Rewrote/reorganized Abstract and Introduction.
context of the Internet Message Format, and adds Multipurpose o Added required SP to ABNF of header definitions.
Internet Mail Extensions (MIME) support for multimedia and o Reorganized header sections.
internationalized message bodies. o Compatibility changes based on comments from Charles.
o Added Injection-Date and Injection-Info headers.
Changes since draft-kohn-news-article-03 Changes since draft-ietf-usefor-article-13
o Document is now a work product of USEFOR o The Mail-Copies-To, Posted-And-Mailed and Complaints-To headers
o Added new co-authors have been moved to other documents.
o Added some definitions from draft-ietf-usefor-article-13 o Dropped MIME parameters, as there is no WG consensus (per Chair).
o Removed text that belongs in [usepro]
o Reorganized header sections
o Added Archive and User-Agent headers
o Compatibility changes based on comments from Charles
Issues to be addressed Issues to be addressed
o More detailed discussion of Control header verbs o Decide which definitions should go in this document and in
o Discussion of 78 character limit in headers [USEPRO].
o Discussion of required space after ':' in headers o Decide how much (if any) discussion of Injection-Info content
o Review Message-ID limitations belongs in this document vs. [USEPRO].
o Further discussion of newsgroup name character limits o Do we want to discuss message/partial?
o Investigate using MIME parameters for Archive header o Add appendixes for obsolete headers, changes from RFC 1036 and
o Should we use the User-Agent specification from HTTP? differences from RFC 2822.
o Review of ABNF o Merge more security issues?
o Merge acknowledgments?
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Structure of This Document . . . . . . . . . . . . . . . . 6 1.6 Structure of This Document . . . . . . . . . . . . . . . . 5
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 7 2.2 Header Fields . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Additional MIME Support . . . . . . . . . . . . . . . . . 7 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 8
3. Internet Message Format Headers . . . . . . . . . . . . . . 8 2.4 Additional MIME Support . . . . . . . . . . . . . . . . . 8
3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 8 3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 8 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 9
3.3 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Subject . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 News Headers . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 Date . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5.1 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Message-ID . . . . . . . . . . . . . . . . . . . . . . 10
3.5.2 Path . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 11
3.5.3 Followup-To . . . . . . . . . . . . . . . . . . . . . 11 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.4 Expires . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 12
3.5.5 Control . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 12
3.5.6 Distribution . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 13
3.5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 13
3.5.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.9 Organization . . . . . . . . . . . . . . . . . . . . . 12 3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 14
3.5.11 Supersedes . . . . . . . . . . . . . . . . . . . . . 13 3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 14
3.5.12 Archive . . . . . . . . . . . . . . . . . . . . . . 13 3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.13 User-Agent . . . . . . . . . . . . . . . . . . . . . 13 3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 15
4. Internationalization Considerations . . . . . . . . . . . . 14 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . 15 3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 15
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 16
6.2 Informative References . . . . . . . . . . . . . . . . . . . 16 3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 4. Internationalization Considerations . . . . . . . . . . . . 18
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
6.2 Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . 24
1. Introduction 1. Introduction
1.1 Scope 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" (a subset of the Internet Message Format) retrieving news "articles" (which resemble email messages) and for
and for exchanging them among a readership which is potentially exchanging them amongst a readership which is potentially widely
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 she 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.
This is the first of four documents that obsolete RFC 1036. This 1.2 Scope
document focuses on the syntax and semantics of network news
articles. [usepro] is also a standards-track document, and describes
the protocol issues of network news articles, independent of
transmission protocols such as NNTP [RFC0977] and IMAP [RFC3501]. An
informational document, [useage], describes implementation
recommendations to improve interoperability and usability. The
fourth document, [useint], an experimental standard, specifies
internationalization of message headers.
The predecessor to this document [RFC1036] said that: "In any This document specifies the syntax of network news articles in the
situation where this standard conflicts with the Internet [email context of the "Internet Message Format" [RFC2822] and "Multipurpose
standard, the latter] should be considered correct and this standard Internet Mail Extensions (MIME)" [RFC2045]. This document supersedes
in error." The basic philosophy of this document follows that [RFC1036], updating it to reflect current practice and incorporating
previous convention, so as to standardize news article syntax firmly incremental changes specified in other documents such as
as a subset of the Internet Message Format syntax. Note that this [Son-of-1036].
means that all news articles are suitable for email, but the converse
isn't necessarily true.
In the context of the Internet messaging architecture, different This is the first in a set of documents that obsolete [RFC1036].
protocols (such as IMAP, POP3 [RFC1939], NNTP and SMTP [RFC2821]) are This document focuses on the syntax and semantics of network news
seen as alternative ways of moving around the same content. That articles. [USEPRO] is also a standards-track document, and describes
content is the Internet Message Format as specified by [RFC2822], the protocol issues of network news articles, independent of
including optional enhancements such as MIME [RFC2049]. A user transmission protocols such as NNTP [RFC0977]. An informational
should be able to ingest an article via NNTP, read it via IMAP, document, [USEAGE], describes implementation recommendations to
forward it off to someone else via SMTP and have them read it via improve interoperability and usability.
POP3 all without having to alter the content.
This document uses a cite by reference methodology, rather than This specification is intended as a definition of what article
trying to repeat the contents of other standards, which could content format is to be passed between systems. Though some news
otherwise result in subtle differences and interoperability systems locally store articles in this format (which eliminates the
challenges. Although this document is as a result rather short, it need for translation between formats) and others use formats that
requires complete understanding and implementation of the normative differ from the one specified in this standard, local storage is
references to be compliant. outside of the scope of this standard.
1.2 Requirements Notation 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
This document occasionally uses terms that appear in capital letters.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3 Errata
The RFC Editor makes available errata for RFCs at [errata].
Implementers should review that page for normative references, noting
in particular that errata currently exist for [RFC2046] and
[RFC2231].
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 (specifically <date-time>, [RFC2234] and many constructs defined in [RFC2822]. Section 3.1.4
<mailbox-list>, <obs-zone>, and <unstructured>) defined in [RFC2822]. updates the [RFC2822] definition of <msg-id>.
Section 3.4 updates the [RFC2822] definition of <msg-id>.
1.5 Definitions 1.5 Definitions
An "article" is the unit of news, analogous to an [RFC 2822] An "article" is the unit of news, synonymous with an [RFC2822]
"message". A "proto-article" is one that has not yet been injected "message".
into the news system.
A "message identifier" Section 3.1.4 is a unique identifier for an
article, usually supplied by the "posting agent" which posted it or,
failing that, by the "injecting agent". It distinguishes the article
from every other article ever posted anywhere. Articles with the
same message identifier are treated as if they are the same article
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 "gateway" is software which receives news articles and converts A "control message" is an article which is marked as containing
them to messages of some other kind (e.g. mail to a mailing list), control information; a relaying or serving agent receiving such an
or vice versa; in essence it is a translating relaying agent that article may (subject to the policies observed at that site) take
straddles boundaries between different methods of message exchange. actions beyond just filing and passing on the article.
The most common type of gateway connects newsgroup(s) to mailing
list(s), either unidirectionally or bidirectionally, but there are
also gateways between news networks using this standard's news format
and those using other formats.
1.6 Structure of This Document 1.6 Structure of This Document
Section 2 defines the format of news articles. Section 3 defines This document uses a cite by reference methodology, rather than
some additional headers necessary for the netnews environment. repeating the contents of other standards, which could otherwise
result in subtle differences and interoperability challenges.
Although this document is as a result rather short, it requires
complete understanding and implementation of the normative references
to be compliant.
Section 2 defines the format of news articles. Section 3 details the
headers necessary to make an article suitable for the netnews
environment.
2. Format 2. Format
2.1 Base 2.1 Base
News articles MUST conform to the "legal to generate syntax" News articles MUST conform to the syntax specified in Section 3 of
specified in Section 3 of [RFC2822]. News agents MAY also accept the [RFC2822]. News agents MAY also accept the obsolete syntax specified
obsolete syntax specified in Section 4 of [RFC2822], but they MUST in Section 4 of [RFC2822], but they MUST NOT generate such syntax.
NOT generate such syntax.
2.2 MIME Conformance 2.2 Header Fields
All headers fields in a news article are compliant with [RFC2822],
however this specification is more restrictive 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.
General rules which apply to all headers (even those documented in
[RFC2822] and [RFC2045]) are listed below and those that apply to
specific headers are described in the relevent sections of this
document.
User agents MUST generate headers so that at least one space
immediately follows the ':' separating the header name and the header
contents. As a result, an <unstructured> header as defined in
Section 3.2.6 of [RFC2822] MUST NOT be empty (it will always contain
at least a single space). News agents MAY accept headers which do
not contain the required space.
Compliant software MUST support headers of at least 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).
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
folding, be made to exceed the 998 octets restriction pertaining
to a single header line).
The character set for headers is US-ASCII. Where the use of
non-ASCII characters is required, they MUST be encoded using the MIME
mechanisms defined in [RFC2045] and [RFC2231].
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]. This level of MIME Conformance provides support for [RFC2049]. This level of MIME Conformance provides support for
internationalization and multimedia in message bodies, and support internationalization and multimedia in message bodies [RFC2045], and
for internationalization of headers. Note that the generation of support for internationalization of headers [RFC2047]. Note that
internationalized newsgroup names for use in headers is specified by [Errata] currently exist for [RFC2046] and [RFC2231].
[useint].
2.3 Additional MIME Support 2.4 Additional MIME Support
User agents conformant with this document MAY support receipt (and User agents conformant with this document MAY support reassembly of
automatic reassembly) of message/partial MIME messages, as specified message/partial MIME messages, as specified in Section 5.2.2 of
in Section 5.2.2 of [RFC2046] and MAY support generation of message/ [RFC2046] and MAY support generation of message/partial articles for
partial articles for excessively large articles. excessively large articles.
User agents SHOULD support on receipt and MAY generate MIME extension User agents SHOULD accept and MAY generate MIME extension header
header fields, including but not limited to Content-Disposition fields, including but not limited to Content-Disposition [RFC2183]
[RFC2183] and Content-Language [RFC3282]. and Content-Language [RFC3282].
3. Internet Message Format Headers 3. News Headers
Following [RFC2822] syntax, the headers defined in this document do The following news headers (also known as header fields) extend the
not require a space between the ":" and the field's contents. (E.g., fields defined in section 3.6 of [RFC2822] as follows:
"Subject:Hello World" is acceptable, as opposed to requiring
"Subject: Hello World".) To be compliant with this specification, fields =/ *( newsgroups /
news agents MUST support 0 or more spaces between the colon and the path /
field's contents. However, to maximize compatibility with the injection-date /
installed base of news agents, implementers SHOULD use exactly one followup-to /
space. expires /
control /
supersedes /
distribution /
summary /
approved /
organization /
xref /
archive /
user-agent /
injection-info )
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, Subject, Date,
Message-ID, Newsgroups, and Path. Message-ID, Newsgroups, Path, and Injection-Date.
From and Subject are exactly as specified in Sections 3.6.2 and 3.6.5
respectively of [RFC2822]. Further discussion of the content of the
Subject header is discussed in [usepro] and [useage].
Date is fully conformant with [RFC2822], though with extra
restrictions detailed in Section 3.3
In Section 3.4, this document updates the <msg-id> construct from
[RFC2822] so as to ensure that Internet Message Format Message-IDs
are usable in widely deployed news software.
Newsgroups and Path are defined in Section 3.5.1 and Section 3.5.2 3.1.1 From
respectively.
3.2 Optional Headers 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.
The headers Reply-To, Sender, Comments, and Keywords are often used 3.1.2 Subject
in news articles and have the identical meaning as that specified in
[RFC2822]. References and In-Reply-To are also regularly used in
news articles and have same the same meaning as that specified in
[RFC2822], except that they use the updated <msg-id> construct
defined in Section 3.4.
The headers Followup-To, Expires, Control, Distribution, Summary, The Subject header is the same as that specified in Section 3.6.5 of
Approved, Organization, Xref, Supersedes, Archive, and User-Agent are [RFC2822] with the added restrictions detailed in Section 2.2.
often used in news articles and are defined in Section 3.5. Further discussion of the content of the Subject header is discussed
in [USEPRO] and [USEAGE].
3.3 Date 3.1.3 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]. However, the use of "GMT" as a time zone, which 3.6.1 of [RFC2822] with the added restrictions detailed in Section
is part of <obs-zone>, is widespread in news articles today. 2.2. However, the use of "GMT" and "UT" as time zones, which are
Therefore, agents MUST accept, but MUST NOT generate, <date-time> part of <obs-zone>, is widespread in news articles today. Therefore,
constructs which include <obs-zone>. (As stated in Section 2.1, agents MUST accept, but MUST NOT generate, <date-time> constructs
support for <obs-zone> would otherwise have been SHOULD accept, MUST which include <obs-zone>. As stated in Section 2.1, support for
NOT generate.) Note that these requirements apply wherever <obs-zone> would otherwise have been SHOULD accept, MUST NOT
<date-time> is used, including Expires in Section 3.5.4. 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.4 Message-ID 3.1.4 Message-ID
The "Message-ID:" field contains a single unique message identifier. The Message-ID header contains a single unique message identifier.
This is the only header field definition that updates [RFC2822]. The This document updates the <msg-id> construct from Section 3.6.4 of
ABNF should be used as below, but the requirements and descriptive [RFC2822] so as to ensure that Internet Message Format Message-IDs
text from Section 3.6.4 of [RFC2822] still apply. are usable in widely deployed news software. 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:" msg-id CRLF message-id = "Message-ID:" SP msg-id CRLF
msg-id = [CFWS] msg-id-core [CFWS] 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 / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE
skipping to change at page 9, line 43 skipping to change at page 10, line 44
no-space-qp = ( "\" ptext ) / obs-qp no-space-qp = ( "\" ptext ) / obs-qp
ptext = %d33-61 / ; Printable characters excluding ">" ptext = %d33-61 / ; Printable characters excluding ">"
%d63-126 / %d63-126 /
obs-text obs-text
htext = HEXDIG / ; hexadecimal digits, case-insensitive htext = HEXDIG / ; hexadecimal digits, case-insensitive
"." / ; IPv4 separator "." / ; IPv4 separator
":" ; IPv6 separator ":" ; IPv6 separator
Although compliant agents MUST support [CFWS] between the The msg-id-core MUST NOT be more than 250 octets in length.
"Message-ID:" and the <msg-id-core>, implementers SHOULD generate
exactly one space there, to maximize compatibility with the installed
base.
Note that this updated ABNF applies wherever <msg-id> is used,
including the In-Reply-To and References headers mentioned in Section
3.2.
3.5 News Headers
The following news headers (also known as header fields) extend the NOTE: The length restriction ensures that systems which accept
fields defined in section 3.6 of [RFC2822] as follows: message identifiers as a parameter when retrieving an article
(e.g. NNTP [RFC0977]) can rely on a bounded length. Observe that
msg-id-core includes the < and >.
fields =/ *( newsgroups / Observe that in contrast to the corresponding header in [RFC2822],
path / the syntax does not allow comments within the Message-ID header; this
followup-to / is to simplify processing by relaying and serving agents and to
expires / ensure interoperability with existing implementations.
control /
distribution /
summary /
approved /
organization /
xref /
supersedes /
archive /
user-agent )
Each of these headers may occur at most once in a news article. Also note that this updated ABNF applies wherever <msg-id> is used,
including the References header discussed in Section 3.2.1.
3.5.1 Newsgroups 3.1.5 Newsgroups
The Newsgroups header specifies to which newsgroup(s) the article is The Newsgroups header specifies the newsgroup(s) to which the article
posted. is posted.
newsgroups = "Newsgroups:" newsgroup-list CRLF newsgroups = "Newsgroups:" SP newsgroup-list CRLF
newsgroup-list = [FWS] newsgroup-name newsgroup-list = [FWS] newsgroup-name
*( "," [FWS] newsgroup-name ) [FWS] *( "," [FWS] newsgroup-name ) [FWS]
newsgroup-name = component *( "." component ) ; 71 character max newsgroup-name = component *( "." component ) ; 66 character max
component = plain-component component = plain-component
plain-component = component-start *29component-rest plain-component = component-start *29component-rest
component-start = ALPHA / DIGIT component-start = ALPHA / DIGIT
component-rest = ALPHA / DIGIT / "+" / "-" / "_" component-rest = ALPHA / DIGIT / "+" / "-" / "_"
A newsgroup name consists of one or more components separated by A newsgroup name consists of one or more components separated by
periods, with no more than 71 characters total. Each component periods, with no more than 66 characters total. Each component
consists of less than 30 or less letters and digits. consists of less than 30 or less letters and digits. These limits
are discussed further in Section 7.2 of [USEAGE].
3.5.2 Path 3.1.6 Path
The Path header's content indicates which relayers the article has The Path header indicates the route taken by an article since its
already visited, so that unnecessary redundant transmission can be entry into the Netnews system, so that unnecessary redundant
avoided. transmission can be avoided.
path = "Path:" [FWS] path = "Path:" SP path-list CRLF
*( path-host [FWS] path-delimiter [FWS] )
path-host [FWS] CRLF
path-host = ( ALPHA / DIGIT ) path-list = [FWS] path-identity
*( path-delimiter [FWS] path-identity ) [FWS]
path-identity = ( ALPHA / DIGIT )
*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
path-delimiter = "!" path-delimiter = "!"
3.5.3 Followup-To 3.1.7 Injection-Date
The Injection-Date header contains the date and time that the article
was injected into the network. Its purpose is to prevent the
reinjection into the news stream of "stale" articles which have
already expired by the time they arrive at some relaying or serving
agent.
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
See the remarks under Section 3.1.3 regarding the syntax of
date-time and the requirements and recommendations to which it is
subject.
NOTE: The date-time in this header would normally be expected to
be later than the date-time in the Date header, but differences
between the clocks on the various agents and other special
circumstances might vitiate that; no provision is made for any
such discrepancy to be corrected - better that the injecting agent
should just insert the correct time as it sees it.
This header is intended to replace the currently-used but
undocumented "NNTP-Posting-Date" header, whose use is now deprecated.
3.2 Optional Headers
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
article, such as followups. Further discussion of these requirements
is discussed in [USEPRO] and [USEAGE].
The headers Reply-To, Sender, Comments, and Keywords are often used
in news articles and have the identical meaning as that specified in
[RFC2822] with the added restrictions detailed in Section 2.2.
The MIME headers Content-Type and Content-Transfer-Encoding are often
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.
3.2.1 References
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
those listed below:
o The updated <msg-id> construct defined in Section 3.1.4 MUST be
used.
o Message IDs MUST be separated with CFWS.
o Comments in CFWS between Message IDs can cause interoperability
problems, so comments SHOULD NOT be generated, but MUST be
accepted.
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.
followup-to = "Followup-To:" ( 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 content, with the The syntax is the same as that of the Newsgroups header (Section
exception that the magic word "poster" (which is always lowercase) 3.1.5, with the exception that the magic word "poster" (which is
means that followups should be mailed to the article's reply address always lowercase) means that followups should be mailed to the
rather than posted. article's reply address rather than posted. In order to improve
interoperability with deployed clients, followup agents MAY choose to
recognize case-insensitive forms such as "Poster".
3.5.4 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 useful and could usefully be removed
("expired"). ("expired").
expires = "Expires:" date-time CRLF expires = "Expires:" SP date-time CRLF
3.5.5 Control See the remarks under Section 3.1.3 regarding the syntax of
date-time and the requirements and recommendations to which it is
subject.
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). The verb indicates what action storing and/or relaying the article).
should be taken, and the argument(s) (if any) supply details. In
some cases, the body of the article may also contain details.
Control messages are further specified in the companion document,
[usepro].
control = "Control:" verb *( FWS argument ) CRLF control = "Control:" SP [CFWS] control-message [CFWS] CRLF
An article with a Control header MUST NOT have a Supersedes header. control-message = <empty>
3.5.6 Distribution The control-message indicates what action should be taken. The exact
syntax for control-message is specified in the companion document,
[USEPRO].
3.2.5 Supersedes
The Supersedes header contains a message identifier specifying an
article to be superseded upon the arrival of this one. The specified
article MUST be treated as though a "cancel" [USEPRO] control message
had arrived for the article (but observe that a site MAY choose not
to honor a "cancel" message, especially if its authenticity is in
doubt).
supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF
NOTE: There is no "c" in Supersedes.
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:" dist-name *( "," dist-name ) CRLF distribution = "Distribution:" SP dist-list CRLF
dist-name = [FWS] ALPHA / DIGIT list-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS]
*( ALPHA / DIGIT / "+" / "-" / "_" ) [FWS]
dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" )
"All" MUST NOT be used as a distribution-name. Distribution-names "All" MUST NOT be used as a distribution-name. Distribution-names
SHOULD contain at least three characters, except when they are SHOULD contain at least three characters, except when they are
two-letter country names as in [ISO.3166.1988]. Distribution-names two-letter country names as in [ISO.3166.1988]. Distribution-names
are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify
the same distribution). the same distribution).
3.5.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:" unstructured CRLF summary = "Summary:" SP unstructured CRLF
3.5.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 moderators approving the article for posting.
approved = "Approved:" mailbox-list CRLF approved = "Approved:" SP mailbox-list CRLF
3.5.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:" unstructured CRLF organization = "Organization:" SP unstructured CRLF
There is no "s" in Organization. There is no "s" in Organization.
3.5.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
server to process it. serving agent to process it.
xref = "Xref:" [CFWS] path-host xref = "Xref:" SP [CFWS] server-name
1*( CFWS location ) CRLF 1*( CFWS location ) [CFWS] CRLF
location = newsgroup-name ":" 1*16DIGIT server-name = path-identity
3.5.11 Supersedes location = newsgroup-name ":" article-locator
The Supersedes header specifies articles to be cancelled. article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters
; except '(' and ';'
supersedes = "Supersedes:" 1*( [FWS] msg-id-core ) CRLF The server-name is included so that software can determine which
serving agent generated the header. The locations specify what
newsgroups the article was filed under (which may differ from those
in the Newsgroups-header) and where it was filed under them. The
exact form of an article-locator is implementation-specific.
There is no "c" in Supersedes. NOTE: The traditional form of an article-locator (as used by NNTP) is
a decimal number, with articles in each newsgroup numbered
consecutively starting from 1.
3.5.12 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:" [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 = <a parameter with attribute "filename"
and any value> and any value>
3.5.13 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. Although not one of the mandatory headers,
posting agents SHOULD normally include it. It is also intended that posting agents SHOULD normally include it. It is also intended that
this header be suitable for use in Email. this header be suitable for use in Email.
user-agent = "User-Agent:" user-agent = "User-Agent:" SP 1*product CRLF
1*( [CFWS] product [ "/" prod-version ] ) CRLF
product = token product = [CFWS] token [CFWS] [ "/" product-version ]
prod-version = token
product-version = [CFWS] token [CFWS]
3.2.13 Injection-Info
The Injection-Info header provides information as to how an article
entered the Netnews system and to assist in tracing its true origin.
injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS]
*( ";" injection-info-parameter )
injection-info-parameter
= posting-host-parameter /
posting-account-parameter /
posting-sender-parameter /
posting-logging-parameter
posting-host-parameter
= <a parameter with attribute "posting-host"
and value some host-value>
host-value = dot-atom / [ dot-atom ":" ]
( IPv4address / IPv6address ) ; see [RFC 2373]
posting-account-parameter
= <a parameter with attribute "posting-account"
and any value>
posting-sender-parameter
= <a parameter with attribute "sender"
and value some sender-value>
sender-value = mailbox / "verified"
posting-logging-parameter
= <a parameter with attribute "logging-data"
and any value>
Although comments and folding of white space are permitted throughout
the Injection-Info header, it is RECOMMENDED that folding is not used
within any parameter (but only before or after the ";" separating
those parameters), and that comments are only used following the last
parameter. It is also RECOMMENDED that such parameters as are
present are included in the order in which they have been defined in
the syntax above.
This header is intended to replace various currently-used but
undocumented headers such as "NNTP-Posting-Host" and "X-Trace".
These headers are now deprecated.
4. Internationalization Considerations 4. Internationalization Considerations
Internationalization of news article bodies is provided using MIME Internationalization of news article headers and bodies is provided
mechanisms in Section 2.2. Generation of internationalized message using MIME mechanisms discussed in Section 2.3. Note that the
headers is not specified in this document, and is instead specified generation of internationalized newsgroup names for use in headers is
in the experimental standard, [useint]. 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-forgery. Instead, such services need to be layered sender, or non-repudiation. Instead, such services need to be
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 (see Section 3.4) in news are required to be unique; Message-IDs (Section 3.1.4) 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
used to attempt to store archived articles in inappropriate
locations. Archiving sites should be suspicious of absolute filename
parameters, as opposed to those relative to some location of the
archiver's choosing.
6. References 6. References
6.1 Normative References 6.1 Normative References
[Errata] "RFC Editor Errata".
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996. Examples", RFC 2049, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S. and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S. and K. Moore, "Communicating
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. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2646] Gellens, R., "The Text/Plain Format Parameter", RFC 2646,
August 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001. 2001.
[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.
[PGPVERIFY] [PGPVERIFY]
Lawrence, D., "PGPverify Lawrence, D., "PGPverify", June 1999.
<ftp://ftp.isc.org/pub/pgpcontrol/README.html>", June
1999.
[RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer [RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986. 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.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[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.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[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.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [Son-of-1036]
4rev1", RFC 3501, March 2003. Spencer, H., "News Article Format and Transmission", June
1994.
[errata] "RFC Editor Errata
<http://www.rfc-editor.org/errata.html>".
[useage] "Usenet Implementation Recommendations (work in
progress)".
[useint] "Usenet Internationalization (work in progress)". [USEAGE] Lindsey, C., "Usenet Best Practice",
draft-ietf-usefor-useage-*.txt.
[usepro] "Usenet Protocol (work in progress)". [USEPRO] Lindsey, C., "News Article Architecture and Protocols",
draft-ietf-usefor-usepro-*.txt.
Authors' Addresses Authors' Addresses
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
Dan Kohn
Skymoon Ventures
3045 Park Boulevard
Palo Alto, CA 94306
US
Phone: +1 650 327 2600
EMail: dan@dankohn.com
Kenneth Murchison Kenneth Murchison
Oceana Matrix Ltd. Oceana Matrix Ltd.
21 Princeton Place 21 Princeton Place
Orchard Park, NY 14127 Orchard Park, NY 14127
US US
Phone: +1 716 662 8973 Phone: +1 716 662 8973
EMail: ken@oceana.com EMail: ken@oceana.com
Dan Kohn
Skymoon Ventures
3045 Park Boulevard
Palo Alto, CA 94306
US
Phone: +1 650 327 2600
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, and Henry Spencer.
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
 End of changes. 

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