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