rfc724.txt

RFC 相关的技术文档

     indicated  how  such long strings can be represented on more than
     one line in the actual transmitted message.


     3.  SYNTAX OF GENERAL ADDRESSEE ITEMS

         <mach-addr-list>  ::=   <mach-addr-item>
                               | <mach-addr-item> "," <address-list>

         <address-list>    ::=   <null>
                               | <address-item>
                               | <address-item> "," <address-list>
         <address-item>    ::=   <mach-addr-item>
                               | <group-name> ":" <address-list> ";"
                               | <any-name>
                               | <path>

         <mach-addr-item>  ::=   <mailbox>
                               | <phrase> "<" <mailbox-list> ">"

         <group-name>      ::=   <phrase>
         <any-name>        ::=   <quoted-string>

         <mailbox-list>    ::=   <mailbox>
                               | <mailbox> "," <mailbox-list>
         <mailbox>         ::=   <host-phrase>

         <path>            ::=   ":" "File" ":" <path-name>
         <path-name>       ::=   <path-item>
                               | "<" <path-list> ">"
         <path-list>       ::=   <path-item>
                               | <path-item> "," <path-list>
         <path-item>       ::=   <host-phrase>




     II. Standard for the Format of Messages                      / 17
      B. Syntax
      4. Supporting Constructs



     4.  SUPPORTING SYNTAX

         <reference-list>  ::=   <null>
                               | <reference-item>
                               | <reference-item> "," <reference-list>
         <reference-item>  ::=   <phrase>
                               | <mach-host-phrase>

         <mach-host-phrase>::=   "<" <host-phrase> ">"
         <host-phrase>     ::=   <phrase> <host-indicator>
         <host-indicator>  ::=   <at-indicator> <host-name>
         <at-indicator>    ::=   "at" | "@"
         <host-name>       ::=   <atom>
                               | <decimal host address>

         <date-time>       ::=   <day> <date> <time>
         <day>             ::=   <null>
                               | <day-of-week> ","
         <day-of-week>     ::=   "Monday"    | "Mon"
                               | "Tuesday"   | "Tue"
                               | "Wednesday" | "Wed"
                               | "Thursday"  | "Thu"
                               | "Friday"    | "Fri"
                               | "Saturday"  | "Sat"
                               | "Sunday"    | "Sun"
         <date>            ::=   <string-date>
                               | <slash-date>
         <string-date>     ::=   <day-of-month> <string-month>
                                                <4-digit-year>
         <slash-date>      ::=   <numeric-month> "/" <date-of-month>
                                                 "/" <2-digit-year>
         <numeric-month>   ::=   <one or two decimal digits>
         <day-of-month>    ::=   <one or two decimal digits>
         <string-month>    ::=   "January" | "Jan"
                               | "February" | "Feb"
                               | "March"    | "Mar"
                               | "April"    | "Apr"
                               | "May"
                               | "June"     | "Jun"
                               | "July"     | "Jul"
                               | "August"   | "Aug"
                               | "September"| "Sep"
                               | "October"  | "Oct"
                               | "November" | "Nov"
                               | "December" | "Dec"
         <4-digit-year>    ::=   <four decimal digits>
         <2-digit-year>    ::=   <two decimal digits>
         <time>            ::=   <24-hour-time> "-" <time-zone>
         <24-hour-time>    ::=   <hour> <minute>
         <hour>            ::=   <two decimal digits>
         <minute>          ::=   <two decimal digits>


     II. Standard for the Format of Messages                      / 18
      B. Syntax
      4. Supporting Constructs



         <time-zone>       ::=   "GMT" | "Z"   | "GDT"
                               | "AST" | "ADT"
                               | "EST" | "EDT" | "CST" | "CDT"
                               | "MST" | "MDT" | "PST" | "PDT"
                               | "YST" | "YDT" | "HST" | "HDT"

         <phrase>          ::=   <word>
                               | <word> <phrase>
         <phrase-list>     ::=   <null>
                               | <phrase>
                               | <phrase> "," <phrase-list>

         <word>            ::=   <atom>
                               | <quoted-string>



     II. Standard for the Format of Messages                      / 19
      C. Semantics
      1. Address Fields





     C. SEMANTICS


     1. ADDRESS FIELDS

     a. General

        1) <path>s are used to refer to a location,  on  the  ARPANET,
           containing  a  stored  address  list.   The <phrase> 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:

           - the   file  must  be  accessible  through  the   local
             operating  system  interface  (if  it  exists),  given
             adequate user access rights; and

           - 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 will allow  programs  to
           retrieve such lists automatically.

           The interpretation  of  a  <path>  follows.   This  is  not
           intended to imply any particular implementation scheme, but
           is included to aid in understanding the notion of <path>s:

           - The contents of the file indicated by a <path-name> is
             treated  as  an  <address-list>  and is inserted as an
             <address-item> in the position of the <path-name> item
             in  the  syntax.   That is, the TELNET ASCII character
             string of the <path-name> or, if present,  the  <path-
             list>  containing  it,  is replaced by the contents of
             the file to which the <path-name>  refers.  Therefore,
             the  contents  of  the file indicated by a <path-name>
             must be syntactically self-contained and  must  adhere
             to  the  full  syntax  prescribed herein for <address-
             list>.

           - <Path-item>s of a <path-list> are alternates  and  the
             contents  of ONLY ONE of them is to be included in the
             resultant address list.

        2) The <phrase> part  of  a  <mailbox>  is  understood  to  be
           whatever  the  receiving  FTP  Server  allows (for example,


     II. Standard for the Format of Messages                      / 20
      C. Semantics
      1. Address Fields



           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.

           A user may have several mailboxes. The use  of  the  second
           alternative  of  <mach-addr-item>  (<phrase>  "<" <mailbox-
           list> ">") indicates that a copy of the message  is  to  be
           sent to EACH mailbox named.

        3) <any-name>  may  contain  any  sequence  of  "words".  This
           sequence  of  words,  used as an <address-item>, is used to
           facilitate reference  to  non-standard  (e.g.  non-Network)
           addresses.    Such   an  address  might  be  one  which  is
           acceptable to the U.S.  Postal Service.

        4) The <host-name> in a <host-phrase>  must  be  THE  official
           name of a Network host, or else a decimal number indicating
           the Network address for that host.  The USE OF  NUMBERS  IS
           STRONGLY  DISCOURAGED  and  is  permitted  only  due to the
           occasional necessity of bypassing local host-name tables.

           The  <phrase>  in  a  <host-phrase>  is  intended   to   be
           meaningful only to the indicated host.  To all other hosts,
           the <phrase> is treated  as  a  literal  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.

     b. 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; the permitted
                    alternatives have been  carefully  chosen
                    and are adequate for the purposes of this
                    standard.



     II. Standard for the Format of Messages                      / 21
      C. Semantics
      1. Address Fields



        1) 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 user entering the message; if and
           only if this is done,  the  "Sender:"  field  need  not  be
           present.

        2) Sender:

           This field contains the identity of the  person  who  sends
           the  message.   It need not be present in the header of the
           message if it is the SAME as the "From:" field.

           The <sender-field-body>  includes  a  <phrase>  which  must
           correspond  to  a  user,  rather  than a standard <address-
           item>, to indicate the  expectation  that  the  field  will
           refer  to  the  PERSON responsible for sending the 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>  (user)  is  a  system  entity,  not a generalized
           person reference.

        3) Reply-to:

           This field provides a general mechanism for indicating  any
           mailbox(es)  to  which  responses  are  to  be sent.  Three
           different uses for this feature can be  distinguished.   In
           the  first  case,  the  author(s)  may  not  have   regular
           machine-based  mailboxes  and therefore wish 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).  More interesting
           is a case such as text-message teleconferencing in which an
           automatic distribution facility  is  provided  and  a  user
           submitting  an  "entry" for distribution only needs to send
           their message to the mailbox(es) indicated in  the  "Reply-
           to:" field.

           If there is no <reply-to-field>, then the <from-field> MUST
           contain  AT  LEAST  ONE machine address.  In all cases when
           used and even if a <sender> field is present, the  Reply-to
           field must contain at least one machine address.

        NOTE: For systems which automatically generate  address  lists
        for replies to messages, the following requirements are made:



     II. Standard for the Format of Messages                      / 22
      C. Semantics
      1. Address Fields



           - The receiver, when replying to a message,  must  NEVER
             automatically  include  the <sender-field-body> in the
             reply's address list

           - If the <reply-to-field> exists, then the reply  should
             go ONLY to the <reply-to-field-body> addressees.

        (Extensive  examples  are  provided  in  Section  II.D.)  This
        recommendation is intended only for <originator-field>s and in
        no way is intended to reflect that replies should not be sent,
        also,  to  the  other recipients of this message.  It is up to
        the respective mail handling programs as  to  what  additional
        facilities will be provided.

     c. Receiver Fields

        1) To:

           This field contains the identity of the primary  recipients
           of the message.

        2) cc:

           This  field  contains  the  identity   of   the   secondary
           recipients of the message.

        3) Bcc:

           This field contains the identity of  additional  recipients