doc: Add RFC documents

1 files changed, 1958 insertions, 0 deletions

diff --git a/doc/rfc/rfc733.txt b/doc/rfc/rfc733.txt
new file mode 100644
index 0000000..a2a1472
--- /dev/null
+++ b/doc/rfc/rfc733.txt
@@ -0,0 +1,1958 @@
+
+
+
+
+RFC #   733
+NIC # 41952
+
+Obsoletes:  RFC #561  (NIC #18516)
+            RFC #680  (NIC #32116)
+            RFC #724  (NIC #37435)
+
+
+
+
+
+
+
+                   STANDARD FOR THE FORMAT OF
+
+                  ARPA NETWORK TEXT MESSAGES(1)
+
+
+
+
+                        21 November 1977
+
+
+
+
+                               by
+
+
+                        David H. Crocker
+                      The Rand Corporation
+
+                         John J. Vittal
+                  Bolt Beranek and Newman Inc.
+
+                        Kenneth T. Pogran
+              Massachusets Institute of Technology
+
+                   D. Austin Henderson, Jr.(2)
+                  Bolt Beranek and Newman Inc.
+
+
+
+_________________________________________________________________
+(1)This work was  supported  by  the  Defense  Advanced  Research
+Projects Agency of the Department of Defense, under contract Nos.
+N00014-75-C-0661, MDA903-76-C-0212, and DAHC15-73-C0181.
+
+(2)The authors' postal  addresses  are:   D.  Crocker,  The  Rand
+Corporation,  Information  Sciences  Dept.,  1700 Main St., Santa
+Monica, California 90406; J.  Vittal  &  D.  A.  Henderson,  Bolt
+Beranek & Newman, 50 Moulton St., Cambridge, Massachusetts 02138;
+and  K.  Pogran,  MIT  Laboratory  for  Computer   Science,   545
+Technology  Square, Cambridge, Massachusetts 02139.  The authors'
+ARPANET addresses are:  DCrocker at  Rand-Unix,  Vittal  at  BBN-
+TenexD, Pogran at MIT-Multics, and Henderson at BBN-TenexD.
+
+                              -iii-
+
+
+
+
+
+                             PREFACE
+
+
+
+     ARPA's  Committee  on  Computer-Aided  Human   Communication
+(CAHCOM)  wishes  to promulgate a standard for the format of ARPA
+Network text message (mail) headers which  will  reasonably  meet
+the  needs  of  the  various  message  service  subsystems on the
+Network today.  The  authors  of  this  document  constitute  the
+CAHCOM  subcommittee charged with the task of developing this new
+standard.
+
+     Essentially, we specify a revision to  ARPANET  Request  for
+Comments (RFC) 561, "Standardizing Network Mail Headers", and RFC
+680, "Message Transmission Protocol".  This revision removes  and
+compacts  portions  of  the  previous  syntax  and  adds  several
+features to network address  specification.   In  particular,  we
+focus  on  people  and  not  mailboxes  as  recipients  and allow
+reference to stored address lists.   We  expect  this  syntax  to
+provide  sufficient  capabilities  to  meet most users' immediate
+needs and, therefore, give developers enough  breathing  room  to
+produce  a new mail transmission protocol "properly".  We believe
+that there is enough of a consensus in the Network  community  in
+favor  of such a standard syntax to make possible its adoption at
+this time.  An earlier draft of this specification was  published
+as  RFC  #724, "Proposed Official Standard for the Format of ARPA
+Network Messages"  and  contained  extensive  discussion  of  the
+background and issues in ARPANET mail standards.
+
+     This specification was developed  over  the  course  of  one
+year,  using  the ARPANET mail environment, itself, to provide an
+on-going forum for discussing the capabilities  to  be  included.
+More   than   twenty   individuals,   from  across  the  country,
+participated in this discussion and we would like to  acknowledge
+their  considerable  efforts.   The  syntax  of  the standard was
+originally specified in the Backus-Naur Form (BNF) meta-language.
+Ken  L.   Harrenstien,  of SRI International, was responsible for
+re-coding the BNF  into  an  augmented  BNF  which  compacts  the
+specification and allows increased comprehensibility.
+
+
+
+                               -v-
+
+
+
+
+
+                            CONTENTS
+
+
+
+PREFACE..................................................... iii
+
+
+Section
+   I.  INTRODUCTION.........................................   1
+
+  II.  FRAMEWORK............................................   2
+
+ III.  SYNTAX...............................................   4
+       A. Notational Conventions............................   4
+       B. Lexical Analysis of Messages......................   5
+       C. General Syntax of Messages........................  13
+       D. Syntax of General Addressee Items.................  15
+       E. Supporting Constructs.............................  15
+
+  IV.  SEMANTICS............................................  17
+       A. Address Fields....................................  17
+       B. Reference Specification Fields....................  22
+       C. Other Fields and Syntactic Items..................  23
+       D. Dates and Times...................................  24
+
+   V.  EXAMPLES.............................................  25
+       A. Addresses.........................................  25
+       B. Address Lists.....................................  26
+       C. Originator Items..................................  26
+       D. Complete Headers..................................  28
+
+
+Appendix
+   A.  ALPHABETICAL LISTING OF SYNTAX RULES.................  31
+   B.  SIMPLE PARSING.......................................  35
+
+BIBLIOGRAPHY................................................  37
+
+
+Standard for the Format of Text Messages                        1
+I. Introduction
+
+
+
+
+
+                        I.  INTRODUCTION
+
+
+
+
+     This standard specifies a syntax for text messages which are
+passed between computer users within the framework of "electronic
+mail".  The standard supersedes the informal standards  specified
+in  ARPANET  Request  for  Comments  numbers  561, "Standardizing
+Network Mail Headers", and 680, "Message Transmission  Protocol".
+In  this  document,  a  general framework is first described; the
+formal syntax is then specified, followed by a discussion of  the
+semantics.  Finally, a number of examples are given.
+
+     This specification is intended strictly as a  definition  of
+what  is  to  be  passed between hosts on the ARPANET.  It is NOT
+intended to dictate either features which systems on the  Network
+are  expected  to support, or user interfaces to message creating
+or reading programs.
+
+     A distinction should be made between what the  specification
+REQUIRES  and  what  it ALLOWS.  Messages can be made complex and
+rich with formally-structured components of information or can be
+kept small and simple, with a minimum of such information.  Also,
+the standard simplifies the interpretation  of  differing  visual
+formats in messages.  These simplifications facilitate the formal
+specification and indicate what the OFFICIAL  semantics  are  for
+messages.   Only  the  visual aspect of a message is affected and
+not the interpretation of information  within  it.   Implementors
+may choose to retain such visual distinctions.
+
+
+
+
+Standard for the Format of Text Messages                        2
+II. Framework
+
+
+
+
+
+                         II.  FRAMEWORK
+
+
+
+
+     Since there are many message systems which exist outside the
+ARPANET environment, as well as those within it, it may be useful
+to consider the general framework, and resulting capabilities and
+limitations, provided by this standard.
+
+     Messages are expected to  consist  of  lines  of  text.   No
+special provisions are made, at this time, for encoding drawings,
+facsimile, speech, or structured text.
+
+     No significant consideration has been given to questions  of
+data   compression   or   transmission/storage  efficiency.   The
+standard, in fact, tends to be very free with the number of  bits
+consumed.   For  example, field names are specified as free text,
+rather than special terse codes.
+
+     A general "memo" framework is  used.   That  is,  a  message
+consists  of some information, in a rigid format, followed by the
+main part of the message, which is text and whose format  is  not
+specified  in this document.  The syntax of several fields of the
+rigidly-formated  ("header")   section   is   defined   in   this
+specification;  some of the header fields must be included in all
+messages.  The syntax  which  distinguishes  between  headers  is
+specified  separately  from  the  internal  syntax for particular
+headers.  This separation is intended to allow  extremely  simple
+parsers  to operate on the overall structure of messages, without
+concern  for  the  detailed  structure  of  individual   headers.
+Appendix B is provided to facilitate construction of these simple
+parsers.  In addition to the fields specified in  this  document,
+it  is  expected  that  other fields will gain common use.  User-
+defined header fields allow systems to extend their functionality
+while  maintaining  a uniform framework.  The approach is similar
+to that of the TELNET protocol,  in  that  a  basic  standard  is
+defined  which  includes  a  mechanism for (optionally) extending
+itself.  As necessary, the authors of this document will regulate
+the  publishing  of  specifications for these "extension-fields",
+through the same mechanisms used to publish this document.
+
+     Such a  framework  severely  constrains  document  tone  and
+appearance  and  is  primarily useful for most intra-organization
+communications  and  relatively   structured   inter-organization
+communication.   A more robust environment might allow for multi-
+font, multi-color, multi-dimension encoding  of  information.   A
+less  robust  environment,  as  is present in most single-machine
+message systems, would more severely constrain the ability to add
+fields  and the decision to include specific fields.  In contrast
+to paper-based communication, it is interesting to note that  the
+
+Standard for the Format of Text Messages                        3
+II. Framework
+
+
+
+RECEIVER  of  a  message  can exercise an extraordinary amount of
+control over the message's  appearance.   The  amount  of  actual
+control  available  to  message  receivers is contingent upon the
+capabilities of their individual message systems.
+
+
+Standard for the Format of Text Messages                        4
+III. Syntax
+
+
+
+
+
+                          III.  SYNTAX
+
+
+
+     This  syntax  is  given  in  five  parts.   The  first  part
+describes  the  notation  used  in the specification.  The second
+part describes the base-level lexical analyzers  which  feed  the
+higher-level  parser  described  in the succeeding sections.  The
+third part gives a  general  syntax  for  messages  and  standard
+header  fields;  and  the  fourth  part  specifies  the syntax of
+addresses.  A final part  specifies  some  general  syntax  which
+supports the other sections.
+
+
+
+A.  NOTATIONAL CONVENTIONS
+
+These specifications are made in an  augmented  Backus-Naur  Form
+(BNF).  Differences  from  standard  BNF  involve  the  naming of
+rules, the indication of repetition and of "local" alternatives.
+
+
+1.  Rule naming
+
+Angle brackets ("<", ">") are not used, in general.  The name  of
+a   rule  is  simply  the  name  itself,  rather  than  "<name>".
+Quotation-marks enclose literal text (which may be  upper  and/or
+lower case).  Certain basic  rules  are  in  uppercase,  such  as
+SPACE,  TAB, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used in
+rule definitions, and in the  rest  of  this  document,  whenever
+their presence will facilitate discerning the use of rule names.
+
+
+2.  Parentheses:  Local alternatives
+
+Elements enclosed in parentheses are treated as a single element.
+Thus,  "(elem  (foo  /  bar)  elem)" allows "(elem foo elem)" and
+"(elem bar elem)".
+
+
+3.  * construct:  Repetition
+
+The character "*" preceding an element indicates repetition.  The
+full form is:
+
+          <l>*<m>element
+
+indicating at least <l> and at most <m> occurrences  of  element.
+Default values are 0 and infinity so that "*(element)" allows any
+number, including zero; "1*element" requires at  least  one;  and
+"1*2element" allows one or two.
+
+Standard for the Format of Text Messages                        5
+III. Syntax
+  A. Notational Conventions
+
+
+
+4.  <number>element
+
+"<n>(element)" is  equivalent  to  "<n>*<n>(element)";  that  is,
+exactly  <n>  occurrences of (element).  Thus 2DIGIT is a 2-digit
+number, and 3ALPHA is a string of three alphabetic characters.
+
+
+5.  # construct:  Lists
+
+A construct "#" is defined, similar to "*", as follows:
+
+                  <l>#<m>element
+
+indicating at least <l> and at most <m> elements, each  separated
+by  one or more commas (",").  This makes the usual form of lists
+very easy; a rule such as '(element *("," element))' can be shown
+as  "1#element".   Wherever this construct is used, null elements
+are allowed, but do not  contribute  to  the  count  of  elements
+present.   That  is,  "(element),,(element)"  is  permitted,  but
+counts as only two  elements.   Therefore,  where  at  least  one
+element  is  required,  at  least  one  non-null  element must be
+present.
+
+
+6.  [optional]
+
+Square  brackets  enclose  optional  elements;  "[foo  bar]"   is
+equivalent to "*1(foo bar)".
+
+
+7.  ; Comments
+
+A semi-colon, set off some distance to the right  of  rule  text,
+starts  a  comment which continues to the end of line.  This is a
+simple way  of  including  useful  notes  in  parallel  with  the
+specifications.
+
+
+
+B.  LEXICAL ANALYSIS OF MESSAGES
+
+
+1.  General Description
+
+A message consists of headers and, optionally,  a  body  (i.e.  a
+series of text lines).  The text part is just a sequence of lines
+containing ASCII characters; it is separated from the headers  by
+a null line (i.e., a line with nothing preceding the CRLF).
+
+
+Standard for the Format of Text Messages                        6
+III. Syntax
+  B. Lexical Analysis
+
+
+
+a.  Folding and unfolding of headers
+
+    Each header item can be viewed as a single, logical  line  of
+    ASCII characters.  For convenience, the field-body portion of
+    this conceptual entity can  be  split  into  a  multiple-line
+    representation  (i.e.,  "folded").   The general rule is that
+    wherever there can be linear-white-space  (NOT  simply  LWSP-
+    chars), a CRLF immediately followed by AT LEAST one LWSP-char
+    can instead be inserted.  (However, a header's name  and  the
+    following  colon  (":"),  which occur at the beginning of the
+    header item, may NOT be folded onto multiple  lines.)   Thus,
+    the single line
+
+       To:  "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN
+
+    can be represented as
+
+       To:  "Joe Dokes & J. Harvey" <ddd at Host>,
+            JJV at BBN
+
+    and
+
+       To:  "Joe Dokes & J. Harvey"
+                        <ddd at Host>,
+        JJV at BBN
+
+    and
+
+       To:  "Joe Dokes
+        & J. Harvey" <ddd at Host>, JJV at BBN
+
+    The  process  of  moving  from  this   folded   multiple-line
+    representation   of   a  header  field  to  its  single  line
+    representation will  be  called  "unfolding".   Unfolding  is
+    accomplished  by  regarding  CRLF  immediately  followed by a
+    LWSP-char as equivalent  to  the  LWSP-char.
+
+b.  Structure of header fields
+
+    Once header fields have been unfolded, they may be viewed  as
+    being  composed  of  a  field-name followed by a colon (":"),
+    followed by a field-body.  The field-name must be composed of
+    printable  ASCII  characters  (i.e.,  characters  which  have
+    values between 33.  and  126.,  decimal,  except  colon)  and
+    LWSP-chars.   The  field-body  may  be  composed of any ASCII
+    characters (other than  an  unquoted  CRLF,  which  has  been
+    removed by unfolding).
+
+    Certain field-bodies of  header  fields  may  be  interpreted
+    according  to  an internal syntax which some systems may wish
+    to parse.  These fields will be referred to  as  "structured"
+    fields.    Examples   include  fields  containing  dates  and
+
+Standard for the Format of Text Messages                        7
+III. Syntax
+  B. Lexical Analysis
+
+
+
+    addresses.  Other fields, such as "Subject"  and  "Comments",
+    are regarded simply as strings of text.
+
+    NOTE:  Field-names, unstructured field bodies and  structured
+    field  bodies  each  are  scanned  by  their own, INDEPENDENT
+    "lexical" analyzer.
+
+c.  Field-names
+
+    To aid in the creation and reading of field-names,  the  free
+    insertion  of  LWSP-chars  is  allowed in  reasonable places.
+
+    Rather than obscuring the syntax specification for field-name
+    with  the explicit syntax for these LWSP-chars, the existence
+    of a "lexical" analyzer is assumed.  The analyzer  interprets
+    the  text  which  comprises  the  field-name as a sequence of
+    field-name atoms (fnatoms) separated by LWSP-chars
+
+    Note that ONLY LWSP-chars may occur between the fnatoms of  a
+    field-name and that CRLFs may NOT.  In addition, comments are
+    NOT lexically recognized, as such, but parenthesized  strings
+    are  legal  as  part  of  field-names.  These constraints are
+    different from what is permissible  within  structured  field
+    bodies.   In  particular,  this means that header field-names
+    must wholly occur on the FIRST line of a folded  header  item
+    and may NOT be split across two or more lines.
+
+d.  Unstructured field bodies
+
+    For  some  fields,  such  as  "Subject"  and  "Comments",  no
+    structuring is assumed; and they are treated simply as texts,
+    like those in the message body.  Rules of  folding  apply  to
+    these  fields, so that such field bodies which occupy several
+    lines must therefore have the  second  and  successive  lines
+    indented by at least one LWSP-char.
+
+e.  Structured field bodies
+
+    To aid in the creation and reading of structured fields,  the
+    free  insertion  of linear-white-space (which permits folding
+    by inclusion of  CRLFs)  is  allowed  in  reasonable  places.
+    Rather  than  obscuring  the  syntax specifications for these
+    structured fields  with  explicit  syntax  for  this  linear-
+    white-space,  the  existence of another "lexical" analyzer is
+    assumed.  This analyzer does not apply for field bodies which
+    are  simply unstructured strings of text, as described above.
+    It provides an interpretation of the unfolded text comprising
+    the  body  of  the  field  as  a sequence of lexical symbols.
+    These symbols are:
+
+            -  individual special characters
+            -  quoted-strings
+
+Standard for the Format of Text Messages                        8
+III. Syntax
+  B. Lexical Analysis
+
+
+
+            -  comments
+            -  atoms
+
+    The first three of these symbols are self-delimiting.   Atoms
+    are  not; they therefore are delimited by the self-delimiting
+    symbols and by linear-white-space.  For the purposes  of  re-
+    generating sequences of atoms and quoted-strings, exactly one
+    SPACE is assumed to exist and should be  used  between  them.
+    (Also,  in  Section  III.B.3.a,  note  the  rules  concerning
+    treatment of multiple continguous LWSP-chars.)
+
+    So, for example, the folded body of an address field
+
+            ":sysmail"@   Some-Host,
+            Muhammed(I am   the greatest)Ali   at(the)WBA
+
+    is analyzed into the following lexical symbols and types:
+
+            ":sysmail"              quoted string
+            @                       special
+            Some-Host               atom
+            ,                       special
+            Muhammed                atom
+            (I am   the greatest)   comment
+            Ali                     atom
+            at                      atom
+            (the)                   comment
+            WBA                     atom
+
+    The cononical representations for the data in these addresses
+    are  the  following  strings  (note that there is exactly one
+    SPACE between words):
+
+                :sysmail at Some-Host
+
+    and
+
+                Muhammed Ali at WBA
+
+
+
+2.  Formal Definitions
+
+The first four rules, below, indicate a meta-syntax  for  fields,
+without  regard to their particular type or internal syntax.  The
+remaining rules define basic syntactic structures which are  used
+by the rules in Sections III.C, III.D, and III.E.
+
+field       =  field-name ":" [ field-body ] CRLF
+
+field-name  =  fnatom *( LWSP-char [fnatom] )
+
+
+Standard for the Format of Text Messages                        9
+III. Syntax
+  B. Lexical Analysis
+
+
+
+fnatom      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+field-body  =  field-body-contents
+               [CRLF LWSP-char field-body]
+
+field-body-contents = <the TELNET ASCII characters making up the
+               field-body, as defined in the following sections,
+               and consisting of combinations of atom, quoted-
+               string, and specials tokens, or else consisting of
+               texts>
+
+                                            ; (  Octal, Decimal.)
+CHAR        =  <any TELNET ASCII character> ; (  0-177,  0.-127.)
+ALPHA       =  <any TELNET ASCII alphabetic character>
+                                            ; (101-132, 65.- 90.)
+                                            ; (141-172, 97.-122.)
+DIGIT       =  <any TELNET ASCII digit>     ; ( 60- 71, 48.- 57.)
+CTL         =  <any TELNET ASCII control    ; (  0- 37,  0.- 31.)
+                character and DEL>          ; (    177,     127.)
+CR          =  <TELNET ASCII carriage return>;(     15,      13.)
+LF          =  <TELNET ASCII linefeed>      ; (     12,      10.)
+SPACE       =  <TELNET ASCII space>         ; (     40,      32.)
+HTAB        =  <TELNET ASCII horizontal-tab>; (     11,       9.)
+<">         =  <TELNET ASCII quote mark>    ; (     42,      34.)
+CRLF        =  CR LF
+
+LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
+linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
+                                            ; CRLF => folding
+
+specials    =  "(" / ")" / "<" / ">" / "@"  ; To use in a word,
+            /  "," / ";" / ":" / "\" / <">  ;  word must be a
+                                            ;  quoted-string.
+
+delimiters  =  specials / comment / linear-white-space
+
+text        =  <any CHAR, including bare    ; => atoms, specials,
+                CR and/or bare LF, but NOT  ;  comments and
+                including CRLF>             ;  quoted-strings are
+                                            ;  NOT interpreted.
+
+atom        =  1*<any CHAR except specials and CTLs>
+
+quoted-string = <"> *(qtext/quoted-pair) <">; Any number of qtext
+                                            ;   chars or any
+                                            ;   quoted char.
+
+qtext       =  <any CHAR excepting <">      ; => may be folded
+                and CR, and including
+                linear-white-space>
+
+
+Standard for the Format of Text Messages                       10
+III. Syntax
+  B. Lexical Analysis
+
+
+
+comment     =  "(" *(ctext / comment / quoted-pair) ")"
+ctext       =  <any CHAR excluding "(",     ; => may be folded
+                ")" and CR, and including
+                linear-white-space>
+
+quoted-pair =  "\" CHAR
+
+
+3.  Clarifications
+
+a.  "White space"
+
+    Remember that in field-names  and  structured  field  bodies,
+    MULTIPLE  LINEAR  WHITE SPACE TELNET ASCII CHARACTERS (namely
+    HTABs and SPACEs) ARE TREATED AS SINGLE SPACES AND MAY FREELY
+    SURROUND ANY SYMBOL.  In all header fields, the only place in
+    which at least one space is REQUIRED is at the  beginning  of
+    continuation  lines  in a folded field.  When passing text to
+    processes which do  not  interpret  text  according  to  this
+    standard  (e.g.,  ARPANET FTP mail servers), then exactly one
+    SPACE should be used in place of arbitrary linear-white-space
+    and comment sequences.
+
+    WHEREVER A MEMBER OF THE LIST  OF  <DELIMITER>S  IS  ALLOWED,
+    LWSP-CHARS MAY ALSO OCCUR BEFORE AND/OR AFTER IT.
+
+    Writers of mail-sending  (i.e.  header  generating)  programs
+    should  realize  that  there is no Network-wide definition of
+    the effect of horizontal-tab TELNET ASCII characters  on  the
+    appearance  of  text  at another Network host; therefore, the
+    use  of  tabs  in  message  headers,  though  permitted,   is
+    discouraged.
+
+    Note that  during  transmissions  across  the  ARPANET  using
+    TELNET  NVT  connections,  data  must  conform  to TELNET NVT
+    conventions (e.g., CR must be followed by either LF, making a
+    CRLF, or <null>, if the CR is to stand alone).
+
+b.  Comments
+
+    Comments are detected as such  only  within  field-bodies  of
+    structured  fields.   A  comment  is  a  set  of TELNET ASCII
+    characters, which is not within a quoted-string and which  is
+    enclosed  in  matching parentheses; parentheses nest, so that
+    if an unquoted left parenthesis occurs in a  comment  string,
+    there  must  also  be  a  matching right parenthesis.  When a
+    comment is used to act as the delimiter between a sequence of
+    two  lexical  symbols,  such  as  two  atoms, it is lexically
+    equivalent with one SPACE, for the purposes  of  regenerating
+    the  sequence,  such as when passing the sequence onto an FTP
+    mail server.
+
+
+Standard for the Format of Text Messages                       11
+III. Syntax
+  B. Lexical Analysis
+
+
+
+    In particular comments are NOT passed to the FTP  server,  as
+    part  of  a MAIL or MLFL command, since comments are not part
+    of the "formal" address.
+
+    If a comment is to be "folded" onto multiple lines, then  the
+    syntax for folding must be adhered to.  (See items III.B.1.a,
+    above,  and  III.B.3.f,  below.)   Note  that  the   official
+    semantics therefore do not "see" any unquoted CRLFs which are
+    in comments, although particular parsing programs may wish to
+    note  their  presence.   For  these  programs,  it  would  be
+    reasonable to interpret a "CRLF LWSP-char" as  being  a  CRLF
+    which  is part of the comment; i.e., the CRLF is kept and the
+    LWSP-char is discarded.   Quoted  CRLFs  (i.e.,  a  backslash
+    followed  by a CR followed by a LF) still must be followed by
+    at least one LWSP-char.
+
+c.  Delimiting and quoting characters
+
+    The quote character (backslash) and characters which  delimit
+    syntactic units are not, generally, to be taken as data which
+    are part  of  the  delimited  or  quoted  unit(s).   The  one
+    exception is SPACE.  In particular, the quotation-marks which
+    define  a  quoted-string,  the  parentheses  which  define  a
+    comment  and the backslash which quotes a following character
+    are  NOT  part  of  the  quoted-string,  comment  or   quoted
+    character.   A  quotation-mark  which  is  to  be  part  of a
+    quoted-string, a parenthesis which is to be part of a comment
+    and  a  backslash  which is to be part of either must each be
+    preceded by the quote-character backslash ("\").   Note  that
+    the  syntax  allows  any  character  to  be  quoted  within a
+    quoted-string or comment;  however  only  certain  characters
+    MUST  be quoted to be included as data.  These characters are
+    those which are not part of the alternate text  group  (i.e.,
+    ctext or qtext).
+
+    A single SPACE is assumed to exist between  contiguous  words
+    in  a  phrase,  and this interpretation is independent of the
+    actual number of LWSP-chars which the creator places  between
+    the  words.  To include more than one SPACE, the creator must
+    make the LWSP-chars be part of a quoted-string.
+
+    Quotation marks which delimit a quoted string and backslashes
+    which  quote the following character should NOT accompany the
+    quoted-string when the string is used with processes that  do
+    not  interpret  data  according  to this specification (e.g.,
+    ARPANET FTP mail servers).
+
+
+Standard for the Format of Text Messages                       12
+III. Syntax
+  B. Lexical Analysis
+
+
+
+d.  Quoted-strings
+
+    Where   permitted  (i.e.,  in  words  in  structured  fields)
+    quoted-strings   are   treated   as  a  single  symbol  (i.e.
+    equivalent to an atom, syntactically).  If a quoted-string is
+    to  be  "folded"  onto  multiple  lines,  then the syntax for
+    folding must be adhered to.  (See items III.B.1.a, above, and
+    III.B.3.f,   below.)    Note   that  the  official  semantics
+    therefore do not "see" any bare CRLFs which  are  in  quoted-
+    strings,  although  particular  parsing  programs may wish to
+    note  their  presence.   For  these  programs,  it  would  be
+    reasonable  to  interpret  a "CRLF LWSP-char" as being a CRLF
+    which is part of the quoted-string; i.e., the  CRLF  is  kept
+    and  the  LWSP-char  is  discarded.   Quoted  CRLFs  (i.e., a
+    backslash followed by a CR followed by a LF) are also subject
+    to  rules  of  folding,  but  the  presence  of  the  quoting
+    character (backslash) explicitly indicates that the  CRLF  is
+    data to the quoted string.  Stripping off the first following
+    LWSP-char is also appropriate when parsing quoted CRLFs.
+
+e.  Bracketing characters
+
+    There are three types of brackets which must be well nested:
+
+        o  Parentheses are used to indicate comments.
+
+        o  Angle brackets ("<" and ">") are  generally  used
+           to indicate the presence of at least one machine-
+           usable code (e.g., delimiting mailboxes).
+
+        o  Colon/semi-colon  (":"  and  ";")  are   used  in
+           address   specifications  to  indicate  that  the
+           included list of addresses are to be treated as a
+           group.
+
+f.  Case independence of certain specials atoms
+
+    Certain atoms, which are represented in the syntax as literal
+    alphabetic  strings, can be represented in any combination of
+    upper and lower case.  These are:
+
+        -  field-name,
+        -  "Include", "Postal" and equivalent atoms in a
+           ":"<atom>":" address specification,
+        -  "at", in a host-indicator,
+        -  node,
+        -  day-of-week,
+        -  month, and
+        -  zones.
+
+    When matching an atom against one of these literals, case  is
+    to  be ignored.  For example, the field-names "From", "FROM",
+
+Standard for the Format of Text Messages                       13
+III. Syntax
+  B. Lexical Analysis
+
+
+
+    "from", and even "FroM" should all  be  treated  identically.
+    However,  the  case  shown in this specification is suggested
+    for message-creating processes.  Note that, at the  level  of
+    this  specification,  case  IS  relevant  to  other words and
+    texts.  Also see Section IV.A.1.f, below.
+
+g.  Folding long lines
+
+    Each header item (field of the message) may be represented on
+    exactly  one line consisting of the name of the field and its
+    body; this is what the parser sees.  For readability,  it  is
+    recommended  that the field-body portion of long header items
+    be "folded" onto multiple lines of the actual header.  "Long"
+    is  commonly  interpreted  to  mean  greater  than  65  or 72
+    characters.  The former length is recommended as a limit, but
+    it is not imposed by this standard.
+
+h.  Backspace characters
+
+    Backspace TELNET ASCII characters (ASCII BS, decimal 8.)  may
+    be   included   in   texts   and   quoted-strings  to  effect
+    overstriking; however, any use of backspaces which effects an
+    overstrike  to  the  left  of  the  beginning  of the text or
+    quoted-string is prohibited.
+
+
+
+C.  GENERAL SYNTAX OF MESSAGES:
+
+
+    NOTE:  Due to an artifact of the notational conventions,
+           the  syntax indicates that, when present, "Date",
+           "From", "Sender", and "Reply-To" fields  must  be
+           in  a  particular order.  These header items must
+           be unique (occur exactly once).   However  header
+           fields, in fact, are NOT required to occur in any
+           particular order, except that  the  message  body
+           must  occur  AFTER  the headers.  For readability
+           and ease of parsing  by  simple  systems,  it  is
+           recommended  that  headers  be  sent in the order
+           "Date", "From", "Subject", "Sender", "To",  "cc",
+           etc.    This   specification   permits   multiple
+           occurrences of  most  optional-fields.   However,
+           their  interpretation  is not specified here, and
+           their use is strongly discouraged.
+
+The following syntax for the bodies of various fields  should  be
+thought  of as describing each field body as a single long string
+(or line).   The  section  on  Lexical  Analysis  (section  II.B)
+indicates how such long strings can be represented on more than
+one line in the actual transmitted message.
+
+
+Standard for the Format of Text Messages                       14
+III. Syntax
+  C. Messages
+
+
+
+message     =  fields *( CRLF *text )       ; Everything after
+                                            ;  first null line
+                                            ;  is message body
+
+fields      =  date-field                   ; Creation time-stamp
+               originator-fields            ;  & author id are
+               *optional-field              ;  required: others
+                                            ;  are all optional
+
+originator-fields =
+               (  "From"     ":" mailbox    ; Single author
+                 ["Reply-To" ":" #address] )
+            /  (  "From"     ":" 1#address  ; Multiple authors &
+                  "Sender"   ":" mailbox    ;  may have non-mach-
+                 ["Reply-To" ":" #address] );  ine addresses
+
+date-field  =  "Date"       ":" date-time
+
+optional-field  =
+               "To"         ":" #address
+            /  "cc"         ":" #address
+            /  "bcc"        ":" #address    ; Blind carbon
+            /  "Subject"    ":" *text
+            /  "Comments"   ":" *text
+            /  "Message-ID" ":" mach-id     ; Only one allowed
+            /  "In-Reply-To"":" #(phrase / mach-id)
+            /  "References" ":" #(phrase / mach-id)
+            /  "Keywords"   ":" #phrase
+            /  extension-field              ; To be defined in
+                                            ;  supplemental
+                                            ;  specifications
+            /  user-defined-field           ; Must have unique
+                                            ;  field-name & may
+                                            ;  be pre-empted
+
+extension-field = <Any field which is defined in a document
+               published as a formal extension to this
+               specification>
+
+user-defined-field = <Any field which has not been defined in
+               this specification or published as an extension to
+               this specification; names for such fields must be
+               unique and may be preempted by published
+               extensions>
+
+
+
+
+Standard for the Format of Text Messages                       15
+III. Syntax
+  D. Addressee Items
+
+
+
+D.  SYNTAX OF GENERAL ADDRESSEE ITEMS
+
+
+address     =  host-phrase                  ; Machine mailbox
+            / ( [phrase] "<" #address ">")  ; Individual / List
+            / ( [phrase] ":" #address ";")  ; Group
+            /  quoted-string                ; Arbitrary text
+            / (":" ( "Include"              ; File, w/ addr list
+                   / "Postal"               ; (U.S.) Postal addr
+                   /  atom )                ; Extended data type
+               ":" address)
+
+mailbox     =  host-phrase /  (phrase mach-id)
+
+mach-id     =  "<" host-phrase ">"          ; Contents must never
+                                            ;  be modified!
+
+
+
+E.  SUPPORTING CONSTRUCTS
+
+
+host-phrase =  phrase  host-indicator       ; Basic address
+
+host-indicator =  1*( ("at" / "@") node )   ; Right-most node is
+                                            ;  at top of network
+                                            ;  hierarchy; left-
+                                            ;  most must be host
+
+node        =  word / 1*DIGIT               ; Official host or
+                                            ;  network name or
+                                            ;  decimal address
+
+
+date-time   =  [ day-of-week "," ] date time
+
+day-of-week =  "Monday"    / "Mon"  / "Tuesday"   / "Tue"
+            /  "Wednesday" / "Wed"  / "Thursday"  / "Thu"
+            /  "Friday"    / "Fri"  / "Saturday"  / "Sat"
+            /  "Sunday"    / "Sun"
+
+date        =  1*2DIGIT ["-"] month         ; day month year
+               ["-"] (2DIGIT /4DIGIT)       ;  e.g. 20 Aug [19]77
+
+month       =  "January"   / "Jan"  / "February"  / "Feb"
+            /  "March"     / "Mar"  / "April"     / "Apr"
+            /  "May"                / "June"      / "Jun"
+            /  "July"      / "Jul"  / "August"    / "Aug"
+            /  "September" / "Sep"  / "October"   / "Oct"
+            /  "November"  / "Nov"  / "December"  / "Dec"
+
+
+Standard for the Format of Text Messages                       16
+III. Syntax
+  E. Supporting Constructs
+
+
+
+time        =  hour zone                    ; ANSI and Military
+                                            ;  (seconds optional)
+
+hour        =  2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
+                                            ; 0000[00] - 2359[59]
+
+zone        = ( ["-"] ( "GMT"               ; Relative to GMT:
+                                            ; North American
+                 /  "NST" /                 ;  Newfoundland:-3:30
+                 /  "AST" / "ADT"           ;  Atlantic: - 4/ - 3
+                 /  "EST" / "EDT"           ;  Eastern:  - 5/ - 4
+                 /  "CST" / "CDT"           ;  Central:  - 6/ - 5
+                 /  "MST" / "MDT"           ;  Mountain: - 7/ - 6
+                 /  "PST" / "PDT"           ;  Pacific:  - 8/ - 7
+                 /  "YST" / "YDT"           ;  Yukon:    - 9/ - 8
+                 /  "HST" / "HDT"           ;  Haw/Ala   -10/ - 9
+                 /  "BST" / "BDT"           ;  Bering:   -11/ -10
+                    1ALPHA       ))         ; Military: Z = GMT;
+                                            ;  A:-1; (J not used)
+                                            ;  M:-12; N:+1; Y:+12
+            / ( ("+" / "-") 4DIGIT )        ; Local differential
+                                            ;  hours/min. (HHMM)
+
+phrase      =  1*word                       ; Sequence of words.
+                                            ;  Separation seman-
+                                            ;  tically = SPACE
+
+word        =  atom / quoted-string
+
+
+
+Standard for the Format of Text Messages                       17
+IV. Semantics
+ A. Address Fields
+
+
+
+
+
+                         IV.  SEMANTICS
+
+
+
+A.  ADDRESS FIELDS
+
+
+1.  General
+
+a.  The phrase part of a host-phrase in an address  specification
+    (i.e.,  the  host's name for the mailbox) is understood to be
+    whatever the receiving FTP Server allows (for example,  TENEX
+    systems  do  not  now understand addresses of the form "P. D.
+    Q. Bach", but another system might).
+
+    Note that a mailbox is a conceptual  entity  which  does  not
+    necessarily pertain to file storage.  For example, some sites
+    may choose to print mail on their line  printer  and  deliver
+    the output to the addressee's desk.
+
+    An individual may have  several  mailboxes  and  a  group  of
+    individuals  may wish to receive mail as a single unit (i.e.,
+    a distribution list).  The second and third  alternatives  of
+    an  address  list  (#address)  allow  naming  a collection of
+    subordinate  addresses  list(s).   Recipient  mailboxes   are
+    specified  within the bracketed part ("<" - ">" or ":" - ";")
+    of such named lists.  The use of angle-brackets ("<", ">") is
+    intended for the cases of individuals with multiple mailboxes
+    and of special mailbox lists; it is not expected to be nested
+    more  than  one level, although the specification allows such
+    nesting.  The use of colon/semi-colon (":", ";") is  intended
+    for  the  case  of  groups.   Groups  can be expected to nest
+    (i.e., to  contain  subgroups).   For  both  individuals  and
+    groups,  a  copy  of the transmitted message is to be sent to
+    EACH mailbox  listed.   For  the  case  of  a  special  list,
+    treatment of addresses is defined in the relevant subsections
+    of this section.
+
+b.  The inclusion of bare quoted-strings as addresses (i.e.,  the
+    fourth  address-form  alternative)  is allowed as a syntactic
+    convenience, but no semantics  are  defined  for  their  use.
+    However,  it is reasonable, when replicating an address list,
+    to replicate ALL of its members, including quoted-strings.
+
+c.  ":Include:" specifications are used to refer to one  or  more
+    locations  containing  stored  address  lists (#address).  If
+    more than one location is referenced, the address part of the
+    Include  phrase  must  be  a  list  (#address)  surrounded by
+    angle-brackets, as per the "Individual / List" alternative of
+    <address>.   Constituent  addresses  must  resolve to a host-
+
+Standard for the Format of Text Messages                       18
+IV. Semantics
+ A. Address Fields
+
+
+
+    phrase; only they have any  meaning  within  this  construct.
+    The phrase part of indicated host-phrases should contain text
+    which the referenced  host  can  resolve  to  a  file.   This
+    standard is not a protocol and so does not prescribe HOW data
+    is to be retrieved from the  file.   However,  the  following
+    requirements are made:
+
+         o  The file must be accessible  through  the  local
+            operating system interface (if it exists), given
+            adequate user access rights; and
+
+         o  If a host has an FTP server and a user  is  able
+            to  retrieve  any files from the host using that
+            server, then the file must be accessible through
+            FTP,  using  DEFAULT  transfer  settings,  given
+            adequate user access rights.
+
+    It is intended that this mechanism allow programs to retrieve
+    such lists automatically.
+
+    The interpretation of such a file reference follows.  This is
+    not  intended  to imply any particular implementation scheme,
+    but is presented  to  aid  in  understanding  the  notion  of
+    including  file  contents in address lists:
+
+         o  Elements of the address list part are alternates
+            and  the  contents of ONLY ONE of them are to be
+            included in the resultant address list.
+
+         o  The contents of the file indicated by  a  member
+            host-phrase  are  treated as an address list and
+            are inserted as an address  list  (#address)  in
+            the  position  of  the  path item in the syntax.
+            That is, the TELNET ASCII characters  specifying
+            the  entire Include <address> is replaced by the
+            contents of one of the files to which the  host-
+            phrase(s),   of  the  address  list  (#address),
+            refers.  Therefore, the contents of  each  file,
+            indicated   by   an  Include  address,  must  be
+            syntactically self-contained and must adhere  to
+            the full syntax prescribed herein for an address
+            list.
+
+d.  ":Postal:" specifications are used to indicate (U.S.)  postal
+    addresses,  but  can  be  treated  the  same as quoted-string
+    addresses.  To reference a list of postal addresses, the list
+    must  conform  to  the  "Individual  /  List"  alternative of
+    <address>.  The ":Include:" alternative also is valid.
+
+e.  The "':' atom ':'" syntax is intended as a general  mechanism
+    for  indicating  specially  data-typed  addresses.   As  with
+    extension-fields, the authors of this document will  regulate
+
+Standard for the Format of Text Messages                       19
+IV. Semantics
+ A. Address Fields
+
+
+
+    the  publishing  of  specifications  for these extended data-
+    types.  In the absence of defined semantics,  any  occurrence
+    of  an address in this form may be treated as a quoted-string
+    address.
+
+f.  A node name must be THE official name of a network or a host,
+    or  else  a decimal number indicating the Network address for
+    that network or host, at the time  the  message  is  created.
+    The  USE  OF NUMBERS IS STRONGLY DISCOURAGED and is permitted
+    only due to the occasional necessity of bypassing local  name
+    tables.   For  the  ARPANET, official names are maintained by
+    the Network Information Center at  SRI  International,  Menlo
+    Park, California.
+
+    Whenever a message might be transmitted or migrate to a  host
+    on  another  network,  full  hierarchical  addresses  must be
+    specified.   These  are  indicated  as  a  series  of  words,
+    separated  by at-sign or "at" indications.  The communication
+    environment is assumed to consist of a collection of networks
+    organized  as  independent  "trees"  except  for  connections
+    between the root nodes.  That is, only the roots can  act  as
+    gateways  between  these  independent  networks.  While other
+    actual connections may exist, it is believed  that  presuming
+    this  type of organization will provide a reliable method for
+    describing VALID, if not EFFICIENT, paths between  hosts.   A
+    typical full mailbox specification might therefore look like:
+
+         Friendly User @ hosta @ local-net1 @ major-netq
+
+    In the simplest case, a mail-sending host should transmit the
+    message  to the node which is mentioned last (farthest to the
+    right), strip off that node reference from the specification,
+    and then pass the remaining host-phrase to the recipient host
+    (in  the  ARPANET,  its  FTP server) for it to process.  This
+    treats the remaining portion of the host-indicator merely  as
+    the terminating part of the phrase.
+
+         NOTE:  When passing any portion of a host-indicator
+                onto a process which does not interpret data
+                according to this  standard  (e.g.,  ARPANET
+                FTP  servers), "@" must be used and not "at"
+                and it must not be preceded or  followed  by
+                any  LWSP-chars.   Using  the above example,
+                the following string would be passed to  the
+                major-netq gateway:
+
+                Friendly User@hosta@local-net1
+
+    When the sending host  has  more  knowledge  of  the  network
+    environment,  then  it  should  send the message along a more
+    efficient path, making appropriate changes to the form of the
+    host-phrase which it gives to the recipient host.
+
+Standard for the Format of Text Messages                       20
+IV. Semantics
+ A. Address Fields
+
+
+
+    To use the above specification as an example:  If  a  sending
+    hostb  also were part of local-net1, then it could  send  the
+    message  directly  to  hosta  and  would give only the phrase
+    "Friendly User" to hosta's mail-receiving program.  If  hostb
+    were  part  of  local-net2, along with hostc, and happened to
+    know that hosta and hostc were  part  of  another  local-net,
+    then  hostb  could  send  the message to hostc to the address
+    "Friendly User@hosta".
+
+    The phrase in a host-phrase is intended to be meaningful only
+    to  the  indicated  receiving  host.  To all other hosts, the
+    phrase is to be treated as an uninterpreted string.  No  case
+    transformations  should  be  (automatically) performed on the
+    phrase.  The phrase  is  passed  to  the  local  host's  mail
+    sending  program; it is the responsibility of the destination
+    host's mail receiving (distribution) program to perform  case
+    mapping on this phrase, if required, to deliver the mail.
+
+
+2.  Originator Fields
+
+    WARNING:  The standard  allows  only  a  subset  of  the
+              combinations  possible  with the From, Sender,
+              and  Reply-To  fields.   The   limitation   is
+              intentional.
+
+a.  From
+
+    This field contains the identity of the person(s) who  wished
+    this message to be sent.  The message-creation process should
+    default this field to be a single machine address, indicating
+    the AGENT (person or process) entering the message.  If  this
+    is  NOT  done, the "Sender" field MUST be present; if this IS
+    done, the "Sender" field is optional.
+
+b.  Sender
+
+    This field contains  the  identity  of  the  AGENT (person or
+    process) who  sends the message.  It is intended for use when
+    the sender is not the author of the message, or  to  indicate
+    who  among  a group of authors actually sent the message.  If
+    the contents  of  the  "Sender"  field  would  be  completely
+    redundant with the "From" field, then the "Sender" field need
+    not be present and  its  use  is  discouraged  (though  still
+    legal);  in  particular,  the  "Sender" field MUST be present
+    if it is NOT the same as the "From" Field.
+
+    The  Sender  host-phrase  includes  a   phrase   which   must
+    correspond  to  a  specific  agent  (i.e.,  a human user or a
+    computer program)  rather  than  a  standard  address.   This
+    indicates  the  expectation  that the field will identify the
+    single AGENT (person or process) responsible for sending  the
+
+Standard for the Format of Text Messages                       21
+IV. Semantics
+ A. Address Fields
+
+
+
+    mail  and not simply include the name of a mailbox from which
+    the mail was sent.  For example in the case of a shared login
+    name, the name, by itself, would not be adequate.  The phrase
+    part of the host-phrase,  which  refers  to  this  agent,  is
+    expected  to be a computer system term, and not (for example)
+    a generalized person reference which can be used outside  the
+    network text message context.
+
+    Since the critical function served by the "Sender"  field  is
+    the  identification of the agent responsible for sending mail
+    and since computer programs cannot be  held  accountable  for
+    their  behavior, is strongly recommended that when a computer
+    program generates a message, the HUMAN who is responsible for
+    that  program  be  referenced  as  part of the "Sender" field
+    host-phrase.
+
+c.  Reply-To
+
+    This field provides a general mechanism  for  indicating  any
+    mailbox(es) to which responses are to be sent.  Three typical
+    uses for this feature can be  distinguished.   In  the  first
+    case,  the  author(s)  may  not  have  regular  machine-based
+    mailboxes and therefore wish(es)  to  indicate  an  alternate
+    machine  address.   In  the  second  case, an author may wish
+    additional persons to be made aware of, or  responsible  for,
+    responses;  responders  should  send  their  replies  to  the
+    "Reply-To" mailbox(es) listed in  the  original  message.   A
+    somewhat  different  use may be of some help to "text message
+    teleconferencing" groups equipped with automatic distribution
+    services:   include  the  address  of  that  service  in  the
+    "Reply-To"  field  of   all   messages   submitted   to   the
+    teleconference;  then  participants can "reply" to conference
+    submissions to guarantee  the  correct  distribution  of  any
+    submission of their own.
+
+    Reply-To fields are  NOT  required  to  contain  any  machine
+    addresses  (i.e., host-phrases).   Note,  however,  that  the
+    absence  of even one  valid  network  address  will  tend  to
+    prevent  software  systems from automatically assisting users
+    in conveniently responding to mail.
+
+NOTE:  For systems which automatically generate address lists for
+replies to messages, the following recommendations are made:
+
+     o  The receiver, when replying  to  a  message,  should
+        NEVER automatically include the "Sender" host-phrase
+        in the reply's address list;
+
+     o  If the  "Reply-To"  field  exists,  then  the  reply
+        should  go  ONLY  to the addresses indicated in that
+        field and not to  the  addresses  indicated  in  the
+        "From" field.
+
+Standard for the Format of Text Messages                       22
+IV. Semantics
+ A. Address Fields
+
+
+
+(Extensive    examples  are  provided  in   Section   V.)    This
+recommendation  is intended only for originator-fields and is not
+intended to suggest that replies should not also be sent  to  the
+other  recipients  of  this  message.  It is up to the respective
+mail handling programs to decide what additional facilities  will
+be provided.
+
+
+3.  Receiver Fields
+
+a.  To
+
+    This field contains the identity of the primary recipients of
+    the message.
+
+b.  cc
+
+    This field contains the identity of the secondary  recipients
+    of the message.
+
+b.  Bcc
+
+    This field contains the identity of additional recipients  of
+    the  message.  The contents of this field are not included in
+    copies of the message  sent  to  the  primary  and  secondary
+    recipients.   Some  systems may choose to include the text of
+    the "Bcc" field only in the author(s)'s  copy,  while  others
+    may  also  include it in the text sent to all those indicated
+    in the "Bcc" list.
+
+
+
+B.  REFERENCE SPECIFICATION FIELDS
+
+
+1.  Message-ID
+
+This field contains a unique identifier (the phrase) which refers
+to  THIS  version of THIS message.  The uniqueness of the message
+identifier is guaranteed by the host which  generates  it.   This
+identifier is intended to be machine readable and not necessarily
+meaningful to humans.  A message identifier pertains  to  exactly
+one  instantiation  of a particular message; subsequent revisions
+to the message should each receive a new message identifier.
+
+
+2.  In-Reply-To
+
+The contents of this field identify previous correspondence which
+this  message answers.  Note that if message identifiers are used
+in this field, they must use the mach-id specification format.
+
+
+Standard for the Format of Text Messages                       23
+IV. Semantics
+ B. Reference Specification Fields
+
+
+
+3.  References
+
+The contents of this field identify  other  correspondence  which
+this  message  references.   Note  that  if  message  identifiers
+are used, they  must  use  the  mach-id  specification format.
+
+
+4.  Keywords
+
+This field contains keywords or phrases, separated by commas.
+
+
+
+C.  OTHER FIELDS AND SYNTACTIC ITEMS
+
+
+1.  Subject
+
+The "Subject" field is intended to provide as much information as
+necessary  to  adequately summarize or indicate the nature of the
+message.
+
+
+2.  Comments
+
+Permits adding text comments onto the message without  disturbing
+the contents of the message's body.
+
+
+3.  Extension-field
+
+A relatively limited number of common fields have been defined in
+this  document.  As network mail requirements dictate, additional
+fields may be standardized.  The authors of  this  document  will
+regulate  the publishing of such definitions as extensions to the
+basic specification.
+
+
+4.  User-defined-field
+
+Individual users of network mail  are  free  to  define  and  use
+additional  header fields.  Such fields must have names which are
+not  already  used  in  the  current  specification  or  in   any
+definitions  of extension-fields, and the overall syntax of these
+user-defined-fields must conform to  this  specification's  rules
+for  delimiting and  folding  fields.  Due to the extension-field
+publishing process, the name of a user-defined-field may be  pre-
+empted.
+
+
+
+
+Standard for the Format of Text Messages                       24
+IV. Semantics
+ D. Dates
+
+
+
+D.  DATES AND TIMES
+
+If included, day-of-week must be the  day  implied  by  the  date
+specification.
+
+Time zone  may  be  indicated  in  several  ways.   The  military
+standard   uses  a  single  character  for  each  zone.   "Z"  is
+Greenwhich Mean Time; "A" indicates one  hour  earlier,  and  "M"
+indicates  12 hours earlier; "N" is one hour later, and "Y" is 12
+hours later.  The letter "J" is not used.   The  other  remaining
+two  forms  are  taken from ANSI standard X3.51-1975.  One allows
+explicit indication of the amount of offset from GMT;  the  other
+uses  common  3-character  strings  for  indicating time zones in
+North America.
+
+
+Standard for the Format of Text Messages                       25
+V. Examples
+A. Addresses
+
+
+
+
+
+                          V.  EXAMPLES
+
+
+A.  ADDRESSES
+
+
+1.  Alfred E. Neuman <Neuman at BBN-TENEXA>
+
+2.  Neuman@BBN-TENEXA
+
+These two "Alfred E. Neuman" examples have  identical  semantics,
+as  far  as  the  operation  of  the  local  host's  mail sending
+(distribution) program (also sometimes called its  "mailer")  and
+the  remote  host's  FTP  server  are  concerned.   In  the first
+example, the "Alfred E. Neuman" is  ignored  by  the  mailer,  as
+"Neuman  at  BBN-TENEXA" completely specifies the recipient.  The
+second example contains no superfluous information,  and,  again,
+"Neuman@BBN-TENEXA" is the intended recipient.
+
+
+3.  Al Neuman at BBN-TENEXA
+
+This is identical to "Al Neuman <Al Neuman at BBN-TENEXA>".  That
+is,  the  full  phrase, "Al Neuman", is passed to the FTP server.
+Note that not all FTP servers accept multi-word identifiers;  and
+some  that  do  accept  them  will treat each word as a different
+addressee (in this case, attempting to send a copy of the message
+to "Al" and a copy to "Neuman").
+
+
+4.  "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1>
+
+This form might be used to indicate  that  a  single  mailbox  is
+shared  by  several  users.   The quoted string is ignored by the
+originating  host's  mailer,  as  "Shared-Mailbox  at   Office-1"
+completely specifies the destination mailbox.
+
+
+4.  Wilt (the Stilt) Chamberlain at NBA
+
+The "(the Stilt)" is a comment, which  is  NOT  included  in  the
+destination  mailbox  address  handed to the originating system's
+mailer.  The  address  is  the  string  "Wilt Chamberlain",  with
+exactly  one  space  between  the  first  and second words.  (The
+quotation marks are not included.)
+
+
+
+
+Standard for the Format of Text Messages                       26
+V. Examples
+B. Address Lists
+
+
+
+B.  ADDRESS LISTS
+
+    Gourmets:  Pompous Person <WhoZiWhatZit at Cordon-Bleu>,
+               Cooks:  Childs at WGBH, Galloping Gourmet at
+                       ANT (Australian National Television);,
+               Wine Lovers:  Cheapie at Discount-Liquors,
+                             Port at Portugal;;,
+    Jones at SEA
+
+This group list example points  out  the  use  of  comments,  the
+nesting  of groups, and the mixing of addresses and groups.  Note
+that the two consecutive semi-colons  preceding  "Jones  at  SEA"
+mean that Jones is NOT a member of the Gourmets group.
+
+
+C.  ORIGINATOR ITEMS
+
+
+1.  Author-sent
+
+George Jones logs into  his  Host  as  "Jones".   He  sends  mail
+himself.
+
+    From:  Jones at Host
+or
+    From:  George Jones <Jones at Host>
+
+
+2.  Secretary-sent
+
+George Jones logs in as Jones on his Host.   His  secretary,  who
+logs in as Secy on Shost sends mail for him.  Replies to the mail
+should go to George, of course.
+
+    From:    George Jones <Jones at Host>
+    Sender:  Secy at SHost
+
+
+3.  Shared directory or unrepresentative directory-name
+
+George Jones logs in as Group at Host.  He  sends  mail  himself;
+replies should go to the Group mailbox.
+
+    From:  George Jones <Group at Host>
+
+
+
+Standard for the Format of Text Messages                       27
+V. Examples
+C. Originator Items
+
+
+
+4.  Secretary-sent, for user of shared directory
+
+George Jones' secretary sends mail for George in his capacity  as
+a  member  of  Group  while  logged  in as Secy at Host.  Replies
+should go to Group.
+
+    From:   George Jones<Group at Host>
+    Sender: Secy at Host
+
+Note that there need not be a space between "Jones" and the  "<",
+but  adding a space enhances readability (as is the case in other
+examples).
+
+
+5.  Secretary acting as full agent of author
+
+George Jones asks his secretary (Secy at Host) to send a  message
+for  him  in  his  capacity  as Group.  He wants his secretary to
+handle all replies.
+
+    From:     George Jones <Group at Host>
+    Sender:   Secy at Host
+    Reply-To: Secy at Host
+
+
+6.  Agent for user without online mailbox
+
+A  non-ARPANET  user  friend  of  George's,  Sarah,  is  visting.
+George's  secretary  sends  some  mail  to  a  friend of Sarah in
+computer-land.  Replies should go to  George,  whose  mailbox  is
+Jones at Host.
+
+    From:     Sarah Friendly
+    Sender:   Secy at Host
+    Reply-To: Jones at Host
+
+
+7.  Sent by member of a committee
+
+George is a member of a committee.  He wishes to have any replies
+to his message go to all committee members.
+
+    From:     George Jones
+    Sender:   Jones at Host
+    Reply-To: Big-committee: Jones at Host,
+                             Smith at Other-Host,
+                             Doe at Somewhere-Else;
+
+Note that if George had not included himself in  the  enumeration
+of Big-committee, he would not have gotten an implicit reply; the
+presence  of  the  "Reply-to"  field  SUPERSEDES the sending of a
+reply to the person named in the "From" field.
+
+Standard for the Format of Text Messages                       28
+V. Examples
+C. Originator Items
+
+
+
+8.  Example of INCORRECT use
+
+George desires a reply to go  to  his  secretary;  therefore  his
+secretary  leaves  his  mailbox  address  off  the  "From" field,
+leaving only his name, which is not, itself, a mailbox address.
+
+         From:   George Jones
+         Sender: Secy at SHost
+
+THIS IS NOT PERMITTED.  Replies are NEVER implicitly sent to  the
+"Sender";  George's  secretary  should  have  used the "Reply-To"
+field, or the  mail  creating  program  should  have  forced  the
+secretary to.
+
+9.  Agent for member of a committee
+
+George's secretary sends out a message which was authored jointly
+by all the members of the "Big-committee".
+
+         From:   Big-committee: Jones at Host,
+                                Smith at Other-Host,
+                                Doe at Somewhere-Else;
+         Sender: Secy at SHost
+
+
+
+D.  COMPLETE HEADERS
+
+
+1.  Minimum required:
+
+       Date:  26 August 1976 1429-EDT
+       From:  Jones at Host
+
+
+2.  Using some of the additional fields:
+
+       Date: 26 August 1976 1430-EDT
+       From:George Jones<Group at Host>
+       Sender:Secy at SHOST
+       To:Al Neuman at Mad-Host,
+                Sam Irving at Other-Host
+       Message-ID:  <some string at SHOST>
+
+
+
+Standard for the Format of Text Messages                       29
+V. Examples
+D.  Complete Headers
+
+
+
+3.  About as complex as you're going to get:
+
+       Date     :  27 Aug 1976 0932-PDT
+       From     :  Ken Davis <KDavis at Other-Host>
+       Subject  :  Re: The Syntax in the RFC
+       Sender   :  KSecy at Other-Host
+       Reply-To :  Sam Irving at Other-Host
+       To       :  George Jones <Group at Host>,
+                   Al Neuman at Mad-Host
+       cc       :  Important folk:
+                   Tom Softwood <Balsa at Another-Host>,
+                   Sam Irving at Other-Host;,
+                   Standard Distribution::Include:
+                    </main/davis/people/standard at Other-Host,
+                     "<Jones>standard.dist.3" at Tops-20-Host>,
+                   (The following Included Postal list is part
+                   of Standard Distribution.)
+                   :Postal::Include: Non-net-addrs@Other-host;,
+                   :Postal: "Sam Irving, P.O. Box 001, Las Vegas,
+                             Nevada"  (So that he can stay
+                             apprised of the situation)
+       Comment  :  Sam is away on business. He asked me to handle
+                   his mail for him.  He'll be able to provide  a
+                   more  accurate  explanation  when  he  returns
+                   next week.
+       In-Reply-To: <some string at SHOST>
+       Special (action):  This is a sample of multi-word field-
+                   names, using a range of characters.  There
+                   could also be a field-name "Special (info)".
+       Message-ID: <4231.629.XYzi-What at Other-Host>
+
+
+Standard for the Format of Text Messages                       31
+Appendix
+A. Alphabetical Listing of Syntax Rules
+
+
+
+
+
+                        APPENDIX
+
+
+
+A.  ALPHABETICAL LISTING OF SYNTAX RULES
+
+
+address     =  host-phrase / quoted-string
+            / (*phrase "<" #address ">" )
+            / (*phrase ":" #address ";" )
+            / (":" ("Include" / "Postal" / atom) ":" address)
+ALPHA       =  <any TELNET ASCII alphabetic character>
+atom        =  1*<any CHAR except specials and CTLs>
+
+CHAR        =  <any TELNET ASCII character>
+comment     =  "(" *(ctext / comment / quoted-pair) ")"
+CR          =  <TELNET ASCII carriage return>
+CRLF        =  CR LF
+ctext       =  <any CHAR excluding "(", ")", CR, LF and
+               including linear-white-space>
+CTL         =  <any TELNET ASCII control character and DEL>
+
+date        =  1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT)
+date-field  =  "Date"       ":" date-time
+date-time   =  [ day-of-week "," ] date time
+day-of-week =  "Monday"    / "Mon"  / "Tuesday"   / "Tue"
+            /  "Wednesday" / "Wed"  / "Thursday"  / "Thu"
+            /  "Friday"    / "Fri"  / "Saturday"  / "Sat"
+            /  "Sunday"    / "Sun"
+delimiters  =  specials / comment / linear-white-space
+DIGIT       =  <any TELNET ASCII digit>
+
+extension-field = <Any field which is defined in a document
+               published as a formal extension to this
+               specification>
+
+field       =  field-name ":" [ field-body ] CRLF
+
+fields      =  date-field  originator-fields  *optional-field
+field-body  =  field-body-contents
+               [CRLF LWSP-char field-body]
+field-body-contents = <the TELNET ASCII characters making up the
+               field-body, as defined in the following sections,
+               and consisting of combinations of atom, quoted-
+               string, and specials tokens, or else consisting of
+               texts>
+field-name  =  fnatom *(LWSP-char [fnatom])
+fnatom      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+
+Standard for the Format of Text Messages                       32
+Appendix
+A. Alphabetical Listing of Syntax Rules
+
+
+
+host-indicator =  1*( ("at" / "@") node )
+host-phrase =  phrase  host-indicator
+hour        =  2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
+HTAB        =  <TELNET ASCII horizontal-tab>
+
+LF          =  <TELNET ASCII linefeed>
+linear-white-space =  1*([CRLF] LWSP-char)
+LWSP-char   = SPACE / HTAB
+
+mach-id     =  "<" host-phrase ">"
+mailbox     =  host-phrase /  (phrase mach-id)
+message     =  fields *(CRLF *text)
+month       =  "January"   / "Jan"  / "February"  / "Feb"
+            /  "March"     / "Mar"  / "April"     / "Apr"
+            /  "May"                / "June"      / "Jun"
+            /  "July"      / "Jul"  / "August"    / "Aug"
+            /  "September" / "Sep"  / "October"   / "Oct"
+            /  "November"  / "Nov"  / "December"  / "Dec"
+
+node        =  word / 1*DIGIT
+
+optional-field  =
+               "To"         ":" #address
+            /  "cc"         ":" #address
+            /  "bcc"        ":" #address
+            /  "Subject"    ":" *text
+            /  "Comments"   ":" *text
+            /  "Message-ID" ":" mach-id
+            /  "In-Reply-To"":" #(phrase / mach-id)
+            /  "References" ":" #(phrase / mach-id)
+            /  "Keywords"   ":" #phrase
+            /  extension-field
+            /  user-defined-field
+originator-fields =
+               (  "From"     ":" mailbox
+                 ["Reply-To" ":" #address] )
+            /  (  "From"     ":" 1#address
+                  "Sender"   ":" mailbox
+                 ["Reply-To" ":" #address] )
+
+phrase      =  1*word
+
+quoted-pair =  "\" CHAR
+quoted-string =  <">  *(qtext / quoted-pair)  <">
+qtext       =  <any CHAR except <">, CR, or LF and including
+               linear-white-space>
+SPACE       =  <TELNET ASCII space>
+specials    =  "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":"
+            /  "\" / <">
+
+text        =  <any CHAR, including bare CR and/or bare LF, but
+               NOT including CRLF>
+
+Standard for the Format of Text Messages                       33
+Appendix
+A. Alphabetical Listing of Syntax Rules
+
+
+
+time        =  hour zone
+
+user-defined-field = <Any field which has not been defined in
+               this specification or published as an extension to
+               this specification; names for such fields must be
+               unique and may be preempted by putlished
+               extensions>
+
+word        =  atom / quoted-string
+
+zone        = ( ("+" / "-") 4DIGIT )
+            / ( ["-"] (1ALPHA
+              / "GMT" / "NST"  / "AST" / "ADT" / "EST" / "EDT"
+              / "CST" / "CDT"  / "MST" / "MDT" / "PST" / "PDT"
+              / "YST" / "YDT"  / "HST" / "HDT" / "BST" / "BDT" ))
+
+<">         =  <TELNET ASCII quote mark>
+
+
+Standard for the Format of Text Messages                       35
+Appendix
+B. Simple Parsing
+
+
+
+
+B.  SIMPLE PARSING
+
+
+     Some mail-reading software systems may wish to perform  only
+minimal  processing,  ignoring  the internal syntax of structured
+field-bodies and treating them the  same  as  unstructured-field-
+bodies.  Such software will need only to distinguish:
+
+     -  Header fields from the message body,
+     -  Beginnings of fields from lines which continue fields,
+     -  Field-names from field-contents.
+
+     The abbreviated set of syntactic rules  which  follows  will
+suffice  for  this  purpose.   They  describe  a  limited view of
+messages and are a subset of the syntactic rules provided in  the
+main part of this specification.  One small exception is that the
+contents of field-bodies consist only of text:
+
+
+SYNTAX:
+
+message         =  *field *(CRLF *text)
+
+field           =  field-name ":" [field-body] CRLF
+
+field-name      =  fnatom *( LWSP-char [fnatom] )
+
+fnatom          =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+
+field-body      =  *text [CRLF LWSP-char field-body]
+
+
+SEMANTICS:
+
+     Headers occur before the message body and are terminated  by
+a null line (i.e., two contiguous CRLFs).
+
+     A line which continues a header field begins with a SPACE or
+HTAB  character,  while  a  line  beginning a field starts with a
+printable character which is not a colon.
+
+     A field-name consists of one or  more  printable  characters
+(excluding colon), each separated by one or more SPACES or HTABS.
+A field-name MUST be contained on one line.  Upper and lower case
+are not distinguished when comparing field-names.
+
+
+Standard for the Format of Text Messages                       37
+Bibliography
+
+
+
+
+
+
+                          BIBLIOGRAPHY
+
+
+ANSI.   Representations   of   universal   time,    local    time
+   differentials,  and  United  States  time  zone references for
+   information interchange.  ANSI X3.51-1975;  American  National
+   Standards Institute:  New York, 1975.
+
+Bhushan, A.K.  The File Transfer Protocol.  ARPANET  Request  for
+   Comments,  No.   354,  Network  Information Center No.  10596;
+   Augmentation Research  Center,  Stanford  Research  Institute:
+   Menlo Park, July 1972.
+
+Bhushan, A.K.  Comments on the File Transfer  Protocol.   ARPANET
+   Request for Comments, No.  385, Network Information Center No.
+   11357;  Augmentation  Research   Center,   Stanford   Research
+   Institute:  Menlo Park, August 1972.
+
+Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
+   Standardizing  Network  Mail  Headers.   ARPANET  Request  for
+   Comments, No.  561,  Network  Information  Center  No.  18516;
+   Augmentation  Research  Center,  Stanford  Research Institute:
+   Menlo Park, September 1973.
+
+Feinler,  E.J.  and  Postel,  J.B.   ARPANET  Protocol  Handbook.
+   Network  Information  Center  No.  7104; Augmentation Research
+   Center, Stanford Research Institute:  Menlo Park,  April  1976.
+   (NTIS AD A003890).
+
+McKenzie,  A.   File  Transfer  Protocol.   ARPANET  Request  for
+   Comments,  No.  454,  Network  Information  Center  No. 14333;
+   Augmentation Research  Center,  Stanford  Research  Institute:
+   Menlo Park, February 1973.
+
+McKenzie,  A. TELNET Protocol Specification.  Network Information
+   Center  No.   18639;  Augmentation  Research  Center, Stanford
+   Research Institute:  Menlo Park, August 1973.
+
+Myer, T.H. and Henderson, D.A.   Message  Transmission  Protocol.
+   ARPANET  Request  for  Comments,  No. 680, Network Information
+   Center  No.  32116;  Augmentation  Research  Center,  Stanford
+   Research Institute:  Menlo Park, 1975.
+
+Neigus,  N.   File  Transfer  Protocol.   ARPANET   Request   for
+   Comments,  No.  542,  Network  Information  Center  No. 17759;
+   Augmentation Research  Center,  Stanford  Research  Institute:
+   Menlo Park, July 1973.
+
+Pogran, K., Vittal, J., Crocker, D. and Henderson,  A.   Proposed
+   official  standard  for  the  format of ARPA network messages.
+
+Standard for the Format of Text Messages                       38
+Bibliography
+
+
+
+
+   ARPANET Request for Comments,  No.  724,  Network  Information
+   Center  No.  37435;  Augmentation  Research  Center,  Stanford
+   Research Institute:  Menlo Park, May 1977.
+
+Postel, J.B.  Revised  FTP  Reply  Codes.   ARPANET  Request  for
+   Comments,  No.  640,  Network  Information  Center  No. 30843;
+   Augmentation Research  Center,  Stanford  Research  Institute:
+   Menlo Park, June 1974.
+
\ No newline at end of file