usefor-article-04 April 2001

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.

   "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 "ASCII" means X3.4 and
   only X3.4. 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
        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).

   All numeric values are given in decimal unless otherwise indicated.
   Octets are assumed to be unsigned values for this purpose.

   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 of ".example" is used in all sample domains and addresses. The
   hierarchy of example.* is also used as a sample hierarchy.
   Information on the ".example" top level domain is in [RFC 2606].

--- ../usefor-article-03/Textual_Notations.out          February 2000
+++ ../usefor-article-04/Textual_Notations.out          April 2001
@@ -2,9 +2,10 @@
 
    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
+   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.
@@ -21,30 +22,42 @@
    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", "SHOULD", "MAY" and
-   the same words followed by "NOT" are to be interpreted as described
-   in [RFC 2119].
-
-        NOTE: The use of "MUST" always implies a requirement that would
-        lead to interoperability problems if not followed, but the word
-        "SHOULD", especially when it is applied to actions of posting
-        and similar agents which the individual poster may easily
-        override, is often used where a violation would do no more than
-        breach established policy, or accepted standards of "Good
-        Netkeeping". Moreover, even a "MUST" requirement imposed on a
-        relaying or serving agent applies only to articles actually
-        processed by that agent (since such an agent may always reject
-        any article entirely for reasons of site policy).
+   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).
 
    All numeric values are given in decimal unless otherwise indicated.
    Octets are assumed to be unsigned values for this purpose.
 
    Throughout this standard we will give examples of various
-   definitions, headers and other specifications. It needs to be be
+   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 of ".example" is used in all sample domains and addresses.
-   The hierarchy of example.* is also used as a sample hierarchy.
+   domain of ".example" is used in all sample domains and addresses. The
+   hierarchy of example.* is also used as a sample hierarchy.
    Information on the ".example" top level domain is in [RFC 2606].