rfc724.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,576 行 · 第 1/5 页
TXT
1,576 行
<extension-field> ::= "In-Reply-To" ":" <reference-list>
| "Keywords" ":" <phrase-list>
| "Message-Id" ":" <mach-host-phrase>
| "References" ":" <reference-list>
| "Subject" ":" <text-line>
| "Comments" ":" <text-line>
| <user-defined-field>
II. Standard for the Format of Messages / 16
B. Syntax
2. Messages
<user-defined-field> ::= <A <field> which has a <field-name>
not defined in this specification>
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.1)
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?