rfc724.txt

RFC 相关的技术文档

     chance to properly develop and mature.   We  are  very  concerned
     that this phenomenon not afflict the Network mail system any more
     than it already has.

          While it is true that there are several sites  in  the  ARPA
     Community  which  have  mail  systems  that understand the syntax
     specified in RFC's 561 and 680, in addition to some of the  "non-
     standard"  syntax  provided  by  the  mail generating programs at
     several other sites, most mail systems do not parse much  of  the
     contents  of  received  messages.   A consideration of the syntax
     specified here is that messages which are sent to  people  should
     be  easily  read  by  people.   Parsers  which  can turn an ugly,
     syntactically expedient form into something which is easy to read
     are  the  exception,  rather  than  the  rule, in today's message
     systems.  Also, the modifications to the existing  "non-standard"
     syntax  should  be  kept  to a minimum, enhancing the probability
     that the requirement of small perturbations to existing  software
     will be accepted.

          With this syntax, we introduce mechanisms so that:

          1. Users of mail systems can have multiple mailboxes, either
             on  one  machine  or  multiple machines, all of which are
             treated identically; the default mailbox for  a  user  is
             not  necessarily  associated  (directly)  with  his login
             name.

          2. Mail for a person can be sent to  other  than  a  single,
             default mailbox.

          3. Named   groups  may  consist  of  both  individuals   and
             (possibly)  other  named  groups  (i.e.,  nesting  within
             groups is permitted).

          4. Address lists may contain references  to  other,  stored,
             lists.  The complete path with which one can retrieve the
             stored list may be specified in  order  to  allow  either
             manual or automatic retrieval of the stored list.

          5. Address lists may contain references to  addresses  which
             are  not  accessible through the standard ARPANET message
             system.  For example, U.S.  Postal system  addresses  can
             be specified.  Such addresses are, of course, expected to
             be ignored by the  ARPANET  system,  although  individual
             sites  may  provide  services  for  using the information
             (e.g., automatically sending a copy of the  message to  a
             line printer, in preparation for transmission through the
             Postal system).

          6. Parenthetical remarks, or comments, can be  included  and
             syntactically  recognized  as  such  within  some  header
             items.


     I. Problems with ARPANET Message Standards                    / 5
     B. Issues and Conclusions



          7. Received messages are capable of  being  read  by  humans
             without  a  program having to parse the message (or parts
             of it) before presenting the message to the user; however
             there  is  sufficient  formal  syntax to enable a parsing
             program to modify the appearance and content of  material
             presented  to  users.   Although message-display software
             may   exercise   considerable   control   over    message
             appearance, the degree to which a message's actual format
             is  PLEASANT  for  humans  to  read   is   entirely   the
             responsibility of the message creation program.

     No mechanism for authentication is provided,  since  the  Network
     provides  no  mechanisms for enforcing mail security.  The syntax
     does provide for one aspect of "correctness":  a  distinction  is
     made  between  an  address which is claimed to be a valid network
     address and one which is  simply  free  text,  included  for  the
     convenience of the human participants.




     C. MESSAGE PARTS

          Some  confusion  has  existed  over  the  roles  played   by
     different message parts.  Einar Stefferud has suggested using the
     perspective of envelope, letter head, and  letter  content.   The
     presence of structured portions in messages additionally requires
     reference to "headers".

          In  computer-based  message  systems,  human  users  do  not
     generally  encounter  "envelopes",  which  are  often constructed
     automatically, to be  used  by  the  participating  system(s)  to
     deliver  the  message.  For example on TENEX, the envelope is the
     name of the file containing a message awaiting transmission.  For
     FTP  servers,  it is the data portion of the MAIL or MLFL command
     line.  Some systems attach  "envelope-like"  information  to  the
     message header, such as time-stamp and originating host name.

          In paper-based communications,  headers  occur  both  before
     (e.g., "To:" and "From:" and after (e.g., "cc:" and "enclosure:")
     the body of the message.  Within this standard, all headers occur
     before  the  body  of the message, although local message display
     programs may choose to alter that ordering.

          Wayne Hathaway has pointed out that ARPANET  message  format
     does not support specification of letterheads, since these are  a
     type   of   organizational   public   relations   symbol.    Some
     idiosyncrasies are supported, however, by way of choosing special
     field names.

          In general, it is  important  to  realize  that  the  header
     portion  of  a  message  plays several roles during the life of a


     I. Problems with ARPANET Message Standards                    / 6
     C. Message Parts



     message, variously participating in each of the  three  functions
     suggested by Stefferud.



     D. ADOPTION OF THE STANDARD


         During the early phases of specifying this standard, a  great
     deal  of  concern  was  expressed  over the problems which may be
     experienced during the transition from the  current  standard  to
     this  new  one.   We  feel  that  the true problem is the lack of
     realization that THERE IS NO CURRENT OFFICIAL  STANDARD.   Enough
     systems  have  enough  overlapping behaviors to allow the current
     mail environment to function, but this in no  way  constitutes  a
     standard.

          In fact, we  strongly  believe  that  the  new  requirements
     imposed by the proposed standard involve less complexity than the
     ambiguities resulting  from  the  current  variations  in  system
     behaviors.



     II. Standard for the Format of Messages                       / 7







                     II. STANDARD FOR THE FORMAT
                         OF ARPA NETWORK MESSAGES



          This standard supercedes 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 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.  Certain equivalences are defined,
     such as between a space  character  <space>  and  an  end-of-line
     character  <crlf>, which both facilitate the formal specification
     and indicate  what  the  OFFICIAL  semantics  are  for  messages.
     Particular   implementations   may   wish   to  preserve  further
     distinctions which the specification does not require.



     A. 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, of this standard.

          Messages are expected to  consist  of  lines  of  text.   No
     special provisions are made, at this time, for encoding drawings,
     facimile, 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


     II. Standard for the Format of Messages                       / 8
      A. Framework



     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.  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.  Our approach is similar
     to that of the TELNET protocol, in that we are defining  a  basic
     standard which includes a mechanism  for  (optionally)  extending
     itself.    The   authors  of  this  document  will  regulate  the
     publishing of specifications for these extensions.

          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.  Relative to
     paper-based communication, it is interesting  to  note  that  the
     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
     capabilties of their individual message systems.



     II. Standard for the Format of Messages                       / 9
      B. Syntax





     B.  SYNTAX


          This  syntax  is  given  in  four  parts.   The  first  part
     describes  a  base-level lexical analyzer which feeds the higher-
     level parser described in the succeeding  sections.   The  second
     part  gives  a  general  syntax  for messages and standard header
     fields.  The third part specifies the  syntax  of  addresses.   A
     final  section  specifies  some general syntax which supports the
     other sections.



     1.  LEXICAL ANALYSIS OF MESSAGES


     a.  General Description

         A message consists of headers and, optionally, a  body  (i.e.
         the  <message-text>).   The  <message-text>  part  is  just a
         sequence of  ASCII  characters;  it  is  separated  from  the
         headers  by  a null line (i.e., a line with nothing preceding
         the <crlf>).

         1) Folding and unfolding of headers

            Each header item can be viewed as a single, logical,  long
            line   of   ASCII   characters.    For  convenience,  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> characters, you
            can  instead  insert  a  <crlf> immediately followed by AT
            LEAST  one  <linear-white-space>  character.   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



     II. Standard for the Format of Messages                      / 10
      B. Syntax
      1. Lexical Analysis



            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
            <linear-white-space-char> as equivalent  to  the  <linear-
            white-space-char>.


         2) 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 decimal values between 33  and  126)
            and <linear-white-space> characters.  The <field-body> may
            composed of any ASCII  characters  (other  than  <cr>  and
            <lf>, which have been removed by unfolding).

            Certain header fields may be interpreted according  to  an
            internal  syntax  which  some  systems  may wish to parse.