📄 rfc759.txt
字号:
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.
User User
\ /
UIP UIP
\ /
+---------------------------------------------------------+
| \ / |
| +-----+ +-----+ +-----+ |
| | MPM | <--Protocol--> | MPM | <--Protocol--> | MPM | |
| +-----+ +-----+ +-----+ |
| | / \ | |
| +-----------------------+ +-----------------------+ |
| |Communication Service A| |Communication Service B| |
| +-----------------------+ +-----------------------+ |
| |
+---------------------------------------------------------+
Message Service with Internal Relaying
Figure 2.
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
+-----+ 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 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:
+------+ +-----+ +-------+ +-----+ +-----+
|Telnet| | FTP | |Message| |Voice| ... | | Application Level
+------+ +-----+ +-------+ +-----+ +-----+
\ | / | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
|
Protocol Relationships
Figure 4.
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -