📄 rfc753.txt
字号:
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 1979Internet Message ProtocolIntroduction 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 DESCRIPTION2.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 willPostel [Page 5] March 1979Internet Message ProtocolFunctional 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 1979Internet Message ProtocolFunctional 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 1979Internet Message ProtocolFunctional 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 Description2.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 1979Internet Message Protocol⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -