RFC753 日本語訳
0753 Internet Message Protocol. J. Postel. March 1979. (Format: TXT=93363 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
March 1979
1979年3月
IEN: 85 RFC: 753
IEN: 85RFC: 753
INTERNET MESSAGE PROTOCOL
インターネットメッセージプロトコル
Jonathan B. Postel
ジョナサン・B.ポステル
March 1979
1979年3月
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
南カリフォルニア4676海軍本部Wayマリナデルレイ、カリフォルニア 90291人の情報Sciences Institute大学
(213) 822-1511
(213) 822-1511
< INC-PROJECT, MAIL-MAR-79.NLS.38, >, 31-Mar-79 19:50 JBP ;;;;
<INC-プロジェクト、メール3月の79.NLS.38、>、1979年3月31日19時50分JBP。
[Page 0] Postel
[0ページ] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
TABLE OF CONTENTS
目次
PREFACE ........................................................ iii
PREFACE… iii
1. INTRODUCTION ..................................................... 1
1. 序論… 1
1.1. Motivation ................................................... 1 1.2. Scope ........................................................ 1 1.3. The Internetwork Environment ................................. 2 1.4. Operation .................................................... 2 1.5. Interfaces ................................................... 3
1.1. 動機… 1 1.2. 範囲… 1 1.3. インターネットワーク環境… 2 1.4. 操作… 2 1.5. インタフェース… 3
2. FUNCTIONAL DESCRIPTION ........................................... 5
2. 機能的な記述… 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
2.1. 他のプロトコルとの関係… 5 2.2. 用語… 5 2.3. 仮定… 6 2.4. 一般仕様… 7 2.5. メカニズム… 11
3. DETAILED SPECIFICATION .......................................... 13
3. 詳細な仕様… 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
3.1. メッセージ構造の概要… 13 3.2. データ要素… 13 3.3. メッセージオブジェクト… 16 3.4. 命令してください… 23 3.5. 記録します。 31 3.6. メッセージ構造… 33 3.7. mpm、組織… 36 3.8. インタフェース… 39
4. EXAMPLES & SCENARIOS ............................................ 41
4. 例とシナリオ… 41
Example 1: Message Format ........................................ 41 Example 2: Delivery and Acknowledgment ........................... 43
例1: メッセージ形式… 41 例2: 配送と承認… 43
GLOSSARY ............................................................ 49
用語集… 49
REFERENCES .......................................................... 51
参照… 51
APPENDICES .......................................................... 53
付録… 53
Postel [Page i]
ポステル[ページi]
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
[Page ii] Postel
[ページii] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
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.
これは、この仕様の初版であり、コメント、アドバイス、および提案のために要求として扱われるべきです。 コンピュータの支援されたメッセージシステムの上で大きな先の仕事をしました、そして、参照部でこの或るものを記載します。 この仕様はARPA研究団体のメンバーと共に多くのdiscusionsによって形成されました、そして、コンピュータの開発に興味を持っている他のものはメッセージシステムを支援しました。ARPAの一部がISIでInternetwork Concepts Research Projectを後援したとき、このドキュメントは準備されました、グレッグフィンランド人の支援、アラン・キャッツ、ポールMockapetris、およびMamie Chewと共に。
Jon Postel
ジョン・ポステル
Postel [Page iii]
ポステル[ページiii]
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
[Page iv] Postel
[ページiv] ポステル
March 1979
IEN: 85 J. Postel
RFC: 753 USC-ISI
March 1979
1979年3月のIEN: 85 J.ポステルRFC: 753 1979年のUSC-ISI行進
INTERNET MESSAGE PROTOCOL
インターネットメッセージプロトコル
1. INTRODUCTION
1. 序論
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
1.1. 動機
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
1.2. 範囲
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.
ネットワークの間のメッセージの伝達にインターネットMessageプロトコルが使用されることを意図します。 また、それはネットワークかホストのローカルのメッセージシステムに使用されるかもしれません。 この仕様はネットワークのインタコネクトに対するARPA仕事の文脈で開発されましたが、より一般的な範囲を持っていると予期されます。
Postel [Page 1]
ポステル[1ページ]
March 1979
Internet Message Protocol
Introduction
1979年3月のインターネットメッセージプロトコル序論
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
1.3. インターネットワーク環境
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].
インターネットワークメッセージ環境はホストに立候補するプロセスから成ります(ゲートウェイによってインタコネクトされるネットワークに関連づけられます)。 それぞれの個々のネットワークは多くの異なったホストから成ります。 ネットワークはゲートウェイを通して結びつけられます。 ゲートウェイは、本質的には2つ(さらに)のネットワークのホストであり、多くの記憶容量を持っているか、またはそれらが付属[5]であるネットワークでホストがどれであるかを「知っている」と思われません。
1.4. Operation
1.4. 操作
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.
操作のモデルはこのプロトコルがプロセスで実装されるということです。 そのようなプロセスはMessage Processing ModuleかMPMと呼ばれます。 MPMsは、本書では説明された固定フォーマットで全二重通信を確立して、メッセージを送ることによって、メッセージを交換します。 また、MPMはここで説明されたコマンドによって他の情報を伝えるかもしれません。
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.
メッセージはUser Interface ProgramかUIPと対話するユーザによって形成されます。 ユーザは、メッセージの多岐を作成するいくつかのコマンドを利用して、メッセージのいくつかかすべてを修正するか、またはフォーマットするために編集プログラムを呼び出すかもしれません。 一度、ユーザはそれが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.
MPMは未加工の入力データ(特定の要求か一般的なバックグラウンド検索による)を発見して、それを調べます、そして、経路指定テーブルを使用するのはどの出発しているリンクを使用したらよいかを決定します。 目的地は、このホストの上の別のユーザ、別のホストの上のこのネットワークにおけるユーザ、または別のネットワークでユーザであるかもしれません。
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.
前者の場合このホストの上の別のユーザ、MPMは目的地ユーザと共有されたデータ構造にメッセージを置きます。そこでは、そのユーザのUIPが入力メッセージを探すでしょう。
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.
2番目のケース、このネットワークの別のホストの上のユーザでは、MPMはそのホストの上のMPMにメッセージを送ります。 次に、そのMPMはルーティング決定を繰り返します、そして、目的地を発見するのはそれ(データ構造におけるメッセージが目的地ユーザと共有された場所)に地方です。
[Page 2] Postel
[2ページ] ポステル
March 1979
Internet Message Protocol
Introduction
1979年3月のインターネットメッセージプロトコル序論
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.
3番目のケース、別のネットワークのホストの上のユーザでは、直接それに取引関係を築く方法を知っているなら、MPMはそのネットワークにおけるMPMにメッセージを送ります。さもなければ、MPMは「より近いところに目的地の」あるMPMにメッセージを送ります。 MPMはMPMsにおいて他のすべてのネットワークでダイレクト接続を知らないかもしれませんが、それは、次のMPMがそれぞれの可能な送信先ネットワークへのメッセージを扱うのを選択できなければなりません。
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.
MPMはそれぞれのいくつかのMPMsにおいて他の近いネットワークでダイレクト接続を確立する方法を知って、インターネット環境に関する、より広い知識を持っている特定の兄MPMに他のすべてのメッセージを送るかもしれません。
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.
個々のネットワークのメッセージシステムはインターネットメッセージシステムと全く異なっているかもしれません。 この場合、イントラネットメッセージは、ネットワークの自身のメッセージシステムを使用することで提供されるでしょう。 メッセージがネットワークの外で扱われるなら、それは次に適切なゲートウェイを通してインターネット手順でそれを送るMPMに与えて、送信先ネットワークで(or toward)にMPMをフォーマットすることです。 結局、メッセージはメッセージの受取人のネットワークのMPMを始めます。 そして、そのホストへのローカルのメッセージシステムでメッセージを送ります。
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.
ローカルのメッセージプロトコルが使用されているとき、特別な変換プログラムが出かける、および地方の形式への変換インターネットメッセージにはそれらがあるとき地方の環境に入るときインターネットへのローカルのメッセージがフォーマットする変換に必要です。 そのような変換は潜在的に情報損失性です。 インターネットメッセージ・フォーマットは、どんなローカルのメッセージシステムも使用するかもしれないすべての情報を得る特徴を提供するのを試みます。 しかしながら、特定のローカルのメッセージシステムで、特徴はインターネットメッセージシステムのすべての可能な特徴に同等になりそうにはありません。 その結果、いくつかの場合いくつかの情報の地方のメッセージ破棄へのインターネットメッセージの変換。 例えば、テキストを運ぶだけであるローカルシステムで提供されています、スピーチデータをテキスト文字列に取り替えるかもしれないということになるように、ボディーで複雑なテキストとスピーチデータを運ぶインターネットメッセージがそうであるなら「何らかのスピーチがここにありました」。 情報をそのような捨てるのが可能であるときに、避けられて、できるだけ長い間deferedされることであり、それでも、可能性は残っていて、そんなにいくつかの場合、それはする唯一の妥当なことです。
1.5. Interfaces
1.5. インタフェース
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).
MPMは、信頼できる通信規定が他のMPMsとコミュニケートするよう呼びかけます。これはTCP[20]などのTransport Levelプロトコルです。 そのような手順へのインタフェースは慣習上、接続を開いて、終えて、発信して、接続に関するデータ、およびいくつかの合図している、特別な状態について通知されるべき手段を受け取るという要求(すなわち、中断)を提供します。
Postel [Page 3]
ポステル[3ページ]
March 1979
Internet Message Protocol
Introduction
1979年3月のインターネットメッセージプロトコル序論
The MPM receives input and produces output through data structures that are produced and consumed respectively by user interface (or other) programs.
MPMはユーザーインタフェース(何らかの)プログラムでそれぞれ生産されて、消費されるデータ構造を通して入力を受け取って、出力を起こします。
[Page 4] Postel
[4ページ] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
2. FUNCTIONAL DESCRIPTION
2. 機能的な記述
2.1. Terminology
2.1. 用語
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.
親書に関して、文書本体はコンテンツに対応します。a手紙、ドキュメントヘッダーは封筒の上のアドレスと返送先に文通しています。
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.
メッセージはメッセージ処理モジュールと呼ばれるプロセスかMPMによって発送されます。 メッセージは、ユーザに関連してUser Interface Programs(UIPs)によって作成されて、消費されます。
Please see the Glossary section for a more complete list of terminology.
Glossaryがaのために用語に関する、より多くの全リストを区分するのを見てください。
2.2. Assumptions
2.2. 仮定
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.
一般に、形式イントラネットアドレスが何を仮定するかは知られていません。 どんな標準のアドレシング体系もすべてのネットワークに合うというわけではないでしょう、したがって、数個があって、時間を交換すると仮定するのは安全です。 したがって、そのようなMPMsが多くのネットワークの形式に関して知るなら、すべてのインターネットMPMs中の頻繁なソフトウェア変更が必要でしょうに。 したがって、インターネットメッセージを扱う各MPMが、それらを提供するのに必要な最小限だけを知るのに必要です。
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.
私たちは、各MPMがそれ自身のネットワークのアドレス指定形式だけを完全に知るのを必要とします。 さらに、MPMは別のネットワークかホストに扱われた各メッセージのために出力リンクを選択できなければなりません。 これは与えられたMPM側のより知的な振舞いを排除しませんが、少なくともこの最小限が必要です。 各ネットワークには、ユニークな名前と数があります。
Each MPM will have a unique internet address. This feature will
各MPMには、ユニークなインターネットアドレスがあるでしょう。 この特徴はそうするでしょう。
Postel [Page 5]
ポステル[5ページ]
March 1979
Internet Message Protocol
Functional Description
1979年3月のインターネットのメッセージのプロトコルの機能的な記述
enable every MPM to place a unique "handling-stamp" on a message which passes through it en-route to delivery.
あらゆるMPMが配送への途中でそれを通り抜けるメッセージにユニークな「取り扱いスタンプ」を置くのを可能にしてください。
2.3. General Specification
2.3. 一般仕様
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.
指定されるために、分配されたサービスへのいくつかの局面があります。 まず最初に、提供されるサービス、すなわち、ユーザによって見られるサービスの特性があります。 そこの2番目はそれが利用するサービスです、すなわち、それが何らかの下のレベルサービスで提供されると仮定する特性。 そして、3番目に、分配されたサービスのモジュールの間で使用されるプロトコルがあります。
User User
\ /
\ /
\ /
--+----------------------------------------+-- Service
! \ / ! Interface
! +--------+ +--------+ !
! ! Module ! <--Protocol--> ! Module ! !
! +--------+ +--------+ !
! \ / !
! +-----------------------+ !
! ! Communication Service ! !
! +-----------------------+ !
! !
+----------------------------------------+
ユーザユーザ\/\/\/--+----------------------------------------+--サービス!\/!インタフェース+!--------+ +--------+ モジュール!<--プロトコル-->!モジュール+!--------+ +--------+ ! ! \ / ! ! +-----------------------+ 通信サービス+!-----------------------+ ! ! ! +----------------------------------------+
Message Service
メッセージサービス
Figure 1.
図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.
メッセージ配送システムが提供するサービスは、指定された形式に従うメッセージを受け入れて、それらのメッセージを提供して、配送試みの成否に関して報告するのを試みることです。 このサービスは、ネットワークの相互接続システムの文脈に前提とされて、異なった通信サービスを利用する数個の中間的MPMsを通して伝言を伝えることを伴うかもしれません。
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
コミュニケーションにおけるメッセージ配送システムコールは1MPMから別のMPMまで転送に情報を修理します。 異なることの間で中古のサービスが対にする異なったコミュニケーションがあるかもしれません。
[Page 6] Postel
[6ページ] ポステル
March 1979
Internet Message Protocol
Functional Description
1979年3月のインターネットのメッセージのプロトコルの機能的な記述
MPMs, though all communication services must meet the following
service characteristics.
MPMs、すべての通信サービスが以下に会わなければなりませんが、特性を修理してください。
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:
通信サービスが信頼できるツーウェイデータ・ストリームを供給すると思われます。 例えば、通常、小川を得ることができる輸送からのコンピュータネットワークが平らにするそのようなデータは議定書を作ります、通信制御プロトコル(TCP)[20]。 どのような場合でも、通信サービスが提供しなければならない資産は以下の通りです。
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 任意のデータ(すなわち、コードは禁じられない)のツーウェイの同時のデータフローのための論理的な接続。 データはギャップなしで送られた注文で提供されます。
o Simple commands to open and close the connections, and to send
and receive data on the connections.
o 接続での接続を開いて、終えて、発信する簡単なコマンドと受信データ。
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 合図して、「バンドの外」という通知されて、ことである方法(緊急のTCPのものなどのように)は、「他のものより重要である」といくつかのメッセージをラベルできるくらい利用可能です。
o Controlled flow of data so that data is not transmitted faster
that the receiver chooses to consume it (on the average).
o そのデータがあって、データの制御流れは、より速く伝わりませんでした。受信機は、それ(平均して)を消費するのを選びます。
o Transmission errors are corrected without user notification or
involvement. Complete breakdown on communication is reported
to the user.
o 伝送エラーはユーザ通知もかかわり合いなしで修正されます。 コミュニケーションに関する完全な故障はユーザに報告されます。
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.
メッセージ配送システムの分配されたモジュールの間で使用されるプロトコル、すなわち、MPMsは要求と回答を伝える小さいコマンドです。 これらのコマンドは非常に構造化されて、厳格に指定された形式でコード化されます。
2.4. Mechanisms
2.4. メカニズム
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.
MPMsは何らかの通信サービスを使用するプロセスです。 交信できる1組のMPMsが一般的なプロセス間通信環境で住んでいます。 MPMは2つ(さらに)のプロセス間通信環境で存在するかもしれません、そして、そのようなMPMは環境でMPMsの間のメッセージをリレーするために行動するかもしれません。
Postel [Page 7]
ポステル[7ページ]
March 1979
Internet Message Protocol
Functional Description
1979年3月のインターネットのメッセージのプロトコルの機能的な記述
User User
\ /
\ /
\ /
+---------------------------------------------------------+
! \ / !
! +-----+ +-----+ +-----+ !
! ! MPM ! <--Protocol--> ! MPM ! <--Protocol--> ! MPM ! !
! +-----+ +-----+ +-----+ !
! ! / \ ! !
! +-----------------------+ +-----------------------+ !
! !Communication Service A! !Communication Service B! !
! +-----------------------+ +-----------------------+ !
! !
+---------------------------------------------------------+
ユーザユーザ\/\/\/+---------------------------------------------------------+ ! \ / ! ! +-----+ +-----+ +-----+ mpm!<--プロトコル-->!mpm!<--プロトコル-->!mpm+!-----+ +-----+ +-----+ ! ! ! / \ ! ! ! +-----------------------+ +-----------------------+ 通信サービスA! 通信サービスB! ! ! +-----------------------+ +-----------------------+ ! ! ! +---------------------------------------------------------+
Message Service with Internal Relaying
内部のリレーとのメッセージサービス
Figure 2.
図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.
UIPsとMPMsの間のデータ転送はメッセージをコード化するデータ構造の交換として想像されます。 MPMsの間のデータ転送が構造化されたデータの伝達でもあります。
[Page 8] Postel
[8ページ] ポステル
March 1979
Internet Message Protocol
Functional Description
1979年3月のインターネットのメッセージのプロトコルの機能的な記述
+-----+ DATA +-----+
USER-->! UIP !-->STRUCTURES-->! MPM !-->other
+-----+ +-----+ +-----+ MPMs
! !
! +-----+
+--! !
! +-----+
+--! !
! !
+-----+
+-----+ データ+-----+ ユーザ-->!UIP!-->構造-->!mpm!-->他の+-----+ +-----+ +-----+ MPMs!+-----+ +--! ! ! +-----+ +--! ! ! ! +-----+
+-----+ DATA +-----+
other-->! MPM !-->STRUCTURES-->! UIP !-->USER
MPMs +-----+ +-----+ +-----+
! !
! +-----+
+--! !
! +-----+
+--! !
! !
+-----+
+-----+ データ+-----+ 他の-->!MPM!-->STRUCTURES-->!UIP!-->USER MPMs+-----+ +-----+ +-----+ ! ! ! +-----+ +--! ! ! +-----+ +--! ! ! ! +-----+
Message Flow
メッセージ流動
Figure 3.
図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.
以下では、メッセージは特定の種類のタイプされたデータ要素に表された構造化されたデータ・オブジェクトとして記述されるでしょう。 これはメッセージをMPMsの間に伝えると提示するか、またはMPMとUIPの間でどう交換するかということです。 MPM(または、UIP)に内部であり、メッセージはどんな便利なフォームにも表されるかもしれません。 以下の図が示すように、メッセージがトランスミッションの準備ができているとき、それは、タイプされたデータ要素とそして、データ圧縮ルーチンにコード化されるために処理ルーチンから移行して、最終的に伝えられます。 受信側では、メッセージが最初に、次に、処理ルーチンのためにデータ要素表現からローカルの表現まで解読されていた状態で減圧されます。
Postel [Page 9]
ポステル[9ページ]
March 1979
Internet Message Protocol
Functional Description
1979年3月のインターネットのメッセージのプロトコルの機能的な記述
+------------------------------------------------+
! !
! processing DATA DATA !
! routines ---> ENCODER ---> COMPRESSOR ---> !
! !
+------------------------------------------------+
Send MPM
+------------------------------------------------+! 処理DATA DATA!ルーチン--->エンコーダ--->コンプレッサー--->!+------------------------------------------------+はmpmを送ります。
+------------------------------------------------+
! !
! DATA DATA processing !
! ---> DECOMPRESSOR ---> DECODER ---> routines !
! !
+------------------------------------------------+
Receive MPM
+------------------------------------------------+! DATA DATA処理!--->減圧装置--->デコーダ--->ルーチン!+------------------------------------------------+はmpmを受けます。
Detailed View
詳細な視点
Figure 4.
図4。
[Page 10] Postel
[10ページ] ポステル
March 1979
Internet Message Protocol
Functional Description
1979年3月のインターネットのメッセージのプロトコルの機能的な記述
2.5. Relation to Other Protocols
2.5. 他のプロトコルとの関係
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
+---------------------------+
!
+------+ +-----+ +-------+ +-----+ +-----+ telnet! ! FTP!メッセージ! 声! ... ! ! アプリケーションレベル+------+ +-----+ +-------+ +-----+ +-----+ \ ! / ! ! +-----+ +-----+ +-----+ TCP!RTP! ! ! ホストレベル+-----+ +-----+ +-----+ ! ! ! +-------------------------------+ インターネットプロトコル!ゲートウェイレベル+-------------------------------+ ! +---------------------------+ 企業内情報通信網プロトコル!ネットワークレベル+---------------------------+ !
Protocol Relationships
プロトコル関係
Figure 5.
図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.
ユーザーインタフェースプログラムへの半面の上と、そして、信頼できる輸送への反対側の上のメッセージプロトコルインタフェースはTCPなどのように議定書を作ります。
Postel [Page 11]
ポステル[11ページ]
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
[Page 12] Postel
[12ページ] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
3. DETAILED SPECIFICATION
3. 仕様詳細
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
3.1. メッセージ構造の概要
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.
一般に、メッセージは3つの部品で構成されます: 識別、コマンド、およびドキュメント。 各部分はメッセージオブジェクトで順番に構成されます。
The identification part is composed of a transaction number assigned by the originating MPM, and the internet host number of that MPM.
識別部分は起因しているMPMによって割り当てられたトランザクション番号、およびその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.
コマンド一部が操作タイプ、命令コード、アーギュメントの並び、エラー・リスト、あて先メールボックス、およびスタンプで構成されます。 スタンプはこのメッセージを扱ったMPMsのリストです。
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.
以下のセクションは他のオブジェクトで構成された構造化されたオブジェクトとメッセージの表現を定義します。 オブジェクトは、1セットの基礎データ要素を使用することで順番に表されます。
3.2. Data Elements
3.2. データ要素
The data elements defined here are similar to the data structure and encoding used in NSW [18].
ここで定義されたデータ要素は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.
従うそれぞれのダイヤグラムは八重奏の系列を表します。 分野境界は“!"キャラクタによって指示されて、「+」による八重奏境界はキャラクタです。 ダイヤグラムは左に正しいオーダーに提示されます。 各要素は1つの八重奏コードで始まります。
Postel [Page 13]
ポステル[13ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
Code Type Representation ---- ---- --------------
コードタイプ表現---- ---- --------------
+------+
0 No Operation ! 1 !
+------+
+------+ 0いいえ操作1!+------+
+------+------+------+------+------
1 Padding ! 0 ! octet count ! Data ...
+------+------+------+------+------
+------+------+------+------+------ 1 八重奏カウント!詰め物0!!Data… +------+------+------+------+------
+------+------+
2 Boolean ! 2 ! 1/0 !
+------+------+
+------+------+2論理演算子2!!1/0! +------+------+
+------+------+------+
3 Index ! 3 ! Data !
+------+------+------+
+------+------+------+ 3インデックス3!!データ!+------+------+------+
+------+------+------+------+------+
4 Integer ! 4 ! Data !
+------+------+------+------+------+
+------+------+------+------+------+ 4整数4!!データ!+------+------+------+------+------+
+------+------+------+------+------
5 Bit String ! 5 ! bit count ! Data ...
+------+------+------+------+------
+------+------+------+------+------ 5ビットのString5!!はカウント!Dataに噛み付きました… +------+------+------+------+------
+------+------+------+------+------
6 Text String ! 6 ! octet count ! Data ...
+------+------+------+------+------
+------+------+------+------+------ 6 テキストString6!!八重奏カウント!Data… +------+------+------+------+------
+------+------+------+------+------+------+-----
7 List ! 7 ! octet count ! item count ! Data
+------+------+------+------+------+------+-----
+------+------+------+------+------+------+----- 7 八重奏カウント!項目カウント!リスト7!!Data+------+------+------+------+------+------+-----
+------+------+------+------+------
8 Proplist ! 8 ! octet count ! Data ...
+------+------+------+------+------
+------+------+------+------+------ 8 Proplist8!!八重奏カウント!Data… +------+------+------+------+------
[Page 14] Postel
[14ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
Element code 0 (NOP) is an empty data element used for padding when it is necessary. It is ignored.
要素コード0(NOP)はそれが必要であるときにそっと歩くのに使用される空のデータ要素です。 それは無視されます。
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.
要素コード1(PAD)は、テストへのメッセージで多量のデータを送るのに使用されるか、または目的を水増ししています。 このデータで行動を全く取りませんが、ダミーの八重奏のカウントは、次の要素コードを示すために正しくなければなりません。
Element code 2 (BOOLEAN) is a boolean data element which has the value 1 for True and 0 for False.
要素コード2(ブール)はTrueのための値1とFalseのための0を持っている論理演算子データ要素です。
Element code 3 (INDEX) is a 16-bit unsigned integer datum. Element code 3 occupies only 3 octets.
要素コード3(INDEX)は16ビットの符号のない整数データです。 要素コード3は3つの八重奏だけを占領します。
Element code 4 (INTEGER) is a signed 32-bit integer datum. This will always occupy five octets. Representation is two's complement.
要素コード4(INTEGER)は署名している32ビットの整数データです。 これはいつも5つの八重奏を占領するでしょう。 表現は2の補数です。
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.
要素コード5(BITSTR)はバイナリ・データのために要素を少し結ぶことです。 ビット列が八重奏境界で終わらないならビット列は右でゼロで水増しされて、最後の八重奏に書き込みます。 このデータ型は八重奏の数の代わりに2八重奏カウント分野にビットカウントを持たなければなりません。
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.
要素コード6(TEXT)はテキストの表現に使用されます。 7ビットのASCII文字は、中古であって、八重奏でまさしく正当です。 八重奏における高位のビットはゼロです。
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).
他の要素で構成された構造を作成するのに、要素コード7(LIST)を使用できます。 項目カウントは従う要素の数を含んでいます。 List自身を含んでいて、どんな要素も使用されるかもしれません。 八重奏カウントは全体のリストの八重奏の数を指定します。 ヌルの、または、空のList(要素のない1)には、(0)がない項目カウントがあります。
Postel [Page 15]
ポステル[15ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
Element code 8 (PROPLIST) is the Property-List element. It has the following form:
要素コード8(PROPLIST)はProperty-リスト要素です。 それで、以下は形成されます:
+------+------+------+------+------+
! 8 ! octet ! pair !
! ! count ! count!
+------+------+------+------+------+
+------+------+------+---------+---------+
! name ! value ! name ! value !
repeated ! count! count ! ...! ...!
+------+------+------+---------+---------+
+------+------+------+------+------数えてください!+! 8!八重奏!組!数えてください! +------+------+------+------+------+ +------+------+------+---------+---------+! 名前!値!名前!値!カウント!カウントを繰り返しました!! ...! +------+------+------+---------+---------+
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.
Property-リスト構造は1セットの順不同の名前/値の組から成ります。 組は、名前と値のストリングがいうことになった1つの八重奏名前カウントと2八重奏値のカウントです。 カウントは名前と値のストリングの八重奏における長さを指定します。 各ストリングには、八重奏におけるそれぞれのカウントに同意する長さがあります。 所有地の次の組が記載するまで、八重奏のカウントは1+2+名前カウント+価値のカウント八重奏です。 全体のProperty-リストはもちろん長さにおいて要素自体の八重奏カウントと等しいです。 すぐに全体の要素のための八重奏カウントに続くのは、Proplistの名前/値の組の総数を含む1つの八重奏組カウント分野です。
3.3. Message Objects
3.3. メッセージオブジェクト
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.
メッセージの構成では、私たちは、1セットのアドレスなどのオブジェクトを使用するか、またはデートします。 これらのオブジェクトは基礎データ要素でコード化されます。 メッセージオブジェクトはデータ要素で造られます。
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.
データ要素はタイプされますが、メッセージオブジェクトはタイプされるというわけではありません。 これはメッセージが1種類のメッセージオブジェクトだけがメッセージ構造のどんな位置にも現れるかもしれないという範囲に構造化されるからです。
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
[16ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
Identification
識別
Internet Host Number (ihn)
インターネットホスト番号(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.
これはインターネットワーク環境でホストを特定します。 tidの一部として使用されると、それはメッセージの送信元ホストを特定します。 ihnは32ビットの数です、そして、より高いオーダー8ビットはネットワークを特定します、そして、下層階級24ビットはそのネットワークでホストを特定します。
INTEGER
整数
Transaction Identifier (tid)
トランザクション識別子(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 )
リスト(tn、ihn)
Transaction Number (tn)
トランザクション番号(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.
これは送信元ホストによって唯一このトランザクションに関連づけられる数です。 それはトランザクションを特定します。 (トランザクションがメッセージと承認である、さらに詳細に後のセクションでこれについて議論します。) tnは中の能動態がネットワークであったならそれを含むメッセージ(要求か回答)がそうすることができた時にユニークであるに違いありません。
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.
これはそれがユーザの「アドレス」であるという点においてもMailboxと非常に同様です。 しかしながら、Addressが配送に必要な最小の情報、およびいいえをさらに含むことを意図します。
PROPLIST ( --- )
PROPLIST( --- )
Answer
答え
A yes (true) or no (false) answer to a question.
はい(本当の)にもかかわらず、(誤っている)の質問への答がありません。
BOOLEAN
論理演算子
Postel [Page 17]
ポステル[17ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
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から成ります。 Listはフォームとデータを特定の操作で関連するようにするでしょう。
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.
エラー・リストはoccuredされた誤りに関して情報を含んでいます。 それは2のオブジェクト誤りクラスと誤りストリングから成るListです。
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
[18ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
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.
これはインターネットワークメールシステムのユーザの「アドレス」です。 メールボックスはメッセージの受取人のネットや、ホストや、位置や、地方のユーザIDなどの情報を含んでいます。 Mailboxに含まれた何らかの情報は配送に必要でないかもしれません。
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.
1つが初めてメッセージをだれかに送るとき、例として、彼は多くの単に配送を保障するのに必要でない項目を入れるかもしれません。 しかしながら、彼がいったんこのメッセージに回答を得ると、回答はユーザがそれ以来使用するAddress(Mailboxと対照的に)を含むかもしれません。
A mailbox is a PROPLIST. A mailbox might contain the following
name-value pairs:
メールボックスはPROPLISTです。メールボックスは以下の名前価値の組を含むかもしれません:
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
名前要素記述---- ------- ----------- IA INTEGERインターネットアドレスNET TEXTネットワーク名HOST TEXTホスト名USER TEXTユーザ名前CITY TEXT都市のCOUNTRY TEXT国のSTATE TEXT州のZIP TEXT郵便番号PHONE TEXT電話番号
PROPLIST ( --- )
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.
後で定義されるかもしれない正常分娩のためのREGULAR、メッセージ推進のためのFORWARD、局留め郵便のためのGENDEL、または別の選択肢。
LIST ( TEXT, ... )
リスト(テキスト)
Postel [Page 19]
ポステル[19ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
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.
メッセージを扱う各MPMはユニークな識別子(ihn、上を見る)をリストに追加しなければなりません。 これは、メッセージがインターネットメールシステムを通して前後に結局送付者に提供するか、または返さないで送られるのを防ぐでしょう。
LIST ( ihn, ihn, ... )
リスト(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.
インターネットワーク環境を通してメッセージを送るとき、それは「スタンプ」でメッセージを扱ったMPMsのリストを取得します。 そして、このリストはそのメッセージの回答か承認のときに「道」として運ばれます。 より単に、要求と回答には、「スタンプ」がいつもあります、そして、各MPMはこの「スタンプ」にihnを加えます。 回答には、オリジナルのメッセージの完全な「スタンプ」である「道」がさらに、あります。
LIST ( ihn, ihn, ... )
リスト(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].
このセクションで、私たちはメッセージドキュメントヘッダーで役に立ついくつかのオブジェクトを定義します。 現在のアルパネットメッセージ構文規格[6、8]から私たちが使用するものを取ります。
CC
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.
Toオブジェクトのアドレスに加えてメッセージのコピーを他のものに送るとき、コピーが送られるそれらで、ここにそれらのアドレスを記録するでしょう。 CCはただ一つのTEXT要素になるでしょう。
TEXT
テキスト
[Page 20] Postel
[20ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
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:
国際Standards Organization(ISO)推薦[13、14、15]に従って、日付と時間は表されます。 日時の以下の表現で推薦2014、3307、および4031年の結果をISOに一緒に取ります:
yyyy-mm-dd-hh:mm:ss,fff+hh:mm
mm dd-hhをyyyyしている、fff+hh: : mm: ss、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.
yyyyが4ケタ年であるところでは、mmは2ケタカ月です、そして、ddは2ケタ日です、そして、hhは24時間の回は2ケタ時間です、そして、mmは2ケタ分です、そして、ssは2番目に、2ケタです、そして、fffは2番目の小数です。 この基礎に、日付と時間は追加して、プラスかマイナスとしてのグリニッジからのオフセットが分間何時間もmmをhhするということです。
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.
文書本体はテキスト部分として一般的に考えられたメッセージのその部分を含むでしょう。 それは要素のリストで構成されるでしょう。 そのような能力が必要であるなら、これは純粋なテキスト以外のデータの伝達を許すでしょう。 例えば、私たちはBITSTR要素のトランスミッション、または図形データなどの送信でデジタル声のコミュニケーションを思い描くことができます。 協力サイトへのヘッダー、またはボディー自体にそのような特徴のコントロールに関する情報を含むことができましたが、そのようなプロトコルはかかわったそれらのサイトの中の協定によるでしょう。 メッセージの大部分がTEXT要素から成るボディー部分を含むともちろん予想されます。
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が使用されて、名前価値の組がRFC733[6]のヘッダーフィールドに文通するのは、お勧めです。
PROPLIST ( --- )
PROPLIST( --- )
Postel [Page 21]
ポステル[21ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
From
from
The From is meant to be the name of the author of a document. It
will be one TEXT element.
Fromはドキュメントの作者の名前であることが意味されます。 それは1つのTEXT要素になるでしょう。
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.
時々、FromかSender以外の何らかのアドレスにメッセージの回答を向けるのは必要でしょう。 このような場合には、Reply、-、オブジェクトを使用できます。
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.
Senderはメッセージを送った個人のアドレスを含むでしょう。 いくつかの場合、これはメッセージの作者と同じではありません。 そのような条件のもとでは、作者はFromオブジェクトで指定されるべきです。 Senderはただ一つのTEXT要素です。
TEXT
テキスト
Subject
対象
The subject of the message.
メッセージの対象。
TEXT
テキスト
To
to
To identifies the addressees of the message. The To object is one
TEXT element.
メッセージの受け取り人を特定します。 Toオブジェクトは1つのTEXT要素です。
TEXT
テキスト
[Page 22] Postel
[22ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
3.4. Command
3.4. コマンド
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.
このセクションはインターネットメッセージシステムのプロセスが交信するのに使用できるコマンドについて説明します。 命令系統のいくつかの局面がNSW Transactionプロトコル[19]に基づいています。 コマンドは対応する回答を持っている各要求のときに組に入ります。
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
メールボックス: 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.
これはメッセージの“to"仕様です。 メールボックスはどれが配送のための不可欠の情報であるか、そして、いくつかのそれのいくつかが配送に、有用であるかもしれないその他の情報であるかもしれない一般情報の特性のリストの形を取ります。 メールボックスはアドレスとアドレスがその他の情報がなければ非常に特定のリストであるという点において異なっています。
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.
これはメッセージを扱ったMPMsのリストです。 各MPMは32ビットのインターネットHost Number(ihn)をLISTに加えなければなりません。
type: INDEX
以下をタイプしてください。 インデックス
type=1 a REQUEST operation.
REQUEST操作あたり=1をタイプしてください。
type=2 a REPLY operation.
REPLY操作あたり=2をタイプしてください。
type=3 an ALARM operation. (A high priority message.)
ALARM操作あたり=3をタイプしてください。 (高い至急メッセージ。)
type=4 a RESPONSE to an alarm operation.
1RESPONSEあたり=4をアラーム操作にタイプしてください。
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]
ポステル[23ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
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):
メッセージがタイプ1か3である(要求かアラーム)なら:
LIST ( ) (a zero length list)
リスト( )(ゼロ・レングスリスト)
If message is a type 2 or 4 (a response or response to alarm)
メッセージがタイプ2か4であるなら(驚かせる応答か応答)
LIST ( error-class, error-string ) indicates what,if any, error
occured
誤りがいくらかoccuredされたなら、LIST(誤りクラス、誤りストリング)はなにかを示すか。
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
=0: 成功、誤りがない=1は示します: 部分的な結果は戻りました。 数ステップが1つの操作で実行されるとき、この誤りのクラスは使用されています、そして、それらのいくつかが失敗します。 =2: 失敗、入手できないリソース。 =3: 失敗、ユーザ誤り。 =4: 失敗、MPM誤り。 回復可能。 =5: 失敗、MPM誤り。 致命的。 =6: 要求されたユーザアボート
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
2Syntax誤りであることは実装されなかったいいえ誤り0Command(議論3Server誤りにおけるコマンド認識されていない3Syntax誤り)は再びUserが6を中止するよう要求した後の4いいえサービス利用可能な5を試みます。
[Page 24] Postel
[24ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
command: DELIVER
コマンド: 配送してください。
type: 1
以下をタイプしてください。 1
function: Sends message to a mailbox
機能: メッセージをメールボックスに送ります。
reply: The reply is ACKNOWLEDGE
回答: 回答はACKNOWLEDGEです。
arguments: LIST ( options )
議論: リスト(オプション)
options: one or more of the following
オプション: 以下の1つ以上
"REGULAR" regular delivery
"REGULAR"定期的な配送
"FORWARD" message forwarding
"FORWARD"メッセージ推進
"GENDEL" general delivery
"GENDEL"局留め郵便
other options which may be defined later
後で定義されるかもしれない別の選択肢
argument structure:
議論構造:
LIST ( LIST ( TEXT, ... ))
リスト(リスト(テキスト、…))
Postel [Page 25]
ポステル[25ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
command: ACKNOWLEDGE
コマンド: 承認します。
type: 2
以下をタイプしてください。 2
function: reply to DELIVER
機能: DELIVERに答えてください。
arguments: LIST ( tid, trail, answer, reasons, how-delivered )
議論: リスト(tid、道(答え)が推論する、どのように、-、配送、)
tid: tid of the originating message
tid: 起因するメッセージのtid
trail: the stamp from the deliver command
以下を引きずってください。 配送コマンドからのスタンプ
answer: yes if delivered successfully,
no if error in delivery.
以下に答えてください。 首尾よく提供されるならいいえ。はい、配送における誤りであるなら。
reasons: if the answer is yes, the reason is "ok", if the answer
is no the reason could be one of "no such user", "no such host",
"no such network", "address ambiguous", or a similar response
理由: 答えがはいであるなら、理由は「間違いありません」、答えがそうなら理由、「そのようなユーザでない」、「そのようなネットワークでない」の、そして、「アドレスあいまいである」「そのようなホストでない」、または同様の応答の1つであるかもしれません。
how-delivered: one or more of the following:
どのように、-、配送、: 以下の1つ以上:
"FORWARD" message was accepted for forwarding
推進のために"FORWARD"メッセージを受け入れました。
"GENDEL" message was accepted for general delivery
局留め郵便のために"GENDEL"メッセージを受け入れました。
"ACCEPT" message was accepted for normal delivery
正常分娩のために"ACCEPT"メッセージを受け入れました。
other types of delivery may be defined later
他のタイプの配送は後で定義されるかもしれません。
argument structure:
議論構造:
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
LIST ( TEXT ),
LIST ( TEXT ))
リスト((インデックス、整数)がリストアップするリスト(整数、…)、論理演算子、リスト(テキスト)、リスト(テキスト))
[Page 26] Postel
[26ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
command: PROBE
コマンド: 徹底的調査
type: 1
以下をタイプしてください。 1
function: finds out if specified mailbox (specified in mailbox of
the command) exists at a host
機能: 指定されたメールボックス(コマンドのメールボックスの中に指定される)がホストに存在するかどうか見つけます。
reply: the reply is RESPONSE
回答: 回答はRESPONSEです。
arguments: LIST ( --none-- )
議論: リスト(--なにも--)
argument structure:
議論構造:
LIST ( )
リスト( )
Postel [Page 27]
ポステル[27ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
command: RESPONSE
コマンド: 応答
type: 2
以下をタイプしてください。 2
function: reply to PROBE
機能: PROBEに答えてください。
arguments: LIST ( tid, trail, answer, address OR reasons )
議論: リスト(tid、道、答え、アドレスOR理由)
tid: the tid which came from the originating PROBE
tid: 起因しているPROBEから来たtid
trail: the stamp which came from the originating PROBE
以下を引きずってください。 起因しているPROBEから来たスタンプ
answer: Yes if mailbox found, or no for invalid mailbox
以下に答えてください。 見つけられたメールボックス、またはいいえなら無効のメールボックスのためにはい
if answer is yes the fourth argument is address
if answer is no it is reasons
答えがはいであるなら、4番目の議論はアドレスが答えがノーであるなら推論するということです。
address: a specific address in the network
アドレス: ネットワークにおける特定のアドレス
reasons: a reason why mailbox is invalid
理由: メールボックスが無効である理由
Possible reasons include:
可能な理由は:
"Mailbox doesn't exist"
「メールボックスは存在していません」
"Mailbox full"
「メールボックス満」
"Mailbox has moved, try this new location", address
「メールボックスは、移行して、この新しい位置を試みる」アドレス
address is a new address to try
アドレスは試みる新しいアドレスです。
argument structure:
議論構造:
if answer is yes
答えがはいであるなら
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
PROPLIST )
リスト((インデックス、整数)がリストアップするリスト(整数、…)、論理演算子、PROPLIST)
if answer is no
答えがノーであるなら
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
LIST ( TEXT ))
リスト((インデックス、整数)がリストアップするリスト(整数、…)、論理演算子、リスト(テキスト))
[Page 28] Postel
[28ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
command: CANCEL
コマンド: キャンセル
type: 3
以下をタイプしてください。 3
function: abort request for specified transaction
機能: 指定されたトランザクションを求める要求を中止してください。
reply: The reply is CANCELED
回答: 回答はCANCELEDです。
arguments: LIST ( tid )
議論: リスト(tid)
tid of transaction to be cancelled
取り消されるべきトランザクションのtid
argument structure:
議論構造:
LIST ( LIST ( INDEX, INTEGER ))
リスト(リスト(インデックス、整数))
Postel [Page 29]
ポステル[29ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
command: CANCELED
コマンド: 取り消されます。
type: 4
以下をタイプしてください。 4
function: reply to CANCEL
機能: キャンセルに答えてください。
arguments: LIST ( tid, trail, answer )
議論: リスト(tid、引きずってください、そして、答えてください)
tid: tid of transaction to be cancelled
tid: 取り消されるべきトランザクションのtid
trail: the stamp of the CANCEL command
以下を引きずってください。 キャンセル命令のスタンプ
answer: yes if the command was canceled, no if not.
以下に答えてください。 はい、そうでなければ、コマンドが中止されたならいいえ。
argument structure:
議論構造:
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN )
リスト((インデックス、整数)がリストアップするリスト(整数、…)、論理演算子)
[Page 30] Postel
[30ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
To summarize again, a command consists of a LIST of the following objects:
再びaをまとめるために、コマンドは以下のオブジェクトのLISTから成ります:
name element
---- -------
mailbox PROPLIST
stamp LIST ( INTEGER, ... )
type INDEX
operation TEXT
arguments LIST ( --- )
error LIST ( INDEX, TEXT )
名前要素---- ------- メールボックスPROPLISTスタンプLIST(INTEGER、…)タイプINDEX操作TEXT議論LIST( --- )誤りLIST(インデックス、テキスト)
3.5. Document
3.5. ドキュメント
The actual document follows the command list. It contains a header which usually contains such information as From, To, Date, CC, etc.; and the actual body of the message. The message delivery system does not depend on the document. The following section should be taken as a recommendation for common practice, not as a requirement.
実際のドキュメントはコマンドリストに従います。 それは通常、From、To、Date、CCなどのような情報を含むヘッダーを含んでいます。 そして、実際のメッセージ欄。 メッセージ配送システムはドキュメントによりません。 以下のセクションは要件としてみなされるのではなく、一般的な習慣のための推薦としてみなされるべきです。
Document Header
ドキュメントヘッダー
For the same reason that it is impossible to for see the many forms
that intranet addresses will take, standardizing of document headers
would also be a mistake. The approach we suggest is to lay the
groundwork for a set of basic document header functions and provide
for enough extensibility to allow nets to add whatever header
features they desire. Features added in this fashion, however, may
not be understood by other networks. It is suggested that subset
defined here be implemented by all networks.
また、同じくらいに関しては、イントラネットアドレスが取る多くの形を見て、標準化するのに、それが不可能であるドキュメントヘッダーの理由は誤りでしょう。 私たちが勧めるアプローチは、1セットの基本的なドキュメントヘッダー機能のために土台を作って、ネットが彼らが望んでいるどんなヘッダーの特徴も加えるのを許容できるくらいの伸展性に備えることです。 しかしながら、こんなやり方で加えられた特徴は他のネットワークに解釈されないかもしれません。 ここで定義された部分集合がすべてのネットワークによって実装されることが提案されます。
This subset is taken from the current ARPANET standard for message
headers in the text oriented computer message system [6,8].
テキスト指向のコンピュータメッセージシステム[6、8]でメッセージヘッダーの現在のアルパネット規格からこの部分集合を取ります。
The document header will precede the document body portion of the
message and will consist of a proplist data element. The document
header is meant to be used by individual networks to tailor the
header to suit their individual needs. As an example, consider the
ARPA network. Typically, the receiver's name is taken to be his
network address. It often prints in the document header in just
that form: Frank@SITEX. Such a salutation is unacceptable in some
more formal modes of communication. Some network might choose to
place into header proplist the name-value pair ("SALUTATION:", "Mr.
Frank Hacker"). Upon receipt of the message, the document handling
program would then be able to scan the header proplist looking for
such a pair and so be able to correctly address the recipient by
name instead of by network address. However, other networks or
ドキュメントヘッダーは、メッセージの文書本体部分に先行して、proplistデータ要素から成るでしょう。 ドキュメントヘッダーは、彼らの個々の必要性に合うようにヘッダーを仕立てるのに個々のネットワークによって使用されることになっています。 例と、ARPAネットワークを考えてください。 通常、彼のネットワーク・アドレスになるように受信機の名前を取ります。 それはまさしくそのフォームでしばしばドキュメントヘッダーに印刷します: Frank@SITEX 。 そのような挨拶はコミュニケーションのそれ以上の正式なモードで容認できません。 何らかのネットワークが、名前価値の組をヘッダーproplistに置くのを選ぶかもしれない、(「挨拶:」、「フランクさんのハッカー」) メッセージを受け取り次第、ドキュメント処理プログラムは、そのような組を探しながらヘッダーproplistをスキャンするので、その時、ネットワーク・アドレスの代わりに名前で正しく受取人に演説できるでしょう。 またはしかしながら、もう一方がネットワークである。
Postel [Page 31]
ポステル[31ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
sites within the network may not understand such specific
information. Under such a condition it should be ignored.
ネットワークの中のサイトはそのような特殊情報を理解しないかもしれません。 そのような条件のもとでは、それは無視されるべきです。
The minimum header is a PROPLIST of the following name-value pairs:
最小のヘッダーは以下の名前価値の組のPROPLISTです:
Name Value
---- -----
DATE TEXT
FROM TEXT
名前値---- ----- テキストからの日付のテキスト
A normal header is a PROPLIST containing the following name-value
pairs:
普通のヘッダーは以下の名前価値の組を含むPROPLISTです:
Name Value
---- -----
DATE TEXT
SENDER TEXT
FROM TEXT
TO TEXT
CC TEXT
SUBJECT TEXT
名前値---- ----- テキストからテキストCCテキスト対象テキストまでの日付のテキスト送付者テキスト
Document Body
文書本体
The Body of the message is just a sequence of data elements which
contains the actual document. Much of the time this will be a
single TEXT element, but for some applications other data elements
may be utilized.
メッセージのBodyはただ実際のドキュメントを含むデータ要素の系列です。 よく、これはただ一つのTEXT要素になるでしょうが、いくつかのアプリケーションにおいて、他のデータ要素は利用されるかもしれません。
LIST ( --- )
リスト( --- )
[Page 32] Postel
[32ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
3.6. Message Structure
3.6. メッセージ構造
An internet message is composed of three parts. The first is the tid which identifies the transaction; the second is the Command List; and the third part is the Document List, which is itself comprised of a Document-Header and a Document-Body.
インターネットメッセージは3つの部品で構成されます。 1番目はトランザクションを特定するtidです。 2番目はCommand Listです。 そして、3番目の部分はDocument Listです。(そのDocument ListはDocument-ヘッダーとDocument-ボディーから成ります)。
When shipped between two MPMs, a message will take the form of a LIST:
2MPMsの間に出荷すると、メッセージはLISTの形を取るでしょう:
Message is:
メッセージは以下の通りです。
LIST ( tid, Command-List, Document-List )
リスト(tid、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.
それは、それらを一体にして1MPMから別のMPMまで出荷するので、一緒にバッチいくつかのメッセージに便利です。 メッセージのそのようなグループはメッセージバッグと呼ばれます。
A message-bag will be a LIST of Messages, each Message is of the
form described above.
メッセージバッグがMessagesのLISTになる、各Messageは上で説明されたフォームのものです。
Thus, a message-bag is:
したがって、メッセージバッグは以下の通りです。
LIST ( Message1, Message2, ... )
リスト(Message1、Message2)
Message Sharing
メッセージ共有
When messages are batched for delivery, 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
parts of the message, much repeated data would be sent if a copy of
the Mail for each recipient were to be shipped in the message-bag.
メッセージが配送のためにbatchedされるとき、しばしば同じDocumentを1人以上の受取人に送るのは、事実であるかもしれません。 メッセージの大半であると通常Document部分を予想できて、各受取人のためのメールのコピーがメッセージバッグで出荷することであるなら多くの繰り返しデータを送ります。
To avoid this redundancy, messages are assembled in the message-bag
so that actual data appears first and references to it appear later
in the message-bag. Since each message has a unique tid, the
references will indicate the tid of the actual data. In this sense,
all references to copied data may be thought of as pointing earlier
in the message-bag. The data to be retrieved can be thought of as
indexed by tid. Note that the semantics require such references to
point to data already seen.
この冗長を避けるために、メッセージがメッセージバッグで組み立てられるので、実際のデータは最初に現れます、そして、それの参照は後でメッセージバッグに現れます。 各メッセージにはユニークなtidがあるので、参照は実際のデータのtidを示すでしょう。 この意味で、コピーされたデータのすべての参照が、より早くメッセージバッグで指すと考えられるかもしれません。 tidによって索引をつけられるように検索されるべきデータは考えることができます。 意味論が既に見られたデータを示すためにそのような参照を必要とすることに注意してください。
When a portion is Shared, that portion is determined by its position
within a message, i.e., if the Command list was to be Shared, then
its position within a Message would contain the tid of the message
already seen whose Command list was identical to it. The same is
true of the Document Header and the Document Body. Only a complete
Command, Header, or Body may be Shared, never a partial one.
部分がSharedであるときに、その部分がメッセージの中で位置のそばで決定している、すなわち、CommandリストがSharedであることであるなら、Messageの中の位置は既に見られたCommandリストがそれと同じであったメッセージのtidを含んでいます。 同じくらいはDocument HeaderとDocument Bodyに関して本当です。 完全なCommand、Header、またはBodyがShared、決して部分的なものであるかもしれないだけではありません。
Postel [Page 33]
ポステル[33ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
If an encryption scheme is used, that portion of the message which
is encrypted can not be shared. This is due to the fact that
encrypting keys will be specific between two individuals.
暗号化体系が使用されているなら、暗号化されたメッセージのその部分を共有できません。 これはキーを暗号化するのが2人の個人の間で特定であるという事実のためです。
Internal Message Organization
社内通信文組織
The tid
tid
This is the transaction identifier. It is assigned by the
originating MPM.
これはトランザクション識別子です。 それは起因しているMPMによって割り当てられます。
The Command List
コマンドリスト
The command-list is a LIST which contains two elements, content
and command.
コマンドリストは2つの要素、内容、およびコマンドを含むLISTです。
Content is one item of element type INDEX. If content=0, the item
is not shared and the next element of the LIST is the command. If
content=1 the item is shared. In this case, the second element
will contain the tid of the command to share from. The tid must
be of a prior message in the current message-bag. Other values of
content may be defined later for different data structures.
内容は要素型INDEXの1つの項目です。 内容=0であるなら、項目は共有されません、そして、LISTの次の要素はコマンドです。 内容=1であるなら、項目は共有されます。 この場合、2番目の要素は共有するコマンドのtidを含むでしょう。 tidは現在のメッセージバッグの先のメッセージのものであるに違いありません。 内容の他の値は後で異なったデータ構造のために定義されるかもしれません。
Thus, command-list is:
したがって、コマンドリストは以下の通りです。
LIST ( content, tid ) if content=1
LIST(内容、tid)は内容であるなら1と等しいです。
Or,
または
LIST ( content, command ) if content=0
LIST(内容、コマンド)は内容であるなら0と等しいです。
content is:
内容は以下の通りです。
INDEX which is 0 if there is no sharing
and is 1 if sharing occurs
共有するなら、そこであるなら0が共有でないということであり、1歳であるINDEXは起こります。
tid is:
tidは以下の通りです。
the tid of the message to be shared from
共有されるメッセージのtid
command is:
コマンドは以下の通りです。
LIST ( mailbox, stamp, type, operation, arguments, error-list )
リスト(メールボックス、スタンプ、タイプ、操作、議論、エラー・リスト)
The document-list
ドキュメントリスト
The document portion of an internet message is optional and when
present is comprised of a LIST containing two elements:
インターネットメッセージのドキュメント部分は任意です、そして、現在のいつが2つの要素を含むLISTから成るか:
[Page 34] Postel
[34ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
document-list is:
ドキュメントリストは以下の通りです。
LIST ( header-list, body-list )
リスト(ヘッダーリスト、ボディーリスト)
While either the header-list or the body-list may be shared, both
elements must appear in the m.
ヘッダーリストかボディーリストのどちらかが共有されているかもしれない間、両方の要素はmに現れなければなりません。
The document-header
ドキュメントヘッダー
The header-list will be a List which will always contain two
elements. The first element will be content to indicate whether
or not the header is to be shared. The second element will either
be the tid of the header to be copied (if content=1) or it will be
the document-header (which is a PROPLIST) containing the actual
header information (if content=0). The tid must point to a
document-header already seen in the message-bag.
ヘッダーリストはいつも2つの要素を含むListになるでしょう。 ヘッダーが共有されることになっているかどうかを示して、最初の要素は満足するでしょう。 それは2番目の要素がコピーされるべきヘッダーのtidになるだろうか(内容=1であるなら)、ドキュメントヘッダーになるでしょう実際のヘッダー情報を含む(PROPLISTです)(内容=0であるなら)。 tidはメッセージバッグの既に見られたドキュメントヘッダーを示さなければなりません。
The header-list is either:
ヘッダーリストはどちらかです:
LIST ( content, tid ) if content=1
LIST(内容、tid)は内容であるなら1と等しいです。
Or,
または
LIST ( content, document-header ) if content=0
LIST(内容、ドキュメントヘッダー)は内容であるなら0と等しいです。
document-header is:
ドキュメントヘッダーは以下の通りです。
PROPLIST which contains header information
ヘッダー情報を含むPROPLIST
The document-body
文書本体
The body-list will be a LIST of two elements. The first element
will again be content, indicating whether or not the body is to be
shared. If it is shared, the second element will be tid
indicating which body to copy. This tid must be of a message
already seen in the message-bag. If content indicates no sharing,
then the second item is a document-body.
ボディーリストは2つの要素のLISTになるでしょう。 ボディーが共有されることになっているかどうかを示して、最初の要素は再び満足するでしょう。 それが共有されると、2番目の要素はどのボディーをコピーしたらよいかを示すtidになるでしょう。 このtidはメッセージバッグの既に見られたメッセージのものであるに違いありません。 内容が共有でないのを示すなら、第2項目は文書本体です。
body-list is:
ボディーリストは以下の通りです。
LIST ( content, tid ) if content=1
LIST(内容、tid)は内容であるなら1と等しいです。
Or,
または
LIST ( content, document-body ) if content=0
LIST(内容、文書本体)は内容であるなら0と等しいです。
Postel [Page 35]
ポステル[35ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
document-body is:
文書本体は以下の通りです。
LIST ( items comprising the body ... )
リスト(ボディーを包括する項目)
Message Fields
メッセージ分野
message := ( tid, command-list, document-list )
メッセージ:=(tid、コマンドリスト、ドキュメントリスト)
tid := ( tn, ihn )
tid:=(tn、ihn)
command-list := ( content, command )
コマンドリスト:=(内容、コマンド)
command := ( mailbox, stamp, type, operation,
arguments, error-list )
コマンド:=(メールボックス、スタンプ、タイプ、操作、議論、エラー・リスト)
document-list := ( header-list, body-list )
ドキュメントリスト:=(ヘッダーリスト、ボディーリスト)
header-list := ( content, document-header )
ヘッダーリスト:=(内容、ドキュメントヘッダー)
body-list := ( content, document-body )
ボディーリスト:=(内容、文書本体)
3.7. MPM Organization
3.7. mpm、組織
Introduction
序論
The heart of the internet message system is the MPM which is
responsible for routing and delivering message between the networks.
Each network must have at least one MPM. These MPMs are connected
together, and internet mail is always transferred along channels
between them. The system interfaces with the already existent local
message system.
インターネットメッセージシステムの中心は、ルーティングに責任があるMPMとネットワークの間にメッセージを送ることです。 各ネットワークには、少なくとも1MPMがなければなりません。 これらのMPMsを一緒に接続します、そして、彼らの間のチャンネルに沿っていつもインターネットメールを移します。 システムは既に目下のローカルのメッセージシステムに接続します。
Since the local network message system may be very different from
the internet system, special programs may be necessary to convert
incoming internet messages to the local format. Likewise, messages
outgoing to other networks may be converted to the internet format.
企業内情報通信網メッセージシステムがインターネットシステムと非常に異なるかもしれないので、特別なプログラムが入って来るインターネットメッセージを地方の形式に変換するのに必要であるかもしれません。 同様に、他のネットワークに送信するメッセージはインターネット形式に変換されるかもしれません。
The MPM
mpm
Messages in the internet mail system are shipped in "bags," each bag
containing one or more messages. Each bag is addressed to a
specific MPM and contains messages for the hosts on that MPM's
network.
「バッグ」、1つ以上のメッセージを含む各バッグでインターネットメールシステムのメッセージを出荷します。 各バッグは、特定のMPMに記述されて、そのMPMのネットワークのホストのためにメッセージを含んでいます。
Each MPM is expected to implement functions which will allow it to
deliver local messages it receives and to forward non-local ones to
other MPMs presumably closer to the message's destination.
各MPMがそれがそれが受け取るローカルのメッセージを渡して、おそらくメッセージの目的地の、より近くで非地方のものを他のMPMsに送る機能を実行すると予想されます。
[Page 36] Postel
[36ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
Loosely, each MPM can be separated into five components:
緩く、5つのコンポーネントに各MPMを切り離すことができます:
1--Acceptor
1--アクセプタ
Receives incoming Message-Bags, from other MPMs, from UIPs, or
from conversion programs.
他のMPMsか、UIPsか、変換プログラムから入って来るMessage-バッグを受けます。
2--Message-Bag Processor
2--メッセージバッグプロセッサ
Splits a Bag into these three portions:
これらの3への股割りa Bagは分配します:
a. Local Host Messages
b. Local Net Messages
c. Foreign Net Messages
a。 地方のHost Messages b。 地方のネットMessages c。 外国ネットのメッセージ
3--Local Net Delivery
3--地方のネットの配送
Delivers local net and local host messages, may call on
conversion program.
ローカルのネットの、そして、ローカルのホストメッセージを送って、変換プログラムを訪問するかもしれません。
4--Foreign Net Router
4--外国ネットのルータ
Creation of new Message-Bags for forwarding to other MPMs,
determines route.
新しいことの創造は、他のMPMsへの推進のためにMessage膨らんで、ルートを決定します。
5--Foreign Net Shipper
5--外国人のネットの荷主
Activates foreign shipping channels and ships Message-Bag to
foreign MPMs. Performs data compression while shipping bags.
動かす、外航海運チャンネルと船の外国へのMessage-バッグMPMsバッグを出荷している間、データ圧縮を実行します。
All of these components can be thought of as independent. Of the
five, the Acceptor, the Local-Net Delivery, and the Message-Bag
Processor are fully self-contained and communicate with each other
only through a queue, the Bag-Input Queue. The function of the
Acceptor is to await incoming Message-Bags and to insert them into
the Bag-Input Queue.
同じくらい独立していた状態でこれらのコンポーネントのすべてを考えることができます。 5では、Acceptor、LocalネットのDelivery、およびMessage-バッグProcessorは完全に自己充足的であり、単に待ち行列(Bag-入力Queue)で互いにコミュニケートします。 Acceptorの機能は、入って来るMessage-バッグを待って、Bag-入力Queueにそれらを挿入することです。
That queue is the input to the Message-Bag Processor component which
will separate and deliver suitable portions of the Message-Bags it
retrieves from the queue to one of three queues:
その待ち行列はそれが待ち行列から3つの待ち行列の1つまで検索するMessage-バッグの適当な部分を切り離して、送るMessage-バッグProcessorの部品への入力です:
a. Local-Host Queue
b. Local-Net Queue
c. Foreign Net Queue
a。 地元のホストQueue b。 ローカルのネットQueue c。 外国ネットの待ち行列
When a MPM decides to forward a message to another MPM, it must add
its own identification (i.e., its ihn) to the stamp field of the
command. The stamp then becomes a record of the route the message
MPMが、別のMPMにメッセージを転送すると決めると、それはそれ自身の識別(すなわち、ihn)をコマンドのスタンプ分野に加えなければなりません。 次に、スタンプがルートに関する記録になる、メッセージ
Postel [Page 37]
ポステル[37ページ]
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
has taken. An MPM should examine the stamp field to see if the
message is in a routing loop. Some commands require the return of
the stamp as a trail in the matching reply command.
取りました。 MPMは、メッセージがルーティング輪にあるかを確認するためにスタンプ分野を調べるはずです。 いくつかのコマンドが合っている応答コマンドにおける道としてスタンプの復帰を必要とします。
All of these queues have as elements complete Message-Bags (some of
which may have been portions of the original Bag).
これらの待ち行列のすべてには、要素として完全なMessage-バッグ(それのいくつかがオリジナルのBagの一部であったかもしれない)があります。
The Local-Host and Local-Net queues serve as input to the Local-Net
Delivery process. This component is responsible for delivering
messages to its local host and other hosts on its local net to which
it is connected. It must be capable of handling whatever error
conditions the local net might return, including the ability to
retransmit. It may call on conversion program to reformat the
messages into a form the local protocol will accept. This will
probably involve such things as copying shared information.
Local-ホストとLocal-ネット待ち行列はLocal-ネットDeliveryの過程に入力されるように役立ちます。 このコンポーネントはそれが関連しているローカルのネットをそのローカル・ホストと他のホストにメッセージを果たすのに原因となります。 それは再送する能力を含んでいて、ローカルのネットが返すどんなエラー条件も扱うことができなければなりません。 それは変換プログラムにローカルのプロトコルが受け入れるフォームへのメッセージを再フォーマットに呼ぶかもしれません。 これはたぶん共有された情報をコピーするようなものにかかわるでしょう。
The other two processes are more closely coupled. The Foreign Net
Router takes its input Bags from the Foreign Net Queue. From the
internal information it contains, it determines which one of the
MPMs to which it is connected should receive the Bag.
他の2つの過程が、より密接に結合されます。 ForeignネットRouterはForeignネットQueueから入力Bagsを取ります。 含む内部の情報から、それは、それが接続されているMPMsのどれがBagを受けるべきであるかを決定します。
It then places the Bag along with the routing information into the
Shippable Mail Queue. The Foreign Net Shipper retrieves it from
that queue and transmits it across a channel to the intended foreign
MPM.
次に、それはルーティング情報に伴うBagを「シップ-可能」に置きます。メールQueue。 ForeignネットShipperはその待ち行列からそれを検索して、チャンネルの向こう側に意図している外国MPMにそれを伝えます。
The Foreign Net Router should be capable of receiving external input
to its routing information table. This may come from the Foreign
Net Shipper in the case of a channel going down, requiring a
decision to either postpone delivery or to determine a new route.
ForeignネットRouterはルーティング情報テーブルに外部の入力を受け取ることができるべきです。 これはチャンネルが落ちる場合におけるForeignネットShipperから来るかもしれません、配送を延期するか、または新しいルートを決定するという決定を必要として。
The Router is responsible for maintaining sufficient topological
information to determine where to forward any incoming Message-Bag.
Decisions concerning the return of undeliverable Bags are made by
the Router.
Routerは何か入って来るMessage-バッグをどこに送るかを決定できるくらいの位相的な情報を保守するのに責任があります。 undeliverable Bagsの復帰に関する決定はRouterによってされます。
It should be stressed here that message delivery should be reliable.
In the event that delivery is impossible, the message should be
returned to the sender along with information regarding the reason
for not delivering it.
ここでメッセージ配送が信頼できるべきであると強調されるべきです。 配送が不可能である場合、それを届けない理由の情報に伴う送付者にメッセージを返すべきです。
Implementation Recommendations
実現推薦
Transaction numbers can be assigned sequentially with wrap around
when the highest value is reached. This should ensure that no
message with a particular transaction number from this source is in
the network when another instance of this transaction number is
chosen.
達している中で値最も高い時の周りに包装がある状態で、取引番号を連続して割り当てることができます。 これは、この取引番号の別の例が選ばれているとき、ネットワークにはこのソースからの特定の取引番号があるメッセージが全くないのを確実にするべきです。
[Page 38] Postel
[38ページ] ポステル
March 1979
Internet Message Protocol
Specification
1979年3月のインターネットメッセージプロトコル仕様
3.8. Interfaces
3.8. インタフェース
User Interface
ユーザーインタフェース
It is assumed that the interface between the MPM and the UIP
provides for passing data structures which represent the document
portion of the message. In addition this interface must pass the
delivery address information (which becomes the information in the
mailbox field of the command). It is weakly assumed that the
information is passed between the UIP and the MPM via shared files,
but this is not the only possible mechanism. These two processes
may be more strongly coupled (e.g., by sharing memory), or less
strongly coupled (e.g., by communicating via logical channels).
MPMとUIPとのインタフェースがメッセージのドキュメント部分を表すデータ構造を通過するのに提供されると思われます。 さらに、このインタフェースは配送アドレス情報(コマンドのメールボックス分野で情報になる)を通過しなければなりません。 情報がUIPとMPMの間で共有ファイルで通過されると弱々しく思われますが、これは唯一の可能なメカニズムではありません。 これらの2つの過程は、より強く結合するか(例えば、メモリを共有することによって)、またはそれほど強くなく結合できません(例えば、論理チャネルで交信することによって)。
Communication Interface
通信インターフェース
It is assumed here that the MPM use an underlying communication
system, and TCP [20] has been taken as the model. Again, this is
not intended to limit the implementation choices, other forms of
interprocess communication are allowed and other types of physical
interconnection are permitted. One might even use dial telephone
calls to interconnect MPMs (using suitable protocols to provide
reliable communication).
ここでMPMが基本的な通信系を使用すると思われて、TCP[20]はモデルとしてみなされました。 プロセス間通信の他のフォームは許容されています、そして、一方、これが実現選択を制限することを意図しないで、物理的なインタコネクトの他のタイプは受入れられます。 1つは、MPMsとインタコネクトするのにダイヤル通話を使用さえするかもしれません(信頼できるコミュニケーションを提供するのに適当なプロトコルを使用して)。
Postel [Page 39]
ポステル[39ページ]
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
[Page 40] Postel
[40ページ] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
4. EXAMPLES & SCENARIOS
4. 例とシナリオ
Example 1: Message Format
例1: メッセージ・フォーマット
Suppose we want to send the following message:
以下のメッセージを送りたいと思うと仮定してください:
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIB>
Subject: Meeting Thursday
To: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie
日付: 1979年3月29日-11時46分から8時0分From: ジョン Postel <Postel@ISIB 、gt;、Subject: 木曜日To:に間に合います。 デーヴ Crocker <DCrocker@Rand-Unix 、gt;、CC: Mamie
Dave:
デーヴ:
Please mark your calendar for our meeting Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon.
--jon。
It will be encoded in the structured format. The following will present successive steps in the top down generation of this message.
それは構造化された形式でコード化されるでしょう。 以下はこのメッセージのトップダウン世代における連続したステップを提示するでしょう。
1. message
1. メッセージ
2. ( tid, command-list, document-list )
2. (tid、コマンドリスト、ドキュメントリスト)
3. ( ( tn, ihn ),
( content, command ),
( header-list, body-list ) )
3. (tn、ihn)、(内容、コマンド)、(ヘッダーリスト、ボディーリスト)
4. ( ( tn, ihn ),
( content,
( mailbox, stamp, type, operation,
arguments, error-list ) ),
( ( content, document-header ),
( content, document-body ) ) )
4. (tn、ihn)、(満足している、ヘッダーを記録します)の(内容、(メールボックス、スタンプ、タイプ、操作、議論、エラー・リスト))(内容、文書本体)
5. ( ( 37, 167772404 ),
( 0, (
( IA: 167772359, NET: arpa, HOST: rand-unix,
USER: DCrocker ),
( 167772404 ),
1
DELIVER
( ( REGULAR ) ),
( ) ) ),
( ( 0, (
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIB>
Subject: Meeting Thursday
5. (37、167772404)、(0 (アイオワ: NET: 167772359、アルパ、HOST: USER: 底ならし革unix、DCrocker)、( 167772404 )、1DELIVER((REGULAR))、( ) ) )、(0、(日付: 11時46分から8時0分From:1979年3月29日ジョン Postel <Postel@ISIB 、gt;、Subject: 木曜日のMeeting
Postel [Page 41]
ポステル[41ページ]
March 1979
Internet Message Protocol
Examples & Scenarios
1979年3月のインターネットメッセージプロトコルの例とシナリオ
To: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
( 0, ( Dave:
To: デーヴ Crocker <DCrocker@Rand-Unix 、gt;、CC: Mamie) )、(0、(デーヴ:
Please mark your calendar for our meeting
Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon. ) ) ) )
--jon。 ) ) ) )
6. LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
6. LIST、(LIST(INDEX=37、INTEGER=167772404)、LIST、(INDEX=0、コマンドLIST、(PROPLIST(アイオワ: 167772359、NET: アルパ、メールボックスHOST: USER: 底ならし革unix、DCrocker)、LIST(INTEGER=167772404)を押し込んでください、と"DELIVER"議論INDEX=1操作TEXT=LIST(LIST(TEXTは"REGULAR"と等しい))はタイプします、エラー・リストLIST( ) ) ); LIST、(LIST、(INDEX=0、ドキュメントヘッダーPROPLIST、(日付: 11時46分から8時0分FROM:1979年3月29日ジョン Postel <Postel@ISIB 、gt;、SUBJECT: Meeting木曜日TO:デーヴ Crocker <DCrocker@Rand-Unix 、gt;、CC:Mamie)、LIST、(INDEX=0、文書本体LIST、(TEXTが等しい、「デーヴ:」
Please mark your calendar for
our meeting Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon." ) ) ) )
--"jon"。 ) ) ) )
[Page 42] Postel
[42ページ] ポステル
March 1979
Internet Message Protocol
Examples & Scenarios
1979年3月のインターネットメッセージプロトコルの例とシナリオ
Example 2: Delivery and Acknowledgment
例2: 配送と承認
The following is four views of the message of example 1 during the successive transmission from the origination MPM, through a relay MPM, to the destination MPM, and the return of the acknowledgment, through a relay MPM, to the originating MPM.
創作MPMからの連続したトランスミッションの間、↓これは例1に関するメッセージの4つの視点です、リレーMPMを通して、目的地MPM、および承認の復帰に、リレーMPMを通して、由来しているMPMに。
+-----------------------------------------------------------------+ ! 1 2 ! ! sending --> originating --> relay --> destination --> receiving ! ! user MPM MPM MPM user ! ! ! ! 4 3 ! ! originating <-- relay <-- destination ! ! MPM MPM MPM ! +-----------------------------------------------------------------+
+-----------------------------------------------------------------+ 1 2!発信(>の起因する)>リレー-->の目的地-->受信!ユーザMPM MPM MPMユーザ!4 3!起因する<--リレー<--目的地!MPM MPM MPM!+-----------------------------------------------------------------+
Transmission Path
トランスミッション経路
Figure 6.
図6。
Postel [Page 43]
ポステル[43ページ]
March 1979
Internet Message Protocol
Examples & Scenarios
1979年3月のインターネットメッセージプロトコルの例とシナリオ
1. Between the originating MPM and the relay MPM.
1. 起因しているMPMとリレーMPMの間で。
LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
LIST、(LIST(INDEX=37、INTEGER=167772404)、LIST、(INDEX=0、コマンドLIST、(PROPLIST(アイオワ: 167772359、NET: アルパ、メールボックスHOST: USER: 底ならし革unix、DCrocker)、LIST(INTEGER=167772404)を押し込んでください、と"DELIVER"議論INDEX=1操作TEXT=LIST(LIST(TEXTは"REGULAR"と等しい))はタイプします、エラー・リストLIST( ) ) ); LIST、(LIST、(INDEX=0、ドキュメントヘッダーPROPLIST、(日付: 11時46分から8時0分FROM:1979年3月29日ジョン Postel <Postel@ISIB 、gt;、SUBJECT: Meeting木曜日TO:デーヴ Crocker <DCrocker@Rand-Unix 、gt;、CC:Mamie)、LIST、(INDEX=0、文書本体LIST、(TEXTが等しい、「デーヴ:」
Please mark your calendar for
our meeting Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon." ) ) ) )
--"jon"。 ) ) ) )
The originating MPM sends the message of example 1 to a relay MPM.
起因しているMPMは例1に関するメッセージをリレーMPMに送ります。
[Page 44] Postel
[44ページ] ポステル
March 1979
Internet Message Protocol
Examples & Scenarios
1979年3月のインターネットメッセージプロトコルの例とシナリオ
2. Between the relay MPM and the destination MPM.
2. リレーMPMと目的地MPMの間で。
LIST( LIST( INDEX=37, INTEGER=167772404 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772359,
NET: arpa,
mailbox HOST: rand-unix,
USER: DCrocker ),
stamp LIST( INTEGER=167772404,
INTEGER=167772246 ),
type INDEX=1
operation TEXT="DELIVER"
arguments LIST( LIST( TEXT="REGULAR" )),
error-list LIST( ) ) ),
LIST( LIST( INDEX=0,
document-header PROPLIST(
DATE: 1979-03-29-11:46-08:00
FROM: Jon Postel <Postel@ISIB>
SUBJECT: Meeting Thursday
TO: Dave Crocker <DCrocker@Rand-Unix>
CC: Mamie ) ),
LIST( INDEX=0,
document-body LIST( TEXT=
"Dave:
LIST、(LIST(INDEX=37、INTEGER=167772404)、LIST、(INDEX=0、コマンドLIST、(PROPLIST(アイオワ: 167772359、NET: アルパ、メールボックスHOST: USER: 底ならし革unix、DCrocker)、LIST(INTEGER=167772404、INTEGER=167772246)を押し込んでください、と"DELIVER"議論INDEX=1操作TEXT=LIST(LIST(TEXTは"REGULAR"と等しい))はタイプします、エラー・リストLIST( ) ) ); LIST、(LIST、(INDEX=0、ドキュメントヘッダーPROPLIST、(日付: 11時46分から8時0分FROM:1979年3月29日ジョン Postel <Postel@ISIB 、gt;、SUBJECT: Meeting木曜日TO:デーヴ Crocker <DCrocker@Rand-Unix 、gt;、CC:Mamie)、LIST、(INDEX=0、文書本体LIST、(TEXTが等しい、「デーヴ:」
Please mark your calendar for
our meeting Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon." ) ) ) )
--"jon"。 ) ) ) )
The relay MPM adds its ihn to the stamp, but otherwise the message
is unchanged.
リレーMPMはスタンプにihnを加えますが、さもなければ、メッセージは変わりがありません。
Postel [Page 45]
ポステル[45ページ]
March 1979
Internet Message Protocol
Examples & Scenarios
1979年3月のインターネットメッセージプロトコルの例とシナリオ
3. Between the destination MPM and the relay MPM.
3. 目的地MPMとリレーMPMの間で。
LIST( LIST( INDEX=1993, INTEGER=167772359 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772404,
mailbox USER: *MPM* ),
stamp LIST( INTEGER=167772359 ),
type INDEX=2
operation TEXT="ACKNOWLEDGE"
arguments LIST( LIST( INDEX=37,
tid INTEGER=167772404 ),
LIST( INTEGER=167772404,
trail INTEGER=167772246,
INTEGER=167772359 ),
answer BOOLEAN=TRUE,
reason LIST( TEXT="OK" ),
how-delivered LIST( TEXT="ACCEPT" ) ),
error-list LIST( INDEX=0,
TEXT="No Errors") ),
document LIST( ) )
リスト、((1993、インデックス=整数=167772359)を記載してください、そして、記載してください。PROPLIST(アイオワ: 167772404、メールボックスUSER: *MPM*)、LIST(INTEGER=167772359)を押し込んでください、と"ACKNOWLEDGE"議論INDEX=2操作TEXT=LISTはタイプします。(INDEX=0、コマンドLIST、((LIST(INDEX=37、tid INTEGER=167772404)(LIST(INTEGER=167772404、道のINTEGER=167772246、INTEGER=167772359))はブール=TRUEに答えます、理由LIST(TEXTは「OK」と等しい)、どのように、-、配送、LIST(TEXTは"ACCEPT"と等しいです)(エラー・リストLIST(INDEX=0、TEXTは「Errorsがありません」と等しい))はLIST( ) )を記録するか。
The destination MPM delivers the message to the user's UIP, and
composes an acknowledgment. The acknowledgment is addressed to
the originating MPM. Note that the trail is the stamp of the
incoming message plus the ihn of the destination MPM.
目的地MPMはユーザのUIPにメッセージを提供して、承認を構成します。 承認は起因しているMPMに扱われます。 道が入力メッセージのスタンプと目的地MPMのihnであることに注意してください。
[Page 46] Postel
[46ページ] ポステル
March 1979
Internet Message Protocol
Examples & Scenarios
1979年3月のインターネットメッセージプロトコルの例とシナリオ
4. Between the relay MPM and the originating MPM.
4. リレーMPMと起因しているMPMの間で。
LIST( LIST( INDEX=1993, INTEGER=167772359 ),
LIST( INDEX=0,
command LIST( PROPLIST( IA: 167772404,
mailbox USER: *MPM* ),
stamp LIST( INTEGER=167772359
INTEGER=167772246),
type INDEX=2
operation TEXT="ACKNOWLEDGE"
arguments LIST( LIST( INDEX=37,
tid INTEGER=167772404 ),
LIST( INTEGER=167772404,
trail INTEGER=167772246,
INTEGER=167772359 ),
answer BOOLEAN=TRUE,
reason LIST( TEXT="OK" ),
how-delivered LIST( TEXT="ACCEPT" ) ),
error-list LIST( INDEX=0,
TEXT="No Errors") ),
document LIST( ) )
リスト、((1993、インデックス=整数=167772359)を記載してください、そして、記載してください。PROPLIST(アイオワ: 167772404、メールボックスUSER: *MPM*)、LIST(INTEGER=167772359 INTEGER=167772246)を押し込んでください、と"ACKNOWLEDGE"議論INDEX=2操作TEXT=LISTはタイプします。(INDEX=0、コマンドLIST、((LIST(INDEX=37、tid INTEGER=167772404)(LIST(INTEGER=167772404、道のINTEGER=167772246、INTEGER=167772359))はブール=TRUEに答えます、理由LIST(TEXTは「OK」と等しい)、どのように、-、配送、LIST(TEXTは"ACCEPT"と等しいです)(エラー・リストLIST(INDEX=0、TEXTは「Errorsがありません」と等しい))はLIST( ) )を記録するか。
The relay MPM adds its ihn to the stamp and forwards the
acknowledgment.
リレーMPMはスタンプにihnを加えて、承認を送ります。
Postel [Page 47]
ポステル[47ページ]
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
[Page 48] Postel
[48ページ] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
GLOSSARY
用語集
1822
BBN Report 1822, "The Specification of the Interconnection of
a Host and an IMP". The specification of interface between a
host and the ARPANET.
1822BBNは1822、「ホストと悪童のインタコネクトの仕様」を報告します。 ホストとアルパネットとのインタフェースの仕様。
Command List
The part of a message used by the MPMs to determine the
processing action to be taken.
MPMsによって使用されたメッセージの部分のListが、処理行動が取られることを決定すると命令してください。
datagram
A logical unit of data, in particular an internet datagram is
the unit of data transfered between the internet module and a
higher level module.
データのデータグラムA論理装置、インターネットデータグラムは特に、インターネットモジュールと、より高い平らなモジュールの間でtransferedされたデータのユニットです。
Destination
The destination address, an internet header datagram protocol
field.
目的地が扱う目的地、インターネットヘッダーデータグラムプロトコル分野。
Document List
The part of the message created by or delivered to a user.
ユーザに作成されたメッセージの部分のListを記録するか、または配送してください。
header
Control information at the beginning of a message, segment,
datagram, packet or block of data.
データのメッセージ、セグメント、データグラム、パケットまたは1ブロックの始めのヘッダーControl情報。
IMP
The Interface Message Processor, the packet switch of the
ARPANET.
IMP Interface Message Processor、アルパネットのパケット交換機。
Internet Address
A four octet (32 bit) source or destination address consisting
of a Network field and a Local Address field.
インターネットAddress A four八重奏(32ビット)ソースかNetwork分野とLocal Address分野から成る送付先アドレス。
internet datagram
The unit of data exchanged between a pair of internet modules
(includes the internet header).
データのユニットが1組のインターネットモジュール(インターネットヘッダーを含んでいる)の間で交換したインターネットデータグラム。
Local Address
The address of a host within a network. The actual mapping of
an internet local address on to the host addresses in a
network is quite general, allowing for many to one mappings.
aのアドレスがネットワークの中で接待する地方のAddress。 ネットワークにおけるホスト・アドレスへのインターネットローカルアドレスの実際のマッピングはかなり一般的です、多くを1つのマッピングまで考慮して。
Postel [Page 49]
ポステル[49ページ]
March 1979
Internet Message Protocol
Glossary
1979年3月のインターネットメッセージプロトコル用語集
message
The unit of information transmitted between users of message
systems. As transmitted between MPMs a message consists of a
Transaction Identifier, a Command List, and a Document List.
情報のユニットはメッセージシステムのユーザの間で送られました。メッセージがMPMsの間に伝えられるようにTransaction Identifier、Command List、およびDocument Listから成るというメッセージ。
module
An implementation, usually in software, of a protocol or other
procedure.
通常プロトコルか他の手順のソフトウェアのモジュールAn実装。
MPM
A Message Processing Module, the process which implements this
internet message protocol.
MPM A Message Processing Module、このインターネットメッセージプロトコルを実装するプロセス。
octet
An eight bit byte.
八重奏An eightはバイトに噛み付きました。
Rest
The 3 octet (24 bit) local address portion of an Internet
Address.
インターネットAddressの3八重奏(24ビット)ローカルアドレス一部を休ませてください。
RTP
Real Time Protocol: A host-to-host protocol for communication
of time critical information.
RTPのリアルタイムのプロトコル: 時間重要情報に関するコミュニケーションのためのホスト間プロトコル。
Source
The source address, an internet header field.
ソースが演説するソース、インターネットヘッダーフィールド。
TCP
Transmission Control Protocol: A host-to-host protocol for
reliable communication in internetwork environments.
TCP通信制御プロトコル: インターネットワーク環境における信頼できるコミュニケーションのためのホスト間プロトコル。
Transaction Identifier
The unique identifier of a message.
aのユニークな識別子が通信させるトランザクションIdentifier。
Type of Service
An internet datagram protocol header field which indicates the
type (or quality) of service for this internet packet.
Service Anインターネットデータグラムのタイプはこのインターネットパケットのためのサービスのタイプ(または、品質)を示すヘッダーフィールドについて議定書の中で述べます。
UIP
A User Interface Program, a program which presents message
data to a user and accepts message data from a user. A
program which interacts with the user in the composition and
examination of messages.
UIP A User Interface Program(メッセージデータをユーザに提示して、ユーザからメッセージデータを受け入れるプログラム)。 メッセージの構成と調査でユーザと対話するプログラム。
XNET
A cross-net debugging protocol.
XNETのA十字ネットのデバッグプロトコル。
[Page 50] Postel
[50ページ] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
REFERENCES
参照
[1] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192,
February 1979.
1979年2月の[1] バーバー、D.とJ.法、「EINの基本的なメール体系」INWG192。
[2] Bhushan, A., K. Progran, R. Tomlinson, and J. White,
"Standardizing Network Mail Headers," RFC 561, NIC 18516, 5
September 1973.
[2]Bhushan、A.、K.Progran、R.トムリンスン、およびJ.ホワイト、「ネットワークメールヘッダを標準化します」、RFC561、NIC18516(1973年9月5日)。
[3] Bolt Beranek and Newman, "Specification for the Interconnection of
a Host and an IMP," BBN Technical Report 1822, May 1978 (Revised).
[3] Beranek、ニューマン、および「ホストのインタコネクトのための仕様と悪童」をボルトで締めてください、BBN技術報告書1822、1978(改訂される)年5月。
[4] Braaten, O., "Introduction to a Mail Protocol," Norwegian
Computing Center, INWG 180, August 1978.
[4]Braaten、O.、「メールプロトコルへの序論」、ノルウェーの計算機センタ、INWG180、1978年8月。
[5] Cerf, V., "The Catenet Model for Internetworking," Information
Processing Techniques Office, Defense Advanced Research Projects
Agency, IEN 48, July 1978.
[5] サーフ、V.、「Catenetはインターネットワーキングのためにモデル化します」、情報処理テクニックオフィス、国防高等研究計画庁、IEN48、1978年7月。
[6] Crocker, D., J. Vittal, K. Progran, and D. Henderson, "Standard
for the Format of ARPA Network Text Messages," RFC 733, NIC 41952,
21 November 1977.
[6] クロッカー、D.、J.Vittal、K.Progran、およびD.ヘンダーソン、「アーパネットテキスト・メッセージの形式の規格」、RFC733、NIC41952(1977年11月21日)。
[7] Crocker, D., E. Szurkowski, and D. Farber, "Components of a
Channel-independent Memo Transmission System," Department of
Electrical Engineering, University of Delaware,, February 1979.
電気工学の[7] クロッカーとD.、E.SzurkowskiとD.ファーバー、「チャンネルから独立しているメモ伝動装置の部品」部、1979年2月のデラウエア大学
[8] Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook,"
NIC 7104, for the Defense Communications Agency by the Network
Information Center of SRI International, Menlo Park, California,
Revised January 1978.
[8] Feinler、E.、およびJ.ポステル(eds)、「アルパネットはハンドブックについて議定書の中で述べます」、NIC7104、SRIインターナショナルのNetworkインフォメーション・センターによるDefense Communications Agencyのために、メンローパーク(カリフォルニア)Revised1978年1月。
[9] Harrenstien, K., "Field Addressing," ARPANET Message, SRI
International, October 1977.
[9]Harrenstien、K.、「分野アドレシング」、アルパネットメッセージ、SRIインターナショナル、1977年10月。
[10] Haverty, J., "MSDTP -- Message Services Data Transmission
Protocol," RFC 713, NIC 34739, April 1976.
[10]Haverty、J.、「MSDTP--サービスデータ伝送プロトコルを通信する」RFC713、NIC34739、1976年4月。
[11] Haverty, J., "Thoughts on Interactions in Distributed Services,"
RFC 722, NIC 36806, 16 September 1976.
[11]Haverty、J.、「分配されたサービスにおける相互作用に関する考え」、RFC722、NIC36806、1976年9月16日。
[12] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed
Specification of an Inter-site Message Protocol," 8 July 1975.
[12]Haverty、J.、D.ヘンダーソン、およびD.Oestreicher、「相互サイトメッセージプロトコルの提案された仕様」、1975年7月8日。
[13] ISO-2014, "Writing of calendar dates in all-numeric form,"
Recommendation 2014, International Organization for
Standardization, 1975.
[13] ISO-2014「オール数値のフォームにカレンダ日付を主題にして書く」Recommendation2014、国際標準化機構1975。
Postel [Page 51]
ポステル[51ページ]
March 1979
Internet Message Protocol
References
1979年3月インターネットメッセージプロトコル参照箇所
[14] ISO-3307, "Information Interchange -- Representations of time of
the day," Recommendation 3307, International Organization for
Standardization, 1975.
[14] ISO-3307、「情報Interchange--、1日の時間の表現、」、Recommendation3307、国際標準化機構1975
[15] ISO-4031, "Information Interchange -- Representation of local time
differentials," Recommendation 4031, International Organization
for Standardization, 1978.
[15] ISO-4031、「情報Interchange--、現地時間のデフ装置の表現、」、Recommendation4031、国際標準化機構1978
[16] Myer, T., and D. Henderson, "Message Transmission Protocol,"
RFC 680, NIC 32116, 30 April 1975.
[16] マイヤー、T.とD.ヘンダーソン、「メッセージトランスミッションプロトコル」、RFC680、NIC32116、1975年4月30日。
[17] Postel, J. "Internetwork Datagram Protocol, Version 4," USC
Information Sciences Institute, IEN 80, February 1979.
[17] IEN80、USC情報科学はJ. ポステル、「インターネットワークデータグラムプロトコル、バージョン4」と設けて、2月は1979です。
[18] Postel, J. "NSW Data Representation (NSWB8)," IEN 39, May 1978.
[18] ポステル(J.「NSWデータ表現(NSWB8)」、IEN39)は1978がそうするかもしれません。
[19] Postel, J. "NSW Transaction Protocol (NSWTP)," IEN 38, May 1978.
[19] ポステル(J.「NSWトランザクションプロトコル(NSWTP)」、IEN38)は1978がそうするかもしれません。
[20] Postel, J. "Transmission Control Protocol, TCP, Version 4," USC
Information Sciences Institute, IEN 81, February 1979.
[20] IEN81、USC情報科学はJ. ポステル、「通信制御プロトコル、TCP、バージョン4」と設けて、2月は1979です。
[21] Postel, J., "Assigned Numbers," RFC 750, NIC 45500,
26 September 1978.
[21] ポステル、J.、「規定番号」、RFC750、NIC45500、1978年9月26日。
[22] Postel, J., "Message System Transition Plan," JBP 64,
USC-Information Sciences Institute, February 1979.
[22] ポステル、J.、「メッセージシステム変遷プラン」、JBP64、USC-情報科学研究所、1979年2月。
[23] Rivest, R. L. "A Method for Obtaining Digital Signatures and
Public-Key Cryptosystems" Communications of the ACM, Vol. 21,
Number 2, February 1978.
[23] ACM、Vol.21、No.2(1978年2月)の最もRivestな「デジタル署名と公開鍵暗号系を得るためのメソッド」R.L.コミュニケーション。
[24] Shoch, J., "A Note On Inter-Network Naming, Addressing, and
Routing," Xerox Palo Alto Research Center, IEN 19, January 1978.
[24]Shoch、J.、「インターネットワーク命名、アドレシング、およびルート設定に関する注」、ゼロックスパロアルト研究センター、IEN19、1978年1月。
[25] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW
Working Note 24, Bolt Beranek and Newman, October 1978.
[25] BBN NSWが注意24を扱って、「メールサービスをNSWユーザに提供し」て、トーマス、R.はBeranekとニューマン、1978年10月をボルトで締めます。
[26] White, J., "A Proposed Mail Protocol," RFC 524, NIC 17140, 13 June
1973.
[26] ホワイト、J.、「提案されたメールプロトコル」、RFC524、NIC17140、1973年6月13日。
[27] White, J., "Description of a Multi-Host Journal," NIC 23144,
30 May 1974.
[27] ホワイト、J.、「マルチホストジャーナルの記述」、NIC23144、1974年5月30日。
[28] White, J., "Journal Subscription Service," NIC 23143, 28 May 1974.
[28] ホワイト、J.、「ジャーナル購読サービス」、NIC23143、1974年5月28日。
[Page 52] Postel
[52ページ] ポステル
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
APPENDICES
付録
A. Encryption
A。 暗号化
It would be straightforward to add the capability to have the document portion of messages either wholly or partially encrypted. The approach is to define an additional basic data element to carry encrypted data. The data within this element could be composed of other elements, but that could only be perceived after the data was decrypted.
それは、完全にメッセージのドキュメント部分を持つ能力を加えるために簡単であるか部分的に暗号化されているでしょう。 アプローチは暗号化されたデータを運ぶために追加基礎データ要素を定義することです。 他の要素でこの要素の中のデータを構成できましたが、データが解読された後にそれを知覚できただけです。
+------+------+------+------+-------
9 Encrypt ! 9 ! octet count ! Data ...
+------+------+------+------+--------
+------+------+------+------+------- 9 9!八重奏カウント!Dataを暗号化してください… +------+------+------+------+--------
Element code 9 (ENCRYPT) is Encrypt. The format is the one octet type code, the three octet type count, and count octets of data. Use of this element indicates that the data it contains is encrypted. The encryption scheme is yet to be decided but will probably be the Public Key Encryption technique [23] due to the capacity for coded signatures.
要素コード9(ENCRYPT)はEncryptです。 形式は、データの3つの1つの八重奏タイプコードと、八重奏タイプカウントと、カウント八重奏です。 この要素の使用は、それが含むデータが暗号化されているのを示します。 暗号化体系は、まだ決められていませんが、コード化された署名のための容量でたぶんPublic Key Encryptionのテクニックにな[23]るでしょう。
To process this, the user is asked for the appropriate key the first time an encryption block is seen for a particular message. The encrypted data is then decrypted. The data thus revealed will be in the form of complete data type fields. Encryption cannot occur over a partial field. The revealed data is then processed normally.
これを処理するために、暗号化ブロックが初めて特定のメッセージに関して見られるとき、適切なキーをユーザに求めます。 そして、暗号化されたデータは解読されます。 このようにして明らかにされたデータが完全なデータ型分野の形にあるでしょう。 暗号化は部分的な分野の上に起こることができません。 そして、通常、明らかにされたデータは処理されます。
Note that there is no reason why all fields of a document could not be encrypted including all document header information such as From, Date, etc.
From、Dateなどのすべてのドキュメントヘッダー情報を含んでいて、ドキュメントのすべての分野を暗号化できたというわけではない理由が全くないことに注意してください。
Postel [Page 53]
ポステル[53ページ]
March 1979
Internet Message Protocol
Appendices
1979年3月インターネットメッセージプロトコル付録
B. Data Compression
B。 データ圧縮
When message-bags are shipped between MPMs the data should be compressed according to the following scheme:
メッセージバッグをMPMsの間に出荷するとき、以下の体系通りにデータを圧縮するべきです:
shipping-unit := compression-type message-bag
出荷ユニット:=圧縮タイプメッセージバッグ
compression-type := A one octet compression type indicator.
1つの八重奏の圧縮がタイプする圧縮タイプ:=インディケータ。
compression-type value description
---------------------- -----------
0 no compression used
1 basic compression
圧縮タイプ値の記述---------------------- ----------- 0 圧縮中古の1の基本的な圧縮がありません。
basic compression
基本的な圧縮
This basic compression procedure is the same as that defined for
use with the ARPANET FTP [8]. Three types of compression-units
may be formed, sequence-units, replication-units, and
filler-units. The data is formed into a series of
compression-units independent of the structure or object and
element boundaries.
この基本的な圧縮手順はアルパネットFTP[8]との使用のために定義されたそれと同じです。 3つのタイプの圧縮単位は、形成されて、ユニットを配列している模写ユニットと、フィラーユニットであるかもしれません。 データは構造かオブジェクトと要素限界の如何にかかわらず一連の圧縮ユニットに形成されます。
sequence-unit
系列単位
A sequence-unit is a one octet flag and count followed by that
many data octets.
系列単位は、そんなに多くのデータ八重奏がいうことになった1個の八重奏旗とカウントです。
+-+-------+--------+--------+----
!0! n ! n data octets ...
+-+-------+--------+--------+----
+-+-------+--------+--------+---- n! 0! nデータ八重奏… +-+-------+--------+--------+----
The flag and count octet has its high order bit zero and the
remaining bits indicate the count (in the range 0 to 127) of
following data octets.
旗とカウント八重奏で、高位のビットゼロと残っているビットはデータ八重奏に続くカウント(範囲0〜127の)を示します。
replication-unit
模写ユニット
A replication-unit is a one octet flag and count followed by one
data octet, which is to be replicated count times.
模写ユニットは、模写されたカウント時間であることである1つのデータ八重奏がいうことになった1個の八重奏旗とカウントです。
+--+------+--------+
!10! n ! data !
+--+------+--------+
+--+------+--------+! 10! n!データ!+--+------+--------+
The flag and count octet has its high order two bits equal
one-zero and the remaining six bits indicate the count (in the
range 0 to 63) of number of time to replicate the data octet.
旗とカウント八重奏で、2ビットの高位の等しいもの-ゼロと残っている6ビットはデータ八重奏を模写する時間の数のカウント(範囲0〜63の)を示します。
[Page 54] Postel
[54ページ] ポステル
March 1979
Internet Message Protocol
Appendices
1979年3月インターネットメッセージプロトコル付録
filler-unit
フィラーユニット
A filler-unit is a one octet flag and count, indicating that a
filler octet is to be inserted count times.
フィラー八重奏が挿入されたカウント時間であることであることを示して、フィラーユニットは、1個の八重奏旗とカウントです。
+--+------+
!11! n !
+--+------+
+--+------+! 11! n!+--+------+
The flag and count octet has its high order two bits equal
one-one and the remaining six bits indicate the count (in the
range 0 to 63) of number of time to insert the filler octet.
旗とカウント八重奏で、2ビットの高位の等しいもの-1と残っている6ビットはフィラー八重奏を挿入する時間の数のカウント(範囲0〜63の)を示します。
The filler octet is zero, the octet with all bits zero.
フィラー八重奏はゼロ、ビットが合っているゼロすべてがある八重奏です。
Postel [Page 55]
ポステル[55ページ]
March 1979
Internet Message Protocol
1979年3月のインターネットメッセージプロトコル
[Page 56] Postel
[56ページ] ポステル
一覧
スポンサーリンク
