March 1979 IEN: 85 RFC: 753 INTERNET MESSAGE PROTOCOL Jonathan B. Postel March 1979 Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 (213) 822-1511 < INC-PROJECT, MAIL-MAR-79.NLS.38, >, 31-Mar-79 19:50 JBP ;;;; [Page 0] Postel March 1979 Internet Message Protocol TABLE OF CONTENTS PREFACE ........................................................ iii 1. INTRODUCTION ..................................................... 1 1.1. Motivation ................................................... 1 1.2. Scope ........................................................ 1 1.3. The Internetwork Environment ................................. 2 1.4. Operation .................................................... 2 1.5. Interfaces ................................................... 3 2. FUNCTIONAL DESCRIPTION ........................................... 5 2.1. Relation to Other Protocols .................................. 5 2.2. Terminology ................................................. 5 2.3. Assumptions .................................................. 6 2.4. General Specification ........................................ 7 2.5. Mechanisms .................................................. 11 3. DETAILED SPECIFICATION .......................................... 13 3.1. Overview of Message Structure ............................... 13 3.2. Data Elements ............................................... 13 3.3. Message Objects ............................................. 16 3.4. Command ..................................................... 23 3.5. Document .................................................... 31 3.6. Message Structure ........................................... 33 3.7. MPM Organization ............................................ 36 3.8. Interfaces .................................................. 39 4. EXAMPLES & SCENARIOS ............................................ 41 Example 1: Message Format ........................................ 41 Example 2: Delivery and Acknowledgment ........................... 43 GLOSSARY ............................................................ 49 REFERENCES .......................................................... 51 APPENDICES .......................................................... 53 Postel [Page i] March 1979 Internet Message Protocol [Page ii] Postel March 1979 Internet Message Protocol PREFACE This is the first edition of this specification and should be treated as a request for comments, advice, and suggestions. A great deal of prior work has been done on computer aided message systems and some of this is listed in the reference section. This specification was shaped by many discusions with members of the ARPA research community, and others interested in the development of computer aided message systems. This document was prepared as part of the ARPA sponsored Internetwork Concepts Research Project at ISI, with the assistance of Greg Finn, Alan Katz, Paul Mockapetris, and Mamie Chew. Jon Postel Postel [Page iii] March 1979 Internet Message Protocol [Page iv] Postel March 1979 IEN: 85 J. Postel RFC: 753 USC-ISI March 1979 INTERNET MESSAGE PROTOCOL 1. INTRODUCTION This document describes an internetwork message system. The system is designed to transmit messages between message processing modules according to formats and procedures specified in this document. The message processing modules are processes in host computers. Message processing modules are located in different networks and together constitute an internetwork message delivery system. This document is intended to provide all the information necessary to implement a compatible cooperating module of this internetwork message system. 1.1. Motivation As computer supported message processing activities grow on individual host computers and in networks of computers, there is a natural desire to provide for the interconnection and interworking of such systems. This specification describes the formats and procedures of a general purpose internetwork message system, which can be used as a standard for the interconnection of individual message systems, or as a message system in its own right. We also provide for the communication of data items beyond the scope of contemporary message systems. Messages can include typed segments which could represent drawings, or facsimile images, or digitized speech. One can imagine message stations equipped with speakers and microphones (or telephone hand sets) where the body of a message or a portion of it is recorded digitized speech. The output terminal could include a graphics display, and the message might present a drawing on the display, and verbally (via the speaker) describe certain features of the drawing. This specification provides basic data elements for the transmission of structured binary data, as well as providing for text transmission. 1.2. Scope The Internet Message Protocol is intended to be used for the transmission of messages between networks. It may also be used for the local message system of a network or host. This specification was developed in the context of the ARPA work on the interconnection of networks, but it is anticipated that it has a more general scope. Postel [Page 1] March 1979 Internet Message Protocol Introduction The focus here is on the internal mechanisms to transmit messages, rather than the external interface to users. It is assumed that a number of user interface programs will exist. These will be both new programs designed to work with system and old programs designed to work with earlier systems. 1.3. The Internetwork Environment The internetwork message environment consists of processes which run in hosts which are connected to networks which are interconnected by gateways. Each individual network consists of many different hosts. The networks are tied together through gateways. The gateways are essentially hosts on two (or more) networks and are not assumed to have much storage capacity or to "know" which hosts are on the networks to which they are attached [5]. 1.4. Operation The model of operation is that this protocol is implemented in a process. Such a process is called a Message Processing Module or MPM. The MPMs exchange messages by establishing full duplex communication and sending the messages in a fixed format described in this document. The MPM may also communicate other information by means of commands described here. A message is formed by a user interacting with a User Interface Program or UIP. The user may utilize several commands to create various fields of the message and may invoke an editor program to correct or format some or all of the message. Once the user is satisfied with the messages it is "sent" by placing it in a data structure shared with the MPM. The MPM discovers the unprocessed input data (either by a specific request or by a general background search), examines it, and using routing tables determines which outgoing link to use. The destination may be another user on this host, a user on another host in this network, or a user in another network. In the first case, another user on this host, the MPM places the message in a data structure shared with the destination user, where that user's UIP will look for incoming messages. In the second case, the user on another host in this network, the MPM transmits the message to the MPM on that host. That MPM then repeats the routing decision, and discovering the destination is local to it, places the messages in the data structure shared with the destination user. [Page 2] Postel March 1979 Internet Message Protocol Introduction In the third case, the user on a host in another network, the MPM transmits the messages to an MPM in that network if it knows how to establish a connection directly to it, otherwise the MPM transmits the message to an MPM that is "closer" to the destination. An MPM might not know of direct connections to MPMs in all other networks, but it must be able to select a next MPM to handle the message for each possible destination network. A MPM might know a way to establish direct connections to each of a few MPMs in other nearby networks, and send all other messages to a particular big brother MPM that has a wider knowledge of the internet environment. A individual network's message system may be quite different from the internet message system. In this case, intranet messages will be delivered using the network's own message system. If a message is addressed outside the network, it is given to a MPM which then sends it through the appropriate gateways via internet procedures and format to (or toward) the MPM in the destination network. Eventually, the message gets to a MPM on the network of the recipient of the message. The message is then sent via the local message system to that host. When local message protocols are used, special conversion programs are required to transform local messages to internet format when they are going out, and to transform internet messages to local format when they come into the local environment. Such transformations are potentially information lossy. The internet message format attempts to provide features to capture all the information any local message system might use. However, a particular local message system is unlikely to have features equivalent to all the possible features of the internet message system. Thus, in some cases the transformation of an internet message to a local message discard of some of the information. For example, if an internet message carrying mixed text and speech data in the body is to be delivered in a local system which only carries text, the speech data may be replaced by the text string "There was some speech here". Such discarding of information is to be avoided when at all possible, and to be defered as long as possible, still the possibility remains, that in some cases, it is the only reasonable thing to do. 1.5. Interfaces The MPM calls on a reliable communication procedure to communicate with other MPMs. This is a Transport Level protocol such as the TCP [20]. The interface to such a procedure conventionally provides calls to open and close connections, send and receive data on a connection, and some means to signal and be notified of special conditions (i.e., interrupts). Postel [Page 3] March 1979 Internet Message Protocol Introduction The MPM receives input and produces output through data structures that are produced and consumed respectively by user interface (or other) programs. [Page 4] Postel March 1979 Internet Message Protocol 2. FUNCTIONAL DESCRIPTION 2.1. Terminology The basic unit transferred between networks is called a message. A message is made up of a transaction identifier (a number which uniquely identifies the message), a command list (which contains the necessary information for delivery), and the document list. The document list consists of a header and a body, which contains the actual data of the message. For a personal letter the document body corresponds to the contents the a letter, the document header corresponds to the the address and return address on the envelope. For an inter-office memo the document body corresponds to the text, the document header corresponds to the header of the memo. The commands correspond to the information used by the Post Office or the mail room to route the letter or memo. The messages are routed by a process called the message processing module or MPM. Messages are created and consumed by User Interface Programs (UIPs) in conjunction with users. Please see the Glossary section for a more complete list of terminology. 2.2. Assumptions The following assumptions are made about the internetwork environment: It is in general not known what format intranet addresses will assume. Since no standard addressing scheme would suit all networks, it is safe to assume there will be several and that they will change with time. Thus, frequent software modification throughout all internet MPMs would be required if such MPMs were to know about the formats on many networks. Therefore, each MPM which handles internet messages is required to know only the minimum necessary to deliver them. We require each MPM to know completely only the addressing format of its own network. In addition, the MPM must be able to select an output link for each message addressed to another network or host. This does not preclude more intelligent behavior on the part of a given MPM, but at least this minimum is necessary. Each network has a unique name and number. Each MPM will have a unique internet address. This feature will Postel [Page 5] March 1979 Internet Message Protocol Functional Description enable every MPM to place a unique "handling-stamp" on a message which passes through it en-route to delivery. 2.3. General Specification There are several aspects to a distributed service to be specified. First there is the service to be provided, that is, the characteristics of the service as seen by its users. Second there is the service it uses, that is, the characteristics it assumes to be provided by some lower level service. And, third there is the protocol used between the modules of the distributed service. User User \ / \ / \ / --+----------------------------------------+-- Service ! \ / ! Interface ! +--------+ +--------+ ! ! ! Module ! <--Protocol--> ! Module ! ! ! +--------+ +--------+ ! ! \ / ! ! +-----------------------+ ! ! ! Communication Service ! ! ! +-----------------------+ ! ! ! +----------------------------------------+ Message Service Figure 1. The User/Message Service Interface The service the message delivery system provides is to accept messages conforming to a specified format and to attempt to deliver those messages, and to report on the success or failure of the delivery attempt. This service is provided in the context of an interconnected system of networks, and may involve relaying a message through several intermediate MPMs utilizing different communication services. The Message/Communication Service Interface The message delivery system calls on a communication service to transfer information from one MPM to another. There may be different communication services used between different pairs of [Page 6] Postel March 1979 Internet Message Protocol Functional Description MPMs, though all communication services must meet the following service characteristics. It is assumed that the communication service provides a reliable two way data stream. Such a data stream can usually be obtained in computer networks from the transport level protocol, for example, the Transmission Control Protocol (TCP) [20]. In any case the properties the communication service must provide are: o Logical connections for two way simultaneous data flow of arbitrary data (i.e., no forbidden codes). Data is delivered in the order sent with no gaps. o Simple commands to open and close the connections, and to send and receive data on the connections. o A way to signal and be notified "out-of-band" (such as TCP's urgent) is available so that some messages can be labeled "more important" than others. o Controlled flow of data so that data is not transmitted faster that the receiver chooses to consume it (on the average). o Transmission errors are corrected without user notification or involvement. Complete breakdown on communication is reported to the user. The Message-Message Protocol The protocol used between the distributed modules of the message delivery system, that is, the MPMs is a small set of commands which convey requests and replies. These commands are encoded in a highly structured and rigidly specified format. 2.4. Mechanisms MPMs are processes which use some communication service. A pair of MPMs which can communicate reside in a common interprocess communication environment. A MPM might exist in two (or more) interprocess communication environments, and such an MPM might act to relay messages between MPMs in the environments. Postel [Page 7] March 1979 Internet Message Protocol Functional Description User User \ / \ / \ / +---------------------------------------------------------+ ! \ / ! ! +-----+ +-----+ +-----+ ! ! ! MPM ! <--Protocol--> ! MPM ! <--Protocol--> ! MPM ! ! ! +-----+ +-----+ +-----+ ! ! ! / \ ! ! ! +-----------------------+ +-----------------------+ ! ! !Communication Service A! !Communication Service B! ! ! +-----------------------+ +-----------------------+ ! ! ! +---------------------------------------------------------+ Message Service with Internal Relaying Figure 2. The transfer of data between UIPs and MPMs is conceived of as the exchange of data structures which encode messages. The transfer of data between MPMs is also in terms of the transmission of structured data. [Page 8] Postel March 1979 Internet Message Protocol Functional Description +-----+ DATA +-----+ USER-->! UIP !-->STRUCTURES-->! MPM !-->other +-----+ +-----+ +-----+ MPMs ! ! ! +-----+ +--! ! ! +-----+ +--! ! ! ! +-----+ +-----+ DATA +-----+ other-->! MPM !-->STRUCTURES-->! UIP !-->USER MPMs +-----+ +-----+ +-----+ ! ! ! +-----+ +--! ! ! +-----+ +--! ! ! ! +-----+ Message Flow Figure 3. In the following, a message will be described as a structured data object represented in a particular kind of typed data elements. This is how a message is presented when transmitted between MPMs or exchanged between an MPM and a UIP. Internal to a MPM (or a UIP), a message may be represented in any convenient form. As the following figure shows, when a message is ready for transmission, it moves from the processing routines to be encoded in the typed data elements and then to a data compression routine, and is finally transmitted. On the receiving side, the message is first decompressed then decoded from the data element representation to the local representation for the processing routines. Postel [Page 9] March 1979 Internet Message Protocol Functional Description +------------------------------------------------+ ! ! ! processing DATA DATA ! ! routines ---> ENCODER ---> COMPRESSOR ---> ! ! ! +------------------------------------------------+ Send MPM +------------------------------------------------+ ! ! ! DATA DATA processing ! ! ---> DECOMPRESSOR ---> DECODER ---> routines ! ! ! +------------------------------------------------+ Receive MPM Detailed View Figure 4. [Page 10] Postel March 1979 Internet Message Protocol Functional Description 2.5. Relation to Other Protocols The following diagram illustrates the place of the message protocol in the protocol hierarchy: +------+ +-----+ +-------+ +-----+ +-----+ !Telnet! ! FTP ! !Message! !Voice! ... ! ! Application Level +------+ +-----+ +-------+ +-----+ +-----+ \ ! / ! ! +-----+ +-----+ +-----+ ! TCP ! ! RTP ! ... ! ! Host Level +-----+ +-----+ +-----+ ! ! ! +-------------------------------+ ! Internet Protocol ! Gateway Level +-------------------------------+ ! +---------------------------+ ! Local Network Protocol ! Network Level +---------------------------+ ! Protocol Relationships Figure 5. The message protocol interfaces on one side to user interface programs and on the other side to a reliable transport protocol such as TCP. Postel [Page 11] March 1979 Internet Message Protocol [Page 12] Postel March 1979 Internet Message Protocol 3. DETAILED SPECIFICATION The presentation of the information in this section is difficult since everything depends on everything, and since this is a linear media it has to come in some order. In this attempt, a very brief overview of the message structure is given, then a radical switch is made to defining the basic building blocks, and finally using the building blocks to reach the overall structure again. 3.1. Overview of Message Structure In general a message is composed of three parts: the identification, the command, and the document. Each part is in turn composed of message objects. The identification part is composed of a transaction number assigned by the originating MPM, and the internet host number of that MPM. The command part is composed of an operation type, an operation code, an argument list, an error list, the destination mailbox, and a stamp. The stamp is a list of the MPMs that have handled this message. The document part is composed of a header and a body. The message delivery system does not depend on the contents of the document part, but this specification does make some recommendations for the document header. The following sections define the representation of a message as a structured object composed of other objects. Objects in turn are represented using a set of basic data elements. 3.2. Data Elements The data elements defined here are similar to the data structure and encoding used in NSW [18]. Each of the diagrams which follow represent a sequence of octets. Field boundaries are denoted by the "!" character, octet boundaries by the "+" character. The diagrams are presented in left to right order. Each element begins with a one octet code. Postel [Page 13] March 1979 Internet Message Protocol Specification Code Type Representation ---- ---- -------------- +------+ 0 No Operation ! 1 ! +------+ +------+------+------+------+------ 1 Padding ! 0 ! octet count ! Data ... +------+------+------+------+------ +------+------+ 2 Boolean ! 2 ! 1/0 ! +------+------+ +------+------+------+ 3 Index ! 3 ! Data ! +------+------+------+ +------+------+------+------+------+ 4 Integer ! 4 ! Data ! +------+------+------+------+------+ +------+------+------+------+------ 5 Bit String ! 5 ! bit count ! Data ... +------+------+------+------+------ +------+------+------+------+------ 6 Text String ! 6 ! octet count ! Data ... +------+------+------+------+------ +------+------+------+------+------+------+----- 7 List ! 7 ! octet count ! item count ! Data +------+------+------+------+------+------+----- +------+------+------+------+------ 8 Proplist ! 8 ! octet count ! Data ... +------+------+------+------+------ [Page 14] Postel March 1979 Internet Message Protocol Specification Element code 0 (NOP) is an empty data element used for padding when it is necessary. It is ignored. Element code 1 (PAD) is used to transmit large amounts of data with a message for test or padding purposes. No action is taken with this data but the count of dummy octets must be correct to indicate the next element code. Element code 2 (BOOLEAN) is a boolean data element which has the value 1 for True and 0 for False. Element code 3 (INDEX) is a 16-bit unsigned integer datum. Element code 3 occupies only 3 octets. Element code 4 (INTEGER) is a signed 32-bit integer datum. This will always occupy five octets. Representation is two's complement. Element code 5 (BITSTR) is a bit string element for binary data. The bit string is padded on the right with zeros to fill out the last octet if the bit string does not end on an octet boundary. This data type must have the bit-count in the two octet count field instead of the number of octets. Element code 6 (TEXT) is used for the representation of text. Seven bit ASCII characters are used, right justified in the octet. The high order bit in the octet is zero. Element code 7 (LIST) can be used to create structures composed of other elements. The item-count contains the number of elements which follow. Any element may be used including List itself. The octet count specifies the number of octets in the whole list. A null or empty List, one with no elements, has an item-count of zero (0). Postel [Page 15] March 1979 Internet Message Protocol Specification Element code 8 (PROPLIST) is the Property-List element. It has the following form: +------+------+------+------+------+ ! 8 ! octet ! pair ! ! ! count ! count! +------+------+------+------+------+ +------+------+------+---------+---------+ ! name ! value ! name ! value ! repeated ! count! count ! ...! ...! +------+------+------+---------+---------+ The Property-List structure consists of a set of unordered name/value pairs. The pairs are a one octet name count and a two octet value count followed by the name and value strings. The counts specify the length in octets of the name and value strings. Each string has a length in octets which agrees with its respective count. The count of octets until the next pair in the property list is 1 + 2 + name count + value count octets. The entire Property-List is of course equal in length to the octet count of the element itself. Immediately following the octet count for the entire element is a one octet pair count field which contains the total number of name/value pairs in the Proplist. 3.3. Message Objects In the composition of messages we use a set of objects such as address, or date. These objects are encoded in the basic data elements. The message objects are built of data elements. While data elements are typed, message objects are not. This is because messages are structured to the extent that only one kind of message object may occur in any position of a message structure. The following is a list of some of the objects used in messages. The object descriptions are grouped by the section of the message in which they normally occur. [Page 16] Postel March 1979 Internet Message Protocol Specification Identification Internet Host Number (ihn) This identifies a host in the internetwork environment. When used as a part of tid, it identifies the originating host of a message. The ihn is a 32 bit number, the higher order 8 bits identify the network, and the lower order 24 bits identify the host on that network. INTEGER Transaction Identifier (tid) This is the transaction identifier associated with a particular command. It is a list of the transaction number and the internet host number of the originating host. LIST ( tn , ihn ) Transaction Number (tn) This is a number which is uniquely associated with this transaction by the originating host. It identifies the transaction. (A transaction is a message and acknowledgment, this is discussed in more detail in later sections.) A tn must be unique for the time which the message (a request or reply) containing it could be active in the network. INDEX Command Address This is very similar to Mailbox in that it also is the "address" of a user. However, Address is intended to contain the minimum information necessary for delivery, and no more. PROPLIST ( --- ) Answer A yes (true) or no (false) answer to a question. BOOLEAN Postel [Page 17] March 1979 Internet Message Protocol Specification Arguments This is the argument to many of the operations. It consists of a List of different data types. The List will have form and data relevant with the particular operation. LIST ( --- ) Command-Type Gives the type of a command (e.g., request, reply, alarm). INDEX Error-List The error list contains information concerning an error which has occured. It is a List comprised of the two objects error-class and error-string. LIST ( error class, error string ) Error-Class A code for the class of the error. INDEX Error-String A text string explaining the error. TEXT How-Delivered A comment on the delivery of a messages, for instance a message could be delivered, forwarded, or turned over to general delivery. LIST ( TEXT ) [Page 18] Postel March 1979 Internet Message Protocol Specification Mailbox This is the "address" of a user of the internetwork mail system. Mailbox contains information such as net, host, location, and local user-id of the recipient of the message. Some information contained in Mailbox may not be necessary for delivery. As an example, when one sends a message to someone for the first time, he may include many items which are not necessary simply to insure delivery. However, once he gets a reply to this message, the reply could contain an Address (as opposed to Mailbox) which the user will use from then on. A mailbox is a PROPLIST. A mailbox might contain the following name-value pairs: name element description ---- ------- ----------- IA INTEGER internet address NET TEXT network name HOST TEXT host name USER TEXT user name CITY TEXT city COUNTRY TEXT country STATE TEXT state ZIP TEXT zip code PHONE TEXT phone number PROPLIST ( --- ) Operation This names the operation or procedure to be performed. TEXT Options REGULAR for normal delivery, FORWARD for message forwarding, GENDEL for general delivery, or other options which may be defined later. LIST ( TEXT, ... ) Postel [Page 19] March 1979 Internet Message Protocol Specification Reasons These could be mailbox does not exist, mailbox full, etc. LIST ( TEXT ) Stamp Each MPM that handles the message must add a unique identifier (ihn, see above) to the list. This will prevent messages from being sent back and forth through the internet mail system without eventually either being delivered or returned to the sender. LIST ( ihn, ihn, ... ) Trail When a message is sent through the internetwork environment, it acquires a list of MPMs that have handled the message in "Stamp". This list is then carried as "Trail" upon reply or acknowledgment of that message. More simply, requests and replies always have a "Stamp" and each MPM adds its ihn to this "Stamp." Replies, in addition, have a "Trail" which is the complete "Stamp" of the original message. LIST ( ihn, ihn, ... ) Type The command type, e.g., request or reply. INDEX Document In this section, we define some objects useful in message document headers. The ones we use are taken from the current ARPANET message syntax standard [6,8]. CC When copies of a message are sent to others in addition to the addresses in the To object, those to whom the copies are sent will have their addresses recorded here. CC will be a single TEXT element. TEXT [Page 20] Postel March 1979 Internet Message Protocol Specification Date The date and time are represented according to the International Standards Organization (ISO) recommendations [13,14,15]. Taken together the ISO recommendations 2014, 3307, and 4031 result in the following representation of the date and time: yyyy-mm-dd-hh:mm:ss,fff+hh:mm Where yyyy is the 4 digit year, mm is the two digit month, dd is the two digit day, hh is the two digit hour in 24 hour time, mm is the two digit minute, ss is the two digit second, and fff is the decimal fraction of the second. To this basic date and time is appended the offset from Greenwich as plus or minus hh hours and mm minutes. TEXT Document-Body The document body will contain that portion of the message commonly thought of as the text portion. It will be composed of a list of elements. This will allow transmission of data other than pure text if such capabilities are needed. We can, for instance, envision digital voice communication through the transmission of BITSTR element, or transmission of graphic data, etc. Information regarding control of such features could be included in the header for cooperating sites, or in the body itself but such protocols would depend upon agreement among those sites involved. It is expected of course that the majority of messages will contain body portions comprised of TEXT elements. LIST ( --- ) Document-Header The document header contains the memo header presented to the user. In principle this may be of any style or structure. In this specification it is recommended that a PROPLIST be used and that the name-value pairs correspond to the header fields of RFC 733 [6]. PROPLIST ( --- ) Postel [Page 21] March 1979 Internet Message Protocol Specification From The From is meant to be the name of the author of a document. It will be one TEXT element. TEXT Reply-To Sometimes it will be desired to direct the replies of a message to some address other than the From or the Sender. In such a case the Reply-To object can be used. TEXT Sender The Sender will contain the address of the individual who sent the message. In some cases this is NOT the same as the author of the message. Under such a condition, the author should be specified in the From object. The Sender is a single TEXT element. TEXT Subject The subject of the message. TEXT To To identifies the addressees of the message. The To object is one TEXT element. TEXT [Page 22] Postel March 1979 Internet Message Protocol Specification 3.4. Command This section describes the commands which processes in the internet message system can use to communicate. Several aspects of the command structure are based on the NSW Transaction Protocol [19]. The commands come in pairs, with each request having a corresponding reply. A command is a list: LIST ( mailbox, stamp, type, operation, arguments, error-list ) The arguments are described generally here and more specifically, if necessary, in the description of each command. mailbox: PROPLIST This is the "to" specification of the message. Mailbox takes the form of a property list of general information, some of which is the essential information for delivery, and some of which could be extra information which may be helpful for delivery. Mailbox is different from address in that address is a very specific list without extra information. stamp: LIST ( INTEGER, ... ) This is a list of the MPMs that have handled the message. Each MPM must add its 32 bit Internet Host Number (ihn) to the LIST. type: INDEX type=1 a REQUEST operation. type=2 a REPLY operation. type=3 an ALARM operation. (A high priority message.) type=4 a RESPONSE to an alarm operation. operation: TEXT Operation is the name of the operation or procedure to be performed. This string must be interpreted in an upper/lower case independent manner. Postel [Page 23] March 1979 Internet Message Protocol Specification arguments: LIST This is a list of arguments to the above operation. error-list: LIST If message is type 1 or 3 (a request or an alarm): LIST ( ) (a zero length list) If message is a type 2 or 4 (a response or response to alarm) LIST ( error-class, error-string ) indicates what,if any, error occured error-class: INDEX =0: indicates success, no error =1: partial results returned. This error class is used when several steps are performed by one operation and some of them fail. =2: failure, resources unavailable. =3: failure, user error. =4: failure, MPM error. Recoverable. =5: failure, MPM error. Fatal. =6: User abort requested error-string: TEXT This is a human readable character string describing the error. Possible errors: error-string error-class No errors 0 Command not implemented 2 Syntax error, command unrecognized 3 Syntax error, in arguments 3 Server error, try again later 4 No service available 5 User requested abort 6 [Page 24] Postel March 1979 Internet Message Protocol Specification command: DELIVER type: 1 function: Sends message to a mailbox reply: The reply is ACKNOWLEDGE arguments: LIST ( options ) options: one or more of the following "REGULAR" regular delivery "FORWARD" message forwarding "GENDEL" general delivery other options which may be defined later argument structure: LIST ( LIST ( TEXT, ... )) Postel [Page 25] March 1979 Internet Message Protocol Specification command: ACKNOWLEDGE type: 2 function: reply to DELIVER arguments: LIST ( tid, trail, answer, reasons, how-delivered ) tid: tid of the originating message trail: the stamp from the deliver command