From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Tue Apr 29 2003 - 15:53:01 CDT
We have agreed that the document should be split into (at least) two, a
standards track document (USEFOR) and an Informational document covering
"Good Netkeeping" issues (which I have called USEAGE for the time
being).
I have now made an experimental split of the first four sections,
primarily to see if we can agree on the criteria for determining what
should be in which document. If that split appears to be satisfactory
(or becomes so after further iterations), then I will proceed to do the
same on further sections of the document.
You can find the modified texts in
http://www.landfield.com/usefor/drafts/section_1-4.10.01
http://www.landfield.com/usefor/drafts/useage_1-4.-1.00
You will also find a full set of diffs for the USEFOR part and the
complete USEAGE part attached below. Note that both documents follow the
same section numbering scheme (this is not a permanent arrangement, of
course) and every section number is included, though sections which have
not changed (in the USEFOR part) and sections with nothing in them (in
the USEAGE part) are just shown as empty.
The criteria used for splitting the material is roughly as follows:
If it is concerned with syntax, or with what a valid article looks
like, or it is a matter which could lead to interoperability
problems, then it belongs in USEFOR.
If it is a matter of policy (things to be decided by hierarchy admins
or agreed conventions), or the setting of default policies, or
behaviour of user agents (which ought to be done properly for social
rather than technical reasons), or it is a recommendation which will
not cause articles to get lost or damaged if not followed, then it
belongs in USEAGE.
What I would like to hear now is discussion of whether those are the
right criteria, and whether I have applied them appropriately. Actually,
in these sections, the decisions were rather easy, but I expect there
are going to be some hard cases to discuss when we come to secions 5 and
6.
Whilst I will accept suggestions for textual change in both documents,
I am well aware that removing great chunks from USEFOR has left some
awkward phraseology in places, and some sections that are now so small
that they could do with some structural rearrangement. However, if we
are next going to split USEFOR into #1 and #2, then that will be the
time for major structural change.
Likewise, the text of USEAGE is very bitty, and even more structural
change will be needed. But again, that is supposed to wait until USEFOR
(or #1+#2) have been largely sorted out. So at this point I would rather
keep suggested changes to short textual matters. It is the division of
_features_ between the two documents that I want to get right at the
moment.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
*** old.sections Mon Apr 28 21:23:52 2003
--- new.sections Mon Apr 28 21:24:57 2003
***************
*** 27,40 ****
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
--- 27,31 ----
recognized "hierarchies". Anybody can join (it is simply necessary
to negotiate an exchange of articles with one or more other
! participating hosts)
A "policy" is a rule intended to facilitate the smooth operation of a
***************
*** 47,61 ****
their recipients.
- Policies may well 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
- standard, 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. For the benefit of
- networks and hierarchies without such established agencies, and to
- provide a basis upon which all agencies can build, this present
- standard often provides default policy parameters, usually
- introducing them by a phrase such as "As a matter of policy ...".
-
1.2. Objectives
--- 38,41 ----
***************
*** 65,74 ****
that implements those protocols.
! It is NOT the purpose of this standard 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).
! Nevertheless, it is assumed that such authorities will exist, and
! tools are provided within the protocols for their use.
1.3. Historical Outline
--- 45,60 ----
that implements those protocols.
! It is NOT the purpose of this standard to settle matters of policy,
! nor aspects of software behaviour which do not impinge upon the
! generation, transmission, storate and reception of articles, nor how
! the authority of various agencies to exercise control or oversight of
! the various parts of Usenet is established. For these purposes, a
! separate informational document [USEAGE] is being provided.
+ Nevertheless, it is assumed that agencies with the necessary
+ authority will exist, and tools are provided within the protocols for
+ their use.
+
+
1.3. Historical Outline
***************
*** 234,253 ****
[RFC 2119].
- In addition, the word "Ought", when applied to a poster, or to
- actions of posting and similar agents which a poster may easily
- override, indicates a recommendation whose violation would do no more
- than breach established policy, or accepted best practice.
-
NOTE: The use of "MUST" or "SHOULD" implies a requirement that
would or could lead to interoperability problems if not
! followed. Although not following an "Ought" recommendation might
! do no worse than cause extreme irritation to other readers,
! particularly in the case of the publicly distributed Usenet,
! that is no reason not to take it seriously. The essential
! distinction is that enforcement of a "MUST" or "SHOULD" is a
! matter of ensuring correct implementation, whereas enforcement
! of an "Ought" is more a matter of sensible design or of social
! pressure (whose effectiveness should not be underestimated, even
! though it cannot be prescribed by this standard).
NOTE: A requirement imposed on a relaying or serving agent
--- 221,227 ----
[RFC 2119].
NOTE: The use of "MUST" or "SHOULD" implies a requirement that
would or could lead to interoperability problems if not
! followed.
NOTE: A requirement imposed on a relaying or serving agent
***************
*** 282,292 ****
of tinkering.
! Likewise, this standard incorporates many (though not all) of the
! provisions of the MIME standards [RFC 2045] et seq which, though
! designed with Email in mind, are mostly applicable to Netnews.
2.4. Syntax
--- 256,264 ----
of tinkering.
! Likewise, this standard incorporates (see section 6.21) many, though
! not all, of the provisions of the MIME standards [RFC 2045] et seq
! which, though designed with Email in mind, are mostly applicable to
! Netnews.
2.4. Syntax
***************
*** 461,469 ****
must the restrictions on the overall length of an encoded-word.
2.5. Language
! Various constant strings in this standard, such as header names and
month names, are derived from English words. Despite their
derivation, these words do NOT change when the poster or reader
--- 436,442 ----
must the restrictions on the overall length of an encoded-word.
2.5. Language
! Various constant strings in this standard, such as header-names and
month names, are derived from English words. Despite their
derivation, these words do NOT change when the poster or reader
***************
*** 589,608 ****
headers are introduced in this standard (or in future extensions),
using the "=/" notation defined in [RFC 2234]. For example, a
! typical USENET-header would be defined as follows:
! header =/ USENET-header
! USENET-header = "USENET" ":" SP USENET-content
! *( ";" ( USENET-parameter /
extension-parameter ) )
! USENET-content = <syntax specific to that USENET-header>
! USENET-parameter = <a parameter specific to that USENET-header>
! where the USENET-parameter, which MUST always be of the same
! syntactic form as an extension-parameter (see below), is not provided
! in all headers, and even the extension-parameter is omitted in some
! cases (see 4.2.2). Observe that "USENET" is (and MUST be) of the
! syntactic form of a header-name.
! extension-parameter= <a parameter not defined by this standard>
x-attribute = "x-" attribute
--- 562,584 ----
headers are introduced in this standard (or in future extensions),
using the "=/" notation defined in [RFC 2234]. For example, a
! typical Usenet-header would be defined as follows:
! header =/ Usenet-header
! Usenet-header = "Usenet" ":" SP Usenet-content
! *( ";" ( Usenet-parameter /
extension-parameter ) )
! Usenet-content = <syntax specific to that Usenet-header>
! Usenet-parameter = <a parameter specific to that Usenet-header>
! where the Usenet-parameter, which MUST always be of the same
! syntactic form as a parameter, is not provided in all headers, and
! even the extension-parameter is omitted in some cases (see 4.2.2).
! Observe that "Usenet" is (and MUST be) of the syntactic form of a
! header-name.
!
!
! extension-parameter
! = <a parameter not defined by this standard>
x-attribute = "x-" attribute
***************
*** 668,678 ****
Header-names are case-insensitive. There is a preferred case
! convention, which posters and posting agents Ought to use: each
! hyphen-separated "word" has its initial letter (if any) in uppercase
! and the rest in lowercase, except that some abbreviations have all
! letters uppercase (e.g. "Message-ID" and "MIME-Version"). The forms
! given in the various rules defining headers in this standard are the
! preferred forms for them. Relaying and reading agents MUST, however,
! tolerate articles not obeying this convention.
4.2.2. MIME-style Parameters
--- 644,650 ----
Header-names are case-insensitive. There is a preferred case
! convention set out in [USEAGE], and which is used in the various
! rules defining headers in this standard. Relaying and reading agents
! MUST, however, tolerate header-names in any case.
4.2.2. MIME-style Parameters
***************
*** 752,756 ****
can be represented as:
Approved: modname@modsite.example
! (Moderator of example.foo.bar)
FWS occurs at many places in the syntax (usually within a CFWS) in
--- 724,728 ----
can be represented as:
Approved: modname@modsite.example
! (Moderator of example.foo.bar)
FWS occurs at many places in the syntax (usually within a CFWS) in
***************
*** 778,790 ****
with an optional CFWS.
- NOTE: Although contents are defined in such a way that folding
- can take place between many of the lexical tokens (and even
- within some of them), folding should be limited to placing the
- CRLF at higher-level syntactic breaks, and should also avoid
- leaving trailing WSP on the preceding line. For instance, if a
- header-content is defined as comma-separated values, it is
- recommended that folding occur after the comma separating the
- values, even if it is allowed elsewhere.
-
In accordance with the syntax, the header-name on the first line MUST
be followed by a SP (even if the rest of the header is empty, but see
--- 750,753 ----
***************
*** 803,806 ****
--- 766,772 ----
and serving agents SHOULD accept HTAB in all such cases, however.
+ Relaying and serving agents MUST NOT refold headers (i.e. they must
+ pass on the folding as received).
+
4.2.4. Comments
***************
*** 818,832 ****
right at the end.
- A comment 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 and
- reading agents SHOULD take special note of such comments as
- indicating the name of the person whose mailbox it is. In all other
- situations a comment is semantically interpreted as a single SP.
Since a comment is allowed to contain FWS, folding is permitted
within it as well as immediately preceding and immediately following
--- 782,785 ----
***************
*** 839,845 ****
Since comments have not hitherto been permitted in news articles,
except in a few specified places, posters and posting-agents SHOULD
! NOT insert them except in those places, namely following addresses in
! From and similar headers, and to indicate the name of the timezone in
! Date-headers. However, compliant software MUST accept them in all
places where they are syntactically allowed.
--- 792,799 ----
Since comments have not hitherto been permitted in news articles,
except in a few specified places, posters and posting-agents SHOULD
! NOT insert them except in those places, namely following mailboxes in
! From and similar headers (a now deprecated convention for indicating
! the owner of that mailbox), and to indicate the name of the timezone
! in Date-headers. However, compliant software MUST accept them in all
places where they are syntactically allowed.
***************
*** 915,929 ****
agents MUST pass them untouched.
- 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
- posters and posting agents Ought Not to include them.
4.3. Body
4.3.1. Body Format Issues
--- 865,873 ----
agents MUST pass them untouched.
4.3. Body
4.3.1. Body Format Issues
***************
*** 949,974 ****
section 4.5.
- 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). Tab signifies sufficient horizontal white
- space to reach the next of a set of fixed positions; posters are
- warned that there is no standard set of positions, so tabs should be
- avoided if precise spacing is essential. Formfeed (which is sometimes
- referred to as the "spoiler character") signifies a point at which a
- reading agent Ought to pause and await reader interaction before
- displaying further text.
-
- NOTE: Passing other control characters or escape sequences
- unaltered to a display or printing device is likely to have
- unpredictable results, except in the case of a device adapted to
- the special needs of some particular character set.
-
- 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.
-
4.3.2. Body Conventions
--- 893,896 ----
***************
*** 979,1051 ****
are to be interpreted.
- The following conventions for quotations, attributions and
- signatures, although not mandated by this standard, describe widely
- used practices. They are documented here in order to establish their
- correct usage, and the use of the words "MUST", "SHOULD", etc. is to
- be understood in that context.
-
- It is conventional for followup agents to enable the incorporation of
- the followed-up article (the "precursor") as a quotation. This SHOULD
- be done 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.
-
- NOTE: Posters should edit quoted context to trim it down to the
- minimum necessary. However, followup agents Ought Not to attempt
- to enforce this beyond issuing a warning (past attempts to do so
- have been found to be notably counter-productive).
-
- 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-ID
- 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 Ought always to be under the control of the
- poster.
-
- To enable this line, and the Message-ID 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-ID 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:
-
- Am 24. Dez 2001 schrieb Helmut Schmidt <helmut@bar.example>:
-
- 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
- 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).
- Followup agents, when incorporating quoted text from a precursor,
- Ought Not to include the signature in the quotation. Posting agents
- Ought to discourage (at least with a warning) signatures of excessive
- length (4 lines is a commonly accepted limit).
-
4.4. Characters and Character Sets
--- 901,904 ----
***************
*** 1123,1133 ****
in the article, or custom within the newsgroup).
- NOTE: It is not expected that reading agents will necessarily be
- able to present characters in all possible character sets. For
- example, a reading agent might be able to present only the ISO-
- 8859-1 (Latin 1) characters [ISO 8859], in which case it Ought
- to present undisplayable characters using some distinctive
- glyph, or by exhibiting a suitable warning.
-
Followup agents MUST be careful to apply appropriate encodings to the
outbound followup. A followup to an article containing non-ASCII
--- 976,979 ----
***************
*** 1136,1147 ****
4.5. Size Limits
! Posting agents SHOULD endeavour to keep all header lines, so far as
! is possible, within 79 characters by folding them at suitable places
! (see 4.2.3). However, posting agents MUST permit the poster to
! include longer headers if he so insists, and compliant software MUST
! support headers of at least 998 octets. Likewise, injecting agents
! SHOULD fold any headers generated automatically by themselves.
! Relaying agents MUST NOT fold headers (i.e. they must pass on the
! folding as received).
NOTE: There is NO restriction on the number of lines into which
--- 982,990 ----
4.5. Size Limits
! Compliant software MUST support headers of at least 998 octets, and
! that is the only limit on the length of a header line prescribed by
! this standard. However, specific rules to the contrary may apply in
! particular cases (for example, according to [RFC 2047] header lines
! containing encoded-words are limited to 76 octets).
NOTE: There is NO restriction on the number of lines into which
***************
*** 1158,1183 ****
of arbitrary length without truncation or any other modification.
NOTE: The limit of 998 octets is consistent with the
corresponding limit in [RFC 2822].
- In plain-text messages (those with no MIME headers, or those with a
- MIME Content-Type of text/plain) posting agents Ought to 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). Exceptionally, posting agents Ought
- Not to adjust the length of quoted lines in followups unless they are
- able to reformat them in a consistent manner. Moreover, posting
- agents MUST permit the poster to include longer lines if he so
- insists.
-
- NOTE: Plain-text messages are intended to be displayed "as-is"
- without any special action (such as automatic line splitting) on
- the part of the recipient. The 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.
-
NOTE: This standard provides no upper bound on the overall size
of a single article, but neither does it forbid relaying agents
--- 1001,1007 ----
***************
*** 1230,1242 ****
Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
- [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.
-
[KLYNE] G. Klyne and J. Mogul, "Registration procedures for message
header fields", draft-klyne-msghdr-registry-06.txt.
--- 1051,1054 ----
***************
*** 1287,1291 ****
--- 1099,1117 ----
<ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>, June 1994.
+ [USEAGE] Draft in preparation.
[This is a very preliminary draft of the "USEAGE" document intended to
accompany [USEFOR]. Currently, if follows the section numbering of
[USEFOR], since most of the texts are extracted from those sections of a
previous [USEFOR] draft. A heading appears for every such section,
though most of them are empty (indicating that no texts were taken
over).
Naturally, this situation will change as soon as serious editing work on
USEAGE commences. The purpose of this preliminary draft is simply to
establish what material needs to be taken over.]
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. These protocols are
defined in [USEFOR].
"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.
Often, these conventions are a matter 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 ...".
1.3. Historical Outline
1.4. Transport
2. Definitions, Notations and Conventions
2.1. Definitions
All the technical terms defined in [USEFOR] are considered to be
defined in this document also.
2.2. Textual Notations
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].
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: 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
pressure (whose effectiveness should not be underestimated, even
though it cannot be prescribed).
[That is the proposed new wording. However, for the moment, I have
preserved the distinction between "Ought" and "SHOULD", so that you can
see where each came from. Ultimately, all the "Oughts" will become
"SHOULD"s, or be otherwise done away with. In the meantime, here follows
the present definitions.]
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].
In addition, the word "Ought", when applied to a poster, or to
actions of posting and similar agents which a poster may easily
override, indicates a recommendation whose violation would do no more
than breach established policy, or accepted best practice.
NOTE: The use of "MUST" or "SHOULD" implies a requirement that
would or could lead to interoperability problems if not
followed. Although not following an "Ought" recommendation might
do no worse than cause extreme irritation to other readers,
particularly in the case of the publicly distributed Usenet,
that is no reason not to take it seriously. The essential
distinction is that enforcement of a "MUST" or "SHOULD" is a
matter of ensuring correct implementation, whereas enforcement
of an "Ought" is more a matter of sensible design or of social
pressure (whose effectiveness should not be underestimated, even
though it cannot be prescribed by this standard).
[End of old text, to be removed.]
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].
2.3. Relation To Email and MIME
2.4. Syntax
2.4.1. Syntax adapted from Email and MIME
2.4.2. Syntax copied from other standards
2.5. Language
3. Changes to the existing protocols
3.1. Principal Changes
3.2. Transitional Arrangements
4. Basic Format
4.1. Syntax of News Articles
4.2. Headers
4.2.1. Naming of Headers
There is a preferred case convention, which posters and posting
agents Ought to use: each hyphen-separated "word" has its initial
letter (if any) in uppercase and the rest in lowercase, except that
some abbreviations have all letters uppercase (e.g. "Message-ID" and
"MIME-Version"). The forms given in the various rules defining
headers in [USEFOR] are the preferred forms for them, but relaying
and reading agents are expected to tolerate articles not obeying this
convention.
4.2.2. MIME-style Parameters
4.2.3. White Space and Continuations
Although header-contents are defined in such a way that folding can
take place between many of the lexical tokens (and even within some
of them), folding SHOULD be limited to placing the CRLF at higher-
level syntactic breaks, and SHOULD also avoid leaving trailing WSP on
the preceding line. For instance, if a header-content is defined as
comma-separated values, it is RECOMMENDED that folding occur after
the comma separating the values, even if it is allowed elsewhere.
4.2.4. Comments
A comment 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 and
reading agents SHOULD take special note of such comments as
indicating the name of the person whose mailbox it is. In all other
situations a comment is semantically interpreted as a single SP.
4.2.5. Header Properties
4.2.5.1. Experimental Headers
4.2.5.2. Inheritable Headers
4.2.5.3. Variant Headers
4.2.6. Undesirable Headers
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
posters and posting agents Ought Not to include them.
4.3. Body
4.3.1. Body Format Issues
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). Tab signifies sufficient horizontal white
space to reach the next of a set of fixed positions; posters are
warned that there is no standard set of positions, so tabs should be
avoided if precise spacing is essential. Formfeed (which is sometimes
referred to as the "spoiler character") signifies a point at which a
reading agent Ought to pause and await reader interaction before
displaying further text.
NOTE: Passing other control characters or escape sequences
unaltered to a display or printing device is likely to have
unpredictable results, except in the case of a device adapted to
the special needs of some particular character set.
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.
4.3.2. Body Conventions
The following conventions for quotations, attributions and
signatures, although not mandated by any standard, describe widely
used practices, and it is RECOMMENDED that all posting, reading and
followup agents should adhere to them. Since much software will
attempt to recognize and act upon them, questions of interoperability
can arise, and so the use of the words "MUST", "SHOULD", etc. is to
be understood in that context.
It is conventional for followup agents to enable the incorporation of
the followed-up article (the "precursor") as a quotation. This SHOULD
be done 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.
NOTE: Posters should edit quoted context to trim it down to the
minimum necessary. However, followup agents Ought Not to attempt
to enforce this beyond issuing a warning (past attempts to do so
have been found to be notably counter-productive).
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-ID
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 Ought always to be under the control of the
poster.
To enable this line, and the Message-ID 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-ID 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:
Am 24. Dez 2001 schrieb Helmut Schmidt <helmut@bar.example>:
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
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).
Followup agents, when incorporating quoted text from a precursor,
Ought Not to include the signature in the quotation. Posting agents
Ought to discourage (at least with a warning) signatures of excessive
length (4 lines is a commonly accepted limit).
4.4. Characters and Character Sets
4.4.1. Character Sets within Article Headers
4.4.2. Character Sets within Article Bodies
It is not expected that reading agents will necessarily be able to
present characters in all possible character sets. For example, a
reading agent might be able to present only the ISO-8859-1 (Latin 1)
characters [ISO 8859], in which case it Ought to present
undisplayable characters using some distinctive glyph, or by
exhibiting a suitable warning.
4.5. Size Limits
Posting agents SHOULD endeavour to keep all header lines, so far as
is possible, within 79 characters by folding them at suitable places.
However, posting agents MUST permit the poster to include longer
headers if he so insists. Likewise, injecting agents SHOULD fold any
headers generated automatically by themselves.
In plain-text messages (those with no MIME headers, or those with a
MIME Content-Type of text/plain) posting agents Ought to 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). Exceptionally, posting agents Ought
Not to adjust the length of quoted lines in followups unless they are
able to reformat them in a consistent manner. Moreover, posting
agents MUST permit the poster to include longer lines if he so
insists.
NOTE: Plain-text messages are intended to be displayed "as-is"
without any special action (such as automatic line splitting) on
the part of the recipient. The 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.
[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.
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names",
RFC 2606, June 1999.
[USEFOR] Charles H. Lindsey, "News Article Format", draft-ietf-
usefor-article-format-*.txt.