From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Dec 12 2000 - 15:30:48 CST
First, find in section 2.2 the proposed official definition of "Ought".
Observe that it is described as a "recommendation" (lower case) as opposed
to a "requirement".
After that, I have gone through chapters 3 and 4. I have changed SHOULD to
Ought in the cases where it was obviously needed, but there are other
cases that may need some debate. Where I have followed a suggestion with
"???", it means that I think it should probably Not be changed, but others
might wish to disagree (many of these cases arise in followups, where the
effect of non-compliance would be externally visible). Some cases have
fewer "?"s, indicating my stronger feeling towards changing them. Observe
several cases of a SHOULD in a NOTE changing to an Ought.
When we have thoroughly discussed these, and established some principles
to be followed, I shall go through the remainder of the document, putting
Oughts in the proper places.
Each change has been given an 'X' number, to facilitate discussion.
Please use them.
2. Definitions, Notations and Conventions
2.2. Textual Notations
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).
NOTE: A requirement imposed on a relaying or serving agent
should be understood as applying only to articles actually
accepted for processing by that agent (since any agent may
always reject any article entirely, for reasons of site policy).
3.2. Transitional Arrangements
o The new style of Path header is already consistent with the
previous standards. However, the intention is that relaying
agents should eventually reject articles in the old style, and so
this should be offered as a configurable option for relaying
agents. User agents are unaffected.
[X1. I have changed that "eventually" from "henceforth".
X2. Should that "should" be a "SHOULD" or a "MAY" or an "Ought to", or left
as a "should"?]
4. Basic Format
4.2.1. Names and Contents
Header-names SHOULD be either those for which a USENET-header-content
is defined in this standard, or those defined in [MESSFOR], or those
defined in any extension to either of these standards including, in
particular, the Mime standards [RFC 2045] et seq., or experimental
headers beginning with "X-" (as defined in 4.2.2.1). Software SHOULD
NOT attempt to interpret headers not described in this standard or in
its extensions, but relaying agents MUST pass them on unaltered and
reading agents MUST enable them to be displayed, at least optionally.
[X3. last MUST -> Ought???]
Header-names are case-insensitive. 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 some abbreviations have all
letters uppercase (e.g. "Message-ID" and "MIME-Version"). The forms
used in this standard are the preferred forms for the headers
described herein. Relaying and reading agents MUST, however, tolerate
articles not obeying this convention.
[X4. SHOULD -> Ought to???]
4.2.2. Header Properties
4.2.2.2. Inheritable Headers
Subject only to the overriding ability of the poster to determine the
contents of the headers in a proto-article, headers with the
inheritable property MUST be copied by followup agents (perhaps with
some modification) into the followup article, and headers without
that property MUST NOT be so copied. Examples include:
[X5. I hope nobody wants those MUSTs -> Oughts]
o Newsgroups (5.5) - copied from the precursor, subject to any
Followup-To header.
o Subject (5.4) - modified by prefixing with "Re: ", but otherwise
copied from the precursor.
o References (6.10) - copied from the precursor, with the addition
of the precursor's Message-ID.
o Distribution (6.6) - copied from the precursor.
4.2.3. White Space and Continuations
[The following text is taken from [MESSFOR], adapted to the different
terminology used for this standard.]
Each header is logically a single line of characters comprising the
header-name, the colon with its following SP, and the header-content.
For convenience, however, the header-content can be split into a
multiple line representation; this is called "folding". The general
rule is that wherever this standard allows for FWS or CFWS (but not
simply SP or HTAB) a CRLF may be inserted before any WSP. For
example, the header:
Approved: modname@modsite.example (Moderator of comp.foo.bar)
can be represented as:
Approved: modname@modsite.example
(Moderator of comp.foo.bar)
NOTE: Though 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
structured items, even if it is allowed elsewhere.
[X6. Anyone want to SHOULD -> Ought there (twice)?]
Since the white space beginning a continuation line remains a part of
the logical line, headers can be "broken" into multiple lines only at
FWS or CFWS. Posting agents SHOULD NOT break headers unnecessarily
(but see 4.5).
[X7. Anyone want to SHOULD -> Ought there?]
4.2.5. 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.
[X8. Was SHOULD NOT]
4.3. Body
4.3.1. Body Format Issues
[Original text, to be rewritten (it was plainly self-inconsistent):]
The body of an article MAY be empty, although posting agents SHOULD
consider this an error condition (meriting returning the article to
the poster for revision). A posting or injecting agent which does not
reject such an article SHOULD issue a warning message to the poster
and supply a non-empty body. Note that the separator line MUST be
present even if the body is empty.
[X9. Rewrite]
The body of an article SHOULD NOT be empty. A posting or injecting
agent which does not reject such an article entirely SHOULD at least
issue a warning message to the poster and supply a non-empty body.
Note that the separator line MUST be present even if the body is
empty.
NOTE: Some existing news software is known to react badly to
body-less articles, hence the request for posting and injecting
agents to insert a body in such cases. The sentence "This
article was probably generated by a buggy news reader" has
traditionally been used is this situation.
Note that an article body is a sequence of lines terminated by CRLFs,
not arbitrary binary data, and in particular it MUST end with a CRLF.
However, relaying agents SHOULD treat the body of an article as an
uninterpreted sequence of octets (except as mandated by changes of
CRLF representation and by control-message processing) and SHOULD
avoid imposing constraints on it. See also section 4.5.
Posters SHOULD avoid using control characters in US-ASCII (or other
CCSs) except for tab (ASCII 9), formfeed (ASCII 12), and backspace
(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
SHOULD pause and await reader interaction before displaying further
text. Backspace SHOULD be used only for underlining, done by a
sequence of underscores (ASCII 95) followed by an equal number of
backspaces, signifying that the same number of text characters
following are to be underlined. Posters are warned that underlining
is not available on all output devices and is best not relied on for
essential meaning. Reading agents SHOULD recognize underlining and
translate it to the appropriate commands for devices that support it.
Reading agents MUST NOT pass other control characters or escape
sequences unaltered to the output device.
[X10. Everybody happy to leave those SHOULDs?]
4.3.2. Body Conventions
It is a common practice 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).
[X11. was SHOULD NOT]
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, whilst not mandated by this
standard, is intended to facilitate their automatic recognition and
processing by sophisticated reading agents. The attribution SHOULD
contain the name 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 SHOULD always be under the control of the
poster.
[X12. both SHOULD -> Ought???]
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. If a poster or posting agent does
append such a signature to an article, it MUST be preceded with a
delimiter line containing (only) two hyphens (ASCII 45) followed by
one SP (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,
SHOULD NOT 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).
[X13. SHOULD NOT -> Ought Not???
X14. Ought was SHOULD]
NOTE: It is undesirable to have more than one personal signature
in an article body (even though the rule above admits the
possibility by recognising only the last one). If, for some
reason, a second signature is considered necessary, it MAY be
preceded by a different delimiter (e.g. "--- ").
[That is Clive's suggestion. Not to be included without further support.
X15. Please can I take it out now?]
4.4. Characters and Character Sets
4.4.2. Character Sets within Article Bodies
Within article bodies, the CES and CCS implied by any Content-
Transfer-Encoding and Content-Type headers [RFC 2045] SHOULD be
applied by reading agents. In the absence of such headers, reading
agents cannot be relied upon to display correctly more than the US-
ASCII characters.
[Observe that reading agents are not forbidden to "guess", or to
interpret as UTF-8 regardless, which would be the simplest course for
them to take.]
NOTE: It is not expected that reading agents will necessarily be
able to present characters in all possible character sets,
although they MUST be able to present all US-ASCII characters.
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. Older reading agents
that do not understand Mime headers or UTF-8 should be able to
display bodies in US-ASCII (with some loss of human
comprehensibility) except possibly when the Content-Transfer-
Encoding is "8bit".
[X16. Ought was SHOULD]
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).
[X17. 1st SHOULD -> Ought??
X18. 2nd SHOULD -> Ought???]
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.
[X19. both Oughts were SHOULDs]
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131 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