usefor-article-03 February 2000

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", "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).

   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
   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].

--- ../s-o-1036/Textual_Notations.out          June 1994
+++ ../usefor-article-03/Textual_Notations.out          February 2000
@@ -1,68 +1,50 @@
-2.1. Textual Notations
+2.2.  Textual Notations
 
-Throughout this Draft, "MAIL" is short for "RFC 822 [rrr] as
-amended  by  RFC  1123  [rrr]".   (RFC 1123's amendments are
-mostly relatively small, but they  are  not  insignificant.)
-See  also  the  discussion  in  section 3 about this Draft's
-relationship to MAIL.  "MIME" is short for  "RFCs  1341  and
-1342" (or their updated replacements).
-
-     UNRESOLVED ISSUE: Update these numbers.
-
-"ASCII"  is  short  for "the ANSI X3.4 character set" [rrr].
-While "ASCII" is often misused to refer to various character
-sets  somewhat similar to X3.4, in this Draft, "ASCII" means
-X3.4 and only X3.4.
-
-     NOTE: The name is traditional (to the point  where
-     the  ANSI standard sanctions it) even though it is
-     no longer an acronym for the name of the standard.
-
-     NOTE:  ASCII,  X3.4,  contains 128 characters, not
-     all of them printable.  Character sets  with  more
-     characters   are  not  ASCII,  although  they  may
-     include it as a subset.
-
-Certain words used to define the significance of  individual
-requirements are capitalized.  "MUST" means that the item is
-an absolute  requirement  of  the  specification.   "SHOULD"
-means that the item is a strong recommendation: there may be
-valid reasons to ignore it  in  unusual  circumstances,  but
-this  should  be  done  only after careful study of the full
-implications and a firm conclusion  that  it  is  necessary,
-because  there are serious disadvantages to doing so.  "MAY"
-means that the item is truly optional, and implementors  and
-users  are warned that conformance is possible but not to be
-relied on.
-
-The term "compliant", applied to implementations etc., indi-
-cates  satisfaction  of  all  relevant  "MUST"  and "SHOULD"
-requirements.  The term "conditionally compliant"  indicates
-satisfaction  of all relevant "MUST" requirements but viola-
-tion of at least one relevant "SHOULD" requirement.
-
-This Draft 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.
-
-INTERNET DRAFT to be        NEWS                    sec. 2.1
-
-
-     NOTE: While such explanatory notes may seem super-
-     fluous  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  descrip-
-     tive  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.
-
-All numeric values are given  in  decimal  unless  otherwise
-indicated.   Octets  are  assumed  to be unsigned values for
-this purpose.  Large numbers are  written  using  the  North
-American  convention, in which "," separates groups of three
-digits but otherwise has no significance.
+   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", "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).
+
+   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
+   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].