rfc733.txt

RFC 相关的技术文档

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