    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.