s-o-1036 June 1994

[< Prev] [TOC] [ Next >]
2.1. 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.
[< 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 April 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



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