This is the second 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 discussions 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,
Suzanne Sluizer, Alan Katz, Paul Mockapetris, and Linda Sato.
Jon Postel
Postel [Page iii]
IEN: 113 J. Postel
RFC: 759 USC-ISI
August 1980
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
delivery 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
delivery system in its own right.
This system also provides for the communication of data items beyond
the scope of contemporary message systems. Messages can include data
objects 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
for the composition of complex data objects and their encoding in
machine independent basic data elements.
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
Postel [Page 1]
August 1980
Internet Message Protocol
Introduction
developed in the context of the ARPA work on the interconnection of
networks, but it is thought that it has a more general scope.
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 this 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 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 [1,2].
1.4. Model of Operation
This protocol is implemented in a process 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 message it is submitted for transmission by placing
it in a data structure read by 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 (or some other method), determines which outgoing link
to use. The destination may be another user on the same host, one on
another host on a network in common with the same host, or a user in
another network.
In the first case, another user on this host, the MPM places the
message in a data structure read by 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
[Page 2] Postel
August 1980
Internet Message Protocol
Introduction
the routing decision, and discovering the destination is local to it,
places the message in the data structure shared with the destination
user.
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.
An 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.
An 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 an MPM which then sends
it through the appropriate gateways to (or towards) the MPM in the
destination network. Eventually, the message gets to an 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
potentially lead to information loss. 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 discards 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 deferred
as long as possible; still, the possibility remains that in some cases
it is the only reasonable thing to do.
Postel [Page 3]
August 1980
Internet Message Protocol
Introduction
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
Transmission Control Protocol (TCP) [3]. 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).
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
August 1980
Internet Message Protocol
2. FUNCTIONAL DESCRIPTION
This section gives an overview of the Internet Message System and its
environment.
2.1. Terminology
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.
The basic unit transferred between MPMs is called a message. A
message is made up of a transaction identifier (which uniquely
identifies the message), a command (which contains the necessary
information for delivery), and document. The document may have a
header and a body.
For a personal letter the document body corresponds to the contents of
the letter; the document header corresponds to the date line,
greeting, and signature.
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. Some of the information in
the command is supplied by the UIP.
2.2. Assumptions
The following assumptions are made about the internetwork environment:
In general, it is 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.
Each MPM is required to know completely only the addressing format of
its own network(s). 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 numeric address. Such names and addresses are
Postel [Page 5]
August 1980
Internet Message Protocol
Functional Description
registered with a naming authority and may be listed in documents such
as Assigned Numbers [4].
Each MPM will have a unique internet address. This feature will
enable every MPM to place a unique 'handling-stamp' on a message which
passes through the MPM enroute 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
/
UIP UIP
/
--+----------------------------------------+-- 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, 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 via different communication
services.
[Page 6] Postel
August 1980
Internet Message Protocol
Functional Description
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
MPMs, though all communication services must meet the service
characteristics described below.
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) [3]. 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). All data sent is
delivered in order.
o Simple commands to open and close the connections, and to send
and receive data on the connections.
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 of the sender or receiver. Complete breakdown on
communication is reported to the sender or receiver.
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. An MPM might exist in two (or more)
interprocess communication environments, and such an MPM might act to
relay messages between MPMs. Messages may be held for a time in an
MPM; the total path required for delivery need not be available
simultaneously.
From the time a message is accepted from a UIP by an MPM until it is
delivered to a UIP by an MPM and an acknowledgment is returned to the
Postel [Page 7]
August 1980
Internet Message Protocol
Functional Description
originating UIP, the message is considered to be active in the message
system.
It should be clear that there are two roles an MPM can play, an
end-point MPM or a relay MPM. Most MPMs will play both roles. A
relay MPM acts to relay messages from one communication environment to
another. An end-point MPM acts as a source or destination of
messages.
The transfer of data between UIPs and MPMs is viewed 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
August 1980
Internet Message Protocol
Functional Description
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 an MPM (or a UIP), a
message may be represented in any convenient form.
Postel [Page 9]
August 1980
Internet Message Protocol
Functional Description
2.5. Relation to Other Protocols
This protocol the benefited from the earlier work on message protocols
in the ARPA Network [5,6,7,8,9], and the ideas of others about the
design of computer message systems
[10,11,12,13,14,15,16,17,18,19,20,21].
Figure 4 illustrates the place of the message protocol in the ARPA
internet protocol hierarchy:
Note that 'local network' means an individual or specific network.
For example, the ARPANET is a local network.
The message protocol interfaces on one side to user interface programs
and on the other side to a reliable transport protocol such as TCP.
In this internet message system the MPMs communicate directly using
the lower level transport protocol. In the old ARPANET system,
message transmission was part of the file transfer protocol.
[Page 10] Postel
August 1980
Internet Message Protocol
Functional Description
Note that in the old ARPANET protocols one can't send messages (or
communicate in any way) to other networks since it has no gateway
level or internet protocol [5].
Postel [Page 11]
August 1980
Internet Message Protocol
[Page 12] Postel
August 1980
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 medium it
has to come in some order. In this attempt, a brief overview of the
message structure is given, the detail of the message is presented in
terms of data objects, the various data objects are defined, and finally
the representation of the data elements is specified. Several aspects
of the message structure are based on the NSW Transaction Protocol [22],
and similar (but more general) proposals [23,24].
3.1. Overview of Message Structure
A message is normally composed of three parts: the identification,
the command, and the document. Each part is in turn composed of data
objects.
The identification part is composed of a transaction number assigned
by the originating MPM and the MPM identifier.
The command part is composed of an operation type, an operation code,
the arguments to the operation, error information, the destination
mailbox, and a trace. The trace is a list of the MPMs that have
handled this message.
The document part is a data structure. The message delivery system
does not depend on the contents of the document part. A standard for
the document part is defined in reference [25].
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.
The basic data elements are defined in section 3.7. In summary, these
are exact forms for representing integers, strings, booleans, et
cetera. There are also two elements for building data structures:
list and property list. Lists are simple lists of elements, including
lists. Property lists are lists of pairs of elements, where the first
element of each pair names the pair. That is, a property list is a
list of pairs. In general, when an object is composed of
multiple instances of a simpler object it is represented as a list of
the simpler objects. When an object is composed of a variety of
simpler objects it is represented as a property list of the simpler
objects. In most uses of the property list representation, the
presence of pairs in addition to those specifically
required is permitted.
Postel [Page 13]
August 1980
Internet Message Protocol
Specification
3.2. Message Structure
An internet message is composed of two or three parts. The first is
the Identification which identifies the transaction; the second is the
Command; and the optional third part is the Document.
When shipped between two MPMs, a message will take the form of a
property list, with the pairs in this order.
MESSAGE is:
( Identification, Command [, Document ] )
It is convenient to batch several messages together, shipping them
as a unit from one MPM to another. Such a group of messages is
called a message-bag.
A message-bag will be a list of Messages; each Message is of the
form described above.
MESSAGE-BAG is:
( Message, Message, ... )
The Identification
This is the transaction identifier. It is assigned by the
originating MPM. The identification is composed of the MPM
identifier, and a transaction number unique in that context for this
message.
The Command
The command is composed of a mailbox, an operation code, the
arguments to that operation, some error information, and a trace of
the route of this message. The command is implemented by a property
list which contains pairs, where the names are used to
identify the associated argument values.
The Document
The document portion of an internet message is optional and when
present is a data structure as defined in [25].
[Page 14] Postel
August 1980
Internet Message Protocol
Specification
3.3. Identification
Each message must have a unique identifier while it exists in the
message delivery system. This is provided by the combination of the
unique identifier of the MPM and a unique transaction number chosen
for the message by this MPM.
IDENTIFICATION is:
( mpm-identifier, transaction-number )
The mpm-identifier is based on the host address of the computer in
which the MPM resides. If there is more than one MPM in a host the
mpm-identifier must be extended to distinguish between the co-resident
MPMs.
3.4. Command
This section describes the commands MPMs use to communicate between
themselves. The commands come in pairs, with each request having a
corresponding reply.
The mailbox is the 'To' specification of the message. Mailbox is 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 property list without extra
information. The mailbox includes a specification of the user, when
a command is addressed to the MPM itself (rather than a user it
serves) the special user name '*MPM*' is specified.
The operation is the name of the operation or procedure to be
performed.
The arguments to the operation vary from operation to operation.
The error information is composed of a error class code and a
character string, and indicates what, if any, error occurred. The
error information is normally present only in replies, and not present
in requests.
Postel [Page 15]
August 1980
Internet Message Protocol
Specification
The trace is a list of the MPMs that have handled the message. Each
MPM must add its handling-stamp to the list.
[Page 16] Postel
August 1980
Internet Message Protocol
Specification
reference: the identifier of the originating message.
address:
The address is the final mailbox the message was delivered to.
This would be different from the original mailbox if the message
was forwarded, and is limited to the essential information
needed for delivery.
type-of-service: one of the following:
'GENDEL' message was accepted for general delivery
'REGULAR' message was accepted for normal delivery
'PRIORITY' message was accepted for priority delivery
error-class:
error-string:
If the document was delivered successfully, the error
information has class 0 and string 'ok'. Otherwise, the error
information has a non-zero class and the string would be one of
'no such user', 'no such host', 'no such network', 'address
ambiguous', or a similar response.
trail: the trace from the DELIVER command.
Postel [Page 17]
August 1980
Internet Message Protocol
Specification
3.4.3. Command: PROBE
function: Finds out if specified mailbox (specified in mailbox of
the command) exists at a host.
reply: The reply is RESPONSE.
arguments: none.
3.4.4. Command: RESPONSE
function: Reply to PROBE.
arguments:
reference: the identification of the originating PROBE.
address: a specific address.
error-class:
error-string:
If the mailbox was found the error class is 0 and the error
string is 'OK'. If the mailbox has moved and a forwarding
address in known the error class is 1 and the error string is
'Mailbox moved, see address'. Otherwise the error class is
greater than 1 and the error string may be one of the following:
'Mailbox doesn't exist', 'Mailbox full', 'Mailbox has moved, try
the new location indicated in the address'.
trail: the trace which came from the originating PROBE.
[Page 18] Postel
August 1980
Internet Message Protocol
Specification
3.4.5. Command: CANCEL
function: Abort request for specified transaction.
reply: The reply is CANCELED.
arguments:
reference: identification of transaction to be canceled.
3.4.6. Command: CANCELED
function: Reply to CANCEL.
arguments:
reference: identification of canceled transaction.
error-class:
error-string:
If the command was canceled the error class is 0 and the error
string is 'OK'. Otherwise the error class is positive and the
error string may be one of the following: 'No such transaction',
or any error for an unreachable mailbox.
trail: the trace of the CANCEL command.
To summarize again, a command generally consists of a property list of
the following objects:
name value
---- -----
mailbox property list of address information
operation name of operation
arguments ---
error-class numeric class of the error
error-string text description of the error
trace list ( handling-stamp, ... )
3.5. Document
The actual document follows the command. The message delivery system
does not depend on the document, examine it, or use it in any way.
The standard for the contents of the document is reference [25]. The
document must be the last pair in the message property
list.
Postel [Page 19]
August 1980
Internet Message Protocol
Specification
3.6. Message Objects
In the composition of messages, we use a set of objects such as
mailbox or date. These objects are encoded in basic data elements.
Some objects are simple things like integers or character strings,
other objects are more complex things built up of lists or property
lists.
The following is a list of the objects used in messages. The object
descriptions are in alphabetical order.
Action
The type of handling action taken by the MPM when processing a
message. One of ORIGIN, RELAY, FORWARD, or DESTINATION.
Address
Address is intended to contain the minimum information necessary to
deliver a message, and no more (compare with mailbox).
An address is a property list. An address contains the following
pairs:
name description
---- -----------
NET network name
HOST host name
USER user name
or:
name description
---- -----------
MPM mpm-identifier
USER user name
Answer
A yes (true) or no (false) answer to a question.
Arguments
Many operations require arguments, which differ from command to
command. This 'object' is a place holder for the actual arguments
when commands are described in a general way.
[Page 20] Postel
August 1980
Internet Message Protocol
Specification
The date and time are represented according to the International
Standards Organization (ISO) recommendations [26,27,28]. 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 four-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.
The time is local time and the offset is the difference between
local time and Coordinated Universal Time (UTC). To convert from
local time to UTC algebraically subtract the offset from the local
time.
For example, when the time in
Los Angeles is 14:25:00-08:00
the UTC is 22:25:00
or when the time in
Paris is 11:43:00+01:00
the UTC is 10:43:00
Document
The document is the user's composition and is not used by the
message delivery system in any way.
Postel [Page 21]
August 1980
Internet Message Protocol
Specification
Error-Class
A numeric code for the class of the error. The error classes are
coded as follows:
= 0: indicates success, no error.
This is the normal case.
= 1: failure, address changed.
This error is used when forwarding is possible, but not allowed
by the type of service specified.
= 2: failure, resources unavailable.
These errors are temporary and the command they respond to may
work if attempted at a later time.
= 3: failure, user error.
For example, unknown operation, or bad arguments.
= 4: failure, MPM error. Recoverable.
These errors are temporary and the command they respond to may
work if attempted at a later time.
= 5: failure, MPM error. Permanent.
These errors are permanent, there is no point in trying the same
command again.
= 6: Aborted as requested by user.
The response to a successfully canceled command.
[Page 22] Postel
August 1980
Internet Message Protocol
Specification
Error-String
This is a character string describing the error. Possible errors:
error-string error-class
No errors 0
Ok 0
Mailbox Moved, see address 1
Mailbox Full, try again later 2
Syntax error, operation unrecognized 3
Syntax error, in arguments 3
No Such User 3
No Such Host 3
No Such Network 3
No Such Transaction 3
Mailbox Does Not Exist 3
Ambiguous Address 3
Server error, try again later 4
No service available 5
Command not implemented 5
Aborted as requested by user 6
Handling-Stamp
The handling-stamp indicates the MPM, the date (including the time)
that a message was processed by an MPM, and the type of handling
action taken.
( mpm-identifier, date, action )
Host
The character string name of a host.
Identification
This is the transaction identifier associated with a particular
message. It is the transaction number, and the MPM identifier of
the originating MPM.
( mpm-identifier, transaction-number )
Postel [Page 23]
August 1980
Internet Message Protocol
Specification
Internet Address
This identifies a host in the ARPA internetwork environment. When
used as a part of identification, it identifies the originating host
of a message. The internet address 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 [2]. For use in the MPMs the
internet address is divided into eight bit fields and the value of
each field is represented in decimal digits. For example, the
ARPANET address of ISIE is 167837748 and is represented as
10,1,0,52. Further, this representation may be extended to include
an address within a host, such as the TCP port of the MPM, for
example, 10,1,0,52,0,45.
Mailbox
This is the destination address of a user of the internetwork mail
system. Mailbox contains information such as network, host,
location, and local user indentifier 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 will contain an Address (as opposed to Mailbox) which may be
used from then on.
A mailbox is a property list. A mailbox might contain the
following pairs:
name description
---- -----------
MPM mpm-identifier
NET network name
HOST host name
PORT address of MPM within the host
USER user name
ORG organization name
CITY city
STATE state
COUNTRY country
ZIP zip code
PHONE phone number
The minimum mail box is an Address.
[Page 24] Postel
August 1980
Internet Message Protocol
Specification
MPM-Identifier
The internetwork address of the MPM. This may be the ARPA Internet
Address or an X.121 Public Data Network Address [29]. The
mpm-identifier is a property list which has one pair.
This unusual structure is used so that it will be easy to determine
the type of address used.
Network
This character string name of a network.
Operation
This names the operation or procedure to be performed. It is a
character string name.
Organization
This character string name of a organization.
Phone
This character string name representation of a phone number. For
example the phone number of ISI is 1 (international region) + 213
(area code) + 822 (central office) + 1511 (station number) =
12138221511.
Port
This names the port or subaddress within a host of the MPM. The
default port for the MPM is 45 (55 octal) [4].
Reference
The reference is an identification from an earlier message.
State
The character string name of a state.
Postel [Page 25]
August 1980
Internet Message Protocol
Specification
Trace
Each MPM that handles the message must add its handling-stamp to
this list. This will allow detection of messages being sent in a
loop within the internet mail system, and aid in fault isolation.
Trail
When a message is sent through the internetwork environment, it
acquires this trace, a list of MPMs that have handled the message.
This list is then carried as the trail in a reply or acknowledgment
of that message. Requests and replies always have a trace and each
MPM adds its handling-stamp to this trace. Replies, in addition,
have a trail which is the complete trace of the original message.
Transaction Number
This is a number which is uniquely associated with this transaction
by the originating MPM. It identifies the transaction. (A
transaction is a message and acknowledgment.) A transaction number
must be unique during the time which the message (a request or
reply) containing it could be active in the network.
Type-of-Service
A service parameter for the delivery of a message, for instance a
message could be delivered (REGULAR), forwarded (FORWARD), turned
over to general delivery (GENDEL) (i.e., allow a person to decide
how to further attempt to deliver the message), or require priority
handling (PRIORITY).
User
The character string name of a user.
X121 Address
This identifies a host in the Public Data Network environment. When
used as a part of identifier, it identifies the originating host of
a message. The X121 address is a sequence of up to 14 digits [29].
For use in the MPMs the X121 address is represented in decimal
digits.
[Page 26] Postel
August 1980
Internet Message Protocol
Specification
Zip Code
The character string representation of a postal zip code. The zip
code of ISI is 90291.
3.7. Data Elements
The data elements defined here are similar to the data structure and
encoding used in NSW [30].
Each of the diagrams which follow represent a sequence of octets.
Field boundaries are denoted by the '|' character, octet boundaries by
the '+' character. Each element begins with a one-octet code. The
order of the information in each element is left-to-right. In fields
with numeric values the high-order (or most significant) bit is the
left-most bit. For transmission purposes, the leftmost octet is
transmitted first. Cohen has described some of the difficulties in
mapping memory order to transmission order [31].
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. The type-octet is followed by a
three-octet count of the number of octets to follow. 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. The octet
following the type-octet has the value 1 for True and 0 for False.
[Page 28] Postel
August 1980
Internet Message Protocol
Specification
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 (EPI) is an extended precision integer. The type octet
is followed by a three-octet count of the number of data octets to
follow. Representation is two's complement.
Element code 6 (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 three-octet count field instead of
the number of octets.
Element code 7 (NAME) is used for the representation of character
string names (or other short strings). The type octet is followed by
a one-octet count of the number of characters (one per octet) to
follow. Seven bit ASCII characters are used, right justified in the
octet. The high order bit in the octet is zero.
Element code 8 (TEXT) is used for the representation of text. The
type octet is followed by a three-octet count of the number of
characters (one per octet) to follow. Seven bit ASCII characters are
used, right justified in the octet. The high order bit in the octet
is zero.
Element code 9 (LIST) can be used to create structures composed of
other elements. The three-octet octet count specifies the number of
octets in the whole list (i.e., the number of octets following this
count field to the end of the list, not including the ENDLIST octet).
The two-octet item count contains the number of elements which follow.
Any element may be used including list itself.
In some situations it may not be possible to know the length of a list
Postel [Page 29]
August 1980
Internet Message Protocol
Specification
until the head of it has been transmitted. To allow for this a
special ENDLIST element is defined. A list of undetermined length is
transmitted with the octet count cleared to zero, and the item count
cleared to zero. A null or empty List, one with no elements, has an
octet count of two (2) and an item count of zero (0). The ENDLIST
element always follows a LIST, even when the length is determined.
Element code 10 (PROPLIST) is the Property List element. It is a
special case of the list element, in which the elements are in pairs
and the first element of each pair is a name. It has the following
form:
+------+------+------+------+------+
| 10 | octet count | pair |
+------+------+------+------+------+
+------+------/---+------+------/---+
repeated | name element | value element |
+------+------/---+------+------/---+
+-------+
|ENDLIST|
+-------+
The Property List structure consists of a set of unordered
pairs. The pairs are composed of a name which must be a
NAME element and a value which may be any kind of element. Following
the type code is a three-octet octet count of the following octets.
Following the octet count is a one-octet pair count of the number of
pairs in the property list.
The name of a pair is to be unique within the property
list, that is, there shall be at most one occurrence of any particular
name in one property list.
In some situations it may not be possible to know the length of a
property list until the head of it has been transmitted. To allow for
this the special ENDLIST element is defined. A property list of
undetermined length is transmitted with the octet count cleared to
zero, and the pair count cleared to zero. A null or empty property
list, one with no elements, has an octet count of one (1) and an pair
count of zero (0). The ENDLIST element always follows a property
list, even when the length is determined.
Element code 11 (ENDLIST) is the end of list element. It marks the
end of the corresponding list or property list.
[Page 30] Postel
August 1980
Internet Message Protocol
Specification
Structure Sharing
When messages are batched in message-bags for transmission, it may
often be the case that the same document will be sent to more than
one recipient. Since the document portion can usually be expected
to be the major part of the message, much repeated data would be
sent if a copy of the document for each recipient were to be shipped
in the message-bag.
To avoid this redundancy, messages may be assembled in the
message-bag so that actual data appears on its first occurrence and
only references to it appear in later occurrences. When data is
shared, the first occurrence of the data will be tagged, and later
locations where the data should appear will only reference the
earlier tagged location. All references to copied data point to
earlier locations in the message-bag. The data to be retrieved is
indicated by the tag.
This is a very general sharing mechanism. PLEASE NOTE THAT THE MPM
WILL NOT SUPPORT THE FULL USE OF THIS MECHANISM. THE MPM WILL ONLY
SUPPORT SHARING OF WHOLE DOCUMENTS. No other level of sharing will
be supported by the MPMs.
This sharing mechanism may be used within a document as long as all
references refer to tags within the same document.
Sharing is implemented by placing a share-tag on the first
occurrence of the data to be shared, and placing a share-reference
at the locations where copies of that data should occur.
+------+------+------+
12 Share Tag | 12 | share-index |
+------+------+------+
Element code 12 (S-TAG) is a share tag element. The two octets
following the type-octet specify the shared data identification code
for the following data element. Note that s-tag is not a DATA
element, in the sense that data elements encode higher level
objects.
Element code 13 (S-REF) is a share reference element. The two
Postel [Page 31]
August 1980
Internet Message Protocol
Specification
octets following the type-octet specify the referenced shared data
identification code.
Site Hosted By Digital Environments, Inc. This Website was Created with DE-Web Version 1.9.7.4, The Fast, Web Based - Website Design Tool, Groupware and Web Hosting System by Digital Environments, Inc. Groupware:Project Management, Sales Tracking, Web Site Design and News / Blogger all in one package.
