draft-ietf-usefor-useage-00.txt   draft-ietf-usefor-useage-01.txt 
INTERNET-DRAFT Charles H. Lindsey INTERNET-DRAFT Charles H. Lindsey
Usenet Format Working Group University of Manchester Usenet Format Working Group University of Manchester
May 2004 March 2005
Usenet Best Practice Usenet Best Practice
<draft-ietf-usefor-useage-00.txt> <draft-ietf-usefor-useage-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC 2026. patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware
will be disclosed, in accordance with 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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.html.
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 in September 2005.
Abstract Abstract
This Draft is intended to become a "Best Current Practice" RFC. This Draft is intended to become a "Best Current Practice" RFC.
Its purpose is to set out how software should behave and Its purpose is to set out how software should behave and
conventions which users should observe, in order that Netnews in conventions which users should observe, in order that Netnews in
general, and Usenet in particular, should provide the most general, and Usenet in particular, should provide the most
effective service to its users. effective service to its users.
[Remarks enclosed in square brackets and aligned with the left margin, [Remarks enclosed in square brackets and aligned with the left margin,
such as this one, are not part of this draft, but are editorial notes to such as this one, are not part of this draft, but are editorial notes to
explain matters amongst ourselves, or to point out alternatives, or to explain matters amongst ourselves, or to point out alternatives, or to
assist the RFC Editor.] assist the RFC Editor.]
[In this draft, references to [NNTP] are to be replaced by [RFC 977], or [In this draft, references to [NNTP] are to be replaced by [RFC 977], or
else by references to the RFC arising from the series of drafts draft- else by references to the RFC arising from the series of drafts draft-
ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at
the time this document is published.] the time this document is published.
Usenet Best Practice March 2005
Table of Contents Table of Contents
1. Introduction .................................................. 4 1. Introduction .................................................. 4
1.1. Basic Concepts ............................................ 4 1.1. Basic Concepts ............................................ 4
1.2. Objectives ................................................ 4 1.2. Objectives ................................................ 4
2. Definitions, Notations and Conventions ........................ 5 2. Definitions, Notations and Conventions ........................ 5
Usenet Best Practice May 2004
2.1. Definitions ............................................... 5 2.1. Definitions ............................................... 5
2.2. Textual Notations ......................................... 5 2.2. Textual Notations ......................................... 5
3. The Well-Behaved User Agent ................................... 6 3. The Well-Behaved User Agent ................................... 6
3.1. The Well-Behaved Posting Agent ............................ 6 3.1. The Well-Behaved Posting Agent ............................ 6
3.1.1. Construction of Headers ............................... 7 3.1.1. Construction of Headers ............................... 7
3.1.1.1. Date .............................................. 8 3.1.1.1. Date .............................................. 8
3.1.1.2. From .............................................. 8 3.1.1.2. From .............................................. 8
3.1.1.3. Message-ID ........................................ 8 3.1.1.3. Message-ID ........................................ 9
3.1.1.4. Subject ........................................... 9 3.1.1.4. Subject ........................................... 9
3.1.1.5. Newsgroups ........................................ 9 3.1.1.5. Newsgroups ........................................ 10
3.1.1.6. Reply-To .......................................... 10 3.1.1.6. Reply-To .......................................... 10
3.1.1.7. Organization ...................................... 10 3.1.1.7. Organization ...................................... 10
3.1.1.8. Distribution ...................................... 10 3.1.1.8. Distribution ...................................... 10
3.1.1.9. Followup-To ....................................... 10 3.1.1.9. Followup-To ....................................... 10
3.1.1.10. User-Agent ....................................... 10 3.1.1.10. User-Agent ....................................... 10
3.1.2. Construction of Bodies ................................ 10 3.1.2. Construction of Bodies ................................ 11
3.1.2.1. Signatures ........................................ 11 3.1.2.1. Signatures ........................................ 11
3.1.2.2. Usage of MIME ..................................... 11 3.1.2.2. Usage of MIME ..................................... 12
3.1.2.3. Content-Transfer-Encoding ......................... 13 3.1.2.3. Content-Transfer-Encoding ......................... 13
3.2. The Well-Behaved Followup Agent ........................... 14 3.2. The Well-Behaved Followup Agent ........................... 15
3.2.1. Construction of Headers ............................... 15 3.2.1. Construction of Headers ............................... 15
3.2.1.1. Subject ........................................... 15 3.2.1.1. Subject ........................................... 15
3.2.1.1.1. Examples ...................................... 16 3.2.1.1.1. Examples ...................................... 17
3.2.1.2. Newsgroups ........................................ 16 3.2.1.2. Newsgroups ........................................ 17
3.2.1.3. Mail-Copies-To .................................... 16 3.2.1.3. Mail-Copies-To .................................... 17
3.2.1.4. Posted-And-Mailed ................................. 17 3.2.1.4. References ........................................ 18
3.2.1.5. References ........................................ 17 3.2.2. Construction of Bodies ................................ 18
3.2.2. Construction of Bodies ................................ 17 3.2.2.1. Quoting and Attributions .......................... 18
3.2.2.1. Quoting and Attributions .......................... 17 3.2.2.2. Signatures ........................................ 20
3.2.2.2. Signatures ........................................ 19 3.2.2.3. Usage of MIME ..................................... 20
3.2.2.3. Usage of MIME ..................................... 19 3.3. The Well-Behaved Reading Agent ............................ 20
3.3. The Well-Behaved Reading Agent ............................ 19 3.3.1. Display of Headers .................................... 20
3.3.1. Interpretation of Headers ............................. 19 3.3.2. Presentation of Articles .............................. 21
3.3.1.1. Presentation of Articles .......................... 19 3.3.2.1. Threading ......................................... 21
3.3.1.2. Summary ........................................... 21 3.3.2.2. Killfiles ......................................... 23
3.3.2. Interpretation of Bodies .............................. 21 3.3.2.3. Interpretation of Distributions ................... 23
3.3.2.1. Usage of MIME ..................................... 22 3.3.3. Interpretation of Bodies .............................. 23
3.4. The Well-Behaved Reply Agent .............................. 23 3.3.3.1. Usage of MIME ..................................... 24
3.5. User Interfaces ........................................... 23 3.4. The Well-Behaved Reply Agent .............................. 25
4. The Well-Behaved Injecting Agent .............................. 23 3.5. User Interfaces ........................................... 25
4.1. Construction of Headers ................................... 24 4. The Well-Behaved Injecting Agent .............................. 26
4.1.1. Sender ................................................ 24 4.1. Construction of Headers ................................... 27
4.1.2. Organization .......................................... 24 4.1.1. Sender ................................................ 27
4.1.3. User-Agent ............................................ 24 4.1.2. Organization .......................................... 27
4.1.4. Injection-Info ........................................ 25 4.1.3. User-Agent ............................................ 27
5. The Well-Behaved Relaying Agent ............................... 25 4.1.4. Injection-Info ........................................ 28
5.1. The Path Header ........................................... 26
5.1.1. Suggested Verification Methods ........................ 26
6. The Well-Behaved Serving Agent ................................ 26
6.1. Control Messages .......................................... 27
6.1.1. The 'newgroup' and 'mvgroup' Control Messages ......... 27
6.1.2. Cancel Messages ....................................... 27
7. The Well-Behaved Hierarchy Administrator ...................... 28
7.1. Control Messages .......................................... 28
Usenet Best Practice May 2004
7.2. Naming of Newsgroups ...................................... 28 Usenet Best Practice March 2005
7.3. Format of Bodies .......................................... 30
7.4. Promulgation .............................................. 30 5. The Well-Behaved Relaying Agent ............................... 28
8. The Well-Behaved Moderator .................................... 31 5.1. The Path Header ........................................... 29
9. The Well-Behaved Poster ....................................... 31 5.1.1. Suggested Verification Methods ........................ 29
9.1. Construction of Headers ................................... 31 6. The Well-Behaved Serving Agent ................................ 30
9.1.1. From .................................................. 31 6.1. Control Messages .......................................... 30
9.1.2. Summary ............................................... 31 6.1.1. The 'newgroup' and 'mvgroup' Control Messages ......... 30
9.1.3. Expires ............................................... 32 6.1.2. Cancel Messages ....................................... 30
9.2. Construction of Bodies .................................... 32 7. The Well-Behaved Hierarchy Administrator ...................... 31
10. References ................................................... 32 7.1. Control Messages .......................................... 31
11. Acknowledgements ............................................. 34 7.2. Naming of Newsgroups ...................................... 32
12. Contact Address .............................................. 34 7.3. Format of Bodies .......................................... 33
Appendix A - Notices .............................................. 34 7.4. Promulgation .............................................. 34
Usenet Best Practice May 2004 8. The Well-Behaved Moderator .................................... 34
9. The Well-Behaved Poster ....................................... 34
9.1. Construction of Headers ................................... 34
9.1.1. From .................................................. 35
9.1.2. Summary ............................................... 35
9.1.3. Expires ............................................... 35
9.2. Construction of Bodies .................................... 35
10. References ................................................... 36
11. Acknowledgements ............................................. 37
12. Contact Address .............................................. 37
Appendix A - Notices .............................................. 38
Usenet Best Practice March 2005
1. Introduction 1. Introduction
1.1. Basic Concepts 1.1. Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing and
retrieving news "articles" (which resemble email messages) and for retrieving news "articles" (which resemble email messages) and for
exchanging them amongst a readership which is potentially widely exchanging them amongst a readership which is potentially widely
distributed. It is organized around "newsgroups", with the distributed. It is organized around "newsgroups", with the
expectation that each reader will be able to see all articles posted expectation that each reader will be able to see all articles posted
to each newsgroup in which he participates. These protocols are to each newsgroup in which he participates. The syntax of such
defined in [USEFOR]. articles is defined in [USEFOR] and the actual protocols in [USEPRO].
"Usenet" is a particular worldwide open network based upon the "Usenet" is a particular worldwide open network based upon the
Netnews protocols, with the newsgroups being organized into Netnews protocols, with the newsgroups being organized into
recognized "hierarchies". Anybody can join (it is simply necessary recognized "hierarchies". Anybody can join (it is simply necessary
to negotiate an exchange of articles with one or more other to negotiate an exchange of articles with one or more other
participating hosts). participating hosts).
Usenet "belongs" to those who administer the hosts of which it is Usenet "belongs" to those who administer the hosts of which it is
comprised. There is no Cabal with overall authority to direct what is comprised. There is no Cabal with overall authority to direct what is
to be be allowed. Nevertheless, there do exist agencies within Usenet to be be allowed. Nevertheless, there do exist agencies within Usenet
skipping to change at page 4, line 50 skipping to change at page 4, line 51
in breach of established policy can cause considerable annoyance to in breach of established policy can cause considerable annoyance to
their recipients. their recipients.
1.2. Objectives 1.2. Objectives
The purpose of this document is to set out how software should behave The purpose of this document is to set out how software should behave
and conventions which users should observe, in order that Netnews in and conventions which users should observe, in order that Netnews in
general, and Usenet in particular, should provide the most effective general, and Usenet in particular, should provide the most effective
service to its users. service to its users.
[USEFOR] is a standard, and hence its requirements are mandatory. The [USEFOR] and [USEPRO] are standards, and hence their requirements are
requirements set out here are in addition to the requirements set out mandatory. The requirements set out here are in addition to those.
in [USEFOR]. Their purpose is to establish "Best Current Practice", Their purpose is to establish "Best Current Practice", and hence they
and hence they are advisory. Nevertheless, failure to observe them are advisory. Nevertheless, failure to observe them will severely
will severely prejudice the good order of Usenet, and cause great prejudice the good order of Usenet, and cause great inconvenience to
inconvenience to the users of that medium. the users of that medium.
NOTE: The extreme irritation caused to other readers by such NOTE: The extreme irritation caused to other readers by such
violations is not to be underestimated; however, enforcement of violations is not to be underestimated; however, enforcement of
such rules is more a matter of sensible design or of social such rules is more a matter of sensible design or of social
Usenet Best Practice May 2004
Usenet Best Practice March 2005
pressure (whose effectiveness should not be underestimated, even pressure (whose effectiveness should not be underestimated, even
though it cannot be prescribed). though it cannot be prescribed).
Many of these requirements are matters of policy which may vary from Many of these requirements are matters of policy which may vary from
network to network, from hierarchy to hierarchy within one network, network to network, from hierarchy to hierarchy within one network,
and even between individual newsgroups within one hierarchy. It is and even between individual newsgroups within one hierarchy. It is
assumed, for the purposes of this document, that agencies with assumed, for the purposes of this document, that agencies with
varying degrees of authority to establish such policies will exist, varying degrees of authority to establish such policies will exist,
and that where they do not, policy will be established by mutual and that where they do not, policy will be established by mutual
skipping to change at page 5, line 33 skipping to change at page 5, line 34
NOTE: The practices recommended here relate only to Netnews and NOTE: The practices recommended here relate only to Netnews and
Usenet, and not to any other medium. Nevertheless, it may be Usenet, and not to any other medium. Nevertheless, it may be
that some of them may turn out to be helpful for other media that some of them may turn out to be helpful for other media
such as mailing lists. such as mailing lists.
2. Definitions, Notations and Conventions 2. Definitions, Notations and Conventions
2.1. Definitions 2.1. Definitions
All the technical terms defined in [USEFOR] section 2.1 are All the technical terms defined in F-1.5 and P-2.1 are considered to
considered to be defined in this document also. be defined in this document also.
2.2. Textual Notations 2.2. Textual Notations
In this document, references to sections in [USEFOR] are prefixed
with "F-" and references to sections in [USEPRO] are prefixed with
"P-".
This document contains explanatory NOTEs using the following format. This document contains explanatory NOTEs using the following format.
These may be skipped by persons interested solely in the content of These may be skipped by persons interested solely in the content of
the specification. The purpose of the notes is to explain why choices the specification. The purpose of the notes is to explain why choices
were made, to place them in context, or to suggest possible were made, to place them in context, or to suggest possible
implementation techniques. implementation techniques.
NOTE: While such explanatory notes may seem superfluous in NOTE: While such explanatory notes may seem superfluous in
principle, they often help the less-than-omniscient reader principle, they often help the less-than-omniscient reader
understand the true intent of the specification in cases where understand the true intent of the specification in cases where
the wording is not entirely clear. the wording is not entirely clear.
Certain words, when capitalized, are used to define the significance Certain words, when capitalized, are used to define the significance
of individual requirements. The key words "MUST", "REQUIRED", of individual requirements. The key words "MUST", "REQUIRED",
"SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words
associated with the word "NOT", are to be interpreted as described in associated with the word "NOT", are to be interpreted as described in
[RFC 2119]. [RFC 2119].
Usenet Best Practice March 2005
However, as provided in that RFC, the force of these words is lower However, as provided in that RFC, the force of these words is lower
here than would have been the case in a standards track document. In here than would have been the case in a standards track document. In
particular, violation of a MUST or SHOULD does not necessarily imply particular, violation of a MUST or SHOULD does not necessarily imply
a failure of interoperability, but rather that established policy or a failure of interoperability, but rather that established policy or
accepted best practice would be breached, to the detriment of the accepted best practice would be breached, to the detriment of the
Usenet Best Practice May 2004
good order of Usenet. good order of Usenet.
NOTE: A requirement imposed on a relaying or serving agent NOTE: A requirement imposed on a relaying or serving agent
regarding some particular article should be understood as regarding some particular article should be understood as
applying only if that article is actually accepted for applying only if that article is actually accepted for
processing (since any agent may always reject any article processing (since any agent may always reject any article
entirely, for reasons of site policy). entirely, for reasons of site policy).
[That NOTE can probably be removed, or severely rewritten, once we have [That NOTE can probably be removed, or severely rewritten, once we have
a better idea of the requirements/recommendations we are going to make a better idea of the requirements/recommendations we are going to make
in this document.] in this document.]
skipping to change at page 6, line 30 skipping to change at page 6, line 36
Throughout this document we will give various examples. In order to Throughout this document we will give various examples. In order to
prevent possible conflict with "Real World" entities and people the prevent possible conflict with "Real World" entities and people the
top level domain ".example" is used in all sample domains and top level domain ".example" is used in all sample domains and
addresses. The hierarchy "example.*" is also used as a sample addresses. The hierarchy "example.*" is also used as a sample
hierarchy. Information on the ".example" top level domain is in [RFC hierarchy. Information on the ".example" top level domain is in [RFC
2606]. 2606].
3. The Well-Behaved User Agent 3. The Well-Behaved User Agent
The term "user agent" comprises posting agents, reading agents and The term "user agent" comprises posting agents, reading agents and
followup agents as defined in [USEFOR], and also reply agents, by followup agents as defined in [USEPRO], and also reply agents, by
which is meant a user agent that is generating an email, presumably which is meant a user agent that is generating an email, presumably
addressed to the poster of an article. Although it is usual for all addressed to the poster of an article. Although it is usual for all
these functionalities to be included within a single piece of these functionalities to be included within a single piece of
software, it is convenient to discuss them separately here. software, it is convenient to discuss them separately here.
This section is addressed primarily to the implementors of user This section is addressed primarily to the implementors of user
agents. Whilst it is common for such agents to combine the functions agents. Whilst it is common for such agents to combine the functions
of a Netnews User Agent (NUA) and a Mail User Agent (MUA), it needs of a Netnews User Agent (NUA) and a Mail User Agent (MUA), it needs
to be realized that they serve different functions, and adding a few to be realized that they serve different functions, and adding a few
extra features to an MUA is unlikely to result in a good NUA, any extra features to an MUA is unlikely to result in a good NUA, any
skipping to change at page 6, line 55 skipping to change at page 7, line 4
The implementor of a posting agent SHOULD make it possible for a The implementor of a posting agent SHOULD make it possible for a
suitably perseverent poster to generate any article, however absurd, suitably perseverent poster to generate any article, however absurd,
that conforms strictly to [USEFOR]. On the other hand, it needs to that conforms strictly to [USEFOR]. On the other hand, it needs to
be understood that the difference between a good posting agent and a be understood that the difference between a good posting agent and a
bad posting agent lies in its ability to encourage the poster to bad posting agent lies in its ability to encourage the poster to
adhere to good standards of "netkeeping", by making it easy to adhere to good standards of "netkeeping", by making it easy to
generate articles that will be widely acceptable to the conventions generate articles that will be widely acceptable to the conventions
and expectations of the Usenet community, and hard to generate and expectations of the Usenet community, and hard to generate
articles outside of those norms. This is largely a matter of choosing articles outside of those norms. This is largely a matter of choosing
Usenet Best Practice March 2005
appropriate defaults for various parameters and settings. appropriate defaults for various parameters and settings.
Here it shold be noted that what is acceptable in Email (which is a Here it shold be noted that what is acceptable in Email (which is a
one-to-few communication where the author can be expected to be aware one-to-few communication where the author can be expected to be aware
of the capabilities and preferences of his correspondents) may not be of the capabilities and preferences of his correspondents) may not be
Usenet Best Practice May 2004
acceptable in Netnews (which is a one-to-many communication directed acceptable in Netnews (which is a one-to-many communication directed
at an unseen and unknown audience). Much grief has arisen in the at an unseen and unknown audience). Much grief has arisen in the
past from poorly designed agents which tried to imppose onto Usenet past from poorly designed agents which tried to imppose onto Usenet
defaults and practices which were perfectly appropriate for Email. defaults and practices which were perfectly appropriate for Email.
3.1.1. Construction of Headers 3.1.1. Construction of Headers
Whilst it SHOULD be possible to insert any legitimate header, not Whilst it SHOULD be possible to insert any legitimate header, not
limited to those defined in [USEFOR] and including experimental limited to those defined in [USEFOR] and including experimental
headers, there are certain essential headers, namely the Subject-, headers, there are certain essential headers, namely the Subject,
Newsgroups-, Followup-To- and Reply-To-headers which the poster MUST Newsgroups, Followup-To and Reply-To headers which the poster MUST be
be able to insert and/or edit (and to do so at any stage during the able to insert and/or edit (and to do so at any stage during the
composition of the article). Note that this specifically includes the composition of the article). Note that this specifically includes the
possibility of setting the followup to "poster". possibility of setting the followup to "poster".
[s/experimental headers/X-headers/ if the term is not defined in
USEFOR.]
NOTE: This does not mean that header must be presented for
editing in the exact form specified in [USEFOR]; a graphical
interface for editing the various header contents would suffice,
although it would be useful if that included the facility for
the poster to determine the folding.
Posting agents SHOULD permit the poster to include headers of Posting agents SHOULD permit the poster to include headers of
arbitrary length (and MUST permit at least 79 characters). However, arbitrary length (and MUST permit at least 79 characters). However,
they SHOULD endeavour to keep individual header lines, so far as is they SHOULD endeavour to keep individual header lines, so far as is
possible, within 79 characters (or other established policy limit) by possible, within 79 characters (or other established policy limit) by
folding them at suitable places (however, the limit of 998 octets folding them at suitable places (however, the limit of 998 octets
([USEFOR] 4.5) on any individual header line still applies); but if [RFC 2822]) on any individual header line still applies); but if the
the poster has manually folded a header within the accepted limits poster has manually folded a header within the accepted limits (to
(to achieve some pleasing layout, for example) the posting agent achieve some pleasing layout, for example) the posting agent SHOULD
SHOULD respect the poster's intent. respect the poster's intent.
Although header-contents are defined in such a way that folding NOTE: The reason for the figure 79 is to ensure that all lines
([USEFOR] 4.2.3) can take place between many of the lexical tokens will fit in a standard 80-column screen without having to be
(and even within some of them), folding SHOULD be limited to placing wrapped. The limit is 79 not 80 because, while 80 fit on a
the CRLF at higher-level syntactic breaks, and SHOULD also avoid line, any character in the last column often forces a line-wrap.
leaving trailing WSP on the preceding line. For instance, if a
header-content is defined as comma-separated values, it is Although headers are defined in such a way that folding can take
RECOMMENDED that folding occur after the comma separating the values, place between many of the lexical tokens (and even within some of
even if it is allowed elsewhere. them), [RFC 2822] RECOMMENDS that folding be limited to placing the
CRLF at higher-level syntactic breaks and that, if a header content
is defined as comma-separated values, folding occur after the comma
separating the values, even if it is allowed elsewhere. It SHOULD
also avoid leaving trailing WSP on the preceding line.
There is a preferred case convention, which posters and posting There is a preferred case convention, which posters and posting
agents SHOULD use: each hyphen-separated "word" has its initial agents SHOULD use: each hyphen-separated "word" has its initial
letter (if any) in uppercase and the rest in lowercase, except that letter (if any) in uppercase and the rest in lowercase, except that
Usenet Best Practice March 2005
some abbreviations have all letters uppercase (e.g. "Message-ID" and some abbreviations have all letters uppercase (e.g. "Message-ID" and
"MIME-Version"). The forms given in the various rules defining "MIME-Version").
headers in [USEFOR] show the preferred forms (but relaying and [If USEFOR follows this, then add "The forms given in the various rules
defining headers in [USEFOR] show the preferred forms (but relaying and
reading agents are expected to tolerate articles not obeying this reading agents are expected to tolerate articles not obeying this
convention). convention)."]
A comment ([USEFOR] 4.2.4) is normally used to provide some human A comment [RFC 2822]) is normally used to provide some human readable
readable informational text, except at the end of a mailbox which informational text, except at the end of a mailbox which contains no
contains no phrase, as in phrase, as in
fred@foo.bar.example (Fred Bloggs) fred@foo.bar.example (Fred Bloggs)
as opposed to as opposed to
"Fred Bloggs" <fred@foo.bar.example> . "Fred Bloggs" <fred@foo.bar.example> .
The former is a deprecated, but commonly encountered, usage for The former is a deprecated, but commonly encountered, usage for
indicating the name of the person whose mailbox it is. Posting agents indicating the name of the person whose mailbox it is. Posting agents
SHOULD NOT now be generating it. SHOULD NOT now be generating it.
Usenet Best Practice May 2004 Headers that merely state defaults explicitly (e.g., a Followup-To
header with the same content as the Newsgroups header, or a MIME
Headers that merely state defaults explicitly (e.g., a Followup-To- Content-Type header with contents "text/plain; charset=us-ascii"), or
header with the same content as the Newsgroups-header, or a MIME
Content-Type-header with contents "text/plain; charset=us-ascii"), or
state information that reading agents can typically determine easily state information that reading agents can typically determine easily
themselves (e.g. the length of the body in octets) are redundant and themselves (e.g. the length of the body in octets) are redundant and
posting agents SHOULD NOT include them. posting agents SHOULD NOT include them.
There follow some recommendations specific to particular headers. There follow some recommendations specific to particular headers.
3.1.1.1. Date 3.1.1.1. Date
It is RECOMMENDED to add a comment, after the date-time, containing It is RECOMMENDED to add a comment, after the <date-time>, containing
the time zone in human-readable form. However, many of the the time zone in human-readable form. However, many of the
abbreviations commonly used for this purpose are ambiguous, and so abbreviations commonly used for this purpose are ambiguous, and so
the value given by the <zone> is the only definitive form. For the value given by the <zone> is the only definitive form. For
example: example:
Date: Sat, 26 May 2001 11:13:00 -0500 (EST) Date: Sat, 26 May 2001 11:13:00 -0500 (EST)
3.1.1.2. From 3.1.1.2. From
The mailboxes in the From-content MUST contain syntactically valid The mailboxes in the From header MUST contain syntactically valid
email addresses identifying the poster(s). Each such mailbox SHOULD email addresses identifying the poster(s). Each such mailbox SHOULD
be a working email address, belonging to the poster(s) of the be a working email address, belonging to the poster(s) of the
article, or the person or agent on whose behalf the article is article, or the person or agent on whose behalf the article is
posted. When, for whatever reason, a poster does not wish ro use a posted. When, for whatever reason, a poster does not wish ro use a
working address, the mailbox concerned SHOULD, to comply with working address, the mailbox concerned SHOULD end in the top level
[USEFOR], end in the top level domain ".invalid" [RFC 2606]. domain ".invalid" [RFC 2606] (cf. P-7.5).
NOTE: It is fashionable for posters to disguise their mail NOTE: It is fashionable for posters to disguise their mail
addresses to discourage malicious harvesting and for other addresses to discourage malicious harvesting and for other
purposes. Whilst the circumstances which might make this seem purposes. Whilst the circumstances which might make this seem
desirable are much to be regretted, the practice cannot be desirable are much to be regretted, the practice cannot be
regarded as in the best interests of Usenet, and this document regarded as in the best interests of Usenet, and this document
does not seek to promote the practice, even though it shows how does not seek to promote the practice, even though it shows how
to do it "correctly". Therefore, it is NOT recommended that to do it "correctly". Therefore, it is NOT recommended that
Usenet Best Practice March 2005
implementors should go out of their way to facilitate it. implementors should go out of their way to facilitate it.
3.1.1.3. Message-ID 3.1.1.3. Message-ID
Posting agents have the option of generating their own message Posting agents have the option of generating their own message
identifiers, or of leaving it to the injecting agent. Recall that it identifiers, or of leaving it to the injecting agent. Recall that it
is an absolute requirement of [USEFOR] that message identifiers is an absolute requirement of [RFC 2822] and [USEFOR] that message
should be unique with regard to all other Netnews articles or Email identifiers should be unique with regard to all other Netnews
messages, past, present or future. However, it would in practice be articles or Email messages, past, present or future. Although it
sufficient to ensure that there were astronomical odds against a would in practice be sufficient to ensure that there were
duplicated message identifier, and this is usually brought about by astronomical odds against a duplicated message identifier, the method
using the domain name of the originating site in the id-right of the RECOMMENDED in [RFC 2822] for bringing this about is by using the
msg-id, together with the time of composition and other domain name (or possibly the IP address) of the originating site in
disambiguating material (such as a process number or a serial number) the <id-right> of the <msg-id>, together with the time of composition
in the id-left. It is also in order to include additional information and other disambiguating material (such as a process number or a
of significance to the poster within the id-left, and even to serial number) in the <id-left>. It is also in order to include
deliberately make a non-unique identifier in cases where the additional information of significance to the poster within the <id-
identical message is to be posted by several posters (for example, a left>, and even to deliberately make a non-unique identifier in cases
Usenet Best Practice May 2004 where the identical message is to be posted by several posters (for
example, a cancel for an article which may also be cancelled by
cancel for an article which may also be cancelled by others). others).
[Recall that we have two drafts regarding the construction of message [Recall that we have two drafts regarding the construction of message
identifiers on www.landfield.com/usefor that were written in the early identifiers on www.landfield.com/usefor that were written in the early
days of Usefor. Maybe these should be dusted down, published, and days of Usefor. Maybe these should be dusted down, published, and
referred to here.] referred to here.]
3.1.1.4. Subject 3.1.1.4. Subject
There is a temptation amongst inventors of new protocols to require There is a temptation amongst inventors of new protocols, and even
particular phrases to be inserted or regognized automatically at amongst lawmakers [MALAMUD], to require particular phrases to be
particular places within the Subject-header. This temptation is inserted or regognized automatically at particular places within the
strongly to be resisted. Subject header. This temptation is strongly to be resisted.
[Remove the reference to [MALAMUD] if it has not made it to RFC by the
time we go to press.]
There are, however, two exceptions to this principle which have There are, however, two exceptions to this principle which have
become hallowed by longstanding usage: become hallowed by longstanding usage:
1. There is an established convention for the Subject-header in a 1. There is an established convention for the Subject header in a
followup to begin with "Re: ", and this SHOULD be supported (see followup to begin with "Re: ", and this SHOULD be supported (see
3.2.1.1). 3.2.1.1).
2. For compatibility with legacy news software, the Subject-content 2. The former practice whereby a Subject starting with "cmsg" was
of a control message (i.e. an article that also contains a construed as a control message (P-6) is now deprecated but, on
Control-header) MAY start with the string "cmsg ", and non-control account of legacy software, non-control messages SHOULD NOT start
messages SHOULD NOT start with the string "cmsg ". See also with the string "cmsg ". Nevertheless, it is still customary for
section 6.1. the Subject content of a control message (i.e. an article that
[SHOULD NOT changed from MUST NOT? Do there really still exist servers also contains a Control header) to start with the string "cmsg ",
or other agents that will recognize and act upon "cmsg" in a Subject- and this convention MAY be followed.
header? And if so, maybe that MUST NOT should be moved back into
[USEFOR].]
Subject-headers are for humans to read, and the most that user agents Subject headers are for humans to read, and the most that user agents
should do is to filter them as directed by their human readers. If should do is to filter them as directed by their human readers. If
some enhancement to Netnews requires support within the headers, then some enhancement to Netnews requires support within the headers, then
the proper procedure is to invent a new header for the purpose, or to the proper procedure is to invent a new header for the purpose, or to
Usenet Best Practice March 2005
adapt an existing header (supposing it had the capability to support adapt an existing header (supposing it had the capability to support
such adaptations). such adaptations).
3.1.1.5. Newsgroups 3.1.1.5. Newsgroups
There are restrictions on the length of components of newsgroup- There are restrictions on the length of components of <newsgroup-
names, and on the newsgroup-names themselves, as described more fully name>s, and on the <newsgroup-name>s themselves, as described more
in 7.2. Posting and injecting agents MAY attempt to enforce them fully in 7.2. Posting and injecting agents MAY attempt to enforce
but, because of the possibility that hierarchy policies or future them but, because of the possibility that hierarchy policies or
standards may relax them, it SHOULD be possible for posters to future standards may relax them, it SHOULD be possible for posters to
override such checks, and software MUST be so written that they can override such checks, and software MUST be so written that they can
be disabled altogether. be disabled altogether.
Posting agents MAY (and followup agents SHOULD) accept articles Posting agents MAY (and followup agents SHOULD) accept articles
crossposted to newsgroups which do not exist on their local hosts, crossposted to newsgroups which do not exist on their local hosts,
though posting agents SHOULD at least alert the poster to the though posting agents SHOULD at least alert the poster to the
situation and request confirmation. situation and request confirmation.
Usenet Best Practice May 2004
3.1.1.6. Reply-To 3.1.1.6. Reply-To
In the absence of Reply-To, the reply address(es) is the address(es) In the absence of Reply-To, the reply address(es) is the address(es)
in the From-header. For this reason a Reply-To SHOULD NOT be included in the From header. For this reason a Reply-To SHOULD NOT be included
if it just duplicates the From-header. if it just duplicates the From header.
NOTE: Use of a Reply-To-header is preferable to including a NOTE: Use of a Reply-To header is preferable to including a
similar request in the article body, because replying agents can similar request in the article body, because replying agents can
take account of Reply-To automatically. take account of Reply-To automatically.
3.1.1.7. Organization 3.1.1.7. Organization
Posting agents are discouraged from providing a default value for Posting agents are discouraged from providing a default value for
this header unless it is acceptable to all posters using those agents this header unless it is acceptable to all posters using those agents
and unless it contains useful information (including some indication and unless it contains useful information (including some indication
of the poster's physical environment). See section 4.1.2 for an even of the poster's physical environment). See section 4.1.2 for an even
stronger discouragement for injecting agents. stronger discouragement for injecting agents.
3.1.1.8. Distribution 3.1.1.8. Distribution
Posting agents SHOULD NOT provide a default Distribution-header Posting agents SHOULD NOT provide a default Distribution header
without giving the poster an opportunity to override it. without giving the poster an opportunity to override it.
3.1.1.9. Followup-To 3.1.1.9. Followup-To
A Followup-To-header SHOULD NOT be included if it just duplicates the A Followup-To header SHOULD NOT be included if it just duplicates the
Newsgroups-header. At least one of its newsgroup-names SHOULD exist Newsgroups header. At least one of its <newsgroup-name>s SHOULD
on the posting agent's host (since a well behaved poster ought not to exist on the posting agent's host (since a well behaved poster ought
be setting followups to a place that he cannot read). Cf. a similar not to be setting followups to a place that he cannot read). Cf. a
rule regarding crossposting in [USEFOR] section 5.5. similar rule regarding crossposting in section P-7.2.2.
3.1.1.10. User-Agent 3.1.1.10. User-Agent
Comments in User-Agent-headers should be restricted to information Comments in User-Agent headers should be restricted to information
regarding the product named to their left, such as its full name or regarding the product named to their left, such as its full name or
platform information, and should be concise. Use as an advertising platform information, and should be concise. Use as an advertising
Usenet Best Practice March 2005
medium (in the mundane sense) is discouraged. medium (in the mundane sense) is discouraged.
3.1.2. Construction of Bodies 3.1.2. Construction of Bodies
It was the fashion at one time to indicate underlining within body It was the fashion at one time to indicate underlining within body
texts using Backspace, in the form of an underscore (US-ASCII 95), a texts using Backspace, in the form of an underscore (US-ASCII 95), a
backspace, and a character, repeated for each character that should backspace, and a character, repeated for each character that should
be underlined. Posting agents MAY support this mechanism, although it be underlined. Posting agents MAY support this mechanism, although it
is no longer so common for reading agents to process it. is no longer so common for reading agents to process it.
NOTE: using this precise method should ensure that reading NOTE: using this precise method should ensure that reading
agents that cannot display the text underlined will at least agents that cannot display the text underlined will at least
display it correctly in an un-underlined form. display it correctly in an un-underlined form.
The formfeed character (US-ASCII 12) (which is sometimes referred to The formfeed character (US-ASCII 12) (which is sometimes referred to
as the "spoiler character") MAY be used (see 3.3.2 for its effect on as the "spoiler character") MAY be used (see 3.3.3 for its effect on
reading agents). reading agents).
Usenet Best Practice May 2004
In plain-text articles (those with no MIME headers, or those with a In plain-text articles (those with no MIME headers, or those with a
MIME Content-Type of "text/plain") posting agents SHOULD endeavour to MIME Media Type of "text/plain") posting agents SHOULD endeavour to
keep the length of body lines within some reasonable limit. The size keep the length of body lines within some reasonable limit. The size
of this limit is a matter of policy, the default being to keep within of this limit is a matter of policy, the default being to keep within
79 characters at most, and preferably within 72 characters (to allow 79 characters at most, and preferably within 72 characters (to allow
room for quoting in followups). room for quoting in followups). Except where "format=flowed" is
being used (3.1.2.2), the line breaks shown to the poster during
editing SHOULD be exactly as they will appear in the posted article.
NOTE: That policy limit (e.g. 72 or 79) should be expressed as a NOTE: That policy limit (e.g. 72 or 79) should be expressed as a
number of characters (as they will be displayed by a reading number of characters (as they will be displayed by a reading
agent) rather than as the number of octets used to encode them. agent) rather than as the number of octets used to encode them.
For use on occasions where established policy prescribes For use on occasions where established policy prescribes
different line lengths (this usually arises in groups where the different line lengths (this usually arises in groups where the
charset for the language used is best represented using double charset for the language used is best represented using double
width characters) the preferred line length SHOULD be a width characters) the preferred line length SHOULD be a
configurable option. In addition, posting agents MUST permit the configurable option.
poster to create individual lines longer than the default or
configured length if he so insists (which may require the Posting agents MUST permit the poster to create individual lines
cessation of any automatic generation of flowed lines [RFC 3676] longer than the default or configured length if he so insists (which
on a temporary basis). may require the cessation of any automatic generation of flowed lines
[RFC 3676] on a temporary basis), but it SHOULD be made apparent to
the poster (e.g. by issuing a warning) that the article contains
lines longer that the customary length.
If the software uses an external editor, the editor called by default
SHOULD be able to meet all the requirements of this section.
3.1.2.1. Signatures 3.1.2.1. Signatures
A "personal signature" is a short closing text automatically added to A "personal signature" is a short closing text automatically added to
the end of articles by posting agents, identifying the poster and the end of articles by posting agents, identifying the poster and
giving his network addresses, etc. Whenever a poster or posting agent giving his network addresses, etc. Whenever a poster or posting agent
appends such a signature to an article, it MUST be preceded with a appends such a signature to an article, it MUST be preceded with a
delimiter line containing (only) two hyphens (US-ASCII 45) followed delimiter line containing (only) two hyphens (US-ASCII 45) followed
by one SP (US-ASCII 32). The signature is considered to extend from by one SP (US-ASCII 32). The signature is considered to extend from
Usenet Best Practice March 2005
the last occurrence of that delimiter up to the end of the article the last occurrence of that delimiter up to the end of the article
(or up to the end of the part in the case of a multipart MIME body). (or up to the end of the part in the case of a multipart MIME body).
Posting agents SHOULD provide a facility to enable the poster to add Posting agents SHOULD provide a facility to enable the poster to add
such signatures, and SHOULD discourage (at least with a warning) such signatures, and SHOULD discourage (at least with a warning)
signatures of excessive length (4 lines is a commonly accepted signatures of excessive length (4 lines is a commonly accepted
limit). limit).
3.1.2.2. Usage of MIME 3.1.2.2. Usage of MIME
When the Content-Type is "text/plain", the recommendations and limits When the Media Type is "text/plain", the recommendations and limits
on line lengths set out above SHOULD be observed. on line lengths set out above SHOULD be observed.
Posting agents MAY use the "format=flowed" parameter of "text/plain" Posting agents MAY use the "format=flowed" parameter of "text/plain"
(and also the "DelSp=yes" if appropriate) defined in [RFC 3676] so as (and also the "DelSp=yes" if appropriate) defined in [RFC 3676] so as
to allow suitably equipped reading agents to reformat flowed to allow suitably equipped reading agents to reformat flowed
paragraphs to suit the width of their display areas. However, it must paragraphs to suit the width of their display areas. However, it must
be understood that many reading agents do not support that feature, be understood that many reading agents do not support that feature,
and therefore the physical length of all lines SHOULD be restricted and therefore the physical length of all lines SHOULD be restricted
to the default preferred length of 72 characters, rather than the 78 to the default preferred length of 72 characters, rather than the 78
recommended in [RFC 3676]. However, single words longer than that recommended in [RFC 3676]. However, single words longer than that
length (and this specifically applies to URIs [RFC 2396]) MUST NEVER length (and this specifically applies to URIs [RFC 3986]) which MUST
be split across more than one physical line. NEVER be split across more than one physical line. Exceptionally, it
is suggested in [RFC 3986] that URIs MAY contain embedded whitespace
and hence be split across lines, but in practice many user agents
fail to recognize URIs split in this way.
Other forms of text, such as "text/html" SHOULD NOT be used except in Other forms of text, such as "text/html" SHOULD NOT be used except in
groups where established policy or custom so allows (7.3). However, groups where established policy or custom so allows (7.3). However,
where they are so used then, for the benefit of readers who see it where they are so used then, for the benefit of readers who see it
Usenet Best Practice May 2004
only in its transmitted form, the material SHOULD be "pretty-printed" only in its transmitted form, the material SHOULD be "pretty-printed"
(for example by restricting its line length as above and by keeping (for example by restricting its line length as above and by keeping
sequences which control its layout or style separate from the sequences which control its layout or style separate from the
meaningful text). meaningful text).
Likewise, Content-Types requiring special processing for their Likewise, Media Types requiring special processing for their display,
display, notably the "binary" Content-Types "image", "audio" and notably the "binary" Media Types "image", "audio" and "video"
"video" (including also material encoded by the "uuencode" protocol), (including also material encoded by the "uuencode" protocol),
together with most "application" types, SHOULD NOT be used except in together with most "application" types, SHOULD NOT be used except in
groups where established policy or custom so allows (7.3). groups where established policy or custom so allows (7.3).
Exceptionally, those application types defined in [RFC 1847] and [RFC Exceptionally, those application types defined in [RFC 1847] and [RFC
3156] for use within "multipart/signed" articles, and the type 3156] for use within "multipart/signed" articles, and the type
"application/pgp-keys" (or other similar types containing digital "application/pgp-keys" (or other similar types containing digital
certificates) may be used freely. certificates) may be used freely.
The Content-Type "message/partial" is not recommended for textual The Media Type "message/partial" is not recommended for textual
articles because the Content-Type, and in particular the charset, of articles because the Media Type, and in particular the charset, of
the complete article cannot be determined by examination of the the complete article cannot be determined by examination of the
second and subsequent parts, and hence (except when they are written second and subsequent parts, and hence (except when they are written
in pure US-ASCII) it is not possible to read them as separate in pure US-ASCII) it is not possible to read them as separate
articles (as by a reader who wanted to "browse ahead" to see whether articles (as by a reader who wanted to "browse ahead" to see whether
it was worth his while to read the whole set). Moreover, for full it was worth his while to read the whole set). Moreover, for full
compliance with [RFC 2046] it would be necessary to use the "quoted- compliance with [RFC 2046] it would be necessary to use the "quoted-
printable" encoding to ensure the material was 7bit-safe. In any printable" encoding to ensure the material was 7bit-safe. In any
case, breaking such long texts into several parts is usually case, breaking such long texts into several parts is usually
Usenet Best Practice March 2005
unnecessary, since modern transport agents should have no difficulty unnecessary, since modern transport agents should have no difficulty
in handling articles of arbitrary length. in handling articles of arbitrary length.
On the other hand, "message/partial" may be useful for binaries of On the other hand, "message/partial" may be useful for binaries of
excessive length, since reading of the individual parts on their own excessive length, since reading of the individual parts on their own
is not required and they would likely already be encoded in a manner is not required and they would likely already be encoded in a manner
that was 7bit-safe. that was 7bit-safe.
The Content-Type "message/rfc822" SHOULD be used where complete news The Media Type "message/rfc822" SHOULD be used where complete news
articles or email messages are to be included within another article articles or email messages are to be included within another article
([USEFOR] 6.21.2). (P-5.2).
The Content-Type "message/external-body" could be appropriate for The Media Type "message/external-body" could be appropriate for texts
texts which it would be uneconomic (in view of the likely readership) which it would be uneconomic (in view of the likely readership) to
to distribute to the entire network. distribute to the entire network.
The Content-Types "multipart/mixed", "multipart/parallel" and The Media Types "multipart/mixed", "multipart/parallel" and
"multipart/signed" may be used freely in news articles. However, "multipart/signed" may be used freely in news articles. However,
except where policy or custom so allows, the Content-Type: except where policy or custom so allows, the Media Type
"multipart/alternative" SHOULD NOT be used, on account of the extra "multipart/alternative" SHOULD NOT be used, on account of the extra
bandwidth consumed and the difficulty of quoting in followups. bandwidth consumed and the difficulty of quoting in followups.
The Content-Type: "multipart/digest" is commended for any article The Media Type "multipart/digest" is commended for any article
composed of multiple messages more conveniently viewed as separate composed of multiple messages more conveniently viewed as separate
entities, thus enabling reading agents to move rapidly between them. entities, thus enabling reading agents to move rapidly between them.
The "boundary" should be composed of 28 hyphens (US-ASCII 45) (which The "boundary" should be composed of 28 hyphens (US-ASCII 45) (which
makes each boundary delimiter 30 hyphens, or 32 for the final one) so makes each boundary delimiter 30 hyphens, or 32 for the final one) so
as to enable reading agents which currently support the digest usage as to enable reading agents which currently support the digest usage
described in [RFC 1153] to continue to operate correctly. described in [RFC 1153] to continue to operate correctly.
Usenet Best Practice May 2004
NOTE: The various recommendations given above regarding the NOTE: The various recommendations given above regarding the
usage of particular Content-Types apply also within the usage of particular Media Types apply also within the individual
individual parts of these multiparts. parts of these multiparts.
A multipart is preceded and followed by some spare text (a preamble A multipart is preceded and followed by some spare text (a preamble
before the first boundary and an epilogue after the last one). It is before the first boundary and an epilogue after the last one). It is
clear from [RFC 2046] that these texts are not to be considered part clear from [RFC 2046] that these texts are not to be considered part
of the official message and SHOULD NOT be displayed by reading of the official message and SHOULD NOT be displayed by reading
agents. It is useful for the preamble to contain words such as "This agents. It is useful for the preamble to contain words such as "This
is a multipart message in MIME format" for the benefit of older is a multipart message in MIME format" for the benefit of older
reading agents that do not support MIME, but the epilogue SHOULD be reading agents that do not support MIME, but the epilogue SHOULD be
empty and, in particular, it SHOULD NOT be used to hold the signature empty and, in particular, it SHOULD NOT be used to hold the signature
(3.1.2.1), as is sometimes done. (3.1.2.1), as is sometimes done.
3.1.2.3. Content-Transfer-Encoding 3.1.2.3. Content-Transfer-Encoding
The normal expectation ([USEFOR] 6.21.3) is that the Content- The normal expectation is that the Content-Transfer-Encoding [RFC
Transfer-Encoding will be "8bit (or maybe "7bit" if the charset 2045] will be "8bit (or maybe "7bit" if the charset allows it). Other
allows it). Other Content-Transfer-Encodings SHOULD NOT be used Content-Transfer-Encodings SHOULD NOT be used unless there are
unless there are pressing reasons to do so. pressing reasons to do so.
The following are examples of such situations where a Content- The following are examples of such situations where a Content-
Transfer-Encoding of other that "8bit" may be necessary. Transfer-Encoding of other that "8bit" may be necessary.
Usenet Best Practice March 2005
1. The content type implies that the content is (or may be) "8bit- 1. The content type implies that the content is (or may be) "8bit-
unsafe"; i.e. it may contain octets equivalent to the US-ASCII unsafe"; i.e. it may contain octets equivalent to the US-ASCII
characters CR or LF (other than in the combination CRLF) or NUL. characters CR or LF (other than in the combination CRLF) or NUL.
In that case one of the Content-Transfer-Encodings "base64" or In that case one of the Content-Transfer-Encodings "base64" or
"quoted-printable" MUST be used, and reading agents MUST be able "quoted-printable" MUST be used, and reading agents MUST be able
to handle both of them. to handle both of them.
NOTE: If a future extension to the MIME standards were to NOTE: If a future extension to the MIME standards were to
provide a more compact encoding of binary suited to transport provide a more compact encoding of binary suited to transport
over an 8bit channel, it could be considered as an alternative over an 8bit channel, it could be considered as an alternative
to base64 once it had gained widespread acceptance. to base64 once it had gained widespread acceptance.
2. It is often the case that "application" Content-Types are textual 2. It is often the case that "application" Media Types are textual in
in nature, and intelligible to humans as well as to machines, and nature, and intelligible to humans as well as to machines, and
where this state can be recognized by the posting agent (either where this state can be recognized by the posting agent (either
through knowledge of the particular application type or by through knowledge of the particular application type or by
testing) the material SHOULD NOT be treated as 8bit-unsafe; this testing) the material SHOULD NOT be treated as 8bit-unsafe; this
has the added benefit, where the posting agent uses other than has the added benefit, where the posting agent uses other than
CRLF for line endings internally, of automatically ensuring that CRLF for line endings internally, of automatically ensuring that
line endings are processed correctly during transport. line endings are processed correctly during transport.
If, on the other hand, the posting agent recognizes that the If, on the other hand, the posting agent recognizes that the
material is not textual, or cannot reasonably determine it to be material is not textual, or cannot reasonably determine it to be
so, then the material MUST be encoded as for 8bit-unsafe (however, so, then the material MUST be encoded as for 8bit-unsafe (however,
in that case, it is the responsibility of the agent generating the in that case, it is the responsibility of the agent generating the
material to ensure that lines endings, if any, are represented material to ensure that lines endings, if any, are represented
correctly). correctly).
Usenet Best Practice May 2004 NOTE: All the application types defined by P-5, namely
NOTE: All the application types defined by [USEFOR], namely
"application/news-transmission", "application/news-groupinfo" "application/news-transmission", "application/news-groupinfo"
and "application/news-checkgroups" are textual, and indeed and "application/news-checkgroups" are textual, and indeed
designed for human reading. designed for human reading.
3. Although the "text" Content-Types should normally be encoded as 3. Although the "text" Media Types should normally be encoded as 8bit
8bit (or 7bit), if the character set specified by the "charset=" (or 7bit), if the character set specified by the "charset="
parameter can include the 3 disallowed octets, then the material parameter can include the 3 disallowed octets, then the material
MUST be encoded as for 8bit-unsafe. This is most likely to arise MUST be encoded as for 8bit-unsafe. This is most likely to arise
in the case of 16-bit character sets such as UTF-16 ([UNICODE 3.2] in the case of 16-bit character sets such as UTF-16 ([UNICODE 3.2]
or [ISO/IEC 10646]). In addition, where it is known that the or [ISO/IEC 10646]). In addition, where it is known that the
material is subsequently to be gatewayed from Netnews to Email material is subsequently to be gatewayed from Netnews to Email P-
([USEFOR] 8.8), the encoding "quoted-printable" MAY be used 7.9), the encoding "quoted-printable" MAY be used (otherwise the
(otherwise the gateway might have to re-encode it itself). gateway might have to re-encode it itself).
4. Some protocols REQUIRE the use of a particular Content-Transfer- 4. Some protocols REQUIRE the use of a particular Content-Transfer-
Encoding. In particular, the authentication protocol based on Encoding. In particular, the authentication protocol based on
OpenPGP defined in [RFC 3156] mandates the use of one of the OpenPGP defined in [RFC 3156] mandates the use of one of the
encodings "quoted-printable" or "base64". Whilst posters might be encodings "quoted-printable" or "base64". Whilst posters might be
tempted to risk the use of "8bit" or "7bit" encodings (and indeed tempted to risk the use of "8bit" or "7bit" encodings (and indeed
the referenced standard recommends that signed messages using the referenced standard recommends that signed messages using
those encodings be accepted and interpreted), they should be those encodings be accepted and interpreted), they should be
warned that differences in the treatment of trailing whitespace warned that differences in the treatment of trailing whitespace
between OpenPGP [RFC 2440] and earlier versions of PGP may render between OpenPGP [RFC 2440] and earlier versions of PGP may render
signatures written with the one unverifiable by the other; and, signatures written with the one unverifiable by the other; and,
moreover, Usenet articles are very likely to include trailing moreover, Usenet articles are very likely to include trailing
Usenet Best Practice March 2005
whitespace in the form of a personal signature (3.1.2.1). whitespace in the form of a personal signature (3.1.2.1).
5. The Content-Type message/partial [RFC 2046] is required to use 5. The Media Type message/partial [RFC 2046] is required to use
encoding "7bit" (the encapsulated complete message may itself use encoding "7bit" (the encapsulated complete message may itself use
encoding "quoted-printable" or "base64", but that information is encoding "quoted-printable" or "base64", but that information is
only conveyed along with the first of the partial parts). only conveyed along with the first of the partial parts).
NOTE: Although there would actually be no problem using encoding NOTE: Although there would actually be no problem using encoding
"8bit" in a pure Netnews (as opposed to Email) environment, this "8bit" in a pure Netnews (as opposed to Email) environment, this
document discourages the use of "message/partial" except for document discourages the use of "message/partial" except for
binary material, which will likely be encoded to pass through binary material, which will likely be encoded to pass through
"7bit" in any case. "7bit" in any case.
It may be necessary to change the Content-Transfer-Encoding at It may be necessary to change the Content-Transfer-Encoding at
gateways. For example in the case where such an encapsulated news gateways. For example in the case where such an encapsulated news
article with the Content-Type "message/rfc822" is to be transported article with the Media Type "message/rfc822" is to be transported by
by email and it has Content-Transfer-Encoding "8bit", the Content- email and it has Content-Transfer-Encoding "8bit", the Content-
Transfer-Encoding may need to be changed, although there may well be Transfer-Encoding may need to be changed, although there may well be
no problems in practice if the email transport supports 8BITMIME [RFC no problems in practice if the email transport supports 8BITMIME [RFC
2821]. 2821].
3.2. The Well-Behaved Followup Agent 3.2. The Well-Behaved Followup Agent
Usenet is primarily a medium for discussion. The majority of articles Usenet is primarily a medium for discussion. The majority of articles
that are posted are in fact followups to previous articles, and that are posted are in fact followups to previous articles, and
exceedingly complex threads can develop. Therefore, it is essential exceedingly complex threads can develop. Therefore, it is essential
that user agents provide facilities for followups that will enable that user agents provide facilities for followups that will enable
such elongated discussions to proceed smoothly. such elongated discussions to proceed smoothly.
Usenet Best Practice May 2004
3.2.1. Construction of Headers 3.2.1. Construction of Headers
The requirements on inserting and editing headers already set out in The requirements on inserting and editing headers already set out in
3.1.1 still apply, and apply in particular to those headers for which 3.1.1 still apply, and apply in particular to those headers for which
the followup agent has set default values. the followup agent has set default values.
3.2.1.1. Subject 3.2.1.1. Subject
The Subject of the followup is, by default, taken from that of the The Subject of the followup is, by default, taken from that of the
precursor, but users are able to override that default; indeed they precursor, but users are able to override that default; indeed they
are to be encouraged to do so whenever appropriate in order to avoid are to be encouraged to do so whenever appropriate in order to avoid
long threads which have wandered far from the topic with which they long threads which have wandered far from the topic with which they
originated, but which still adhere to the original Subject. originated, but which still adhere to the original Subject.
It has been a long standing practice, both on Usenet and in Email, to It has been a long standing practice, both on Usenet and in Email, to
prepend the back-reference "Re: " ([USEFOR] 5.4) to the Subject when prepend the "back-reference" "Re: " ,. [RFC 2822] and P-7.6) to the
preparing a followup, as an indication to the reader that this is a Subject when preparing a followup, as an indication to the reader
continuation of discussion of an earlier topic rather than the start that this is a continuation of discussion of an earlier topic rather
of a new one. [USEFOR] does not require this practice, but permits it than the start of a new one. [USEPRO] does not require this practice,
so long as it is not applied if such a back-reference is already but permits it so long as it is not applied if such a back-reference
present, and provided no string other that "Re: " is used for the is already present, and provided no string other that "Re: " is used
purpose. for the purpose.
Usenet Best Practice March 2005
However, the practice is not without its difficulties: However, the practice is not without its difficulties:
1. Although the "Re" (which is an abbreviation for the Latin "In re", 1. Although the "Re" (which is an abbreviation for the Latin "In re",
meaning "in the matter of", and not an abbreviation of "Reference" meaning "in the matter of", and not an abbreviation of "Reference"
as is sometimes erroneously supposed) may be understood by English as is sometimes erroneously supposed) may be understood by English
speakers, and indeed by speakers of most European Languages, its speakers, and indeed by speakers of most European Languages, its
use in a newsgroup where articles were customarily written in use in a newsgroup where articles were customarily written in
Arabic, or Hindi, or Chinese would be less than helpful. Arabic, or Hindi, or Chinese would be less than helpful.
2. It requires extra processing (to ignore it) in some reading agents 2. It requires extra processing (to ignore it) in some reading agents
which choose to consult the Subject-header when deciding the best which choose to consult the Subject header when deciding the best
order in which to present articles to the reader (see 3.3.1.1). order in which to present articles to the reader (see 3.3.2.1).
This burden has to be weighed against the relatively small benefit This burden has to be weighed against the relatively small benefit
of the indication provided directly to readers. of the indication provided directly to readers.
3. Sometimes, followup agents attempt to use translations of "Re: " 3. Sometimes, followup agents attempt to use translations of "Re: "
into other languages, as in "Sv: " and "Antwort: ". But it is not into other languages, as in "Sv: " and "Antwort: ". But it is not
practicable for those reading agents which take some special note practicable for those reading agents which take some special note
of "Re: " also to take note of translations into an indeterminate of "Re: " also to take note of translations into an indeterminate
number of other languages, and for this reason [USEFOR] makes it number of other languages, and for this reason [USEPRO] does not
clear that such translations SHOULD NOT be used. permit such translations.
4. Even the presence of "Re: " at the start of a Subject may 4. Even the presence of "Re: " at the start of a Subject may
occasionally be misleading, because it might have been occasionally be misleading, because it might have been
deliberately placed there by a poster rather than having been deliberately placed there by a poster rather than having been
generated automatically by a followup agent. generated automatically by a followup agent.
5. And finally, there are philosophical arguments against features 5. And finally, there are philosophical arguments against features
within an unstructured header which imply specific recognition and within an unstructured header which imply specific recognition and
support within user agents (for reason already explained in support within user agents (for reason already explained in
3.1.1.4). Indeed, the only reason why [USEFOR] permits this 3.1.1.4). Indeed, the only reason why [USEPRO] permits this
Usenet Best Practice May 2004
particular exception is on account of its current widespread particular exception is on account of its current widespread
usage. usage.
For these reasons, this document does not seek to perpetuate this For these reasons, this document does not seek to perpetuate this
practice, and indeed it might be better if its use were eventually to practice, and indeed it might be better if its use were eventually to
be phased out. Nevertheless, it is certain that it will continue to be phased out. Nevertheless, it is certain that it will continue to
happen for some considerable period of time in newgroups where happen for some considerable period of time in newgroups where
English is the primary language, simply on account of the inertia English is the primary language, simply on account of the inertia
already behind it. For this reason, section 3.3.1.1 RECOMMENDS already behind it. For this reason, section 3.3.2.1 RECOMMENDS
striping away any initial "Re: " when comparing Subjects. striping away any initial "Re: " when comparing Subjects.
It would be wiser for any followup agents which are able to recognize It would be wiser for any followup agents which can detect apparent
non-standard back-references such as "Re(2): ", "Sv: ", etc. to non-standard back-references such as "Re(2): ", "Sv: ", etc. to
refrain from prepending anything further, but other attempts to mend refrain from prepending anything further, but other attempts to mend
that problem are likely to do more harm than good. that problem are likely to do more harm than good.
As well as the addition of "Re: ", the Subject-header MAY be refolded As well as the addition of "Re: ", the Subject header MAY be refolded
(which MAY include collapsing/expanding whitespace to/from a single (which MAY include collapsing/expanding whitespace to/from a single
SP at any point where the folding is changed). However, it MUST NOT SP at any point where the folding is changed). However, it MUST NOT
(except by deliberate act of the poster) be truncated, extended or (except by deliberate act of the poster) be truncated, extended or
changed in any other way that might cause a reading agent to deduce changed in any other way that might cause a reading agent to deduce
that the subject of a thread had changed. that the subject of a thread had changed.
Usenet Best Practice March 2005
[Bruce wants users users to be requested to confirm that they are happy [Bruce wants users users to be requested to confirm that they are happy
with the derfault Subject as provided.] with the default Subject as provided.]
3.2.1.1.1. Examples 3.2.1.1.1. Examples
In the following examples, please note that only "Re: " has any In the following examples, please note that only "Re: " has any
official status (and hence may be utilized by reading agents). official status (and hence may be utilized by reading agents).
"was: " is a convention used by many English-speaking posters to "was: " is a convention used by many English-speaking posters to
signal a change in subject matter. Software can always recognize signal a change in subject matter. Software can always recognize
that such changes have occurred from the References-header. that such changes have occurred from the References header.
Subject: Film at 11 Subject: Film at 11
Subject: Re: Film at 11 Subject: Re: Film at 11
Subject: Godwin's law considered harmful (was: Film at 11) Subject: Godwin's law considered harmful (was: Film at 11)
Subject: Godwin's law (was: Film at 11) Subject: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law (was: Film at 11) Subject: Re: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law Subject: Re: Godwin's law
3.2.1.2. Newsgroups 3.2.1.2. Newsgroups
The Newsgroups of the followup are, by default, taken from those of
the precursor, or from the precursor's Followup-To header (P-7.6).
But if the precursor's Followup-To header is set to "poster", the
user MUST be warned if he attempts to force the followup to be
posted.
Followup agents SHOULD accept articles crossposted to newsgroups Followup agents SHOULD accept articles crossposted to newsgroups
which do not exist on their local hosts (as opposed to posting which do not exist on their local hosts (as opposed to posting
agents, for which that requirement is only "MAY"). agents, for which that requirement is only "MAY").
3.2.1.3. Mail-Copies-To 3.2.1.3. Mail-Copies-To
If the user attempts to email the poster as well as to followup, in [This header may yet be removed from the drafts.]
the case where the Mail-Copies-To-header is absent, and even more so
when it is present and there is an explicit "nobody", the followup
agent SHOULD issue a warning and ask for confirmation.
Usenet Best Practice May 2004 If the user attempts to email the poster as well as to followup, in
the case where the Mail-Copies-To header is absent, and even more so
when it is present and there is an explicit "nobody", contrary to the
RECOMMENDATION in P-7.6, then the followup agent SHOULD issue a
warning and ask for confirmation.
NOTE: This header is only relevant when posting followups to NOTE: This header is only relevant when posting followups to
Netnews articles, and is to be ignored when sending pure email Netnews articles, and is to be ignored when sending pure email
replies to the poster, which are handled as prescribed under the replies to the poster, which are handled as prescribed under the
Reply-To-header. Reply-To header.
3.2.1.4. Posted-And-Mailed [USEPRO] RECOMMENDS that where a followup is also emailed to the
poster, a suitable Posted-And-Mailed header be added.
NOTE: In addition to the Posted-And-Mailed-header, some followup NOTE: In addition to the Posted-And-Mailed header, some followup
agents also include within the body a mention that the article agents also include within the body a mention that the article
is both posted and mailed, for the benefit of reading agents is both posted and mailed, for the benefit of reading agents
that do not normally show that header. that do not normally show that header.
3.2.1.5. References Usenet Best Practice March 2005
Followup agents SHOULD trim message identifiers out of a References- 3.2.1.4. References
Followup agents SHOULD trim message identifiers out of a References
header but SHOULD NOT do so until the number of message identifiers header but SHOULD NOT do so until the number of message identifiers
exceeds 21, at which time trimming SHOULD be done by removing exceeds 21, at which time trimming SHOULD be done by removing
sufficient identifiers starting with the second from the left so as sufficient identifiers starting with the second from the left so as
to bring the total down to 21 (but the first message identifier MUST to bring the total down to 21 (but the first message identifier MUST
NOT be trimmed). However, it would be wrong to assume that NOT be trimmed). However, it would be wrong to assume that References
References-headers containing more than 21 message identifiers will headers containing more than 21 message identifiers will not occur.
not occur. [21 was the figure agreed by the WG, but I think it would be better to
recommend an overall cutoff at 998 characters, because I have seen
followup agents that systematically undo the folding carefully put their
by precursors.]
3.2.2. Construction of Bodies 3.2.2. Construction of Bodies
Followup agents SHOULD follow policies already described for posting Followup agents SHOULD follow policies already described for posting
agents (3.1.2) regarding the length of lines when generating new text agents (3.1.2) regarding the length of lines when generating new text
Exceptionally, they SHOULD NOT adjust the length of quoted lines Exceptionally, they SHOULD NOT adjust the length of quoted lines
(3.2.2.1) in followups unless they are able to reformat them in a (3.2.2.1) in followups unless they are able to reformat them in a
consistent manner. consistent manner.
3.2.2.1. Quoting and Attributions 3.2.2.1. Quoting and Attributions
skipping to change at page 17, line 60 skipping to change at page 18, line 51
"MUST", "SHOULD", etc. are here to be understood as more than "MUST", "SHOULD", etc. are here to be understood as more than
advisory. advisory.
When the precursor had used the "format=flowed" parameter of When the precursor had used the "format=flowed" parameter of
text/plain [RFC 3676], and when the followup agent also supports text/plain [RFC 3676], and when the followup agent also supports
"format-flowed", flowed paragraphs in the precursor (including any "format-flowed", flowed paragraphs in the precursor (including any
flowed lines within quotations in the precursor) SHOULD be reflowed. flowed lines within quotations in the precursor) SHOULD be reflowed.
Thus, if all agents supported "format=flowed", no physical line, Thus, if all agents supported "format=flowed", no physical line,
quoted ot not, would ever exceed the default (or policy) limit, quoted ot not, would ever exceed the default (or policy) limit,
except by the deliberate intent of the poster. Where the precursor except by the deliberate intent of the poster. Where the precursor
was not flowed, its lines SHOULD be left alone when quoting, except was not flowed, its lines SHOULD initially be left alone when
Usenet Best Practice May 2004 quoting, except that already quoted lines which appeared (from the
presence of trailing SP) to have been flowed by one of the
precursor's precursors MAY be treated as such.
that already quoted lines which appeared (from the presence of For use when "format-flowed" is not available, or when it fails to
trailing SP) to have been flowed by one of the precursor's precursors resolve the problem, the poster SHOULD be provided with a facility to
MAY be treated as such. rewrap lines of quoted text (but only lines all at the same quoting
level).
Usenet Best Practice March 2005
When a followup agent incorporates the "precursor" as a quotation, it When a followup agent incorporates the "precursor" as a quotation, it
MUST be distinguished from the surrounding text in some way, and MUST be distinguished from the surrounding text in some way, and
SHOULD be so dintinguished by prefacing each line of the quoted text SHOULD be so dintinguished by prefacing each line of the quoted text
(even if it is empty) with the character ">" (or perhaps with "> " in (even if it is empty) with the character ">" (or perhaps with "> " in
the case of a previously unquoted line). This will result in multiple the case of a previously unquoted line). This will result in multiple
levels of ">" when quoted content itself contains quoted content, and levels of ">" when quoted content itself contains quoted content, and
it will also facilitate the automatic analysis of articles. it will also facilitate the automatic analysis of articles. A
facility SHOULD be provided for the poster to select less than the
complete body of the precursor in the quotation.
NOTE: Whilst posters should edit quoted context to trim it down NOTE: Whilst posters should edit quoted context to trim it down
to the minimum necessary, followup agents SHOULD NOT attempt to to the minimum necessary, followup agents SHOULD NOT attempt to
enforce this beyond issuing a warning (past attempts to do so enforce this beyond issuing a warning (past attempts to do so
have been found to be notably counter-productive). have been found to be notably counter-productive).
Care needs to be taken to use appropriate charsets in the outbound
followup, and to record them in a Content-Type header. A followup to
an article containing non-ASCII material is very likely to contain
non-ASCII material itself.
The followup agent SHOULD also precede the quoted content by an The followup agent SHOULD also precede the quoted content by an
"attribution line" (however, readers are warned not to assume that "attribution line" (however, readers are warned not to assume that
they are accurate, especially within multiply nested quotations). The they are accurate, especially within multiply nested quotations). The
following convention for such lines is intended to facilitate their following convention for such lines is intended to facilitate their
automatic recognition and processing by sophisticated reading agents. automatic recognition and processing by sophisticated reading agents.
The attribution SHOULD contain the name and/or the email address of The attribution SHOULD contain the name and/or the email address of
the precursor's poster, as in the precursor's poster, as in
Joe D. Bloggs <jdbloggs@foo.example> wrote: Joe D. Bloggs <jdbloggs@foo.example> wrote:
or or
Helmut Schmidt <helmut@bar.example> schrieb: Helmut Schmidt <helmut@bar.example> schrieb:
The attribution MAY contain also a single newsgroup-name (the one The attribution MAY contain also a single <newsgroup-name> (the one
from which the followup is being made), the precursor's message from which the followup is being made), the precursor's message
identifier and/or the precursor's Date and Time. Any of these that identifier and/or the precursor's Date and Time. Any of these that
are present, SHOULD precede the name and/or email address. However, are present, SHOULD precede the name and/or email address. However,
the inclusion or not of such fields SHOULD always be under the the inclusion or not of such fields SHOULD always be under the
control of the poster. control of the poster.
To enable this line, and the message identifier and the email address To enable this line, and the message identifier and the email address
within it, to be recognized (for example to enable suitable reading within it, to be recognized (for example to enable suitable reading
agents to retrieve the precursor or email its poster by clicking on agents to retrieve the precursor or email its poster by clicking on
them), the following conventions SHOULD be observed: them), the following conventions SHOULD be observed:
skipping to change at page 18, line 58 skipping to change at page 20, line 5
<...> <...>
o The various fields may be separated by arbitrary text and they o The various fields may be separated by arbitrary text and they
may be folded in the same way as headers, but attributions SHOULD may be folded in the same way as headers, but attributions SHOULD
always be terminated by a ":" followed by CRLF. always be terminated by a ":" followed by CRLF.
Further examples: Further examples:
On comp.foo in <1234@bar.example> on 24 Dec 2001 16:40:20 +0000, On comp.foo in <1234@bar.example> on 24 Dec 2001 16:40:20 +0000,
"Joe D. Bloggs" <jdbloggs@bar.example> wrote: "Joe D. Bloggs" <jdbloggs@bar.example> wrote:
Am 24. Dez 2002 schrieb Helmut Schmidt <helmut@bar.example>: Usenet Best Practice March 2005
Usenet Best Practice May 2004 Am 24. Dez 2002 schrieb Helmut Schmidt <helmut@bar.example>:
3.2.2.2. Signatures 3.2.2.2. Signatures
Followup agents, when incorporating quoted text from a precursor, Followup agents, when incorporating quoted text from a precursor,
SHOULD NOT include the signature in the quotation. SHOULD NOT include the signature in the quotation.
3.2.2.3. Usage of MIME 3.2.2.3. Usage of MIME
Followup agents which quote parts of a precursor SHOULD initially Followup agents which quote parts of a precursor SHOULD initially
include all parts of the precursor that were displayed inline, as if include all parts of the precursor that were displayed inline, as if
they were a single part. they were a single part.
3.3. The Well-Behaved Reading Agent 3.3. The Well-Behaved Reading Agent
3.3.1. Interpretation of Headers 3.3.1. Display of Headers
The set of headers displayed to the reader of each article is usually
a configurable option, but it MUST by default include at least the
following:
o From header
o Subject header
o Newsgroups header
o Followup-To header
o Reply-To header
and SHOULD include the following:
o Distribution header
o Posted-And-Mailed header
o Summary header
o Control header
Moreover it MUST include a facility to "Display ALL headers" on
demand.
NOTE: There is no necessity to display anything at all for a
header that is completely absent, and indeed some of the ones
listed may seldom, if ever, be seen; they are included simply
because it is essential for the reader to be aware of them on
the rare occasions when they do occur.
There is no requirement to display the headers in the exact format
defined in [USEFOR] (for example, header-names may be displayed in
some local language), but all the information in each header MUST be
shown in some form. It may be necessary to provide a scrollbar or
some equivalent means in order to display long headers (particularly
long Subject headers); alternatively, long headers can be folded for
display (although any folding provided by the original poster SHOULD
be retained if it will fit in the display area). In any case, the
display area SHOULD be able to accomodate up to 79 characters (or
other established policy limit - see 7.3). Even if some header
appears to be non-compliant with [USEFOR], it is better to display it
exactly as received rather than not to display it at all.
Usenet Best Practice March 2005
Reading agents need to be prepared for ancient usages (and even non- Reading agents need to be prepared for ancient usages (and even non-
compliance) which nevertheless still appear from time to time. In compliance) which nevertheless still appear from time to time. In
particular, the following is often seen: particular, the following is often seen:
fred@foo.bar.example (Fred Bloggs) fred@foo.bar.example (Fred Bloggs)
as opposed to as opposed to
"Fred Bloggs" <fred@foo.bar.example> . "Fred Bloggs" <fred@foo.bar.example> .
The former is a deprecated, but commonly encountered, usage and The former is a deprecated, but commonly encountered, usage and
reading agents SHOULD take special note of such comments as reading agents SHOULD take special note of such comments as
indicating (e.g. in killfiles) the name of the person whose mailbox indicating (e.g. in killfiles) the name of the person whose mailbox
it is. it is.
[Reading agents SHOULD make all headers available on user request.]
[What about headers etc that are unparseable?]
3.3.1.1. Presentation of Articles 3.3.2. Presentation of Articles
[The following text might be better placed in the proposed section 3.3.2.1. Threading
concerning reqirements for user interfaces, if we decide to go ahead
with that section.]
Reading agents SHOULD present the articles in each newsgroup in an Reading agents SHOULD present the articles in each newsgroup in an
order which ensures that the reader never sees a followup or reply to order which ensures that the reader never sees a followup or reply to
an article unless he has already had an opportunity to read the an article unless he has already had an opportunity to read the
original. However, this may be easier said than done. Here are some original. However, this may be easier said than done. Here are some
methods commonly used to fulfil this aim; none of them works methods commonly used to fulfil this aim; none of them works
perfectly. perfectly.
1. Present the articles in the order they were received at the local 1. Present the articles in the order they were received at the local
serving agent. However, articles propagated via different routes serving agent. However, articles propagated via different routes
with different delays may well arrive out of order, so this may with different delays may well arrive out of order, so this may
not be reliable. not be reliable.
2. Sort the articles into order according to their Date-headers. This 2. Sort the articles into order according to their Date headers. This
will usually be better than the first method, but relies on the will usually be better than the first method, but relies on the
clock and timezone settings in posting agents being approximately clock and timezone settings in posting agents being approximately
correct. And although it satisfies the minimal recommendation at correct. And although it satisfies the minimal recommendation at
the head of this section, it will likely result in totally the head of this section, it will likely result in totally
separate threads of discussion being merged in an unhelpful order. separate threads of discussion being merged in an unhelpful order.
Usenet Best Practice May 2004 3. Sort the articles according to their Subject headers (or group
them according to their Subject headers, with the groups being
3. Sort the articles according to their Subject-headers (or group presented in order of the Date header of the first article in each
them according to their Subject-headers, with the groups being group). Within a group with the same Subject, sort according to
presented in order of the Date-header). Within a group with the the Date header. This works tolerably well, but within a long
same Subject, sort according to the Date-header. This works discussion with many divergent subthreads, those subthreads are
tolerably well, but within a long discussion with many divergent still merged in an unhelpful order. Moreover, it will
subthreads, those subthreads are still merged in an unhelpful occasionally bring together totally unrelated articles that just
order. Moreover, it will occasionally bring together totally happen to have the same Subject by chance.
unrelated articles that just happen to have the same Subject by
chance.
4. Construct a tree in which each article is within a sub-tree headed 4. Construct a tree in which each article is within a sub-tree headed
by each article mentioned in its References-header, and present by each article mentioned in its References header, and present
articles by a depth-first traversal of that tree, sorting the articles by a depth-first traversal of that tree, sorting the
siblings within each branch according to their Date-headers. This siblings within each branch according to their Date headers. This
method is usually superior to the ones mentioned earlier, but it method is usually superior to the ones mentioned earlier, but it
can go wrong for a number of reasons. can go wrong for a number of reasons.
a) References-headers are sometimes absent, or incomplete (and Usenet Best Practice March 2005
a) References headers are sometimes absent, or incomplete (and
are even permitted to be trimmed when they get too long), are even permitted to be trimmed when they get too long),
and earlier articles in the threads may have expired off the and earlier articles in the threads may have expired off the
local server. Nevertheless, with careful implementation, local server. Nevertheless, with careful implementation,
these problems are mostly surmountable. these problems are mostly surmountable.
b) A poster may join an existing discussion (and clearly intend b) A poster may join an existing discussion (and clearly intend
to do so by using the same Subject-header, possibly with a to do so by using the same Subject header, possibly with a
prepended "Re: ") and yet his article might not be created prepended "Re: ") and yet his article might not be created
as a followup to any specific precursor and hence would not as a followup to any specific precursor and hence would not
have a References-header. Hence it would be presented quite have a References header. Hence it would be presented quite
apart from the other (sub-)threads of that discussion. apart from the other (sub-)threads of that discussion.
c) Conversely, the topic of some sub-thread might have diverged c) Conversely, the topic of some sub-thread might have diverged
so far from the original topic of discussion that some so far from the original topic of discussion that some
poster decides to create a totally new Subject for his poster decides to create a totally new Subject for his
followup. Nevertheless, that followup, and the whole sub- followup. Nevertheless, that followup, and the whole sub-
thread which issues from it, will still be presented in the thread which issues from it, will still be presented in the
midst of the other sub-threads of the original discussion. midst of the other sub-threads of the original discussion.
5. To counter these various deficiences, various hybrid schemes have 5. To counter these various deficiences, various hybrid schemes have
been devised which take account of all three headers, References-, been devised which take account of all three headers, References,
Subject- and Date-, and these often succeed in providing a more Subject and Date, and these often succeed in providing a more
pleasing presentation to the reader. However, different readers pleasing presentation to the reader. However, different readers
can be pleased in different ways, and so it is often the case that can be pleased in different ways, and so it is often the case that
reading agents provide configurable options to choose between reading agents provide configurable options to choose between
several methods. several methods.
This document does not single out any particular method as "the This document does not single out any particular method as "the
best". They are all to be considered acceptable, and implementors are best". They are all to be considered acceptable, and implementors are
encouraged to experiment accordingly. Nevertheless, it is inevitable encouraged to experiment accordingly. Nevertheless, it is inevitable
that some combination of Subjects and followups will eventually arise that some combination of Subjects and followups will eventually arise
that defeats even the most sophisticated scheme. that defeats even the most sophisticated scheme.
It must be noted, however, in the case of those methods which rely on It must be noted, however, in the case of those methods which rely on
the comparison of Subject-headers, whether to detect equality or for the comparison of Subject headers, whether to detect equality or for
sorting, that there are certain additional precautions that need to sorting, that there are certain additional precautions that need to
Usenet Best Practice May 2004
be taken, such as: be taken, such as:
a) [USEFOR] permits a back-reference "Re: " to be prepended a) [USEPRO] permits a back-reference "Re: " to be prepended
(optionally) to a Subject when creating a followup. Therefore, (optionally) to a Subject when creating a followup. Therefore,
that back-reference SHOULD be stripped away before performing any that back-reference SHOULD be stripped away before performing any
comparison of Subjects. On the other hand, "Re:" is the only comparison of Subjects. On the other hand, "Re:" is the only
back-reference permitted, and therefore it is not necessary for back-reference permitted, and therefore it is not necessary for
translations of "Re: " into other languages to be recognized (even translations of "Re: " into other languages to be recognized (even
though such translations are sometimes generated by non-compliant though such translations are sometimes generated by non-compliant
followup agents). Likewise, that "Re: " is case-sensitive, followup agents). Likewise, that "Re: " is case-sensitive,
although non-compliant agents that generate "RE: " are common although non-compliant agents that generate "RE: " are common
enough that it might be wiser to accept that form also. enough that it might be wiser to accept that form also.
[The above wording is subject to change according to what is finally
said in [USEFOR].]
b) It is not unknown for non-compliant followup agents to truncate b) It is not unknown for non-compliant followup agents to truncate
the Subject-header. Some reading agents therefore truncate the the Subject header. Some reading agents therefore truncate the
Subject before making any comparison. Sometimes this makes things Subject before making any comparison. Sometimes this makes things
better; sometimes it makes them worse. better; sometimes it makes them worse.
c) The use of encoded-words ([RFC 2047]) within Subject-headers can Usenet Best Practice March 2005
c) The use of <encoded-word>s ([RFC 2047]) within Subject headers can
give rise to different ways of encoding the same Subject. give rise to different ways of encoding the same Subject.
Therefore, such encoding SHOULD be undone before any comparison of Therefore, such encoding SHOULD be undone before any comparison of
Subject-headers is made. It cannot even be assumed that the back- Subject headers is made. It cannot even be assumed that the back-
reference "Re: " is not within an encoded-word. reference "Re: " is not within an <encoded-word>.
[It is possible that this matter will ultimately be addressed in
[USEFOR] rather than here.]
3.3.1.2. Summary 3.3.2.2. Killfiles
Although this header is not widely used, reading agents SHOULD make The reader SHOULD be provided with a list of articles available for
provision for it to be displayed if present (at least as the reading, as set out more fully in section 3.3.2. Within the list of
default). articles presented, the reader SHOULD be given the choice of seeing
only articles that have not yet been read, or of seeing all articles
available in the particular newsgroup. Moreover, articles
crossposted to many newsgroups SHOULD be considered to have been read
once they have been seen in any of those groups.
3.3.2. Interpretation of Bodies There SHOULD be a facility (usually known as a "killfile") for
filtering out classes of article that the reader does not wish to
see. As a minimum, it SHOULD be possible to filter on the Subject
header (preferably using regular expressions to describe the filter)
and on the From header, but ideally it should be possible on any
header (so, for example, it would be possible to filter out excessive
crossposting, or crossposts to particular groups). Moreover, it
SHOULD be possible to filter out all followups to some given article,
by filtering on the References header or by building upon whatever
threading facility has been provided.
The filters included in a killfile may be permanent, or for a limited
period. A corresponding set of filters to preselect articles for
reading MAY also be provided.
3.3.2.3. Interpretation of Distributions
A reading agent MAY be configured so that articles whose Distribution
headers contained unwanted <dist-name>s do not get displayed (this
would be in addition to any filtering on distributions already
performed by relaying and serving agents - see P-7.3). This might
well be achieved by an appropriate application of killfiles.
3.3.3. Interpretation of Bodies
Implementors of reading agents need to be aware of ancient usages Implementors of reading agents need to be aware of ancient usages
(and even non-compliance) which nevertheless still appear from time (and even non-compliance) which nevertheless still appear from time
to time, and SHOULD endeavour to recognize them and display them to time, and SHOULD endeavour to recognize them and display them
appropriately. appropriately.
An example of this is the use of Backspace by posting agents in order An example of this is the use of Backspace by posting agents in order
to construct composite characters (e.g. by underlining) (3.1.2). to construct composite characters (e.g. by underlining) (3.1.2).
Tab (US-ASCII 9) SHOULD be interpreted as sufficient horizontal white Tab (US-ASCII 9) SHOULD be interpreted as sufficient horizontal white
space to reach the next of a set of fixed positions (customarily set space to reach the next of a set of fixed positions (customarily set
at every 8th character). Formfeed (US-ASCII 12) (which is sometimes at every 8th character). Formfeed (US-ASCII 12) (which is sometimes
referred to as the "spoiler character") signifies a point at which referred to as the "spoiler character") signifies a point at which
the reading agent SHOULD pause and await reader interaction before the reading agent SHOULD pause and await reader interaction before
Usenet Best Practice March 2005
displaying further text. displaying further text.
Reading agents MUST provide facilities to display the whole of long Reading agents MUST provide facilities to display the whole of long
lines up to the maximum of 998 characters (whether by wrapping or by lines up to the maximum of 998 characters (whether by wrapping or by
providing horizontal scroll bars). However, cutting and pasting of providing horizontal scroll bars). However, cutting and pasting of
Usenet Best Practice May 2004
wrapped lines SHOULD copy the original unwrapped line (i.e. all CRLFs wrapped lines SHOULD copy the original unwrapped line (i.e. all CRLFs
not in the original should be discarded). not in the original should be discarded).
3.3.2.1. Usage of MIME It is common for reading agents to recognize the presence of URIs in
the bodies of articles and to permit them to be clicked upon. In such
cases, URIs which contain whitespace or are split over lines SHOULD
be recognized, as is recommended in Appendix C of [RFC 3986].
3.3.3.1. Usage of MIME
Even though this document, or applicable policy, may discourage the Even though this document, or applicable policy, may discourage the
use of some Content-Types, all reading agents SHOULD make some use of some Media Types, all reading agents SHOULD make some
realistic attempt to display at least all text types (especially realistic attempt to display at least all text types (especially
where the Content-Disposition is "inline", even if all that can be where the Content-Disposition is "inline", even if all that can be
done is to exhibit any formatting information as received (thus done is to exhibit any formatting information as received (thus
allowing a suitably knowledgeable reader to interpret it manually). allowing a suitably knowledgeable reader to interpret it manually).
The same applies to unrecognized charsets. It is not expected that The same applies to unrecognized charsets. It is not expected that
reading agents will necessarily be able to present characters in all reading agents will necessarily be able to present characters in all
possible character sets (for example, a reading agent might be able possible charsets (for example, a reading agent might be able to
to present only the ISO-8859-1 (Latin 1) characters [ISO 8859]), but present only the ISO-8859-1 (Latin 1) characters [ISO 8859]), but
where unpresentable characters arise they SHOULD be presented in some where unpresentable characters arise they SHOULD be presented in some
escaped notation, e.g. octal or hexadecimal (rather than as some escaped notation, e.g. octal or hexadecimal (rather than as some
single distinctive glyph or by exhibiting a warning). single distinctive glyph or by exhibiting a warning).
Reading agents MAY interpret image, audio and video Content-Types Reading agents MAY interpret image, audio and video Media Types
inline, but few in fact do so (and the use of such Content-Types is inline, but few in fact do so (and the use of such Media Types is
anyway deprecated in the absence of established policy to the anyway deprecated in the absence of established policy to the
contrary - see 3.1.2.2). Likewise, reading agents MAY interpret contrary - see 3.1.2.2). Likewise, reading agents MAY interpret
"application" types (and SHOULD at least display those types which "application" types (and SHOULD at least display those types which
are inherently textual in nature). However, there are security risks are inherently textual in nature). However, there are security risks
inherent in some application types, and even in "text/html" ([USEFOR] inherent in some application types, and even in "text/html" (P-
9.2.2). Even requiring the reader to click on some icon before 8.2.2). Even requiring the reader to click on some icon before
proceeding with the application has proven notoriously ineffective proceeding with the application has proven notoriously ineffective
against malicious attacks. The only safe alternative is to execute against malicious attacks. The only safe alternative is to execute
the application within a protected environment, or "sandbox", outside the application within a protected environment, or "sandbox", outside
of which its side effects cannot occur. of which its side effects cannot occur.
Of the multipart Content-Types, reading agents MUST handle correctly Of the multipart Media Types, reading agents MUST handle correctly at
at least "multipart/mixed" and "multipart/alternative". Other least "multipart/mixed" and "multipart/alternative". Other multipart
multipart types that are not implemented directly MUST be treated as types that are not implemented directly MUST be treated as
"multipart/mixed". It is a regular practice for some Usenet articles "multipart/mixed". It is a regular practice for some Usenet articles
to consist of digests of other messages or informative documents to consist of digests of other messages or informative documents
(usually known as "FAQ"s). These take the form of digests, as defined (usually known as "FAQ"s). These take the form of digests, as defined
in [RFC 1153] or of the MIME Content-Type "multipart/digest". Reading in [RFC 1153] or of the MIME Media Type "multipart/digest". Reading
agents SHOULD recognize both of these formats and enable the agents SHOULD recognize both of these formats and enable the
individual digest items to be presented separately, as if they were individual digest items to be presented separately, as if they were
separate articles. separate articles.
Reading agents SHOULD honour any Content-Disposition-header that is Usenet Best Practice March 2005
Reading agents SHOULD honour any Content-Disposition header that is
provided (in particular, they SHOULD display any part of a multipart provided (in particular, they SHOULD display any part of a multipart
for which the disposition is "inline", possibly distinguished from for which the disposition is "inline", possibly distinguished from
adjacent parts by some suitable separator). In the absence of such a adjacent parts by some suitable separator). In the absence of such a
header, the body of an article or any part of a multipart with header, the body of an article or any part of a multipart with Media
Content-Type "text" SHOULD be displayed inline. Type "text" SHOULD be displayed inline.
Usenet Best Practice May 2004
3.4. The Well-Behaved Reply Agent 3.4. The Well-Behaved Reply Agent
First and foremost, a reply agent is an Email agent, and therfore its First and foremost, a reply agent is an Email agent, and therfore its
primary responsibility is to generate messages that are compliant primary responsibility is to generate messages that are compliant
with [RFC 2822] and other applicable Email standards and conventions. with [RFC 2822] and other applicable Email standards and conventions.
When a reply is to be emailed to the poster of an article, the reply When a reply is to be emailed to the poster of an article, the reply
agent MUST initially create a To-header from the Reply-To- or From- agent MUST initially create a To header from the Reply-To or From
header, as appropriate, of the precursor. header, as appropriate, of the precursor.
NOTE: A distinction is to be made between when a reply is NOTE: A distinction is to be made between when a reply is
emailed to the poster of an article, and when such a reply is emailed to the poster of an article, and when such a reply is
also posted during the course of generating a followup; in the also posted during the course of generating a followup; in the
latter case (but not the former) it is expected that any Mail- latter case (but not the former) it is expected that any Mail-
Copies-To header will have been observed. Copies-To header will have been observed.
Note also that use of the Posted-And-Mailed header is Note also that use of the Posted-And-Mailed header is
appropriate whenever a message is both posted and emailed, appropriate whenever a message is both posted and emailed,
whether or not this is done during the course of a formal whether or not this is done during the course of a formal
followup. followup.
[Remove those NOTEs if those headers disappear.]
Since addresses ending in ".invalid" are undeliverable, reply agents Since addresses ending in ".invalid" are undeliverable, reply agents
SHOULD warn any user attempting to reply to them and SHOULD NOT, in SHOULD warn any user attempting to reply to them and SHOULD NOT, in
any case, attempt to deliver to them (since that would be pointless any case, attempt to deliver to them (since that would be pointless
anyway). anyway).
3.5. User Interfaces 3.5. User Interfaces
[At this point we need to consider whether to add a section regarding The basic functionalities provided to the poster MUST include the
the user interfaces to NUAs (commands/menus and the like). There is much following:
in the GNKSA of that nature which we might choose to adopt. Indeed, the o To Post a new article;
next step should be a careful comparison of what is contained in the o To Followup to a an existing article;
GNKSA and what has been said here, since there are undoubtedly cases o To Reply by email to the poster of an existing article (assuming,
where are requirements are less strict that those put forward in the of course, that an email capability is available);
GNKSA, and vice versa. Such a comparison might suggest some further and SHOULD include
changes and features to be considered for this draft.] o To Cancel or Supersede articles previously posted by that same
user (though this mechanism MUST NOT be available for other
people's articles).
The commands provided to the user to instigate these operations
SHOULD, in the case of agents designed for English speakers at least,
make use of the words "Post", "Followup", "Reply" and "Cancel" (or of
their initial letters). It is NOT sufficient, particularly in the
case of user agents intended for dual Email and Netnews use, simply
to re-use the words for the corresponding Email operations (such as
"Send" instead of "Post" or "Reply" instead of "Followup" or "Delete"
Usenet Best Practice March 2005
instead of "Cancel"). It SHOULD be immediately evident to an
ordinary, untrained user which command to use for each of the
operations.
There MAY also be a separate facility encompassing "Followup and
Reply", but in that case the provisions of any Mail-Copies-To header
in the precursor (3.2.1.3) SHOULD be observed. It SHOULD be possible
to switch between the Followup, Reply and "do both" commands, even
after the article body has been edited. If, for whatever reason,
there is only one command encompassing all of these operations, its
default action MUST be to Reply (with no possibility to configure it
otherwise).
The user is responsible for providing at least the Newsgroups and
Subject headers of the new article; in the case of Followups and
Replies, it is usual for the user agent to provide defaults for
these, but in all cases facilites for the user to edit these MUST be
provided. In particular, it MUST be possible to specify multiple
Newsgroups (the effect of which MUST be for them to be cross-posted
rather than multi-posted), but the poster SHOULD be prevented (or at
least warned) from excessive crossposting and SHOULD be offered the
opportunity to set a Followup-To header if he insists on an excessive
cross-post. Excessive numbers of newsgroups in a Followup-To header
SHOULD be discouraged likewise.
The user MUST be warned (and SHOULD be prevented) if he attempts to
post an article whose body is empty, or which contains only quoted
text.
When the article is finally posted, the user MUST be warned (with
severe wording) (and SHOULD be prevented) if he attempts to post the
same article again, unless the system is able to report explicitly
that the original posting had failed.
See section 3.1 for further requirements and recommendations to be
followed when posting articles.
4. The Well-Behaved Injecting Agent 4. The Well-Behaved Injecting Agent
The injecting agent bears a responsibility towards the rest of the The injecting agent bears a responsibility towards the rest of the
network for ensuring both that the articles it injects are compliant network for ensuring both that the articles it injects are compliant
with [USEFOR], and that they conform with the general expectations of with [USEFOR], and that they conform with the general expectations of
the rest of the network as to what constitutes "proper behaviour". the rest of the network as to what constitutes "proper behaviour".
[USEFOR] therefore imposes a duty on it to check articles for [USEPRO] therefore imposes a duty on it to check articles for
compliance rather thoroughly, but also a general duty to be compliance rather thoroughly, but also a general duty to be
responsive to complaints concerning the behaviour of those who are responsive to complaints concerning the behaviour of those who are
permitted to post through it. permitted to post through it.
An injecting agent MAY take account of the policies of any newsgroups An injecting agent MAY take account of the policies of any newsgroups
or hierarchies that the article is posted to (though it would be or hierarchies that the article is posted to (though it would be
unreasonable to expect it to be aware of the policies and unreasonable to expect it to be aware of the policies and
idiosyncrasies of all the hierarchies that it might encounter). idiosyncrasies of all the hierarchies that it might encounter).
Usenet Best Practice May 2004 Usenet Best Practice March 2005
As part of their responsibility for the actions of their posters, As part of their responsibility for the actions of their posters,
injecting agents MAY cancel articles which they have previously injecting agents MAY cancel articles which they have previously
injected ([USEFOR] 7.3). injected (P-6.3).
[That paragraph will move back to USEFOR if the rules governing who may [That paragraph will move back to USEPRO if the rules governing who may
issue cancels are moved back.] issue cancels are moved back.]
4.1. Construction of Headers 4.1. Construction of Headers
According to [USEFOR], an injecting agent MAY add other headers not According to [USEPRO], an injecting agent MAY add other headers not
already provided by the poster, but SHOULD NOT alter, delete, or already provided by the poster, but SHOULD NOT alter, delete, or
reorder any existing header. However, the addition of non-mandatory reorder any existing header. However, the addition of non-mandatory
headers by the injecting agent may alter the posting agent's headers by the injecting agent may alter the posting agent's
preferred presentation of information. preferred presentation of information.
Insofar as the injecting agent needs to add headers not present in Insofar as the injecting agent needs to add headers not present in
the proto-article (whether mandatory headers or otherwise), it MUST the proto-article (whether mandatory headers or otherwise), it MUST
also behave as a well-behaved posting agent (3.1) with regard to also behave as a well-behaved posting agent (3.1) with regard to
those headers, including the insertion of appropriate folding so as those headers, including the insertion of appropriate folding so as
to keep line lengths within the accepted limits. to keep line lengths within the accepted limits.
4.1.1. Sender 4.1.1. Sender
The generation of the Sender-header is to be regarded as the The generation of the Sender header is to be regarded as the
responsibility of the posting agent. Although adding this header by responsibility of the posting agent. Although adding this header by
injecting agents is not forbidden by [USEFOR] (though overwriting an injecting agents is not forbidden by [USEPRO] (though overwriting an
existing one is), and although some agents indeed do so, this existing one is), and although some agents indeed do so, this
practice SHOULD be phased out. Exposing a sender's mailbox has practice SHOULD be phased out. Exposing a sender's mailbox has
privacy implications; where the main or only purpose for doing so is privacy implications; where the main or only purpose for doing so is
as tracing information, it is preferable to use instead one of the as tracing information, it is preferable to use instead one of the
options provided for the Injection-Info-header. options provided for the Injection-Info header.
4.1.2. Organization 4.1.2. Organization
The general discouragement from providing a default value for this The general discouragement from providing a default value for this
header (3.1.1.7) applies even more to injecting agents. Where all the header (3.1.1.7) applies even more to injecting agents. Where all the
posters using a given injecting agent belong to a single posters using a given injecting agent belong to a single
organization, including the name of that organization as the default organization, including the name of that organization as the default
might well be reasonable. But if the injecting agent is merely might well be reasonable. But if the injecting agent is merely
providing a service to the general public, providing the name of the providing a service to the general public, providing the name of the
service provider as the default organization is mere advertising, and service provider as the default organization is mere advertising, and
makes no allowance for the possibility that subscribers to the makes no allowance for the possibility that subscribers to the
service who do not provide an Organization-header of their own might service who do not provide an Organization header of their own might
prefer not to have one at all. prefer not to have one at all.
4.1.3. User-Agent 4.1.3. User-Agent
There is provision in [USEFOR] for injecting agents to include (or There is provision in [USEPRO] for injecting agents to include (or
augment if already present) a User-Agent-header to identify the augment if already present) a User-Agent header to identify the
software that they use but, again, use as an advertising medium (in software that they use but, again, use as an advertising medium (in
the mundane sense) is discouraged (cf. 3.1.1.10). the mundane sense) is discouraged (cf. 3.1.1.10).
Usenet Best Practice May 2004 Usenet Best Practice March 2005
4.1.4. Injection-Info 4.1.4. Injection-Info
Various headers such as NNTP-Posting-[Host, Date, etc.] (which Various headers such as NNTP-Posting-[Host, Date, etc.] (which
actually had nothing to do with NNTP) and X-trace have not been actually had nothing to do with NNTP) and X-trace have not been
standardized in [USEFOR], but have instead been incporporated in the standardized in [USEFOR], but have instead been incporporated in the
new Injection-Info-header (whose syntax incorporates more room for new Injection-Info header (whose syntax incorporates more room for
future extension). Use of those headers SHOULD therefore be phased future extension). Use of those headers SHOULD therefore be phased
out. out.
The purpose of the various parameters of the Injection-Info-header is The purpose of the various parameters of the Injection-Info header is
to enable the injecting agent to make assertions about the origin of to enable the injecting agent to make assertions about the origin of
the article, in fulfilment of its responsibilities towards the rest the article, in fulfilment of its responsibilities towards the rest
of the network. These assertions can then be utilized as follows: of the network. These assertions can then be utilized as follows:
1. To enable the administrator of the injecting agent to respond to 1. To enable the administrator of the injecting agent to respond to
complaints and queries concerning the article. For this purpose, complaints and queries concerning the article. For this purpose,
the parameters included SHOULD be sufficient to enable the the parameters included SHOULD be sufficient to enable the
administrator to identify its true origin (which parameters are administrator to identify its true origin (which parameters are
best suited to this purpose will vary with the nature of the best suited to this purpose will vary with the nature of the
injecting site and of its relationship to the posters who use it - injecting site and of its relationship to the posters who use it -
skipping to change at page 25, line 54 skipping to change at page 28, line 54
indirectly, thus affording more privacy to posters who value indirectly, thus affording more privacy to posters who value
their anonymity, but also making harder the tracking of their anonymity, but also making harder the tracking of
malicious disruption of the network, especially so if the malicious disruption of the network, especially so if the
administrators choose not to cooperate. There is thus a balance administrators choose not to cooperate. There is thus a balance
to be struck between the needs of privacy on the one hand and to be struck between the needs of privacy on the one hand and
the good order of Usenet on the other, and administrators need the good order of Usenet on the other, and administrators need
to be aware of this when formulating their policies. to be aware of this when formulating their policies.
5. The Well-Behaved Relaying Agent 5. The Well-Behaved Relaying Agent
[USEFOR] establishes as a basic principle that relaying agents are [USEPRO] establishes as a basic principle that relaying agents are
not to alter articles in any way during transmission (except for not to alter articles in any way during transmission (except for
those headers explicitly defined to be "variant"). This applies even those headers explicitly defined to be "variant"). This applies even
if the article is perceived not to be conformant with [USEFOR]; in if the article is perceived not to be conformant with [USEFOR]; in
such a case it MUST either be passed on as it stands, or else it such a case it MUST either be passed on as it stands, or else it
should be discarded altogether. In this way, it will be ensured that should be discarded altogether. In this way, it will be ensured that
all copies of a given article, wherever they appear throughout all copies of a given article, wherever they appear throughout
Usenet Best Practice May 2004
Usenet Best Practice March 2005
Usenet, will be identical. Usenet, will be identical.
In particular, [USEFOR] requires serving and relaying agents to In particular, [USEPRO] requires serving and relaying agents to
accept any syntactially correct newsgroup-name in Newsgroups-headers, accept any syntactially correct <newsgroup-name> in Newsgroups
even if it would violate one or more of the policy restrictions set headers, even if it would violate one or more of the policy
out in section 7.2; i.e. the injecting agent is the last place for restrictions set out in section 7.2; i.e. the injecting agent is the
such checks to be made (3.1.1.5). last place for such checks to be made (3.1.1.5).
Even if relaying agents do not, as a matter of local policy, intend
to honour certain control messages, they MUST still propagate them in
the normal manner.
5.1. The Path Header 5.1. The Path Header
It is important to be able to determine where a given article was It is important to be able to determine where a given article was
injected into Usenet and the route it took to reach each site at injected into Usenet and the route it took to reach each site at
which it appears. Both the Path- and Injection-Info-headers have an which it appears. Both the Path and Injection-Info headers have an
important part to play in this. [USEFOR] therefore imposes a strong important part to play in this. [USEPRO] therefore imposes a strong
obligation on relaying agents to verify where articles reached them obligation on relaying agents to verify where articles reached them
from and to record this information in the Path-header. It is from and to record this information in the Path header. It is
important that these new requirements in [USEFOR] be adopted by all important that these new requirements in [USEPRO] be adopted by all
injecting and relaying agents at the earliest opportunity. injecting and relaying agents at the earliest opportunity.
[However, the precise form of the Path header is still under
discussion.]
5.1.1. Suggested Verification Methods 5.1.1. Suggested Verification Methods
It is preferable to verify the claimed path-identity against the It is preferable to verify the claimed <path-identity> against the
source than to make routine use of the '?' path-delimiter ([USEFOR] source than to make routine use of the '?' <path-delimiter> with
5.6.1), with consequential wasteful double-entry Path additions. consequential wasteful double-entry Path additions.
If the incoming article arrives through some TCP/IP protocol such as If the incoming article arrives through some TCP/IP protocol such as
NNTP, the IP address of the source will be known, and will likely NNTP, the IP address of the source will be known, and will likely
already have been checked against a list of known FQDNs, IP already have been checked against a list of known FQDNs, IP
addresses, or other registered aliases that the receiving site has addresses, or other registered aliases that the receiving site has
agreed to peer with. agreed to peer with.
Since the source host may have several IP addresses, checking the Since the source host may have several IP addresses, checking the
claimed FQDN or IP address against the source IP, or finding a claimed FQDN or IP address against the source IP, or finding a
suitable FQDN to report with a '?' path-delimiter, may involve suitable FQDN to report with a '?' <path-delimiter>, may involve
several DNS lookups, following CNAME chains as required. Note that several DNS lookups, following CNAME chains as required. Note that
any reverse DNS lookup that is involved needs to be confirmed by a any reverse DNS lookup that is involved needs to be confirmed by a
forward one. forward one.
If the incoming article arrives through some other protocol, such as If the incoming article arrives through some other protocol, such as
UUCP, that protocol MUST include a means of verifying the source UUCP, that protocol MUST include a means of verifying the source
site. In UUCP implementations, commonly each incoming connection has site. In UUCP implementations, commonly each incoming connection has
a unique login name and password, and that login name (or some alias a unique login name and password, and that login name (or some alias
registered for it) would be expected as the path-identity. registered for it) would be expected as the <path-identity>.
If none of these methods is applicable, relaying agents SHOULD If none of these methods is applicable, relaying agents SHOULD
require connecting hosts to identify themselves using some require connecting hosts to identify themselves using some
cryptographic authentication mechanism. cryptographic authentication mechanism (e.g. [NNTP-AUTH]).
[What references should be given here? SASL?]
Usenet Best Practice March 2005
6. The Well-Behaved Serving Agent 6. The Well-Behaved Serving Agent
The principles set out in section 5 regarding not altering articles The principles set out in section 5 regarding not altering articles
in any way apply equally to serving agents. The article as stored in any way apply equally to serving agents. The article as stored
MUST be identical to the article as injected (variant headers MUST be identical to the article as injected (variant headers
Usenet Best Practice May 2004
excepted). excepted).
Serving agents commonly insert an Xref header into articles that they
store (P-7.4) so as to enable reading agents to avoid displaying that
article in more than one of the groups that it is crossposted to, and
to enable them to distinguish that particular serving agent from
others known to them. It is convenient, though not required, for a
serving agent to use the same <server-name> in Xref headers as the
<path-identity> it inserts into Path headers.
6.1. Control Messages 6.1. Control Messages
Serving agents SHOULD deny group control messages ([USEFOR] 7.2) not Serving agents SHOULD deny group control messages not issued by the
issued by the appropriate administrative agencies, and therefore appropriate administrative agencies, and therefore SHOULD take such
SHOULD take such steps as are reasonably practicable to validate steps as are reasonably practicable to validate their authenticity,
their authenticity, e.g. by checking digital signatures in cases e.g. by checking digital signatures in cases where they are provided.
where they are provided.
6.1.1. The 'newgroup' and 'mvgroup' Control Messages 6.1.1. The 'newgroup' and 'mvgroup' Control Messages
Serving agents SHOULD, insofar as they are conveniently able to, Serving agents SHOULD, insofar as they are conveniently able to,
reject all 'newgroup' and 'mvgroup' messages not meeting the policies reject all 'newgroup' and 'mvgroup' messages not meeting the policies
of the relevant hierarchy. of the relevant hierarchy.
Since the 'mvgroup' control message was a feature newly introduced by Since the 'mvgroup' control message was a feature newly introduced by
[USEFOR], the requirements set for it were relatively light, so as to [USEPRO], the requirements set for it were relatively light, so as to
facilitate a rapid deployment within Usenet (treating it as a facilitate a rapid deployment within Usenet (treating it as a
'newgroup' message is minimally conformant). Nevertheless, to achieve 'newgroup' message is minimally conformant). Nevertheless, to achieve
full benefit, serving agents need to arrange to service requests for full benefit, serving agents need to arrange to service requests for
access to the old group by providing access to the new. [USEFOR] access to the old group by providing access to the new. [USEPRO]
states how that MAY be done, but this documents goes further; serving states how that MAY be done, but this documents goes further; serving
agents SHOULD be upgraded to do so at the earliest opportunity. agents SHOULD be upgraded to do so at the earliest opportunity.
6.1.2. Cancel Messages 6.1.2. Cancel Messages
A cancel message may be issued in the following circumstances. A cancel message may be issued in the following circumstances.
1. The poster of an article (or, more specifically, any entity 1. The poster of an article (or, more specifically, any entity
mentioned in the From-header or the Sender-header, whether or not mentioned in the From header or the Sender header, whether or not
that entity was the actual poster) is always entitled to issue a that entity was the actual poster) is always entitled to issue a
cancel message for that article, and serving agents SHOULD honour cancel message for that article, and serving agents SHOULD honour
such requests. Posting agents SHOULD facilitate the issuing of such requests. Posting agents SHOULD facilitate the issuing of
cancel messages by posters fulfilling these criteria. cancel messages by posters fulfilling these criteria.
2. The agent which injected the article onto the network (more 2. The agent which injected the article onto the network (more
specifically, the entity identified by the path-identity in front specifically, the entity identified by the <path-identity> in
of the leftmost '%' delimiter in the Path-header or in the front of the leftmost '%' delimiter in the Path header or in the
Injection-Info-header and, where appropriate, the moderator (more Injection-Info header and, where appropriate, the moderator (more
specifically, any entity mentioned in the Approved-header) is specifically, any entity mentioned in the Approved header) is
always entitled to issue a cancel message for that article, and always entitled to issue a cancel message for that article, and
Usenet Best Practice March 2005
serving agents SHOULD honour such requests. serving agents SHOULD honour such requests.
3. Other entities MAY be entitled to issue a cancel message for that 3. Other entities MAY be entitled to issue a cancel message for that
article, in circumstances where established policy for any article, in circumstances where established policy for any
hierarchy or group in the Newsgroup-header, or established custom hierarchy or group in the Newsgroups header, or established custom
within Usenet, so allows (such policies and customs are not within Usenet, so allows (such policies and customs are not
defined by this document). Such cancel messages MUST include an defined by this document). Such cancel messages MUST include an
Approved-header identifying the responsible entity. Serving agents Approved header identifying the responsible entity. Serving agents
MAY honour such requests, but SHOULD first take steps to verify MAY honour such requests, but SHOULD first take steps to verify
their appropriateness. their appropriateness.
[There was one request to move that back into [USEPRO]. Any one else?]
Usenet Best Practice May 2004
[There was one request to move that back into [USEFOR]. Any one else?]
7. The Well-Behaved Hierarchy Administrator 7. The Well-Behaved Hierarchy Administrator
The term "hierarchy administrator" means any agency responsible for The term "hierarchy administrator" means any agency responsible for
administration of a (sub-)hierarchy (1.1), or in the absence of such administration of a (sub-)hierarchy (1.1), or in the absence of such
an agency, the custom and usage generally accepted for that an agency, the custom and usage generally accepted for that
(sub-)hierarchy, insofar as such can be determined. (sub-)hierarchy, insofar as such can be determined.
7.1. Control Messages 7.1. Control Messages
In those hierarchies where appropriate administrative agencies exist In those hierarchies where appropriate administrative agencies exist
(see 1.1), group control messages SHOULD NOT be issued except as (see 1.1), group control messages SHOULD NOT be issued except as
authorized by those agencies, in which case the administrator needs authorized by those agencies, in which case the administrator needs
to establish just what person (or other entity) is to be permitted to to establish just what person (or other entity) is to be permitted to
issue those messages; moreover he should at the same time establish s issue those messages; moreover he should at the same time establish s
digital signature key to be used for authenticating them ([USEFOR] digital signature key to be used for authenticating them (P-6.1), and
7.1), and finally he SHOULD ensure that this information is widely finally he SHOULD ensure that this information is widely promulgated
promulgated for use by serving agents worldwide. for use by serving agents worldwide.
For compatibility with legacy news software, the Subject-content of a Those issuing control messages should be aware that the former
control message (i.e. an article that also contains a Control-header) practice of using a Subject starting with "cmsg" in lieu of a control
MAY start with the string "cmsg ", and non-control messages SHOULD message is now deprecated (3.1.1.4) although they MAY continue to use
NOT start with the string "cmsg ". that convention in addition to using a proper Control leader.
[SHOULD NOT changed from MUST NOT. Do there really still exist servers
or other agents that will recognize and act upon "cmsg" in a Subject-
header? And if so, maybe that MUST NOT should be moved back into
[USEFOR].]
The newsgroup-name in 'newgroup' control messages (and the second The <newsgroup-name> in 'newgroup' control messages (and the second
(new-)newsgroup-name in 'mvgroup' control messages) SHOULD conform to <(new-)newsgroup-name> in 'mvgroup' control messages) SHOULD conform
whatever policies have been established by the administrator (7.2). to whatever policies have been established by the administrator
(7.2).
Although, in accordance with [RFC 2822] and [USEFOR], a newsgroups- Although, in accordance with [RFC 2822], a <newsgroups-line> (as
line (as found in both 'newgroup' and 'checkgroups' messages) could found in both 'newgroup' and 'checkgroups' messages) could have a
have a maximum length of 998 octets, as a matter of policy a far maximum length of 998 octets, as a matter of policy a far lower
lower limit, expressed in characters, SHOULD be set. The current limit, expressed in characters, SHOULD be set. The current convention
convention is to limit its length so that the newsgroup-name, the is to limit its length so that the <newsgroup-name>, the HTAB(s)
HTAB(s) (interpreted as 8-character tabs that takes one at least to (interpreted as 8-character tabs that takes one at least to column
column 24) and the newsgroup-description (excluding any moderation- 24) and the <newsgroup-description> (excluding any <moderation-flag>)
flag) fit into 79 characters. This document does not seek to enforce fit into 79 characters. This document does not seek to enforce any
any such rule, but any decision to extend it should be made as a such rule, but any decision to extend it should be made as a specific
specific decision for the hierarchy. Reading agents SHOULD therefore decision for the hierarchy. Reading agents SHOULD therefore enable a
enable a newsgroups-line of any length to be displayed, e.g. by <newsgroups-line> of any length to be displayed, e.g. by wrapping it
wrapping it as required. as required.
Usenet Best Practice March 2005
7.2. Naming of Newsgroups 7.2. Naming of Newsgroups
Because group control messages can only be issued on the authority of Because group control messages can only be issued on the authority of
the responsible agency, it follows that the agency has complete the responsible agency, it follows that the agency has complete
control of the names of the newsgroups to be considered as valid control of the names of the newsgroups to be considered as valid
members of that (sub-)hierarchy. Consequently, it needs to establish members of that (sub-)hierarchy. Consequently, it needs to establish
policies for the format of the newsgroup-names it intends to permit; policies for the format of the <newsgroup-name>s it intends to
Usenet Best Practice May 2004 permit; these policies can be both technical and aesthetic.
these policies can be both technical and aesthetic.
[USEFOR] provides by default the following technical restrictions [USEFOR] provides by default the following technical restrictions
upon which hierarchy administrators can then build, and which SHOULD upon which hierarchy administrators can then build, and which SHOULD
in any case be applied in hierarchies not subject to such management. in any case be applied in hierarchies not subject to such management.
[Well, it doesn't provide them yet, but it needs to.]
NOTE: These restrictions are intended to reflect existing NOTE: These restrictions are intended to reflect existing
practice and are intended both to avoid certain technical practice and are intended both to avoid certain technical
difficulties and to avoid unnecessary confusion. They may well difficulties and to avoid unnecessary confusion. They may well
change over time in the light of future experience. change over time in the light of future experience.
1. Uppercase letters are forbidden. 1. Uppercase letters are forbidden.
NOTE: Traditionally, newsgroup-names have been written in NOTE: Traditionally, <newsgroup-name>s have been written in
lowercase. However, posting agents SHOULD NOT convert uppercase lowercase. However, posting agents SHOULD NOT convert uppercase
characters to the corresponding lowercase forms except under the characters to the corresponding lowercase forms except under the
explicit instructions of the poster. explicit instructions of the poster.
2. A component name is forbidden to consist entirely of digits. 2. A <component> is forbidden to consist entirely of digits.
NOTE: This requirement was in [RFC 1036] but nevertheless NOTE: This requirement was in [RFC 1036] but nevertheless
several such groups have appeared in practice and implementors several such groups have appeared in practice and implementors
should be prepared for them. A common implementation technique should be prepared for them. A common implementation technique
uses each component as the name of a directory and uses numeric uses each <component> as the name of a directory and uses
filenames for each article within a group. Such an numeric filenames for each article within a group. Such an
implementation needs to be careful when this could cause a clash implementation needs to be careful when this could cause a clash
(e.g. between article 123 of group xxx.yyy and the directory for (e.g. between article 123 of group xxx.yyy and the directory for
group xxx.yyy.123). Once the latter group exists, the group xxx.yyy.123). Once the latter group exists, the
subsequent creation of the former would be precluded for all subsequent creation of the former would be precluded for all
time. time.
3. A component is limited to 30 component-graphemes and a newsgroup- 3. A <component> is limited to 30 <component-char>s and a
name to 66 component-graphemes (counting also the '.'s separating <newsgroup-name> to 66 <component-char>s (counting also the '.'s
the components). separating the <component>s).
NOTE: Whilst there is no longer any technical reason to limit NOTE: Whilst there is no longer any technical reason to limit
the length of a component (formerly, it was limited to 14 the length of a <component> (formerly, it was limited to 14
octets) nor of a newsgroup-name, it should be noted that these octets) nor of a <newsgroup-name>, it should be noted that these
names are also used in the newsgroups-line where another overall names are also used in the <newsgroups-line> where another
policy limit applies (7.1) and, moreover, excessively long names overall policy limit applies (7.1) and, moreover, excessively
can be exceedingly inconvenient in practical use. The 66 limit long names can be exceedingly inconvenient in practical use. The
on newsgroup-names ensures that a Followup-To-Header with such a 66 limit on <newsgroup-name>s ensures that a Followup-To Header
name will still fit within 79 characters overall. with such a name will still fit within 79 characters overall.
Usenet Best Practice March 2005
In the event that some future extension to [USEFOR] allows In the event that some future extension to [USEFOR] allows
internationalized newsgroup-names including non-ASCII characters, internationalized <newsgroup-name>s including non-ASCII characters,
there will be further technical issues to be taken into account, there will be further technical issues to be taken into account,
including: including:
4. What non-ASCII punctuations and other symbols are to be allowed. 4. What non-ASCII punctuations and other symbols are to be allowed.
5. What normalizations need to be observed to overcome multiple ways 5. What normalizations need to be observed to overcome multiple ways
of constructing glyphs with identical or similar appearance. of constructing glyphs with identical or similar appearance.
Usenet Best Practice May 2004 6. Restrictions on mixing alphabets within one <component> of a name
6. Restrictions on mixing alphabets within one component of a name
(so as to avoid confusion between, for example, Latin A and Greek (so as to avoid confusion between, for example, Latin A and Greek
Alpha, and similar confusions between some Latin and Cyrillic Alpha, and similar confusions between some Latin and Cyrillic
letters - though retaining the restriction on uppercase letters letters - though retaining the restriction on uppercase letters
will mitigate these problems somewhat). will mitigate these problems somewhat).
Aesthetic reasons for policy limitations are likely to include Aesthetic reasons for policy limitations are likely to include
insistence upon a clear hierarchical structure (the tree of names insistence upon a clear hierarchical structure (the tree of names
needs to be neither too broad nor too deep), that the components of needs to be neither too broad nor too deep), that the <component>s of
newsgroup-names are meaningful in the context of the language(s) <newsgroup-name>s are meaningful in the context of the language(s)
expected to be used, that frivolous names are avoided, and that expected to be used, that frivolous names are avoided, and that
abbreviations are likely to be recognized by the intended readership. abbreviations are likely to be recognized by the intended readership.
[David Wright has a FAQ on hierarchical naming which might give us some [David Wright has a FAQ on hierarchical naming which might give us some
help.] help.]
7.3. Format of Bodies 7.3. Format of Bodies
Hierarchy administrators MAY declare, as a matter of policy, which Hierarchy administrators MAY declare, as a matter of policy, which
languages and charsets are to be considered appropriate within their languages and charsets are to be considered appropriate within their
hierarchies (or within particular groups). Whereas in principle, any hierarchies (or within particular groups). Whereas in principle, any
character set may be specified in the "charset=" parameter of a character set may be specified in the "charset=" parameter of a Media
Content-Type, readers cannot be expected to possess agents capable of Type, readers cannot be expected to possess agents capable of
displaying characters not needed for those chosen languages, hence displaying characters not needed for those chosen languages, hence
administrators SHOULD choose charsets accordingly and/or limit the administrators SHOULD choose charsets accordingly and/or limit the
planes to be allowed within charsets based on [UNICODE 3.2], such planes to be allowed within charsets based on [UNICODE 3.2], such
UTF-8. UTF-8.
The document has already provided (3.1.2,3.2.2) for a default limit This document has already provided (3.1.2,3.2.2) for a default limit
on the length of lines (79, or preferably 72) within plain-text on the length of lines (79, or preferably 72) within plain-text
articles, and hierarchy administrators MAY change this, as a matter articles, and hierarchy administrators MAY change this, as a matter
of policy (though there would seems to be little reason to do so of policy (though there would seems to be little reason to do so
except where the intended language and charsets so dictate - e.g. except where the intended language and charsets so dictate - e.g.
because of a need to use double-width characters). because of a need to use double-width characters).
This document has also limited (3.1.2.2), by default, the Content- This document has also limited (3.1.2.2), by default, the Media types
types that may be used in articles to "text/plain". Hierarchy that may be used in articles to "text/plain". Hierarchy
administrators MAY relax this, as a matter of policy (by allowing, administrators MAY relax this, as a matter of policy (by allowing,
for example, "text/http", the "binary" types "audio", "image" and for example, "text/http", the "binary" types "audio", "image" and
"video", and selected "application" types), and they MAY similarly "video", and selected "application" types), and they MAY similarly
regulate the use of "message/partial". regulate the use of "message/partial".
Hierarchy administrators MAY also impose other restrictions relevant Hierarchy administrators MAY also impose other restrictions relevant
to the nature of their hierarchy, such as limits on the overall size to the nature of their hierarchy, such as limits on the overall size
of articles, on the length of signatures, the topics to be discussed of articles, on the length of signatures, the topics to be discussed
Usenet Best Practice March 2005
(usually set out in a charter for each newsgroup) and the extent of (usually set out in a charter for each newsgroup) and the extent of
advertising to be permitted. advertising to be permitted.
7.4. Promulgation 7.4. Promulgation
The policies established by each hierarchy administrator SHOULD be The policies established by each hierarchy administrator SHOULD be
publicised (in the form of guidelines, FAQs and charters) in suitable publicised (in the form of guidelines, FAQs and charters) in suitable
*.announce groups within each hierarchy, and also on suitable web *.announce groups within each hierarchy, and also on suitable web
sites (although it should be understood that Usenet exists as a sites (although it should be understood that Usenet exists as a
separate entity from the World Wide Web, and it would be wrong to separate entity from the World Wide Web, and it would be wrong to
Usenet Best Practice May 2004
assume that every Usenet user has web - or even email - access). assume that every Usenet user has web - or even email - access).
NOTE: The promulgation of policies is one thing; the enforcement NOTE: The promulgation of policies is one thing; the enforcement
of policies is quite another. With the exception of newsgroup- of policies is quite another. With the exception of <newsgroup-
names, for which technical controls exist, policy enforcement is name>s, for which technical controls exist, policy enforcement
a matter of peer pressure (which, when consistently applied, can is a matter of peer pressure (which, when consistently applied,
be remarkably effective), possibly with the aid of the can be remarkably effective), possibly with the aid of the
administrators of injecting agents through their ability, and administrators of injecting agents through their ability, and
even duty (4), to apply disciplinary pressure to their users. even duty (4), to apply disciplinary pressure to their users.
8. The Well-Behaved Moderator 8. The Well-Behaved Moderator
A moderator MAY inform the poster if an article is accepted, and he A moderator MAY inform the poster if an article is accepted, and he
SHOULD inform the poster if it is rejected (except where it appears SHOULD inform the poster if it is rejected (except where it appears
to be a deliberate and malicious attempt to disrupt). to be a deliberate and malicious attempt to disrupt).
A moderator SHOULD NOT (absent any established and widely promulgated A moderator SHOULD NOT (absent any established and widely promulgated
policy to the contrary) remove any newsgroup-name from the policy to the contrary) remove any <newsgroup-name> from the
Newsgroups-header, nor split an article into two versions with Newsgroups header, nor split an article into two versions with
disjoint Newsgroups-headers. These are matters more usually within disjoint Newsgroups headers. These are matters more usually within
the prerogative of the poster; moreover splitting can lead to the prerogative of the poster; moreover splitting can lead to
fragmentation of threads. fragmentation of threads.
9. The Well-Behaved Poster 9. The Well-Behaved Poster
[What you see here is but the tip of a very large iceberg, being the [What you see here is but the tip of a very large iceberg, being the
particular advice to posters which has been transported the earlier particular advice to posters which has been transported from the earlier
drafts of [USEFOR]. There is much more that could, and probably should, drafts of [ARTICLE]. There is much more that could, and probably
be said. should, be said.
However, it would first be advsisable to study [RFC 1855] and to decide However, it would first be advsisable to study [RFC 1855] and to decide
whether we want to adopt and adapt what is already stated there, even to whether we want to adopt and adapt what is already stated there, even to
the extent of obsoleting it entirely.] the extent of obsoleting it entirely.]
9.1. Construction of Headers 9.1. Construction of Headers
Posters SHOULD NOT include redundant headers such as Reply-To and Posters SHOULD NOT include redundant headers such as Reply-To and
Followup-To that merely duplicate the defaults (c.f. 3.1.1.6 and Followup-To that merely duplicate the defaults (c.f. 3.1.1.6 and
3.1.1.9). 3.1.1.9).
Usenet Best Practice March 2005
9.1.1. From 9.1.1. From
Whether or not a valid address can subsequently be extracted from an Whether or not a valid address can subsequently be extracted from an
address ending in ".invalid" falls outside the scope of this document address ending in ".invalid" falls outside the scope of this document
but, obviously, posters wishing to disguise their address should not but, obviously, posters wishing to disguise their address should not
suppose that just adding ".invalid" to it will achieve that effect. suppose that just adding ".invalid" to it will achieve that effect.
9.1.2. Summary 9.1.2. Summary
The summary should be terse. Posters SHOULD avoid trying to cram The summary should be terse. Posters SHOULD avoid trying to cram
their entire article into the headers; even the simplest query their entire article into the headers; even the simplest query
usually benefits from a sentence or two of elaboration and context, usually benefits from a sentence or two of elaboration and context,
and not all reading agents display all headers. On the other hand the and not all reading agents display all headers. On the other hand the
summary should give more detail than the Subject. summary should give more detail than the Subject.
Usenet Best Practice May 2004
9.1.3. Expires 9.1.3. Expires
An Expires-header should only be used in an article if the requested An Expires header should only be used in an article if the requested
expiry time is earlier or later than the time typically to be expiry time is earlier or later than the time typically to be
expected for such articles. Local policy for each serving agent will expected for such articles (for example, a notice for a meeting to be
dictate whether and when this header is obeyed and posters SHOULD NOT held tomorrow on the one hand, or a FAQ which should remain on
depend on it being completely followed. servers until its next issue on the other). Local policy for each
serving agent will dictate whether and when this header is obeyed and
posters SHOULD NOT depend on it being completely followed.
9.2. Construction of Bodies 9.2. Construction of Bodies
Posters SHOULD avoid using control characters and escape sequences Posters SHOULD avoid using control characters and escape sequences
except for tab (US-ASCII 9), formfeed (US-ASCII 12) and, possibly, except for tab (US-ASCII 9), formfeed (US-ASCII 12) and, possibly,
backspace (US-ASCII 8), for reasons already explained in section backspace (US-ASCII 8), for reasons already explained in section
3.3.2. 3.3.3.
NOTE: Backspace was historically used for underlining, done by NOTE: Backspace was historically used for underlining, done by
an underscore (US-ASCII 95), a backspace, and a character, an underscore (US-ASCII 95), a backspace, and a character,
repeated for each character that should be underlined. Posters repeated for each character that should be underlined. Posters
are warned that underlining is not available on all output are warned that underlining is not available on all output
devices or supported by all reading agents and is best not devices or supported by all reading agents and is best not
relied on for essential meaning. relied on for essential meaning.
When preparing followups, posters SHOULD edit quoted context to trim When preparing followups, posters SHOULD edit quoted context to trim
it down to the minimum necessary. it down to the minimum necessary.
Posters SHOULD observe the policies established for each hierarchy Posters SHOULD observe the policies established for each hierarchy
(7.3) or, in the absence of such policies, to the defaults set out in (7.3) or, in the absence of such policies, to the defaults set out in
this document, as regards: this document, as regards:
o The languages and charsets to be used; o The languages and charsets to be used;
o The length of lines; o The length of lines;
o The acceptability of various Content-Types, and especially of o The acceptability of various Media Types, and especially of
"text/html" and the "binary" types; "text/html" and the "binary" types;
o Conventions regarding the advisability of using o Conventions regarding the advisability of using
"message/partial"; "message/partial";
o Limits on the overall size of articles; o Limits on the overall size of articles;
o The topics to discussed in each group, as determined by its o The topics to discussed in each group, as determined by its
charter; charter;
Usenet Best Practice March 2005
o The acceptability of advertising. o The acceptability of advertising.
10. References 10. References
[ARTICLE] Charles H. Lindsey, "News Article Format and Transmission",
draft-ietf-usefor-article-format-*.txt.
[ISO 8859] International Standard - Information Processing - 8-bit [ISO 8859] International Standard - Information Processing - 8-bit
Single-Byte Coded Graphic Character Sets. Part 1: Latin Single-Byte Coded Graphic Character Sets. Part 1: Latin
alphabet No. 1, ISO 8859-1, 1987. Part 2: Latin alphabet No. 2, alphabet No. 1, ISO 8859-1, 1987. Part 2: Latin alphabet No. 2,
ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3,
1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic
alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO
8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
[ISO/IEC 10646] "International Standard - Information technology - [ISO/IEC 10646] "International Standard - Information technology -
Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Universal Multiple-Octet Coded Character Set (UCS) - Part 1:
Architecture and Basic Multilingual Plane", ISO/IEC 10646- Architecture and Basic Multilingual Plane", ISO/IEC 10646-
Usenet Best Practice May 2004
1:2000, 2000. 1:2000, 2000.
[MALAMUD] "Labels in Subject Headers Considered Ineffective At Best",
draft-malamud-subject-line-*.txt.
[NNTP-AUTH] J. Vinocur, K. Murchison, and C. Newman, "NNTP Extension
for Authentication", draft-ietf-nntpext-authinfo-*.txt.
[RFC 1036] M. Horton and R. Adams, "Standard for Interchange of [RFC 1036] M. Horton and R. Adams, "Standard for Interchange of
USENET Messages", RFC 1036, December 1987. USENET Messages", RFC 1036, December 1987.
[RFC 1153] F. Wancho, "Digest Message Format", RFC 1153, April 1990. [RFC 1153] F. Wancho, "Digest Message Format", RFC 1153, April 1990.
[RFC 1847] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security [RFC 1847] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995. RFC 1847, October 1995.
[RFC 1855] S. Hambridge, "Netiquette Guidelines", RFC 1855, October [RFC 1855] S. Hambridge, "Netiquette Guidelines", RFC 1855, October
1995. 1995.
[RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[RFC 2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail [RFC 2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996. 1996.
[RFC 2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) [RFC 2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", RFC Part Three: Message Header Extensions for Non-ASCII Text", RFC
2047, November 1996. 2047, November 1996.
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
Usenet Best Practice March 2005
[RFC 2396] T. Berners-Lee, R. Fielding, U.C. Irvine, and L. Masinter, [RFC 2396] T. Berners-Lee, R. Fielding, U.C. Irvine, and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC 2440] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer, [RFC 2440] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998. "OpenPGP Message Format", RFC 2440, November 1998.
[RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names", [RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names",
RFC 2606, June 1999. RFC 2606, June 1999.
skipping to change at page 33, line 53 skipping to change at page 37, line 29
[RFC 2822] P. Resnick, "Internet Message Format", RFC 2822, April [RFC 2822] P. Resnick, "Internet Message Format", RFC 2822, April
2001. 2001.
[RFC 3156] M. Elkins, D. Del Torto, R. Levien, and T. Roessler, "MIME [RFC 3156] M. Elkins, D. Del Torto, R. Levien, and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001. Security with OpenPGP", RFC 3156, August 2001.
[RFC 3676] R. Gellens, "The Text/Plain Format and DelSp Parameters", [RFC 3676] R. Gellens, "The Text/Plain Format and DelSp Parameters",
RFC 3676, February 2004. RFC 3676, February 2004.
[RFC 3986] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, January
2005.
[UNICODE 3.2] The Unicode Consortium, "The Unicode Standard - Version [UNICODE 3.2] The Unicode Consortium, "The Unicode Standard - Version
3.2, being an amendment to [UNICODE 3.1]", Unicode Standard 3.2, being an amendment to [UNICODE 3.1]", Unicode Standard
Annex #28 <http://www.unicode.org/unicode/reports/tr28>, 2002. Annex #28 <http://www.unicode.org/unicode/reports/tr28>, 2002.
[USEFOR] Charles H. Lindsey, "News Article Format", draft-ietf- [USEFOR] K. Murchison et al, "News Article Format", draft-ietf-
usefor-article-format-*.txt. usefor-usefor-*.txt.
Usenet Best Practice May 2004 [USEPRO] C. H. Lindsey, "News Article Architecture and Protocols",
draft-ietf-usefor-usepro-*.txt.
11. Acknowledgements 11. Acknowledgements
12. Contact Address 12. Contact Address
Editor Editor
Charles. H. Lindsey Charles. H. Lindsey
5 Clerewood Avenue 5 Clerewood Avenue
Heald Green Heald Green
Cheadle Cheadle
Cheshire SK8 3JU Cheshire SK8 3JU
United Kingdom United Kingdom
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clw.cs.man.ac.uk Email: chl@clw.cs.man.ac.uk
Usenet Best Practice March 2005
[ [
Working group chairs Working group chair
Alexey Melnikov <alexey.melnikov-usefor@isode.com> Alexey Melnikov <alexey.melnikov-usefor@isode.com>
] ]
Comments on this draft should preferably be sent to the mailing list Comments on this draft should preferably be sent to the mailing list
of the Usenet Format Working Group at of the Usenet Format Working Group at
usenet-format@landfield.com. ietf-usefor@imc.org.
This draft expires six months after the date of publication (see Page
1) (i.e. in Nov 2004).
Appendix A - Notices Appendix A - Notices
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Usenet Best Practice May 2004
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
This document and translations of it may be copied and furnished to except as set forth therein, the authors retain all their rights.
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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