usefor-article-10 April 2003
[< Prev]
[TOC] [ Next >]
2.2. Textual Notations
This standard 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 grasp
the purpose of the specification and the constraints involved.
Given the limitations of natural language for descriptive
purposes, this improves the probability that implementors and
users will understand the true intent of the specification in
cases where the wording is not entirely clear.
"US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4].
While "ASCII" is often misused to refer to various character sets
somewhat similar to X3.4, in this standard "US-ASCII" is used to mean
X3.4 and only X3.4. US-ASCII is a 7 bit character set. Please note
that this standard requires that all agents be 8 bit clean; that is,
they must accept and transmit data without changing or omitting the
8th bit.
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
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).
Wherever the context permits, use of the masculine includes the
feminine and use of the singular includes the plural, and vice versa.
Throughout this standard we will give examples of various
definitions, headers and other specifications. It needs to be
remembered that these samples are for the aid of the reader only and
do NOT define any specification themselves. 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].
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-09/Textual_Notations.out February 2003
+++ ../usefor-article-10/Textual_Notations.out April 2003
@@ -5,6 +5,7 @@
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 grasp
the purpose of the specification and the constraints involved.