diff options
Diffstat (limited to 'doc/rfc/rfc680.txt')
| -rw-r--r-- | doc/rfc/rfc680.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc680.txt b/doc/rfc/rfc680.txt new file mode 100644 index 0000000..820ec17 --- /dev/null +++ b/doc/rfc/rfc680.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group T. Myer +Request for Comment: 680 D. Henderson +NIC: 32116 BBN-TENEX + April 30, 1975 + + Message Transmission Protocol + + Theodore H. Myer + + D. Austin Henderson + + BBN-TENEX + + This document defines a number of message fields beyond those + discussed in RFC 561. The overall message format is compatible with + RFC 561; it makes extensive use of the miscellaneous fileds defined + within RFC 561. The purpose of this document is to establish ARPANET + standards with regard to the syntax and semantics for these + additional fields. It is fully expected that all fields discussed + herein will not be automatically processed by all Message Servers; + however, the standard is necessary so that sites which wish to make + use of these fields have a standard to work with. + + This document attempts to tread the narrow line between features for + human processing and features for machine processing. The general + feeling is that the fields listed are useful to people even if + automatic processing is not supplied. In most cases, machine- + readable notations have been enclosed in angle brackets (<>) to allow + easy non-ambiguous ways for automatic processes to know whether and + where to look in any field. The entire specifications has been made + excessively general to allow for experimentation. Future documents + based on experience will try to be more specific. This is simply the + next step following <RFC 561>. + + This document is contained in two sections. Section I contains the + relevant parts of RFC 561 which define the basic message syntax. + Section II lists the new (and existing) header fields together with + their proposed uses. + + + + + + + + + + + + + + [Page 1] + +RFC 680 + + +SECTION I: BASIC MESSAGE SYNTAX + + + <message> ::= <header><crlf><body> + <header> ::= <required header><optional header> + <required header> ::= <date item><sender item> + <date item> ::= DATE:<sp><date><sp>AT<sp> + <time>-<zone><crlf> + <date> ::= <vdate> ! <tdate> + <vdate> ::= <dayofmonth><SP><vmonth><SP><vyear> + <tdate> ::= <tmonth>/<dayofmonth>/<tyear> + <dayofmonth> ::= one or two decimal digits + <vmonth> ::= JAN ! FEB ! MAR ! APR ! MAY ! JUN ! + JUL ! AUG ! SEP ! OCT ! NOV ! DEC + <tmonth> ::= one or two decimal digits + <vyear> ::= four decimal digits + <tyear> ::= two decimal digits + <zone> ::= EST ! EDT ! CST ! CDT ! MST ! MDT ! + PST ! PDT ! GMT ! GDT + <time> ::= four decimal digits + <sender item := SENDER: <sp><user><sp>AT<sp><host> + <crlf> + <optional header> ::= <subjects><optional items> + <subjects> ::= !<subject item> ! + <subject item><subjects> + <subject item> ::= SUBJECT:<sp><line><crlf> + <optional items> ::= <optional item> ! <optional item> + <optional items> + <optional item> ::= <messid> ! <addressee item> ! + <other item> + <addressee item> ::= <addressee keyword>:<sp><addressee + list><crlf> + <addressee keywork> ::= TO:! CC:! BCC:! + <messid> ::= Message-ID:<sp>[<Net + Address>}]<line> + <crlf> + <other item> ::= <other keyword>:<sp><line><crlf> + <other keyword> ::= FROM ! IN-REPLY-TO! REFERENCES! + KEYWORD ! PRECEDENCE ! + MESSAGE-CLASS! + SPECIAL-HANDLING! AUTHENTICATION! + ACCESSION-KEY + <address list> ::= <addressee> ! <addressee><addressee + list> + <addressee> ::= <mailbox> ! <mailbox group> + <mailbox> ::= <user><host spec><attention spec> + <host spec> ::= !@<host> + <attention spec> ::= (ATTN:<sp><user list>) + + + + [Page 2] + +RFC 680 + + + <user list> ::= <user> ! <user><user list> + <mailbox group> ::= <group name>:(<group numbers>) + <group numbers> ::= ! (<mailbox list>) + <mailbox list> ::= <mailbox> ! <mailbox>,<mailboxlist> + <body> ::= <line><CRLF> ! <line><CRLF><body> + <user> ::= <word> + <host> ::= a standard host name + <group name> ::= ! <word> + <line> ::= a string containing any of the 128 + ASCII + characters except CR and LF + <word> ::= a string containing any of the 128 + ASCII + characters except CR, LF, and SP + <CRLF> ::= CR LF + <SP> ::= space + + Notes: + + 1. A message may have at most one MESSAGE-ID item. + + 2. All items with the same keyword must be grasped together. + + Please note the following: + + (1) The case (upper or lower) of keywords -- specifically, 'FROM', + 'DATE', 'SUBJECT', 'AT', <host>, <zone>, <vmonth> and <keyword> -- + is insignificant. Although 'FROM', for example, appears in + upper-case in the formal syntax above, in the header of an actual + message it may appear as 'FROM', 'from', or 'From', etc. + + (2) No attempt has been made to legislate the format of <user> + except to exclude spaces from it. + + (3) The time has no internal punctuation. + + + + + + + + + + + + + + + + + [Page 3] + +RFC 680 + + +SECTION II: MESSAGE HEADER FIELDS + + +A. ORIGINATOR SPECIFICATION FIELDS + + FROM + + This field contains the identity of the person who wished this + message to be sent. This is expected to be the originator field + which is specified by the user in the case that the message is being + entered by one person for another. The message-creation process + should default this field to be the user entering the message. [The + usage for FROM and SENDER differs from that of RFC 561.] + + SENDER + + This field contains the identity of the person who sends the message. + This field is expected to be set by the message-creation process + automatically. It is possible that some sites will not include this + field in external communications. + + + AUTHENTICATION + + This field contains a description of which originator fields have + been authenticated, and by which operating systems. This field + should be created by message transmission and/or reception processes + (FTP/Operating System level). + + It is expected that current system will be able to authenticate only + the SENDER field; however, later systems might have mechanisms to + verify that the FROM actually authorized the SENDER to act on his/her + behalf. It is expected that, when the FROM is authenticated, the + SENDER will no longer be necessary for external distribution. + +B. REFERENCE SPECIFICATION FIELDS + + MESSAGE-ID + + This field contains a unique identifier to refer to this message. + The format for a message identifier is: + + + [Net Address]Text String CRLF + Examples: + [ISIB]7-DEC-74.14:23:45 + [ARC]QLOURNAL 39274a3 + + + + + [Page 4] + +RFC 680 + + + The uniqueness of the message identifier is guaranteed by each net- + address message processor making the text which follows unique for + that net-address. This, specifically says net-address and not site + name. This would allow BBN (for instance) to allocate unique + identifiers over all four machines, which may be addressed as BBN + within the message system, thus producing a more integrated service + for their users. + + The text following the net-address is not defined here, as the + problems associated with this specification are too great at this + time. However, the net-address should allow automatic processes to + determine if they can deal intelligently with the following text. + Several types of automatic processing by the local message reader are + thus possible: 1) if the site uses a filing mechanism known to the + reader, the reader can retrieve the message 2) if the site supports + remote message access (protocol not currently defined), the message + id can be passed to the remote site and the message has been filed in + the Datacomputer (using the entire message id [including net-address] + as the handle), the reader can retrieve it from the Datacomputer. + + IN-REPLY-TO + + The contents of this field identify previous correspondence which + this message answers. If message identifiers are used in this field, + they should be enclosed in angle brackets (<>). + + REFERENCES + + The contents of this field identify other correspondence which this + message references. If message identifiers are used, they should be + enclosed in angle brackets (<>). + + KEYWORDS + + This field contains keywords or phrases from the message, separated + by commas. + + + + + + + + + + + + + + + + [Page 5] + +RFC 680 + + +C. RECEIVER SPECIFICATION FIELDS + + TO + + This field contains the identity of the primary receivers of the + message. + + CC + + This field contains the identity of the secondary receivers of the + message. + + BCC + + This field contains the identity of the tertiary receivers of the + message. This field should not be made available to the primary and + secondary receivers, but it may be recorded to provide information + for access control. + +D. MESSAGE-TYPE SPECIFICATION FIELDS + + PRECEDENCE + + This field describes the importance and urgency of the message. + Machine-readable notations will be enclosed in angle brackets (<>). + <PRIORITY> means that the message should be delivered as soons as + possible. <ROUTINE> means that Priority processing is not necessary. + Plain text may also be included in this field. + + MESSAGE-CLASS + + This field describes the "legal" status of the message. Examples: + Official, Unofficial, Record, Off the Record, Junk Mail. No + automatic processing of this field is immediately expected. Certain + message creation processes might, for example, always insert: + + MESSAGE CLASS: Unofficial ARPANET Message + + SPECIAL-HANDLING + + This field contains any special instructions with regard to the + handling of the message at the receiver's end. Machine-readable + notations will be enclosed in angle brackets (<>). <PRIVATE> means + that the message reception process should not aid the user in + circulating copies to others. Plain text may also be included in + this field. + + + + + + [Page 6] + |