[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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
      fred@foo.bar.example (Fred Bloggs)
   as opposed to
      "Fred Bloggs" <fred@foo.bar.example> .

   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 <jdbloggs@foo.example> wrote:
   or
      Helmut Schmidt <helmut@bar.example> 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 <1234@bar.example> on 24 Dec 2001 16:40:20 +0000,
         "Joe D. Bloggs" <jdbloggs@bar.example> wrote:

C. H. Lindsey                                                  [Page 19]

                          Usenet Best Practice                March 2005

      Am 24. Dez 2002 schrieb Helmut Schmidt <helmut@bar.example>:

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:
      fred@foo.bar.example (Fred Bloggs)
   as opposed to
      "Fred Bloggs" <fred@foo.bar.example> .

   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: chl@clw.cs.man.ac.uk


C. H. Lindsey                                                  [Page 37]

                          Usenet Best Practice                March 2005

[

Working group chair

        Alexey Melnikov <alexey.melnikov-usefor@isode.com>
]

   Comments on this draft should preferably be sent to the mailing list
   of the Usenet Format Working Group at

        ietf-usefor@imc.org.

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-
   ipr@ietf.org.

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/