Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc680.txt.pdf Дата изменения: Thu Dec 21 01:33:07 2006 Дата индексирования: Tue Oct 2 16:32:25 2012 Кодировка:

Network Working Group Request for Comment: 680 NIC: 32116

T. Myer D. Henderson 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, machinereadable 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 . 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

::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= := ::= ::= ::= ::= ::= ::= ::= ::=



::= ::=

::= ::= ::= ::= ::=

DATE:AT - ! // one or two decimal digits JAN ! FEB ! MAR ! APR ! MAY ! JUN ! JUL ! AUG ! SEP ! OCT ! NOV ! DEC one or two decimal digits four decimal digits two decimal digits EST ! EDT ! CST ! CDT ! MST ! MDT ! PST ! PDT ! GMT ! GDT four decimal digits SENDER: AT ! ! SUBJECT: ! ! ! : TO:! CC:! BCC:! Message-ID:[}] : FROM ! IN-REPLY-TO! REFERENCES! KEYWORD ! PRECEDENCE ! MESSAGE-CLASS! SPECIAL-HANDLING! AUTHENTICATION! ACCESSION-KEY ! ! !@ (ATTN:)

[Page 2]


RFC 680



::= ::= ::= ::= ::= ::= ::= ::= ::=



::=

Notes:

::= ::=

! :() ! () ! , ! a standard host name ! a string containing any of the 128 ASCII characters except CR and LF a string containing any of the 128 ASCII characters except CR, LF, and SP CR LF space

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', , , and -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 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 netaddress 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 message. secondary for access contains the identity of the tertiary receivers of the This field should not be made available to the primary and receivers, but it may be recorded to provide information 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 (<>). means that the message should be delivered as soons as possible. 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 (<>). 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]