rfc733.txt

RFC 相关的技术文档

    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,