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
NewerOlder
usefor-usepro February 2005
usefor-usepro December 2004
usefor-usepro September 2004
usefor-usepro August 2004
News Article Format and Transmission May 2004
News Article Format and Transmission November 2003
News Article Format June 2003
News Article Format February 2003
News Article Format August 2002
News Article Format May 2002
News Article Format November 2001
News Article Format July 2001
News Article Format April 2001
News Article Format February 2000
Son of 1036 June 1994

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


Documents were processed to this format by Forrest J. Cavalier III