RFC759 日本語訳
0759 Internet Message Protocol. J. Postel. August 1980. (Format: TXT=123606 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
IEN: 113 RFC: 759
IEN: 113RFC: 759
INTERNET MESSAGE PROTOCOL
インターネットメッセージプロトコル
Jonathan B. Postel
ジョナサン・B.ポステル
August 1980
1980年8月
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
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
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. Model of Operation ........................................... 2 1.5. Interfaces ................................................... 4
1.1. 動機… 1 1.2. 範囲… 1 1.3. インターネットワーク環境… 2 1.4. 操作のモデル… 2 1.5. インタフェース… 4
2. FUNCTIONAL DESCRIPTION ........................................... 5
2. 機能的な記述… 5
2.1. Terminology .................................................. 5 2.2. Assumptions ................................................. 5 2.3. General Specification ........................................ 6 2.4. Mechanisms ................................................... 7 2.5. Relation to Other Protocols ................................. 10
2.1. 用語… 5 2.2. 仮定… 5 2.3. 一般仕様… 6 2.4. メカニズム… 7 2.5. 他のプロトコルとの関係… 10
3. DETAILED SPECIFICATION .......................................... 13
3. 詳細な仕様… 13
3.1. Overview of Message Structure ............................... 13 3.2. Message Structure ........................................... 14 3.3. Identification .............................................. 15 3.4. Command ..................................................... 15 3.5. Document .................................................... 19 3.6. Message Objects ............................................. 20 3.7. Data Elements ............................................... 27
3.1. メッセージ構造の概要… 13 3.2. メッセージ構造… 14 3.3. 識別… 15 3.4. 命令してください… 15 3.5. 記録します。 19 3.6. メッセージオブジェクト… 20 3.7. データ要素… 27
4. OTHER ISSUES .................................................... 35
4. 他の問題… 35
4.1. Accounting and Billing ...................................... 35 4.2. Addressing and Routing ...................................... 36 4.3. Encryption .................................................. 37
4.1. 説明して、請求します。 35 4.2. アドレシングとルート設定… 36 4.3. 暗号化… 37
5. The MPM: A Possible Architecture ............................... 39
5. mpm: 可能なアーキテクチャ… 39
5.1. Interfaces .................................................. 39 5.2. MPM Organization ............................................ 40
5.1. インタフェース… 39 5.2. mpm、組織… 40
6. EXAMPLES & SCENARIOS ............................................ 45
6. 例とシナリオ… 45
Example 1: Message Format ........................................ 45 Example 2: Delivery and Acknowledgment ........................... 47
例1: メッセージ形式… 45 例2: 配送と承認… 47
Postel [Page i]
ポステル[ページi]
August 1980
Internet Message Protocol
Table Of Contents
1980年8月のインターネットメッセージプロトコル目次
7. SPECIFICATION SUMMARY ........................................... 55
7. 仕様概要… 55
7.1. Message Fields .............................................. 55 7.2. Deliver Message ............................................. 58 7.3. Acknowledge Message ......................................... 59 7.4. Probe Message ............................................... 61 7.5. Response Message ............................................ 62 7.6. Cancel Message .............................................. 64 7.7. Canceled Message ............................................ 66 7.8. Data Element Summary ........................................ 68
7.1. メッセージ分野… 55 7.2. メッセージを提供してください… 58 7.3. メッセージを承認してください… 59 7.4. メッセージを調べてください… 61 7.5. 応答メッセージ… 62 7.6. メッセージを取り消してください… 64 7.7. メッセージを取り消します… 66 7.8. データ要素概要… 68
REFERENCES .......................................................... 69
参照… 69
[Page ii] Postel
[ページii] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
PREFACE
序文
This is the second edition of this specification and should be treated as a request for comments, advice, and suggestions. A great deal of prior work has been done on computer aided message systems and some of this is listed in the reference section. This specification was shaped by many discussions with members of the ARPA research community, and others interested in the development of computer aided message systems. This document was prepared as part of the ARPA sponsored Internetwork Concepts Research Project at ISI, with the assistance of Greg Finn, Suzanne Sluizer, Alan Katz, Paul Mockapetris, and Linda Sato.
これは、この仕様の第2版であり、コメント、アドバイス、および提案のために要求として扱われるべきです。 コンピュータの支援されたメッセージシステムの上で大きな先の仕事をしました、そして、参照部でこの或るものを記載します。 この仕様はARPA研究団体のメンバーとの多くの議論で形成されました、そして、コンピュータの開発に興味を持っている他のものはメッセージシステムを支援しました。ARPAの一部がISIでInternetwork Concepts Research Projectを後援したとき、このドキュメントは準備されました、グレッグフィンランド人の支援、スザンヌSluizer、アラン・キャッツ、ポールMockapetris、およびリンダ・佐藤と共に。
Jon Postel
ジョン・ポステル
Postel [Page iii]
ポステル[ページiii]
IEN: 113 J. Postel
RFC: 759 USC-ISI
August 1980
IEN: 113 J.ポステルRFC: 759 USC-ISI1980年8月
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 delivery 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 delivery system in its own right.
コンピュータのサポートしているメッセージ処理活動が個々のホストコンピュータの上と、そして、コンピュータのネットワークにに生えているとき、そのようなシステムをインタコネクトと織り込むことに備える自然な願望があります。この仕様は汎用のインターネットワークメッセージシステムの形式と手順について説明します。(個々のメッセージシステムのインタコネクトの規格として、または、メッセージ配送システムとしてそれ自体でシステムを使用できます)。
This system also provides for the communication of data items beyond the scope of contemporary message systems. Messages can include data objects which could represent drawings, or facsimile images, or digitized speech. One can imagine message stations equipped with speakers and microphones (or telephone hand sets) where the body of a message or a portion of it is recorded digitized speech. The output terminal could include a graphics display, and the message might present a drawing on the display, and verbally (via the speaker) describe certain features of the drawing. This specification provides for the composition of complex data objects and their encoding in machine independent basic data elements.
また、このシステムは現代のメッセージシステムの範囲を超えてデータ項目に関するコミュニケーションに備えます。メッセージは図面を表したか、イメージを電送できた、またはスピーチをデジタル化したデータ・オブジェクトを含むことができます。 人は、メッセージステーションがスピーカーに持たせて、メッセージのボディーかそれの部分が記録されているマイクロホン(または、電話ハンド・セット)がスピーチをデジタル化したと想像できます。 出力端末がグラフィックスディスプレイを含むかもしれなくて、メッセージは、ディスプレイでの図面を贈って、口頭で図面のある特徴について説明するかもしれません(スピーカーを通して)。 この仕様は、複雑なデータ・オブジェクトの構成とマシンで独立している基礎データ要素をコード化するのに備えます。
1.2. Scope
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
ネットワークの間のメッセージの伝達にインターネットMessageプロトコルが使用されることを意図します。 また、それはネットワークかホストのローカルのメッセージシステムに使用されるかもしれません。 この仕様はそうでした。
Postel [Page 1]
ポステル[1ページ]
August 1980
Internet Message Protocol
Introduction
1980年8月のインターネットメッセージプロトコル序論
developed in the context of the ARPA work on the interconnection of networks, but it is thought that it has a more general scope.
ネットワークのインタコネクトに対するARPA仕事の文脈で開発されています、唯一のそれは、より一般的な範囲を持っているという考えです。
The focus here is on the internal mechanisms to transmit messages, rather than the external interface to users. It is assumed that a number of user interface programs will exist. These will be both new programs designed to work with this system and old programs designed to work with earlier systems.
外部のインタフェースよりむしろメッセージをユーザに送るために、内部のメカニズムの上にここの焦点はあります。 多くのユーザーインタフェースプログラムが存在すると思われます。 これらはこのシステムと古いプログラムが以前のシステムで働くように設計されている状態で働くように設計された両方の新プログラムになるでしょう。
1.3. The Internetwork Environment
1.3. インターネットワーク環境
The internetwork message environment consists of processes which run in hosts which are connected to networks which are interconnected by gateways. Each network consists of many different hosts. The networks are tied together through gateways. The gateways are essentially hosts on two (or more) networks and are not assumed to have much storage capacity or to "know" which hosts are on the networks to which they are attached [1,2].
インターネットワークメッセージ環境はホストに立候補するプロセスから成ります(ゲートウェイによってインタコネクトされるネットワークに関連づけられます)。 各ネットワークは多くの異なったホストから成ります。 ネットワークはゲートウェイを通して結びつけられます。 ゲートウェイは、本質的には2つ(さらに)のネットワークのホストであり、多くの記憶容量を持っているか、またはそれらが付けているネットワーク[1、2]でホストがどれであるかを「知っている」と思われません。
1.4. Model of Operation
1.4. 操作のモデル
This protocol is implemented in a process called a Message Processing Module or MPM. The MPMs exchange messages by establishing full duplex communication and sending the messages in a fixed format described in this document. The MPM may also communicate other information by means of commands described here.
このプロトコルは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 message it is submitted for transmission by placing it in a data structure read by 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 (or some other method), determines which outgoing link to use. The destination may be another user on the same host, one on another host on a network in common with the same host, or a user in another network.
MPMは、未加工の入力データ(特定の要求か一般的なバックグラウンド検索による)を発見して、それを調べて、経路指定テーブル(または、ある他のメソッド)を使用して、どの出発しているリンクを使用したらよいかを決定します。 目的地は、同じホストの上の別のユーザ、同じホストと共用したネットワークの別のホストの1、または別のネットワークでユーザであるかもしれません。
In the first case, another user on this host, the MPM places the message in a data structure read by the destination user, where that user's UIP will look for incoming messages.
前者の場合このホストの上の別のユーザ、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
2番目のケース、このネットワークの別のホストの上のユーザでは、MPMはそのホストの上のMPMにメッセージを送ります。 そして、そのMPMは繰り返します。
[Page 2] Postel
[2ページ] ポステル
August 1980
Internet Message Protocol
Introduction
1980年8月のインターネットメッセージプロトコル序論
the routing decision, and discovering the destination is local to it, places the message in the data structure shared with the destination user.
ルーティング決定、および目的地がそれに地方であると発見するデータ構造におけるメッセージが目的地ユーザと共有された場所。
In the third case, the user on a host in another network, the MPM transmits the messages to an MPM in that network if it knows how to establish a connection directly to it; otherwise, the MPM transmits the message to an MPM that is "closer" to the destination. An MPM might not know of direct connections to MPMs in all other networks, but it must be able to select a next MPM to handle the message for each possible destination network.
3番目のケース、別のネットワークのホストの上のユーザでは、直接それに取引関係を築く方法を知っているなら、MPMはそのネットワークにおけるMPMにメッセージを送ります。 さもなければ、MPMは「より近いところに目的地の」あるMPMにメッセージを送ります。 MPMはMPMsにおいて他のすべてのネットワークでダイレクト接続を知らないかもしれませんが、それは、次のMPMがそれぞれの可能な送信先ネットワークへのメッセージを扱うのを選択できなければなりません。
An MPM might know a way to establish direct connections to each of a few MPMs in other nearby networks, and send all other messages to a particular big brother MPM that has a wider knowledge of the internet environment.
MPMはそれぞれのいくつかのMPMsにおいて他の近いネットワークでダイレクト接続を確立する方法を知って、インターネット環境に関する、より広い知識を持っている特定の兄MPMに他のすべてのメッセージを送るかもしれません。
An individual network's message system may be quite different from the internet message system. In this case, intranet messages will be delivered using the network's own message system. If a message is addressed outside the network, it is given to an MPM which then sends it through the appropriate gateways to (or towards) the MPM in the destination network. Eventually, the message gets to an MPM on the network of the recipient of the message. The message is then sent via the local message system to that host.
個々のネットワークのメッセージシステムはインターネットメッセージシステムと全く異なっているかもしれません。 この場合、イントラネットメッセージは、ネットワークの自身のメッセージシステムを使用することで提供されるでしょう。 ネットワークの外でメッセージを扱うなら、適切なゲートウェイを通してそれがその時発信するMPMにそれを与えます。(or towards)への送信先ネットワークにおける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 potentially lead to information loss. The internet message format attempts to provide features to capture all the information any local message system might use. However, a particular local message system is unlikely to have features equivalent to all the possible features of the internet message system. Thus, in some cases the transformation of an internet message to a local message discards some of the information. For example, if an internet message carrying mixed text and speech data in the body is to be delivered in a local system which only carries text, the speech data may be replaced by the text string "There was some speech here". Such discarding of information is to be avoided when at all possible, and to be deferred as long as possible; still, the possibility remains that in some cases it is the only reasonable thing to do.
ローカルのメッセージプロトコルが使用されているとき、特別な変換プログラムが出かける、および地方の形式への変換インターネットメッセージにはそれらがあるとき地方の環境に入るときインターネットへのローカルのメッセージがフォーマットする変換に必要です。 そのような変換は潜在的に情報の損失を出します。 インターネットメッセージ・フォーマットは、どんなローカルのメッセージシステムも使用するかもしれないすべての情報を得る特徴を提供するのを試みます。 しかしながら、特定のローカルのメッセージシステムで、特徴はインターネットメッセージシステムのすべての可能な特徴に同等になりそうにはありません。 したがって、いくつかの場合、ローカルのメッセージへのインターネットメッセージの変換は何らかの情報を捨てます。 例えば、テキストを運ぶだけであるローカルシステムで提供されています、スピーチデータをテキスト文字列に取り替えるかもしれないということになるように、ボディーで複雑なテキストとスピーチデータを運ぶインターネットメッセージがそうであるなら「何らかのスピーチがここにありました」。 情報をそのような捨てるのは、可能であるときに、避けられて、できるだけ長い間延期されることです。 それでも、可能性はするのが、唯一の妥当なものであるいくつかの場合にそれのままで残っています。
Postel [Page 3]
ポステル[3ページ]
August 1980
Internet Message Protocol
Introduction
1980年8月のインターネットメッセージプロトコル序論
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 Transmission Control Protocol (TCP) [3]. The interface to such a procedure conventionally provides calls to open and close connections, send and receive data on a connection, and some means to signal and be notified of special conditions (i.e., interrupts).
MPMは、信頼できる通信規定が他のMPMsとコミュニケートするよう呼びかけます。これは通信制御プロトコル(TCP)[3]などのTransport Levelプロトコルです。 そのような手順へのインタフェースは慣習上、接続を開いて、終えて、発信して、接続に関するデータ、およびいくつかの合図している、特別な状態について通知されるべき手段を受け取るという要求(すなわち、中断)を提供します。
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ページ] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
2. FUNCTIONAL DESCRIPTION
2. 機能的な記述
This section gives an overview of the Internet Message System and its environment.
このセクションはインターネットMessage Systemとその環境の概要を与えます。
2.1. Terminology
2.1. 用語
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.
メッセージはMessage Processing ModuleかMPMと呼ばれるプロセスによって発送されます。 メッセージは、ユーザに関連してUser Interface Programs(UIPs)によって作成されて、消費されます。
The basic unit transferred between MPMs is called a message. A message is made up of a transaction identifier (which uniquely identifies the message), a command (which contains the necessary information for delivery), and document. The document may have a header and a body.
MPMsの間に移された原単位はメッセージと呼ばれます。 メッセージはトランザクション識別子(唯一メッセージを特定する)、コマンド(配送のための必要事項を含む)、およびドキュメントで作られます。 ドキュメントには、ヘッダーとボディーがあるかもしれません。
For a personal letter the document body corresponds to the contents of the letter; the document header corresponds to the date line, greeting, and signature.
親書に関しては、文書本体は手紙のコンテンツに対応します。 ドキュメントヘッダーは日付変更線、挨拶、および署名に文通しています。
For an inter-office memo the document body corresponds to the text; the document header corresponds to the header of the memo.
相互事務連絡用メモに関しては、文書本体はテキストに対応します。 ドキュメントヘッダーはメモのヘッダーに文通しています。
The commands correspond to the information used by the Post Office or the mail room to route the letter or memo. Some of the information in the command is supplied by the UIP.
コマンドはポストオフィスによって使用された情報か手紙かメモを発送するメール部屋に対応しています。 コマンドにおける何らかの情報がUIPによって提供されます。
2.2. Assumptions
2.2. 仮定
The following assumptions are made about the internetwork environment:
以下の仮定はインターネットワーク環境に関してされます:
In general, it is not known what format intranet addresses will assume. Since no standard addressing scheme would suit all networks, it is safe to assume there will be several and that they will change with time. Thus, frequent software modification throughout all internet MPMs would be required if such MPMs were to know about the formats on many networks. Therefore, each MPM which handles internet messages is required to know only the minimum necessary to deliver them.
一般に、形式イントラネットアドレスが何を仮定するかは知られていません。 どんな標準のアドレシング体系もすべてのネットワークに合うというわけではないでしょう、したがって、数個があって、時間を交換すると仮定するのは安全です。 したがって、そのようなMPMsが多くのネットワークの形式に関して知るなら、すべてのインターネットMPMs中の頻繁なソフトウェア変更が必要でしょうに。 したがって、インターネットメッセージを扱う各MPMが、それらを提供するのに必要な最小限だけを知るのに必要です。
Each MPM is required to know completely only the addressing format of its own network(s). In addition, the MPM must be able to select an output link for each message addressed to another network or host. This does not preclude more intelligent behavior on the part of a given MPM, but at least this minimum is necessary. Each network has a unique name and numeric address. Such names and addresses are
各MPMが、それ自身のネットワークのアドレス指定形式だけを完全に知るのに必要です。 さらに、MPMは別のネットワークかホストに扱われた各メッセージのために出力リンクを選択できなければなりません。 これは与えられたMPM側のより知的な振舞いを排除しませんが、少なくともこの最小限が必要です。 各ネットワークには、ユニークな名前と数値アドレスがあります。 そのような名前とアドレスはそうです。
Postel [Page 5]
ポステル[5ページ]
August 1980
Internet Message Protocol
Functional Description
1980年8月のインターネットのメッセージのプロトコルの機能的な記述
registered with a naming authority and may be listed in documents such as Assigned Numbers [4].
命名権威とともに記名して、Assigned民数記[4]などのドキュメントに記載されているかもしれません。
Each MPM will have a unique internet address. This feature will enable every MPM to place a unique "handling-stamp" on a message which passes through the MPM enroute to delivery.
各MPMには、ユニークなインターネットアドレスがあるでしょう。 この特徴は、あらゆるMPMが配送への途中で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
\ /
UIP UIP
\ /
--+----------------------------------------+-- Service
| \ / | Interface
| +--------+ +--------+ |
| | Module | <--Protocol--> | Module | |
| +--------+ +--------+ |
| \ / |
| +-----------------------+ |
| | Communication Service | |
| +-----------------------+ |
| |
+----------------------------------------+
ユーザユーザ\/UIP UIP\/--+----------------------------------------+--サービス| \ / | インタフェース| +--------+ +--------+ | | | モジュール| <--プロトコル-->。| モジュール| | | +--------+ +--------+ | | \ / | | +-----------------------+ | | | 通信サービス| | | +-----------------------+ | | | +----------------------------------------+
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, to attempt to deliver
those messages, and to report on the success or failure of the
delivery attempt. This service is provided in the context of an
interconnected system of networks and may involve relaying a message
through several intermediate MPMs via different communication
services.
メッセージ配送システムが提供するサービスは、それらのメッセージを提供するのを試みる指定された形式に従うメッセージを受け入れて、配送試みの成否に関して報告することです。 このサービスは、ネットワークの相互接続システムの文脈に前提とされて、数個の中間的MPMsを通して伝言を伝えることを異なった通信サービスで伴うかもしれません。
[Page 6] Postel
[6ページ] ポステル
August 1980
Internet Message Protocol
Functional Description
1980年8月のインターネットのメッセージのプロトコルの機能的な記述
The Message/Communication Service Interface
メッセージ/通信サービスインタフェース
The message delivery system calls on a communication service to
transfer information from one MPM to another. There may be
different communication services used between different pairs of
MPMs, though all communication services must meet the service
characteristics described below.
コミュニケーションにおけるメッセージ配送システムコールは1MPMから別のMPMまで転送に情報を修理します。 異なった組の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) [3]. In any case, the
properties the communication service must provide are:
通信サービスが信頼できる両用データ・ストリームを供給すると思われます。 例えば、通常、小川を得ることができる輸送からのコンピュータネットワークが平らにするそのようなデータは議定書を作ります、通信制御プロトコル(TCP)[3]。 どのような場合でも、通信サービスが提供しなければならない資産は以下の通りです。
o Logical connections for two way simultaneous data flow of
arbitrary data (i.e., no forbidden codes). All data sent is
delivered in order.
o 任意のデータ(すなわち、コードは禁じられない)のツーウェイの同時のデータフローのための論理的な接続。 データが送ったすべてが整然とした状態で提供されます。
o Simple commands to open and close the connections, and to send
and receive data on the connections.
o 接続での接続を開いて、終えて、発信する簡単なコマンドと受信データ。
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 of the sender or receiver. Complete breakdown on
communication is reported to the sender or receiver.
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. An MPM might exist in two (or more) interprocess communication environments, and such an MPM might act to relay messages between MPMs. Messages may be held for a time in an MPM; the total path required for delivery need not be available simultaneously.
MPMsは何らかの通信サービスを使用するプロセスです。 交信できる1組のMPMsが一般的なプロセス間通信環境で住んでいます。 MPMは2つ(さらに)のプロセス間通信環境で存在するかもしれません、そして、そのようなMPMはMPMsの間のメッセージをリレーするために行動するかもしれません。メッセージは時間、MPMに保持されるかもしれません。 配送に必要である総経路は同時に、利用可能である必要はありません。
From the time a message is accepted from a UIP by an MPM until it is delivered to a UIP by an MPM and an acknowledgment is returned to the
時間から、メッセージはMPMによってUIPからMPMがそれをUIPに提供して、承認に戻るまで受け入れられます。
Postel [Page 7]
ポステル[7ページ]
August 1980
Internet Message Protocol
Functional Description
1980年8月のインターネットのメッセージのプロトコルの機能的な記述
originating UIP, the message is considered to be active in the message system.
UIPを溯源して、メッセージがメッセージシステムでアクティブであると考えられます。
User User
\ /
UIP UIP
\ /
+---------------------------------------------------------+
| \ / |
| +-----+ +-----+ +-----+ |
| | MPM | <--Protocol--> | MPM | <--Protocol--> | MPM | |
| +-----+ +-----+ +-----+ |
| | / \ | |
| +-----------------------+ +-----------------------+ |
| |Communication Service A| |Communication Service B| |
| +-----------------------+ +-----------------------+ |
| |
+---------------------------------------------------------+
ユーザユーザ\/UIP UIP\/+---------------------------------------------------------+ | \ / | | +-----+ +-----+ +-----+ | | | mpm| <--プロトコル-->。| mpm| <--プロトコル-->。| mpm| | | +-----+ +-----+ +-----+ | | | / \ | | | +-----------------------+ +-----------------------+ | | |通信サービスA| |通信サービスB| | | +-----------------------+ +-----------------------+ | | | +---------------------------------------------------------+
Message Service with Internal Relaying
内部のリレーとのメッセージサービス
Figure 2.
図2。
It should be clear that there are two roles an MPM can play, an end-point MPM or a relay MPM. Most MPMs will play both roles. A relay MPM acts to relay messages from one communication environment to another. An end-point MPM acts as a source or destination of messages.
MPMが果たすことができる2つの役割があるのが、明確であるはずであり、エンドポイントは、MPMかリレーMPMです。 ほとんどのMPMsが両方の役割を果たすでしょう。 リレーMPMは、1つの通信環境から別の通信環境までメッセージをリレーするために行動します。 MPMがソースかメッセージの送信先として機能させるエンドポイント。
The transfer of data between UIPs and MPMs is viewed as the exchange of data structures which encode messages. The transfer of data between MPMs is also in terms of the transmission of structured data.
UIPsとMPMsの間のデータ転送はメッセージをコード化するデータ構造の交換として見なされます。 MPMsの間のデータ転送が構造化されたデータの伝達でもあります。
[Page 8] Postel
[8ページ] ポステル
August 1980
Internet Message Protocol
Functional Description
1980年8月のインターネットのメッセージのプロトコルの機能的な記述
+-----+ DATA +-----+
USER-->| UIP |-->STRUCTURES-->| MPM |-->other
+-----+ +-----+ +-----+ MPMs
| |
| +-----+
+--| |
| +-----+
+--| |
| |
+-----+
+-----+ データ+-----+ ユーザ-->| UIP|-->構造-->| mpm|-->他の+-----+ +-----+ +-----+ MPMs| | | +-----+ +--| | | +-----+ +--| | | | +-----+
+-----+ DATA +-----+
other-->| MPM |-->STRUCTURES-->| UIP |-->USER
MPMs +-----+ +-----+ +-----+
| |
| +-----+
+--| |
| +-----+
+--| |
| |
+-----+
+-----+ データ+-----+他-->| mpm|-->構造-->| UIP|-->ユーザ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 an MPM (or a UIP), a message may be represented in any convenient form.
以下では、メッセージは特定の種類のタイプされたデータ要素に表された構造化されたデータ・オブジェクトとして記述されるでしょう。 これはメッセージをMPMsの間に伝えると提示するか、またはMPMとUIPの間でどう交換するかということです。 MPM(または、UIP)に内部であり、メッセージはどんな便利なフォームにも表されるかもしれません。
Postel [Page 9]
ポステル[9ページ]
August 1980
Internet Message Protocol
Functional Description
1980年8月のインターネットのメッセージのプロトコルの機能的な記述
2.5. Relation to Other Protocols
2.5. 他のプロトコルとの関係
This protocol the benefited from the earlier work on message protocols in the ARPA Network [5,6,7,8,9], and the ideas of others about the design of computer message systems [10,11,12,13,14,15,16,17,18,19,20,21].
これはコンピュータメッセージシステム[10、11、12、13、14、15、16、17、18、19、20、21]の設計に関してアーパネット[5、6、7、8、9]のメッセージプロトコル、および他のものの考えに対する以前の仕事からのためになることについて議定書の中で述べます。
Figure 4 illustrates the place of the message protocol in the ARPA internet protocol hierarchy:
図4はARPAインターネットプロトコル階層でメッセージプロトコルの場所を例証します:
+------+ +-----+ +-------+ +-----+ +-----+
|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 4.
図4。
Note that "local network" means an individual or specific network. For example, the ARPANET is a local network.
「企業内情報通信網」が個々の、または、特定のネットワークを意味することに注意してください。 例えば、アルパネットは企業内情報通信網です。
The message protocol interfaces on one side to user interface programs and on the other side to a reliable transport protocol such as TCP.
ユーザーインタフェースプログラムへの半面の上と、そして、信頼できる輸送への反対側の上のメッセージプロトコルインタフェースはTCPなどのように議定書を作ります。
In this internet message system the MPMs communicate directly using the lower level transport protocol. In the old ARPANET system, message transmission was part of the file transfer protocol.
このインターネットメッセージシステムでは、MPMsは、下のレベルトランスポート・プロトコルを使用することで直接伝達します。 古いアルパネットシステムでは、メッセージ送信はファイル転送プロトコルの一部でした。
[Page 10] Postel
[10ページ] ポステル
August 1980
Internet Message Protocol
Functional Description
1980年8月のインターネットのメッセージのプロトコルの機能的な記述
+------+ +-----+ +-------+
|Telnet| | FTP |---|Message| Application Level
+------+ +-----+ +-------+
\ /
+-----+ +-----+
|Voice|---| NCP | Host Level
+-----+ +-----+
|
|
| Gateway Level
|
|
+----------------+
| ARPA NET | Network Level
+----------------+
+------+ +-----+ +-------+ |telnet| | FTP|---|メッセージ| アプリケーションレベル+------+ +-----+ +-------+ \ / +-----+ +-----+ |声|---| NCP| ホストレベル+-----+ +-----+ | | | ゲートウェイレベル| | +----------------+ | アルパネット| ネットワークレベル+----------------+
Old ARPANET Protocols
古いアルパネットプロトコル
Figure 5.
図5。
Note that in the old ARPANET protocols one can't send messages (or communicate in any way) to other networks since it has no gateway level or internet protocol [5].
それにはどんなゲートウェイレベルもインターネットプロトコルも[5]ないので、古いアルパネットプロトコル1のそれがメッセージ(何らかの方法で交信する)を他のネットワークに送ることができないことに注意してください。
Postel [Page 11]
ポステル[11ページ]
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
[Page 12] Postel
[12ページ] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
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 medium it has to come in some order. In this attempt, a brief overview of the message structure is given, the detail of the message is presented in terms of data objects, the various data objects are defined, and finally the representation of the data elements is specified. Several aspects of the message structure are based on the NSW Transaction Protocol [22], and similar (but more general) proposals [23,24].
このセクションの情報のプレゼンテーションは、すべてがすべてによって、これがそれが何らかのオーダーで来させなければならない直線的な媒体であるので、難しいです。 この試みでは、メッセージ構造の簡潔な概要を与えます、そして、データ・オブジェクトに関してメッセージの詳細を提示します、そして、様々なデータ・オブジェクトを定義します、そして、最終的にデータ要素の表現を指定します。 メッセージ構造のいくつかの局面がNSW Transactionプロトコル[22]、および同様の、そして、(より一般的)の提案[23、24]に基づいています。
3.1. Overview of Message Structure
3.1. メッセージ構造の概要
A message is normally composed of three parts: the identification, the command, and the document. Each part is in turn composed of data objects.
通常、メッセージは3つの部品で構成されます: 識別、コマンド、およびドキュメント。 各部分はデータ・オブジェクトで順番に構成されます。
The identification part is composed of a transaction number assigned by the originating MPM and the MPM identifier.
識別部分は起因しているMPMとMPM識別子によって割り当てられたトランザクション番号で構成されます。
The command part is composed of an operation type, an operation code, the arguments to the operation, error information, the destination mailbox, and a trace. The trace is a list of the MPMs that have handled this message.
コマンド一部が操作タイプ、命令コード、操作への議論、エラー情報、あて先メールボックス、および跡で構成されます。 跡はこのメッセージを扱ったMPMsのリストです。
The document part is a data structure. The message delivery system does not depend on the contents of the document part. A standard for the document part is defined in reference [25].
ドキュメント部分はデータ構造です。 メッセージ配送システムはドキュメント部分のコンテンツによりません。 ドキュメント部分の規格は参照[25]で定義されます。
The following sections define the representation of a message as a structured object composed of other objects. Objects in turn are represented using a set of basic data elements.
以下のセクションは他のオブジェクトで構成された構造化されたオブジェクトとメッセージの表現を定義します。 オブジェクトは、1セットの基礎データ要素を使用することで順番に表されます。
The basic data elements are defined in section 3.7. In summary, these are exact forms for representing integers, strings, booleans, et cetera. There are also two elements for building data structures: list and property list. Lists are simple lists of elements, including lists. Property lists are lists of pairs of elements, where the first element of each pair names the pair. That is, a property list is a list of <name,value> pairs. In general, when an object is composed of multiple instances of a simpler object it is represented as a list of the simpler objects. When an object is composed of a variety of simpler objects it is represented as a property list of the simpler objects. In most uses of the property list representation, the presence of <name,value> pairs in addition to those specifically required is permitted.
基礎データ要素はセクション3.7で定義されます。 概要では、これらは、整数、ストリング、論理演算子などを表すための正確なフォームです。 また、ビルデータ構造のための2つの要素があります: リストと特性はリストアップされています。 リストはリストを含む要素に関する単純並びです。 特性のリストは組の要素のリストです。そこでは、それぞれの組の最初の要素が組を命名します。 >組は、すなわち、特性のリストが<名のリストであることを評価します。 オブジェクトが、より簡単なオブジェクトの複数のインスタンスで構成されるとき、一般に、それは、より簡単なオブジェクトのリストとして表されます。 オブジェクトがさまざまなより簡単なオブジェクトで構成されるとき、それは、より簡単なオブジェクトの特性のリストとして表されます。 特性のリスト表現のほとんどの用途、<名の存在では、明確に必要であるものに加えた値の>組は受入れられます。
Postel [Page 13]
ポステル[13ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
3.2. Message Structure
3.2. メッセージ構造
An internet message is composed of two or three parts. The first is the Identification which identifies the transaction; the second is the Command; and the optional third part is the Document.
インターネットメッセージは2か3つの部品で構成されます。 1番目はトランザクションを特定するIdentificationです。 2番目はCommandです。 そして、3番目の任意の部分はDocumentです。
When shipped between two MPMs, a message will take the form of a property list, with the <name,value> pairs in this order.
2MPMsの間に出荷すると、メッセージは特性のリストの形を取るでしょう、<名で、このオーダーにおける値の>組。
MESSAGE is:
MESSAGEは以下の通りです。
( Identification, Command [, Document ] )
(識別、コマンド[ドキュメント])
It is convenient to batch several messages together, shipping them
as a unit from one MPM to another. Such a group of messages is
called a message-bag.
それらを一体にして1MPMから別のMPMまで出荷して、それは一緒にバッチいくつかのメッセージに便利です。 メッセージのそのようなグループはメッセージバッグと呼ばれます。
A message-bag will be a list of Messages; each Message is of the
form described above.
メッセージバッグはMessagesのリストになるでしょう。 各Messageは上で説明されたフォームのものです。
MESSAGE-BAG is:
MESSAGE-BAGは以下の通りです。
( Message, Message, ... )
(メッセージ、メッセージ)
The Identification
識別
This is the transaction identifier. It is assigned by the
originating MPM. The identification is composed of the MPM
identifier, and a transaction number unique in that context for this
message.
これはトランザクション識別子です。 それは起因しているMPMによって割り当てられます。 識別はMPM識別子、およびこのメッセージのその文脈でユニークなトランザクション番号で構成されます。
The Command
コマンド
The command is composed of a mailbox, an operation code, the
arguments to that operation, some error information, and a trace of
the route of this message. The command is implemented by a property
list which contains <name,value> pairs, where the names are used to
identify the associated argument values.
コマンドはメールボックス、命令コード、その操作への議論、何らかのエラー情報、およびこのメッセージのルートの跡で構成されます。 コマンドは<名を含む特性のリストによって実装されます、値の>組、名前が関連パラメータ値を特定するのに使用されるところで。
The Document
ドキュメント
The document portion of an internet message is optional and when
present is a data structure as defined in [25].
インターネットメッセージのドキュメント部分は任意です、そして、現在の時は[25]で定義されるようにデータ構造です。
[Page 14] Postel
[14ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
3.3. Identification
3.3. 識別
Each message must have a unique identifier while it exists in the message delivery system. This is provided by the combination of the unique identifier of the MPM and a unique transaction number chosen for the message by this MPM.
メッセージ配送システムに存在している間、各メッセージには、ユニークな識別子がなければなりません。 MPMのユニークな識別子とこのMPMによってメッセージに選ばれたユニークなトランザクション番号の組み合わせでこれを提供します。
IDENTIFICATION is:
IDENTIFICATIONは以下の通りです。
( mpm-identifier, transaction-number )
(mpm識別子、トランザクション番号)
The mpm-identifier is based on the host address of the computer in which the MPM resides. If there is more than one MPM in a host the mpm-identifier must be extended to distinguish between the co-resident MPMs.
mpm識別子はMPMが住んでいるコンピュータのホスト・アドレスに基づいています。 1MPMがホストにあれば、コレジデントMPMsを見分けるためにmpm識別子を広げなければなりません。
3.4. Command
3.4. コマンド
This section describes the commands MPMs use to communicate between themselves. The commands come in pairs, with each request having a corresponding reply.
このセクションはMPMsが自分たちの間で交信するのに使用するコマンドについて説明します。 コマンドは対応する回答を持っている各要求のときに組に入ります。
COMMAND is:
COMMANDは以下の通りです。
( mailbox, operation, [arguments,]
[error-class, error-string,] trace )
(メールボックス、操作、[議論][誤りクラス、誤りストリング]跡)
The mailbox is the "To" specification of the message. Mailbox is a property list of general information, some of which is the essential information for delivery, and some of which could be extra information which may be helpful for delivery. Mailbox is different from address in that address is a very specific property list without extra information. The mailbox includes a specification of the user, when a command is addressed to the MPM itself (rather than a user it serves) the special user name "*MPM*" is specified.
メールボックスはメッセージの“To"仕様です。 メールボックスは一般情報の特性のリストです。どれが配送のための不可欠の情報であるか、そして、いくつかのそのいくつかが配送に、有用であるかもしれないその他の情報であるかもしれません。 メールボックスはアドレスとアドレスがその他の情報がなければ非常に特定の特性のリストであるという点において異なっています。 「メールボックスはユーザの仕様を含めて、コマンドがMPM(それが役立つユーザよりむしろ)自身に扱われるとき、特別なユーザは」 *をmpm*と命名すること」が指定されます。
The operation is the name of the operation or procedure to be performed.
操作は実行されるべき操作か手順の名前です。
The arguments to the operation vary from operation to operation.
操作によって操作への議論は異なります。
The error information is composed of a error class code and a character string, and indicates what, if any, error occurred. The error information is normally present only in replies, and not present in requests.
エラー情報は、誤りクラスコードと文字列で構成されて、なにかを示すか、誤りがいくらか発生したなら。 エラー情報は、通常、回答だけで現在であって、要求に存在していません。
Postel [Page 15]
ポステル[15ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
The trace is a list of the MPMs that have handled the message. Each MPM must add its handling-stamp to the list.
跡はメッセージを扱ったMPMsのリストです。 各MPMは取り扱いスタンプをリストに追加しなければなりません。
[Page 16] Postel
[16ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
3.4.1. Command: DELIVER
3.4.1. コマンド: 配送してください。
function: Sends a document to a mailbox.
機能: ドキュメントをメールボックスに送ります。
reply: The reply is ACKNOWLEDGE.
回答: 回答はACKNOWLEDGEです。
arguments:
議論:
type-of-service: one or more of the following:
サービスのタイプ: 以下の1つ以上:
"REGULAR" regular delivery
"FORWARD" message forwarding
"GENDEL" general delivery
"PRIORITY" priority delivery
定期的な"REGULAR"配送「前進」のメッセージ推進"GENDEL"局留め郵便「優先権」優先権配送
3.4.2. Command: ACKNOWLEDGE
3.4.2. コマンド: 承認します。
function: Reply to DELIVER.
機能: 配送するには、返答してください。
arguments:
議論:
reference: the identifier of the originating message.
参照: 起因するメッセージに関する識別子。
address:
アドレス:
The address is the final mailbox the message was delivered to.
This would be different from the original mailbox if the message
was forwarded, and is limited to the essential information
needed for delivery.
アドレスはメッセージが提供された最終的なメールボックスです。 メッセージが転送されて、配送に必要である不可欠の情報に制限されるなら、これはオリジナルのメールボックスと異なっているでしょう。
type-of-service: one of the following:
サービスのタイプ: 以下の1つ:
"GENDEL" message was accepted for general delivery
"REGULAR" message was accepted for normal delivery
"PRIORITY" message was accepted for priority delivery
"GENDEL"メッセージは「通常」のメッセージが受け入れられた局留め郵便のために受け入れて、優先権配送のために正常分娩「優先権」メッセージを受け入れたということでした。
error-class:
error-string:
誤りクラス: 誤りストリング:
If the document was delivered successfully, the error
information has class 0 and string "ok". Otherwise, the error
information has a non-zero class and the string would be one of
"no such user", "no such host", "no such network", "address
ambiguous", or a similar response.
ドキュメントが首尾よく提供されたなら、エラー情報は「間違いありません」クラス0とストリングを持っています。 さもなければ、エラー情報には、非ゼロのクラスがあります、そして、ストリングは「そのようなユーザでない」、「そのようなネットワークでない」の、そして、「アドレスあいまいである」「そのようなホストでない」、または同様の応答の1つでしょう。
trail: the trace from the DELIVER command.
以下を引きずってください。 DELIVERコマンドからの跡。
Postel [Page 17]
ポステル[17ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
3.4.3. Command: PROBE
3.4.3. コマンド: 徹底的調査
function: Finds out if specified mailbox (specified in mailbox of
the command) exists at a host.
機能: 指定されたメールボックス(コマンドのメールボックスの中に指定される)がホストに存在するかどうか見つけます。
reply: The reply is RESPONSE.
回答: 回答はRESPONSEです。
arguments: none.
議論: なし。
3.4.4. Command: RESPONSE
3.4.4. コマンド: 応答
function: Reply to PROBE.
機能: 調べるには、返答してください。
arguments:
議論:
reference: the identification of the originating PROBE.
参照: 起因しているPROBEの識別。
address: a specific address.
アドレス: 特定のアドレス。
error-class:
error-string:
誤りクラス: 誤りストリング:
If the mailbox was found the error class is 0 and the error
string is "OK". If the mailbox has moved and a forwarding
address in known the error class is 1 and the error string is
"Mailbox moved, see address". Otherwise the error class is
greater than 1 and the error string may be one of the following:
"Mailbox doesn't exist", "Mailbox full", "Mailbox has moved, try
the new location indicated in the address".
誤りのクラスに見つけられているのが、メールボックスがそうであったなら0であり、誤りストリングは「OKです」。 メールボックスが移行して、知られるところのフォーワーディング・アドレスが誤りのクラスを移行させたなら、1と誤りはストリングです。「メールボックスは移行しました、とアドレスは見ること」。 さもなければ、誤りのクラスは1以上です、そして、誤りストリングは以下の1つであるかもしれません: 「メールボックスは存在していない」「メールボックス満」、「メールボックスは移行して、トライはアドレスで示された新しい位置です」。
trail: the trace which came from the originating PROBE.
以下を引きずってください。 起因しているPROBEから来た跡。
[Page 18] Postel
[18ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
3.4.5. Command: CANCEL
3.4.5. コマンド: キャンセル
function: Abort request for specified transaction.
機能: 指定されたトランザクションを求める要求を中止してください。
reply: The reply is CANCELED.
回答: 回答はCANCELEDです。
arguments:
議論:
reference: identification of transaction to be canceled.
参照: 取り消されるべきトランザクションの識別。
3.4.6. Command: CANCELED
3.4.6. コマンド: 取り消されます。
function: Reply to CANCEL.
機能: 取り消すには、返答してください。
arguments:
議論:
reference: identification of canceled transaction.
参照: 取り消されたトランザクションの識別。
error-class:
error-string:
誤りクラス: 誤りストリング:
If the command was canceled the error class is 0 and the error
string is "OK". Otherwise the error class is positive and the
error string may be one of the following: "No such transaction",
or any error for an unreachable mailbox.
コマンドが中止されたなら、誤りのクラスは0です、そして、誤りストリングは「OKです」。 さもなければ、誤りのクラスは上向きです、そして、誤りストリングは以下の1つであるかもしれません: 「そのようなトランザクションでない」、または手の届かないメールボックスのためのどんな誤り。
trail: the trace of the CANCEL command.
以下を引きずってください。 キャンセル命令の跡。
To summarize again, a command generally consists of a property list of the following objects:
再びaをまとめるために、一般に、コマンドは以下のオブジェクトの特性のリストから成ります:
name value
---- -----
mailbox property list of address information
operation name of operation
arguments ---
error-class numeric class of the error
error-string text description of the error
trace list ( handling-stamp, ... )
名前値---- ----- 操作議論のアドレス情報操作名のメールボックス特性のリスト--- 誤り跡のリストの誤り誤りストリングテキスト記述の誤りクラスの数値クラス(取り扱う押し込んでください…)
3.5. Document
3.5. ドキュメント
The actual document follows the command. The message delivery system does not depend on the document, examine it, or use it in any way. The standard for the contents of the document is reference [25]. The document must be the last <name,value> pair in the message property list.
実際のドキュメントはコマンドに続きます。 メッセージ配送システムは、何らかの方法でドキュメントによりもしませんし、それを調べもしませんし、それを使用もしません。 ドキュメントのコンテンツの規格は参照[25]です。 >組は、メッセージ特性のリストでドキュメントが最後の<名であるに違いないことを評価します。
Postel [Page 19]
ポステル[19ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
3.6. Message Objects
3.6. メッセージオブジェクト
In the composition of messages, we use a set of objects such as mailbox or date. These objects are encoded in basic data elements. Some objects are simple things like integers or character strings, other objects are more complex things built up of lists or property lists.
メッセージの構成では、私たちは、1セットのメールボックスなどのオブジェクトを使用するか、またはデートします。 これらのオブジェクトは基礎データ要素でコード化されます。 いくつかのオブジェクトが整数や文字列のように簡単なものである、他の目的はリストについて確立されたより複雑なものであるか特性が記載します。
The following is a list of the objects used in messages. The object descriptions are in alphabetical order.
↓これはメッセージで使用されるオブジェクトのリストです。 オブジェクト記述がアルファベット順にあります。
Action
動作
The type of handling action taken by the MPM when processing a
message. One of ORIGIN, RELAY, FORWARD, or DESTINATION.
メッセージを処理するときMPMによって取られた取り扱い行動のタイプ。 1つ、発生源、リレー、フォワード、または目的地について。
Address
アドレス
Address is intended to contain the minimum information necessary to
deliver a message, and no more (compare with mailbox).
アドレスがメッセージ、およびいいえをさらに提供するのに必要な最小の情報を含むことを意図します(メールボックスと比較してください)。
An address is a property list. An address contains the following
<name,value> pairs:
アドレスは特性のリストです。 >組は、アドレスが以下の<名を含むのを評価します:
name description
---- -----------
NET network name
HOST host name
USER user name
名前記述---- ----------- NETネットワーク名HOSTホスト名USERユーザ名
or:
または、:
name description
---- -----------
MPM mpm-identifier
USER user name
名前記述---- ----------- MPM mpm識別子USERユーザ名
Answer
答え
A yes (true) or no (false) answer to a question.
はい(本当の)にもかかわらず、(誤っている)の質問への答がありません。
Arguments
議論
Many operations require arguments, which differ from command to
command. This "object" is a place holder for the actual arguments
when commands are described in a general way.
多くの操作が議論を必要とします。(議論は命令するコマンドと異なっています)。 コマンドがザッと説明されるとき、この「オブジェクト」は実際の議論のための場所所有者です。
[Page 20] Postel
[20ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
City
市
The character string name of a city.
都市の文字列名。
Command
コマンド
(mailbox, operation [ ,arguments ]
[ ,error-class, error-string ], trace)
(メールボックス、操作[議論][誤りクラス、誤りストリング]、跡)
Country
国
The character string name of a country.
国の文字列名。
Date
日付
The date and time are represented according to the International
Standards Organization (ISO) recommendations [26,27,28]. Taken
together the ISO recommendations 2014, 3307, and 4031 result in the
following representation of the date and time:
国際Standards Organization(ISO)推薦[26、27、28]に従って、日付と時間は表されます。 日時の以下の表現で推薦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 four-digit year, mm is the two-digit month, dd is
the two-digit day, hh is the two-digit hour in 24 hour time, mm is
the two-digit minute, ss is the two-digit second, and fff is the
decimal fraction of the second. To this basic date and time is
appended the offset from Greenwich as plus or minus hh hours and mm
minutes.
yyyyが4ケタの年であるところでは、mmは2ケタの月です、そして、ddは2ケタの日です、そして、hhは24時間の回の間、2ケタの時間です、そして、mmは2ケタの分です、そして、ssは2番目に、2ケタです、そして、fffは2番目の小数です。 この基礎に、日付と時間は追加して、プラスかマイナスとしてのグリニッジからのオフセットが分間何時間もmmをhhするということです。
The time is local time and the offset is the difference between
local time and Coordinated Universal Time (UTC). To convert from
local time to UTC algebraically subtract the offset from the local
time.
時間は現地時間です、そして、オフセットは現地時間と協定世界時の(UTC)の違いです。 現地時間からUTCに変換するには、現地時間からオフセットを代数的に引き算してください。
For example, when the time in
Los Angeles is 14:25:00-08:00
the UTC is 22:25:00
ロサンゼルスの時間が14:25:00-08:00であるのに、例えば、UTCは00 22:25:歳です。
or when the time in
Paris is 11:43:00+01:00
the UTC is 10:43:00
パリの時間が11:43:00+01:00であるのに、または、UTCは00 10:43:歳です。
Document
ドキュメント
The document is the user's composition and is not used by the
message delivery system in any way.
ドキュメントは、ユーザの構成であり、メッセージ配送システムによって何らかの方法で使用されません。
Postel [Page 21]
ポステル[21ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
Error-Class
誤りクラス
A numeric code for the class of the error. The error classes are
coded as follows:
誤りのクラスのための数字コード。 誤りのクラスは以下の通りコード化されます:
= 0: indicates success, no error.
This is the normal case.
= 1: failure, address changed.
This error is used when forwarding is possible, but not allowed
by the type of service specified.
= 2: failure, resources unavailable.
These errors are temporary and the command they respond to may
work if attempted at a later time.
= 3: failure, user error.
For example, unknown operation, or bad arguments.
= 4: failure, MPM error. Recoverable.
These errors are temporary and the command they respond to may
work if attempted at a later time.
= 5: failure, MPM error. Permanent.
These errors are permanent, there is no point in trying the same
command again.
= 6: Aborted as requested by user.
The response to a successfully canceled command.
= 0: 成功、誤りを全く示しません。 これは正常なそうです。 = 1: 失敗、変えられたアドレス。 この誤りは、推進が可能であるときに、使用されますが、指定されたサービスのタイプによって許容されていません。 = 2: 失敗、入手できないリソース。 これらの誤りは一時的です、そして、後で試みられるなら、彼らが応じるコマンドは働くかもしれません。 = 3: 失敗、ユーザ誤り。 例えば、未知の操作、または有効性のない論拠。 = 4: 失敗、MPM誤り。 回復可能。 これらの誤りは一時的です、そして、後で試みられるなら、彼らが応じるコマンドは働くかもしれません。 = 5: 失敗、MPM誤り。 永久的。 これらの誤りが永久的である、同じ骨の折れるコマンドにはポイントが全く再びありません。 = 6: 要求された通りユーザによって中止されます。 首尾よく取り消されたコマンドへの応答。
[Page 22] Postel
[22ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
Error-String
誤りストリング
This is a character string describing the error. Possible errors:
これは誤りについて説明する文字列です。 可能な誤り:
error-string error-class
誤りストリング誤りクラス
No errors 0
Ok 0
Mailbox Moved, see address 1
Mailbox Full, try again later 2
Syntax error, operation unrecognized 3
Syntax error, in arguments 3
No Such User 3
No Such Host 3
No Such Network 3
No Such Transaction 3
Mailbox Does Not Exist 3
Ambiguous Address 3
Server error, try again later 4
No service available 5
Command not implemented 5
Aborted as requested by user 6
いいえ誤り0Ok0Mailbox Moved、1Mailbox Fullを扱うように確実にしてください、そして、議論3いいえSuch User3いいえSuch Host3いいえSuch Network3ノーSuch Transaction3Mailbox Does Not Exist3Ambiguous Address3Server誤りでもう一度より後半の2Syntax誤り、操作の認識されていない3Syntax誤りを試みてください、そして、もう一度利用可能な5Commandが要求された通りユーザ6で5Abortedを実装しなかった後の4いいえサービスを試みてください。
Handling-Stamp
取り扱いスタンプ
The handling-stamp indicates the MPM, the date (including the time)
that a message was processed by an MPM, and the type of handling
action taken.
取り扱いスタンプはメッセージがMPM、および取られた取り扱い行動のタイプによって処理された日付(時間を含んでいる)にMPMを示します。
( mpm-identifier, date, action )
(mpm識別子、日付、動作)
Host
ホスト
The character string name of a host.
ホストの文字列名。
Identification
識別
This is the transaction identifier associated with a particular
message. It is the transaction number, and the MPM identifier of
the originating MPM.
これは特定のメッセージに関連しているトランザクション識別子です。 それは、トランザクション番号と、起因しているMPMに関するMPM識別子です。
( mpm-identifier, transaction-number )
(mpm識別子、トランザクション番号)
Postel [Page 23]
ポステル[23ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
Internet Address
インターネットアドレス
This identifies a host in the ARPA internetwork environment. When
used as a part of identification, it identifies the originating host
of a message. The internet address is a 32 bit number, the higher
order 8 bits identify the network, and the lower order 24 bits
identify the host on that network [2]. For use in the MPMs the
internet address is divided into eight bit fields and the value of
each field is represented in decimal digits. For example, the
ARPANET address of ISIE is 167837748 and is represented as
10,1,0,52. Further, this representation may be extended to include
an address within a host, such as the TCP port of the MPM, for
example, 10,1,0,52,0,45.
これはARPAインターネットワーク環境でホストを特定します。 識別の一部として使用されると、それはメッセージの送信元ホストを特定します。 インターネットアドレスは32ビットの数であり、8ビットはネットワークを特定して、より高く注文してください、そうすれば注文するほど、[2]をネットワークでつなぐ24ビットがホストを特定するオーダーは、より低いです。 MPMsにおける使用において、インターネットアドレスは8ビットの分野に分割されます、そして、それぞれの分野の値は10進数字で表されます。 例えば、ISIEのアルパネットアドレスは、167837748であり、10、1、0、52として表されます。 さらに、この表現はホストの中にアドレスを含むように広げられるかもしれません、MPM、例えば、10、1、0、52、0、45のTCPポートなどのように。
Mailbox
メールボックス
This is the destination address of a user of the internetwork mail
system. Mailbox contains information such as network, host,
location, and local user indentifier of the recipient of the
message. Some information contained in mailbox may not be necessary
for delivery.
これはインターネットワークメールシステムのユーザの送付先アドレスです。 メールボックスはメッセージの受取人のネットワークや、ホストや、位置や、地方のユーザindentifierなどの情報を含んでいます。 メールボックスに含まれた何らかの情報は配送に必要でないかもしれません。
As an example, when one sends a message to someone for the first
time, he may include many items which are not necessary simply to
insure delivery. However, once he gets a reply to this message, the
reply will contain an Address (as opposed to Mailbox) which may be
used from then on.
1つが初めてメッセージをだれかに送るとき、例として、彼は多くの単に配送を保障するのに必要でない項目を入れるかもしれません。 しかしながら、彼がいったんこのメッセージに回答を得ると、回答はそれ以来使用されるかもしれないAddress(Mailboxと対照的に)を含むでしょう。
A mailbox is a property list. A mailbox might contain the
following <name,value> pairs:
メールボックスは特性のリストです。 >組は、メールボックスが以下の<名を含むかもしれないのを評価します:
name description
---- -----------
MPM mpm-identifier
NET network name
HOST host name
PORT address of MPM within the host
USER user name
ORG organization name
CITY city
STATE state
COUNTRY country
ZIP zip code
PHONE phone number
名前記述---- ----------- ホストUSERユーザ名前ORG組織名前市の都市の州州のCOUNTRY国のZIP郵便番号電話電話番号の中のMPMのMPM mpm識別子NETネットワーク名HOSTホスト名PORTアドレス
The minimum mail box is an Address.
最小のメールボックスはAddressです。
[Page 24] Postel
[24ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
MPM-Identifier
mpm識別子
The internetwork address of the MPM. This may be the ARPA Internet
Address or an X.121 Public Data Network Address [29]. The
mpm-identifier is a property list which has one <name,value> pair.
This unusual structure is used so that it will be easy to determine
the type of address used.
MPMのインターネットワークアドレス。 これは、ARPAインターネットAddressかX.121 Public Data Network Address[29]であるかもしれない。 値の>組、mpm識別子は1つの<名がある特性のリストです。 この珍しい構造は、アドレスのタイプが使用したことを決定しやすいようになるように使用されています。
Network
ネットワーク
This character string name of a network.
ネットワークのこの文字列名。
Operation
操作
This names the operation or procedure to be performed. It is a
character string name.
これは、実行されるために操作か手順を命名します。 それは文字列名です。
Organization
組織
This character string name of a organization.
組織のこの文字列名。
Phone
電話
This character string name representation of a phone number. For
example the phone number of ISI is 1 (international region) + 213
(area code) + 822 (central office) + 1511 (station number) =
12138221511.
電話番号のこの文字列名前表現。 例えば、ISIの電話番号は1(国際的な領域)+213(市外局番)+822(電話局)+1511(ステーション番号)=12138221511です。
Port
ポート
This names the port or subaddress within a host of the MPM. The
default port for the MPM is 45 (55 octal) [4].
これはMPMのホストの中でポートか「副-アドレス」を命名します。 MPMのためのデフォルトポートは45(55 8進)[4]です。
Reference
参照
The reference is an identification from an earlier message.
参照は以前のメッセージからの識別です。
State
状態
The character string name of a state.
状態の文字列名。
Postel [Page 25]
ポステル[25ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
Trace
跡
Each MPM that handles the message must add its handling-stamp to
this list. This will allow detection of messages being sent in a
loop within the internet mail system, and aid in fault isolation.
メッセージを扱う各MPMは取り扱いスタンプをこのリストに追加しなければなりません。 これはインターネットメールシステムの中の輪、および欠点分離における援助で送られるメッセージの検出を許すでしょう。
Trail
道
When a message is sent through the internetwork environment, it
acquires this trace, a list of MPMs that have handled the message.
This list is then carried as the trail in a reply or acknowledgment
of that message. Requests and replies always have a trace and each
MPM adds its handling-stamp to this trace. Replies, in addition,
have a trail which is the complete trace of the original message.
インターネットワーク環境を通してメッセージを送るとき、それはこの跡(メッセージを扱ったMPMsのリスト)を取得します。 そして、このリストはそのメッセージの回答か承認における道として運ばれます。 要求と回答には、跡がいつもあります、そして、各MPMはこの跡に取り扱いスタンプを加えます。 回答には、オリジナルのメッセージの完全な跡である道がさらに、あります。
Transaction Number
トランザクション番号
This is a number which is uniquely associated with this transaction
by the originating MPM. It identifies the transaction. (A
transaction is a message and acknowledgment.) A transaction number
must be unique during the time which the message (a request or
reply) containing it could be active in the network.
これは起因しているMPMによって唯一このトランザクションに関連づけられる数です。 それはトランザクションを特定します。 (トランザクションは、メッセージと承認です。) トランザクション番号は中の能動態がネットワークであったならそれを含むメッセージ(要求か回答)がそうすることができた時間、ユニークであるに違いありません。
Type-of-Service
サービスのタイプ
A service parameter for the delivery of a message, for instance a
message could be delivered (REGULAR), forwarded (FORWARD), turned
over to general delivery (GENDEL) (i.e., allow a person to decide
how to further attempt to deliver the message), or require priority
handling (PRIORITY).
メッセージの配送のためのサービスパラメタ、例えば、メッセージは(REGULAR)が提供されるか、(FORWARD)を進めるか、局留め郵便(GENDEL)(すなわち、人がメッセージを提供するのをさらに試みる方法を決めるのを許容する)に終わるようになるか、または優先権取り扱い(PRIORITY)を必要とするかもしれません。
User
ユーザ
The character string name of a user.
ユーザの文字列名。
X121 Address
X121アドレス
This identifies a host in the Public Data Network environment. When
used as a part of identifier, it identifies the originating host of
a message. The X121 address is a sequence of up to 14 digits [29].
For use in the MPMs the X121 address is represented in decimal
digits.
これはPublic Data Network環境でホストを特定します。 識別子の一部として使用されると、それはメッセージの送信元ホストを特定します。 X121アドレスは最大14ケタ[29]の系列です。 MPMsにおける使用において、X121アドレスは10進数字で表されます。
[Page 26] Postel
[26ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
Zip Code
郵便番号
The character string representation of a postal zip code. The zip
code of ISI is 90291.
郵便の郵便番号の文字列表現。 ISIの郵便番号は90291です。
3.7. Data Elements
3.7. データ要素
The data elements defined here are similar to the data structure and encoding used in NSW [30].
ここで定義されたデータ要素はNSW[30]で使用されるデータ構造とコード化と同様です。
Each of the diagrams which follow represent a sequence of octets. Field boundaries are denoted by the "|" character, octet boundaries by the "+" character. Each element begins with a one-octet code. The order of the information in each element is left-to-right. In fields with numeric values the high-order (or most significant) bit is the left-most bit. For transmission purposes, the leftmost octet is transmitted first. Cohen has described some of the difficulties in mapping memory order to transmission order [31].
従うそれぞれのダイヤグラムは八重奏の系列を表します。 「分野境界が指示される、」|「キャラクタ、「+」キャラクタによる八重奏境界。」 各要素は1八重奏のコードで始まります。 各要素における、情報の注文を右に残します。 数値がある分野では、高い注文であって(最も重要)のビットが最も左のビットです。 トランスミッション目的のために、一番左八重奏は最初に、伝えられます。 コーエンはトランスミッション命令[31]にメモリオーダーを写像することにおける苦労のいくつかについて説明しました。
Code Type Representation ---- ---- --------------
コードタイプ表現---- ---- --------------
+------+
0 No Operation | 0 |
+------+
+------+ 0いいえ操作| 0 | +------+
+------+------+------+------+------
1 Padding | 1 | octet count | Data ...
+------+------+------+------+------
+------+------+------+------+------ 1 詰め物| 1 | 八重奏カウント| データ… +------+------+------+------+------
+------+------+
2 Boolean | 2 | 1/0 |
+------+------+
+------+------+ 2論理演算子| 2 | 1/0 | +------+------+
+------+------+------+
3 Index | 3 | Data |
+------+------+------+
+------+------+------+ 3インデックス| 3 | データ| +------+------+------+
+------+------+------+------+------+
4 Integer | 4 | Data |
+------+------+------+------+------+
+------+------+------+------+------+ 4整数| 4 | データ| +------+------+------+------+------+
Postel [Page 27]
ポステル[27ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
Extended +------+------+------+------+------
5 Precision | 5 | octet count | Data ...
Integer +------+------+------+------+------
拡張+------+------+------+------+------ 5 精度| 5 | 八重奏カウント| データ… 整数+------+------+------+------+------
+------+------+------+------+------
6 Bit String | 6 | bit count | Data ...
+------+------+------+------+------
+------+------+------+------+------ 6ビット列| 6 | ビットカウント| データ… +------+------+------+------+------
+------+------+------
7 Name String | 7 | count| Data ...
+------+------+------
+------+------+------ 7名前ストリング| 7 | カウント| データ… +------+------+------
+------+------+------+------+------
8 Text String | 8 | octet count | Data ...
+------+------+------+------+------
+------+------+------+------+------ 8 テキスト文字列| 8 | 八重奏カウント| データ… +------+------+------+------+------
+------+------+------+------+-----
9 List | 9 | octet count | Data ...
+------+------+------+------+-----
+------+------+------+------+----- 9リスト| 9 | 八重奏カウント| データ… +------+------+------+------+-----
+------+------+------+------+------
10 Proplist | 10 | octet count | Data ...
+------+------+------+------+------
+------+------+------+------+------ 10 Proplist| 10 | 八重奏カウント| データ… +------+------+------+------+------
+------+
11 End of List | 11 |
+------+
+------+リストの11終わり| 11 | +------+
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. The type-octet is followed by a three-octet count of the number of octets to follow. No action is taken with this data but the count of dummy octets must be correct to indicate the next element code.
要素コード1(PAD)は、テストへのメッセージで多量のデータを送るのに使用されるか、または目的を水増ししています。 八重奏の数の3八重奏のカウントはタイプ八重奏のあとに続いて、続きます。 このデータで行動を全く取りませんが、ダミーの八重奏のカウントは、次の要素コードを示すために正しくなければなりません。
Element code 2 (BOOLEAN) is a boolean data element. The octet following the type-octet has the value 1 for True and 0 for False.
要素コード2(ブール)は論理演算子データ要素です。 タイプ八重奏に続く八重奏はTrueのための値1とFalseのための0を持っています。
[Page 28] Postel
[28ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
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 (EPI) is an extended precision integer. The type octet is followed by a three-octet count of the number of data octets to follow. Representation is two's complement.
要素コード5(EPI)は拡大精度整数です。 データ八重奏の数の3八重奏のカウントはタイプ八重奏のあとに続いて、続きます。 表現は2の補数です。
Element code 6 (BITSTR) is a bit string element for binary data. The bit string is padded on the right with zeros to fill out the last octet if the bit string does not end on an octet boundary. This data type must have the bit-count in the three-octet count field instead of the number of octets.
要素コード6(BITSTR)はバイナリ・データのために要素を少し結ぶことです。 ビット列が八重奏境界で終わらないならビット列は右でゼロで水増しされて、最後の八重奏に書き込みます。 このデータ型は八重奏の数の代わりに3八重奏のカウント分野にビットカウントを持たなければなりません。
Element code 7 (NAME) is used for the representation of character string names (or other short strings). The type octet is followed by a one-octet count of the number of characters (one per octet) to follow. Seven bit ASCII characters are used, right justified in the octet. The high order bit in the octet is zero.
要素コード7(NAME)は文字列名(または、他の脆いストリング)の表現に使用されます。 キャラクタ(1八重奏あたり1つ)の数の1八重奏のカウントはタイプ八重奏のあとに続いて、続きます。 7ビットのASCII文字は、中古であって、八重奏でまさしく正当です。 八重奏における高位のビットはゼロです。
Element code 8 (TEXT) is used for the representation of text. The type octet is followed by a three-octet count of the number of characters (one per octet) to follow. Seven bit ASCII characters are used, right justified in the octet. The high order bit in the octet is zero.
要素コード8(TEXT)はテキストの表現に使用されます。 キャラクタ(1八重奏あたり1つ)の数の3八重奏のカウントはタイプ八重奏のあとに続いて、続きます。 7ビットのASCII文字は、中古であって、八重奏でまさしく正当です。 八重奏における高位のビットはゼロです。
Element code 9 (LIST) can be used to create structures composed of other elements. The three-octet octet count specifies the number of octets in the whole list (i.e., the number of octets following this count field to the end of the list, not including the ENDLIST octet). The two-octet item count contains the number of elements which follow. Any element may be used including list itself.
他の要素で構成された構造を作成するのに、要素コード9(LIST)を使用できます。 3八重奏の八重奏カウントは全体のリスト(すなわち、ENDLIST八重奏を含んでいるのではなく、リストの終わりまでこのカウント野原に続く八重奏の数)の八重奏の数を指定します。 2八重奏の項目カウントは従う要素の数を含んでいます。 リスト自体を含んでいて、どんな要素も使用されるかもしれません。
+------+------+------+------+------+------+
| 9 | octet count | item count |
+------+------+------+------+------+------+
+------+------/---+
repeated | element |
+------+------/---+
+-------+
|ENDLIST|
+-------+
+------+------+------+------+------+------+ | 9 | 八重奏カウント| 項目カウント| +------+------+------+------+------+------+ +------+------/---繰り返された+| 要素| +------+------/---+ +-------+ |ENDLIST| +-------+
In some situations it may not be possible to know the length of a list
いくつかの状況で、リストの長さを知るのは可能でないかもしれません。
Postel [Page 29]
ポステル[29ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
until the head of it has been transmitted. To allow for this a special ENDLIST element is defined. A list of undetermined length is transmitted with the octet count cleared to zero, and the item count cleared to zero. A null or empty List, one with no elements, has an octet count of two (2) and an item count of zero (0). The ENDLIST element always follows a LIST, even when the length is determined.
それのヘッドが伝えられるまで。 これを考慮するために、特別なENDLIST要素は定義されます。 八重奏カウントがゼロまでクリアされて、項目カウントがゼロまでクリアされている状態で、非決定している長さのリストは伝えられます。 ヌルの、または、空のList(要素のない1)には、2(2)の八重奏カウントと(0)がない項目カウントがあります。 長さが決定してさえいるとき、ENDLIST要素はいつもLISTに続きます。
Element code 10 (PROPLIST) is the Property List element. It is a special case of the list element, in which the elements are in pairs and the first element of each pair is a name. It has the following form:
要素コード10(PROPLIST)はProperty List要素です。 それはリスト要素の特別なケースです、そして、それぞれの組の最初の要素は名前です。(そこでは、要素が対になっています)。 それで、以下は形成されます:
+------+------+------+------+------+
| 10 | octet count | pair |
+------+------+------+------+------+
+------+------/---+------+------/---+
repeated | name element | value element |
+------+------/---+------+------/---+
+-------+
|ENDLIST|
+-------+
+------+------+------+------+------+ | 10 | 八重奏カウント| 組| +------+------+------+------+------+ +------+------/---+------+------/---繰り返された+| 名前要素| 価値要素| +------+------/---+------+------/---+ +-------+ |ENDLIST| +-------+
The Property List structure consists of a set of unordered <name,value> pairs. The pairs are composed of a name which must be a NAME element and a value which may be any kind of element. Following the type code is a three-octet octet count of the following octets. Following the octet count is a one-octet pair count of the number of <name,value> pairs in the property list.
>組は、Property List構造が1セットの順不同の<名から成るのを評価します。 組はNAME要素であるに違いない名前とどんな種類の要素であるかもしれない価値でも構成されます。 タイプコードに従うのは、以下の八重奏の3八重奏の八重奏カウントです。 所有地の値の>組は、八重奏カウントに続くのが、<名の数の1八重奏の組カウントであると記載します。
The name of a <name,value> pair is to be unique within the property list, that is, there shall be at most one occurrence of any particular name in one property list.
<名の名前、値の>組が特性のリストの中で特有であることになっている、すなわち、最も1つに、1つの特性のリストにおける、どんな特定の名前の発生もあるでしょう。
In some situations it may not be possible to know the length of a property list until the head of it has been transmitted. To allow for this the special ENDLIST element is defined. A property list of undetermined length is transmitted with the octet count cleared to zero, and the pair count cleared to zero. A null or empty property list, one with no elements, has an octet count of one (1) and an pair count of zero (0). The ENDLIST element always follows a property list, even when the length is determined.
いくつかの状況で、それのヘッドが伝えられるまで、特性のリストの長さを知るのは可能でないかもしれません。 これを考慮するために、特別なENDLIST要素は定義されます。 八重奏カウントがゼロまでクリアされて、組カウントがゼロまでクリアされている状態で、非決定している長さの特性のリストは伝えられます。 ヌルの、または、空の特性のリスト(要素のない1)には、1つ(1)の八重奏カウントと(0)がない組カウントがあります。 長さが決定してさえいるとき、ENDLIST要素はいつも特性のリストに従います。
Element code 11 (ENDLIST) is the end of list element. It marks the end of the corresponding list or property list.
要素コード11(ENDLIST)はリスト要素の端です。 それは対応するリストか特性のリストの終わりを示します。
[Page 30] Postel
[30ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
Structure Sharing
構造共有
When messages are batched in message-bags for transmission, it may
often be the case that the same document will be sent to more than
one recipient. Since the document portion can usually be expected
to be the major part of the message, much repeated data would be
sent if a copy of the document for each recipient were to be shipped
in the message-bag.
メッセージがトランスミッションのためのメッセージバッグでbatchedされるとき、しばしば同じドキュメントを1人以上の受取人に送るのは、事実であるかもしれません。 メッセージの大半であると通常ドキュメント部分を予想できて、各受取人へのドキュメントのコピーがメッセージバッグで出荷することであるなら多くの繰り返しデータを送ります。
To avoid this redundancy, messages may be assembled in the
message-bag so that actual data appears on its first occurrence and
only references to it appear in later occurrences. When data is
shared, the first occurrence of the data will be tagged, and later
locations where the data should appear will only reference the
earlier tagged location. All references to copied data point to
earlier locations in the message-bag. The data to be retrieved is
indicated by the tag.
この冗長を避けるために、メッセージがメッセージバッグで組み立てられるかもしれないので、実際のデータは最初の発生に現れます、そして、それの参照だけが後の発生に現れます。 データが共有されるとき、データの最初の発生はタグ付けをされるでしょう、そして、データが現れるべきである後の位置は以前のタグ付けをされた位置に参照をつけるだけでしょう。 コピーされたデータのすべての参照がメッセージバッグに以前の位置を示します。 検索されるべきデータはタグによって示されます。
This is a very general sharing mechanism. PLEASE NOTE THAT THE MPM
WILL NOT SUPPORT THE FULL USE OF THIS MECHANISM. THE MPM WILL ONLY
SUPPORT SHARING OF WHOLE DOCUMENTS. No other level of sharing will
be supported by the MPMs.
これは非常に一般的な共有メカニズムです。 mpmはこのメカニズムの完全利用をサポートしないでしょう。 mpmは全体のドキュメントの共有をサポートするだけでしょう。 他のレベルの共有はMPMsによってサポートされないでしょう。
This sharing mechanism may be used within a document as long as all
references refer to tags within the same document.
すべての参照が同じドキュメントの中のタグについて言及する限り、この共有メカニズムはドキュメントの中に使用されるかもしれません。
Sharing is implemented by placing a share-tag on the first
occurrence of the data to be shared, and placing a share-reference
at the locations where copies of that data should occur.
共有は、データの共有されるべき最初の発生にシェアタグを置いて、そのデータのコピーが現れるはずである位置にシェア参照をみなすことによって、実装されます。
+------+------+------+
12 Share Tag | 12 | share-index |
+------+------+------+
+------+------+------+ 12シェアタグ| 12 | 株価指数| +------+------+------+
+------+------+------+
13 Share Reference | 13 | share-index |
+------+------+------+
+------+------+------+ 13シェア参照| 13 | 株価指数| +------+------+------+
Element code 12 (S-TAG) is a share tag element. The two octets
following the type-octet specify the shared data identification code
for the following data element. Note that s-tag is not a DATA
element, in the sense that data elements encode higher level
objects.
要素コード12(S-TAG)はシェアタグ要素です。 タイプ八重奏に続く2つの八重奏が以下のデータ要素に共有データ識別コードを指定します。 データ要素が、より高い平らなオブジェクトをコード化するという意味でs-タグがDATA要素でないことに注意してください。
Element code 13 (S-REF) is a share reference element. The two
要素コード13(S-REF)はシェア参照要素です。 2
Postel [Page 31]
ポステル[31ページ]
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
octets following the type-octet specify the referenced shared data
identification code.
タイプ八重奏に続く八重奏が参照をつけられた共有データ識別コードを指定します。
An example of using this mechanism is
このメカニズムを使用する例はそうです。
( ( <a>, <b> ) ( <c>, <b> ) )
((<a>、<b>)(<c>、<b>))
could be coded as follows to share <b>
<b>を共有するために以下の通りコード化できました。
( ( <a>, <s-tag-1><b> ) ( <c>, <s-ref-1> ) )
((<a>、<sタグ-1><b>)(<c>、<s審判-1>))
To facilitate working with structures which may contain shared data,
the two high-order bits of the list and property list element codes
are reserved for indicating if the structure contains data to be
shared or contains a reference to shared data. That is, if the
high-order bit of the list or property list element code octet is
set to one then the property list contains a share-reference to
shared data. Or, if the second high-order bit is set to one the
structure contains a share-tag for data to be shared.
共有データを含むかもしれない構造で働くのを容易にするために、リストと特性のリスト要素コードの2高位のビットが、共有されるために構造がデータを含むかどうかを示すために控えられるか、または共有データに参照を含んでいます。 すなわち、リストか特性のリスト要素コード八重奏の高位のビットが1つに設定されるなら、特性のリストは共有データのシェア参照を含んでいます。 または、2番目の高位のビットが1つに設定されるなら、構造はデータが共有されるシェアタグを含んでいます。
The example above is now repeated in detail showing the use of the
high-order bits.
上記の例は、現在、詳細に高位のビットの使用を示していながら、繰り返されます。
+------+------+------+------+------+------+------+------+
|11 - 9|01 - 9| <a> | 12 | 0 | 1 | <b> | 11 |
+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+
|10 - 9| <c> | 13 | 0 | 1 | 11 | 11 |
+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+------+ |11 - 9|01 - 9| <は>です。| 12 | 0 | 1 | <b>。| 11 | +------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+ |10 - 9| <c>。| 13 | 0 | 1 | 11 | 11 | +------+------+------+------+------+------+------+
It is not considered an error for an element to be tagged but not
referenced.
それは、要素がタグ付けをされますが、参照をつけられないように誤りであると考えられません。
A substructure with internal sharing may be created. If such a
substructure is closed with respect to sharing -- that is, all
references to its tagged elements are within the substructure --
then there is no need for the knowledge of the sharing to propagate
up the hierarchy of lists. For example, if the substructure is:
内部の共有がある基礎は作成されるかもしれません。 そのような基礎が共有に関して閉じられるなら(基礎の中にタグ付けをされた要素のすなわちすべての参照があります)、共有に関する知識がリストの階層構造に伝播される必要は全くありません。 基礎が例えばそうなら:
00-LIST ( a b c b )
00リスト(b c b)
which with sharing is:
共有があるどれがあるか:
11-LIST ( a T1:b c R1 )
11リスト(T1: b c R1)
When this substructure is included in a large structure the high
この基礎が多に含まれていたら、高値を構造化してください。
[Page 32] Postel
[32ページ] ポステル
August 1980
Internet Message Protocol
Specification
1980年8月のインターネットメッセージプロトコル仕様
order bits can be reset since the substructure is closed with
respect to sharing. For example:
基礎が共有に関して閉じられるので、オーダービットをリセットできます。 例えば:
00-LIST ( x 11-LIST ( a T1:b c R1 ) y )
00リスト(x11-LIST(T1: b c R1)y)
Note: While sharing adds transmission and memory efficiency, it is
costly in processing to separate shared elements. This is the main
reason for restricting the sharing supported by the MPM. At some
later time these restrictions may be eased.
以下に注意してください。 共有はトランスミッションとメモリ効率を加えますが、処理では、共有された要素を切り離すのは高価です。 これはMPMによってサポートされた共有を制限する主な理由です。 何らかの後の時間に、これらの制限は緩和されるかもしれません。
It is possible to create loops, "strange loops" and "tangled
hierarchies" using this mechanism [32]. The MPM will not check for
such improper structures within documents, and will not deliver
messages involved in such structures between documents.
輪、「奇妙な輪」、およびこのメカニズム[32]を使用する「もつれている階層構造」を作成するのは可能です。 MPMはドキュメントの中のそのような不適当な構造がないかどうかチェックしないで、またそのような構造にかかわるメッセージをドキュメントの間に提供しないでしょう。
If an encryption scheme is used to ensure the privacy of
communication it is unlikely that any parts of the message can be
shared. This is due to the fact that in most case the encryption
keys will be specific between two individuals. There may be a few
cases where encrypted data may be shared. For example, all the
members of a committee may use a common key when acting on committee
business, or in a public key scheme a document may be "signed" using
the private key of the sender and inspected by anyone using the
public key of the sender.
暗号化体系がコミュニケーションのプライバシーを確実にするのに使用されるなら、メッセージのどんな部分も共有できるのはありそうもないです。 これはほとんどの場合では、暗号化キーが2人の個人の間で特定になるという事実のためです。 いくつかのケースが暗号化されたデータが共有されるかもしれないところにあるかもしれません。 委員会のビジネスに影響するとき、例えば、委員会のすべてのメンバーが一般的なキーを使用するかもしれないか、公開鍵体系では、ドキュメントは、送付者の公開鍵を使用することで送付者の秘密鍵を使用することで「署名され」て、だれによっても点検されるかもしれません。
Postel [Page 33]
ポステル[33ページ]
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
[Page 34] Postel
[34ページ] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
4. OTHER ISSUES
4. 他の問題
This section discusses various other issues that need to be dealt with in a computer message system.
このセクションはコンピュータメッセージシステムで対処される必要がある他の様々な問題について論じます。
4.1. Accounting and Billing
4.1. 会計と支払い
Accounting and billing must be performed by the MPM. The charge to the user by the message delivery system must be predictable, and so cannot depend on the actual cost of sending a particular message which incurs random delays, handling and temporary storage charges. Rather, these costs must be aggregated and charged back to the users on an average cost basis. The user of the service may be charged based on the destination or distance, the length of the message, type of service, or other parameters selected as the message is entered into the delivery system, but must not depend on essentially random handling by the system of the particular message.
MPMは会計と支払いを実行しなければなりません。 メッセージ配送システムによるユーザへの充電は、予測できなければならないので、無作為の遅れ、取り扱い、および一時記憶領域充電を被る特定のメッセージを送る実費に依存できません。 むしろ、これらのコストを集められて、平均した原価基準でユーザに請求し返さなければなりません。 サービスのユーザは、目的地、距離、メッセージの長さ、サービスのタイプ、またはメッセージが配送システムに入力されるので選ばれた他のパラメタに基づいて請求されるかもしれませんが、特定のメッセージのシステムで本質的には無作為の取り扱いを当てにしてはいけません。
This means it is pointless to have each message carry an accumulated charge (or list of charges). Rather, the MPM will keep a log of messages handled and periodically bill the originators of those messages.
これは、各メッセージに蓄積された充電(または、料金一覧表)を運ばせるのが、無意味であることを意味します。 むしろ、MPMはメッセージに関するログを扱っておいて、定期的にそれらのメッセージの創始者に請求するでしょう。
It seems that the most reasonable scheme is to follow the practice of the international telephone authorities. In such schemes the authority where the message originates bills the user of the service for the total charge. The authorities assist each other in providing the international message transfer and the authorities periodically settle any differences in accounts due to an imbalance in international traffic.
最も妥当な体系が国際電話当局の習慣に続くことであるように思えます。 そのような体系では、メッセージが起因する権威は全部の請求額のためのサービスのユーザに請求します。 国際的なメッセージ転送と当局が不均衡のため国際輸送で定期的に何かアカウントの違いに決着をつけるなら、当局は互いを助けます。
Thus the MPMs will keep logs of messages handled and will periodically charge their neighboring MPM for messages handled for them. This settlement procedure is outside the message system and between the administrators of the MPMs.
したがって、MPMsはメッセージに関するログを扱っておいて、それらのために扱われたメッセージのために定期的にそれらの隣接しているMPMを宣言するでしょう。 メッセージシステムの外と、そして、MPMsの管理者の間には、この解決手順はあります。
As traffic grows it will be impractical to log every message individually. It will be necessary to establish categories of messages (e.g., short, medium, large) and only count the number in each category.
トラフィックが成長するとき、個別にあらゆるメッセージを登録するのは非実用的でしょう。 メッセージ(例えば、短くて、中型の多大)のカテゴリを確立して、各カテゴリにおける数を数えるだけが必要でしょう。
The MPM at the source of the message will have a local means of identifying the user to charge for the message delivery service. The relay and destination MPMs will know which neighbor MPMs to charge (or settle with) for delivery of their messages.
メッセージの源のMPMには、メッセージデリバリ・サービスに課金するユーザを特定するローカルの手段があるでしょう。 リレーと目的地MPMsが、どの隣人MPMsを請求したらよいかを知る、(清算、)、彼らのメッセージの配送のために。
Postel [Page 35]
ポステル[35ページ]
August 1980
Internet Message Protocol
Other Issues
1980年8月のインターネットメッセージプロトコル他の問題
4.2. Addressing and Routing
4.2. アドレシングとルート設定
The mailbox provides for many types of address information. The MPMs in the ARPA internet can most effectively use the internet address [2]. The use of other address information is not yet very clear. Some thoughts on addressing issues may be found in the references [33,34,35].
メールボックスは多くのタイプに関するアドレス情報に備えます。 ARPAインターネットにおけるMPMsは最も効果的にインターネットアドレス[2]を使用できます。 他のアドレス情報の使用はまだそれほど明確ではありません。 問題提示に関するいくつかの考えが参照[33、34、35]で見つけられるかもしれません。
An MPM sometimes must make a routing decision when it is acting as a relay-MPM (or source MPM). It must be able to use the information from the mailbox to determine to which of its neighbor MPMs to send the message. One way this might be implemented is to have a table of destination networks with corresponding neighbor MPM identifiers to use for routing toward that network.
MPMは時々いつリレー-MPM(または、ソースMPM)として機能しているかというルーティング決定をしなければなりません。 それは、隣人MPMsのどれを送ったらよいかとメッセージを決定するのにメールボックスからの情報を使用できなければなりません。 これが実装されるかもしれない1つの方法はルーティングにそのネットワークに向かって使用する対応する隣人MPM識別子と共に送信先ネットワークのテーブルを持つことです。
It is not expected that such routing tables would be very dynamic. Changes would occur only when new MPMs came into existence or MPMs went out of service for periods of days.
そのような経路指定テーブルがそれほどダイナミックでないと予想されます。 新しいMPMsが生まれたか、またはMPMsが何日もの期間使われなくなるようになったときだけ、変化は起こるでしょう。
Even with relatively slowly changing routing information the MPMs need an automatic mechanism for adjusting their routing tables. The routing problem here is quite similar to the problem of routing in a network of packet switches such as the ARPANET IMPs or a set of internet gateways. A great deal of work has been done on such problems and many simple schemes have been found faulty. There are details of these procedures which may become troublesome when the number of nodes grows beyond a certain point or the frequency of update exchanges gets large.
ゆっくり比較的変化しているルーティング情報があってもMPMsは彼らの経路指定テーブルを調整するのに機械的なメカニズムを必要とします。 ここのルーティング問題はアルパネットIMPsかインターネットゲートウェイの1セットなどのパケット交換機のネットワークにおいてルーティングの問題と全く同様です。 大きな仕事がそのような問題で終わっていました、そして、多くの簡単な体系が不完全であることがわかりました。 ノードの数が一旦ある線を越えると成長するか、またはアップデート交換の頻度が大きくなるとき厄介になるかもしれないこれらの手順の詳細があります。
A basic routing scheme is to have a table of <network-name, mpm-identifier> pairs. The MPM could look up the network name found in the mailbox of the message and determine the internet mpm-identifier of the next MPM to which to route the message. To permit automatic routing updates another column would be added to indicate the distance to the destination. This could be measured in several ways, for example, the number of relay MPM (or hops) to the final destination. In this case each entry in the table is a triple of <network-name, mpm-identifier, distance>.
基本的なルーティング体系が<ネットワーク名のテーブルを持つことであり、mpm識別子>は対にされます。 MPMはメッセージのメールボックスの中に見つけられたネットワーク名を調べて、メッセージを発送する次のMPMに関するインターネットmpm識別子を決定できました。 別のコラムに自動ルーティングアップデートを可能にするのは、距離を目的地に示すために加えられるでしょう。 いくつかの道、例えば、最終的な目的地へのリレーMPM(または、ホップ)の数でこれを測定できました。 この場合、テーブルの各エントリーは<ネットワーク名、mpm識別子、距離>の三重です。
To update the routing information when changes occur an MPM updates its table. It then sends to each next MPM in its table a table of pairs <network-name, distance>, which say in effect "I can get a message to each of these networks with "cost" distance." An MPM which receives such an update will add to all the distances the distance to the MPM sending the update (e.g., one hop) and compare the information with its own table.
変化がいつ起こるかというルーティング情報をアップデートするために、MPMはテーブルをアップデートします。 次に、それはテーブルで組<ネットワーク名のテーブルを次の各MPMに送ります、距離>、事実上、「私は「費用」距離があるそれぞれのこれらのネットワークに伝言を伝えることができます」と言うどれ。 そのようなアップデートを受けるMPMがアップデートを送りながらすべての距離にMPMへの距離を加える、(例えば、ワンバウンド、)、それ自身のテーブルと情報を比べてください。
[Page 36] Postel
[36ページ] ポステル
August 1980
Internet Message Protocol
Other Issues
1980年8月のインターネットメッセージプロトコル他の問題
If the update information shows that the distance to a destination network is now smaller via the MPM which sent the update, the MPM changes its own table to reflect the better route, and the new distance. If the MPM has made changes in its table it sends update information to all the MPMs listed as next-MPMs in its table.
アップデート情報が、アップデートを送ったMPMを通して、送信先ネットワークへの距離が現在よりわずかであることを示すなら、MPMは、より良いルート、および新しい距離を反映するためにそれ自身のテーブルを変えます。 MPMがテーブルの変更を行ったなら、それは次のMPMsとしてテーブルに記載されたすべてのMPMsにアップデート情報を送ります。
One further feature is that when a new network comes into existence an entry must be added to the table in each MPM. The MPMs should therefore expect the case that update information may contain entries which are new networks, and in such an event add these entries to their own tables.
さらなる1つの特徴は新しいネットワークが出現するとき、各MPMのテーブルにエントリーを加えなければならないということです。 したがって、MPMsは、情報をアップデートするこの件が新しいネットワークであるエントリーを含んでいて、そのようなイベントでそれら自身のテーブルにこれらのエントリーを加えるかもしれないと予想するはずです。
When a new MPM comes into existence it will have an initial table indicating that it is a good route (short distance) to the network it is in, and will have entries for a few neighbor networks. It will send an initial "update" to those neighbor MPMs which will respond with more complete tables, thus informing the new MPM of routes to many networks.
新しいMPMが生まれると、それは、初期のテーブルにそれが良いルート(短距離)であることをそれがあるネットワークに示させて、いくつかの隣人ネットワークのためのエントリーを持つでしょう。 それは、より完全なテーブルで応じるそれらの隣人MPMsに初期の「アップデート」を送るでしょう、その結果、多くのネットワークへのルートについて新しいMPMに知らせます。
This routing update mechanism is a simple minded scheme and may have to be replaced as the system of MPMs grows. In addition it ignores the opportunity for MPMs to use other information (besides destination network name) for routing. MPMs may have tables that indicate next-MPMs based on city, telephone number, organization, or other categories of information.
MPMsのシステムが成長するとき、このルーティングアップデートメカニズムを簡単な気にされた体系であり、取り替えなければならないかもしれません。 さらに、それはMPMsがルーティングに、他の情報(目的地ネットワーク名以外に)を使用する機会を無視します。 MPMsには、情報の都市、電話番号、組織、または他のカテゴリに基づく次のMPMsを示すテーブルがあるかもしれません。
4.3. Encryption
4.3. 暗号化
It is straightforward to add the capability to have the document portion of messages either wholly or partially encrypted. An additional basic data element is defined to carry encrypted data. The data within this element may be composed of other elements, but that could only be perceived after the data was decrypted.
それは、完全にメッセージのドキュメント部分を持つ能力を加えるために簡単であるか部分的に暗号化されています。 追加基礎データ要素は、暗号化されたデータを運ぶために定義されます。 この要素の中のデータは他の要素で構成されたかもしれませんが、データが解読された後にそれを知覚できただけです。
+------+------+------+------+
14 Encrypt | 14 | octet count |
+------+------+------+------+
+------+------+------+------14が暗号化する+| 14 | 八重奏カウント| +------+------+------+------+
+------+------+------+-------
|alg id| key id | Data ...
+------+------+------+--------
+------+------+------+------- |algイド| 主要なイド| データ… +------+------+------+--------
Element code 14 (ENCRYPT) is used to encapsulate encrypted data. The format is the one-octet type code, the three-octet octet count, a one-octet algorithm identifier, a two-octet key identifier, and count octets of data. Use of this element indicates that the data it
要素コード14(ENCRYPT)は、暗号化されたデータをカプセル化するのに使用されます。 形式は、1八重奏のタイプコードと、3八重奏の八重奏カウントと、1八重奏のアルゴリズム識別子と、2八重奏の主要な識別子と、データのカウント八重奏です。 この要素の使用がそれを示す、データ、それ
Postel [Page 37]
ポステル[37ページ]
August 1980
Internet Message Protocol
Other Issues
1980年8月のインターネットメッセージプロトコル他の問題
contains is encrypted. The encryption scheme is indicated by the algorithm identifier, and the key used is indicated by the key identifier (this is not the key itself). The NBS Data Encryption Standard (DES) [36], public key encryption [37,38,39], or other schemes may be used.
含有、暗号化されます。 暗号化体系はアルゴリズム識別子によって簡単に述べられます、そして、使用されるキーは主要な識別子によって示されます(これはキー自体ではありません)。 NBSデータ暗号化規格(DES)[36]、公開鍵暗号化[37、38、39]、または他の体系が使用されるかもしれません。
To process this data element, the user is asked for the appropriate key and the data can then be decrypted. The data thus revealed will be in the form of complete data element 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などのすべてのドキュメントヘッダー情報を含んでいて、ドキュメントのすべての分野を暗号化できたというわけではない理由が全くないことに注意してください。
[Page 38] Postel
[38ページ] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
5. THE MPM: A POSSIBLE ARCHITECTURE
5. mpm: 可能なアーキテクチャ
The heart of the internet message system is the MPM which is responsible for routing and delivering messages. Each network must have at least one MPM. These MPMs are logically connected together, and internet mail is always transferred along logical channels between them. The MPMs interface with existing local message systems.
インターネットメッセージシステムの中心は、ルーティングに責任があるMPMとメッセージを提供することです。 各ネットワークには、少なくとも1MPMがなければなりません。 これらのMPMsを論理的に一緒に接続します、そして、それらの間の論理チャネルに沿っていつもインターネットメールを移します。 MPMsは既存のローカルのメッセージシステムに接続します。
Since the local 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 and sent via the MPMs.
ローカルのメッセージシステムがインターネットシステムと非常に異なるかもしれないので、特別なプログラムが入って来るインターネットメッセージを地方の形式に変換するのに必要であるかもしれません。 同様に、他のネットワークに送信するメッセージをインターネット形式に変換して、MPMsを通して送るかもしれません。
5.1. Interfaces
5.1. インタフェース
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 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つのプロセスは、より強く結合するか(例えば、メモリを共有することによって)、またはそれほど強くなく結合できません(例えば、論理チャネルで交信することによって)。
When a UIP passes a document and a destination address to the MPM,
the MPM assigns a transaction-number and forms a message to send.
The MPM must record the relationship between the transaction-number,
the document, and the UIP, so that it can inform the UIP about the
outcome of the delivery attempt for that document when the
acknowledgment message is received at some later time.
UIPがドキュメントと送付先アドレスをMPMに渡すと、MPMはトランザクション番号を割り当てて、発信するメッセージを形成します。 MPMはトランザクション番号と、ドキュメントと、UIPとの関係を記録しなければなりません、承認メッセージが何らかの後の時間にいつ受け取られるかをそのドキュメントのための配送試みの結果の周りのUIPに知らせることができるように。
Assuming a file passing mode of communication between the UIP and
the MPM the sending and receiving of mail might involve the
following interactions:
UIPとMPMとのコミュニケーションのモードにメールの送受信を通過するファイルを仮定すると、以下の相互作用はかかわるかもしれません:
A user has an interactive session with a UIP to compose a document
to send to a destination (or list of destinations). When the user
indicates to the UIP that the document is to be sent, the UIP
places the information into a file for the MPM. The UIP may then
turn to the next request of the user.
ユーザは、目的地(または、目的地のリスト)に発信するためにドキュメントを構成するのにUIPと共に対話的なセッションを過します。 ユーザが、ドキュメントが送られることであることをUIPに示すとき、UIPはMPMのためのファイルの中に情報を置きます。 そして、UIPはユーザの次の要求に変わるかもしれません。
The MPM finds the file and extracts the the information. It
creates a message, assigning a transaction-number and forming a
deliver command. The MPM records the UIP associated with this
message. The MPM sends the message toward the destination.
MPMは、ファイルと抽出が情報であることがわかります。 トランザクション番号を割り当てて、配送コマンドを形成して、それはメッセージを作成します。 MPMはこのメッセージに関連しているUIPを記録します。 MPMは目的地に向かってメッセージを送ります。
Postel [Page 39]
ポステル[39ページ]
August 1980
Internet Message Protocol
MPM Architecture
1980年8月インターネットメッセージプロトコルmpm、アーキテクチャ
When the MPM receives a deliver message from another MPM addressed
to a user in its domain, it extracts the document and puts it into
a file for the UIP associated with the destination user. The MPM
also sends an acknowledge message to the originating MPM.
aを受けたらドメインでユーザに扱われた別のMPMからメッセージを救い出してください、それは、目的地ユーザに関連しているUIPのためにドキュメントを抜粋して、ファイルにそれを入れます。 また、MPMが発信する、起因しているMPMにメッセージを承認してください。
When the MPM receives an acknowledgment for a message it sent, the
MPM creates a notification for the associated UIP and places it in
a file for that UIP.
MPMがそれが送ったメッセージのための承認を受けるとき、MPMは関連UIPのために通知を作成して、そのUIPのためにそれをファイルに置きます。
The format of these files is up to each UIP/MPM interface pair.
One reasonable choice is to use the same data structures used in
the MPM-MPM communication.
これらのファイルの形式はそれぞれのUIP/MPMインタフェース組まで達しています。 1つの正当な選択はMPM-MPMコミュニケーションで使用される同じデータ構造を使用することです。
Communication Interface
通信インターフェース
It is assumed here that the MPMs use an underlying communication
system, and TCP [3] has been taken as the model. In particular, the
MPM is assumed to be listening for a TCP connection on a TCP port,
i.e., it is a server process. The port is either given explicitly
in the mpm-identifier or takes the default vaule 45 (55 octal) [4].
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) [12,19,20,21].
ここでMPMsが基本的な通信系を使用すると思われて、TCP[3]はモデルとしてみなされました。 特に、MPMがTCPポートの上でTCP接続の聞こうとしていると思われて、すなわち、それはサーバプロセスです。 ポートは、mpm識別子で明らかに与えるか、またはデフォルトvaule45(55 8進)[4]を取ります。 一方、これが実装選択を制限することを意図しません。 プロセス間通信の他のフォームは許容されています、そして、物理的なインタコネクトの他のタイプは受入れられます。 1つは、MPMs(信頼できるコミュニケーションを提供するのに適当なプロトコルを使用します)[12、19、20、21]とインタコネクトするのにダイヤル通話を使用さえするかもしれません。
5.2. The MPM Organization
5.2. mpm、組織
Messages in the internet mail system are transmitted in lists called message-bags (or simply bags), each bag containing one or more messages. 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.
1つ以上のメッセージを含んでいて、インターネットメールシステムのメッセージはメッセージバッグ(または、単にバッグ)、各バッグと呼ばれるリストで送られます。 各MPMがそれがそれが受け取るローカルのメッセージを提供して、おそらくメッセージの目的地の、より近くで非地方のものを他のMPMsに送る機能を実装すると予想されます。
Loosely, each MPM can be separated into six components:
緩く、6つのコンポーネントに各MPMを切り離すことができます:
1--Acceptor
1--アクセプタ
Receives incoming message-bags, from other MPMs, from UIPs, or
from conversion programs.
他のMPMsか、UIPsか、変換プログラムから入って来るメッセージバッグを受けます。
2--Message-Bag Processor
2--メッセージバッグプロセッサ
Splits a bag into these three portions:
股割りaはこれらの3つの部分まで膨らみます:
[Page 40] Postel
[40ページ] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
a. Local Host Messages
b. Local Net Messages
c. Foreign Net Messages
a。 地方のHost Messages b。 地方のネットMessages c。 外国ネットのメッセージ
3--Local Host Delivery
3--ローカル・ホスト配送
Delivers local host messages, may call on conversion program.
メッセージをローカル・ホストに提供して、変換プログラムを訪問するかもしれません。
4--Local Net Delivery
4--地方のネットの配送
Delivers local net messages, may call on conversion program.
ローカルのネットのメッセージを提供して、変換プログラムを訪問するかもしれません。
5--Foreign Net Router
5--外国ネットのルータ
Forms message-bags for transmission to other MPMs and determines
the first step in the route.
他のMPMsへの伝送のためメッセージバッグを形成して、ルートで第一歩を決定します。
6--Foreign Net Sender
6--外国人のネットの送付者
Activates transmission channels to other MPMs and sends
message-bags to foreign MPMs.
他のMPMsにトランスミッションチャンネルを動かして、メッセージバッグを外国MPMsに送ります。
If the local net message system uses the protocol of the MPMs, then there need be no distinction between local net and foreign net delivery procedures.
ローカルのネットのメッセージシステムがMPMsのプロトコルを使用するなら、ローカルのネットの、そして、外国のネットの配送手順の間には、区別が全くある必要はありません。
All of these components can be thought of as independent. The function of the Acceptor is to await incoming message-bags and to insert them into the Bag-Input Queue.
同じくらい独立していた状態でこれらのコンポーネントのすべてを考えることができます。 Acceptorの機能は、入って来るメッセージバッグを待って、Bag-入力Queueにそれらを挿入することです。
The Bag-Input queue is read by the message-bag Processor which will separate and deliver suitable portions of the message-bags it retrieves from the queue to one of three queues:
Bag-入力キューは分離するメッセージバッグProcessorで読み込んで、それが待ち行列から検索するメッセージバッグの適当な部分を3つの待ち行列の1つに提供することです:
a. Local Host Queue
b. Local Net Queue
c. Foreign Net Queue
a。 地方のHost Queue b。 地方のネットQueue c。 外国ネットの待ち行列
When an MPM has a message to send to another MPM, it must add its own handling-stamp to the trace field of the command. The trace then becomes a record of the route the message has taken. An MPM should examine the trace field to see if the message is in a routing loop. All commands require the return of the trace as a trail in the matching reply command.
MPMに別のMPMに発信するメッセージがあるとき、それはコマンドの跡の分野にそれ自身の取り扱いスタンプを加えなければなりません。 そして、跡はメッセージが取ったルートに関する記録になります。 MPMは、メッセージがルーティング輪にあるかを確認するために跡の分野を調べるはずです。 すべてのコマンドが合っている応答コマンドにおける道として跡の復帰を必要とします。
All of these queues have as elements complete message-bags created by selecting messages from the input message-bags.
これらの待ち行列のすべてが要素として入力メッセージバッグからメッセージを選択することによって作成された完全なメッセージバッグを持っています。
Postel [Page 41]
ポステル[41ページ]
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
The Local Host queue serves as input to the Local Host Delivery process. This component is responsible for delivering messages to its local host. It may call on a 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 Host待ち行列はLocal Host Deliveryプロセスに入力されるように役立ちます。 このコンポーネントはメッセージをローカル・ホストに提供するのに原因となります。 それは変換プログラムにローカルのプロトコルが受け入れるフォームへのメッセージを再フォーマットに呼ぶかもしれません。 これはたぶん共有された情報をコピーするようなものにかかわるでしょう。
The Local Net queue serves as input to the Local Net Delivery process. This component is responsible for delivering messages to other hosts on its local net. It must be capable of handling whatever error conditions the local net might return, and should include the ability to retransmit. It may call on a 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ネット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 of the MPMs to which it is connected should receive the bag.
他の2つのプロセスが、より密接に結合されます。 ForeignネットRouterはForeignネットQueueから入力バッグを取ります。 含む内部の情報から、それは、それが接続されているMPMsのどれがバッグを受けるべきであるかを決定します。
It then places the bag along with the routing information into the Send Mail Queue. The Foreign Net Sender retrieves it from that queue and transmits it across a channel to the intended foreign MPM. The Sender aggregates messages to the same next MPM into a bag.
次に、それはルーティング情報に伴うバッグをSendに置きます。メールQueue。 ForeignネットSenderはその待ち行列からそれを検索して、チャンネルの向こう側に意図している外国MPMにそれを伝えます。 Senderはバッグへの同じ次のMPMへのメッセージに集めます。
The Foreign Net Router should be capable of receiving external input to its routing information table. This may come from the Foreign Net Sender in the case of a channel going down, requiring a decision to either postpone delivery or to determine a new route. The Router is responsible for maintaining sufficient information to determine where to send any incoming message-bag.
ForeignネットRouterはルーティング情報テーブルに外部の入力を受け取ることができるべきです。 これはチャンネルが落ちる場合におけるForeignネットSenderから来るかもしれません、配送を延期するか、または新しいルートを決定するという決定を必要として。 Routerは何か入って来るメッセージバッグをどこに送るかを決定するために十分な情報を維持するのに責任があります。
Forwarding
推進
An MPM may have available information on the correct mailboxes of
users which are not at its location. This information, called a
forwarding data base, may be used to return the correct address in
response to a probe command, or to actually forward a deliver
command (if allowed by the type of service).
MPMには、位置にないユーザの正しいメールボックスに関する入手可能な情報があるかもしれません。 推進データベースと呼ばれるこの情報は、調べコマンドに対応して正しいアドレスを返すか、または実際に配送コマンドを進めるのに使用されるかもしれません(サービスのタイプによって許容されているなら)。
Because such forwarding may cause the route of a message to pass
through an MPM already on the trace of this message, only the
portion of the trace back to the most recent forward action should
be used for loop detection by a relay relaying MPM, and only the
forward action entries in the trace should be checked by a
forwarding MPM.
そのような推進が既にこのメッセージの跡のMPMを通り抜けるメッセージのルートを引き起こすかもしれないので、最新の前進の行為への跡の部分だけが輪の検出にMPMをリレーするリレーで使用されるべきです、そして、跡の前進の動作エントリーだけが推進MPMによってチェックされるはずです。
[Page 42] Postel
[42ページ] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
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.
達している中で値最も高い時の周りに包装がある状態で、トランザクション番号を連続して割り当てることができます。 これは、このトランザクション番号の別のインスタンスが選ばれているとき、ネットワークにはこのソースからの特定の取引番号があるメッセージが全くないのを確実にするべきです。
The processing to separate shared elements when the routes of the
shared elements diverge while still preserving the sharing possible
appears to be an O(N*M**2) operation where N is the number of
distinct objects in a message which may be shared across message
boundaries and M is the number of messages in the bag.
まだ可能な共有を保存しているのがNがメッセージ限界の向こう側に共有されるかもしれないメッセージの異なったオブジェクトの数であることでのO(N*M**2)操作であるように見えて、Mがバッグのメッセージの数ですが、共有された要素のルートが分岐するとき、切り離す処理は要素を共有しました。
Also note that share-tags may be copied into separate message bags
which are not referenced. These could be removed with another pass
over the message bag.
また、シェアタグが参照をつけられていない別々のメッセージバッグにコピーされるかもしれないことに注意してください。 メッセージバッグの上に別のパスがある状態で、これらを取り除くことができました。
Postel [Page 43]
ポステル[43ページ]
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
[Page 44] Postel
[44ページ] ポステル
August 1980
Internet Message Protocol
1980年8月のインターネットメッセージプロトコル
6. EXAMPLES & SCENARIOS
6. 例とシナリオ
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@ISIE>
Subject: Meeting Thursday
To: Danny Cohen <Cohen@USC-ISIB>
CC: Linda
日付: 1979年3月29日-11時46分から8時0分From: ジョン Postel <Postel@ISIE 、gt;、Subject: 木曜日To:に間に合います。 ダニー Cohen <Cohen@USC-ISIB 、gt;、CC: リンダ
Danny:
ダニー:
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. The actual document above will not be shown in the coded form.
それは構造化された形式でコード化されるでしょう。 以下はこのメッセージのトップダウン世代における連続したステップを提示するでしょう。 上記の実際のドキュメントはコード化形式で見せられないでしょう。
1. message
1. メッセージ
2. (identification, command, document)
2. (識別、コマンド、ドキュメント)
3. (ID:(mpm-identifier, transaction-number),
CMD:(MAILBOX:mailbox, OPERATION:operation,
arguments, TRACE:trace),
DOC:<<document>>)
3. (ID: (mpm識別子、トランザクション番号)、CMD: (MAILBOX: OPERATION: メールボックス、操作、議論、TRACE: 跡)、DOC: <<ドキュメント>>、)
4. (ID:(mpm-identifier, transaction-number),
CMD:(MAILBOX:mailbox, OPERATION:operation,
TYPE-OF-SERVICE:regular, TRACE:trace),
DOC:<<document>>)
4. (ID: (mpm識別子、取引番号)、CMD: (MAILBOX: TYPE-OF-SERVICE: メールボックス、OPERATION: 操作、レギュラー、TRACE: 跡)、DOC: <<ドキュメント>>、)
5. (ID:(MPM:(IA:12,1,0,52,0,45), TRANSACTION:37),
CMD:(MAILBOX:(MPM:(IA:12,3,0,52,0,45),
NET:ARPA,
HOST:ISIB,
PORT:45,
USER:Cohen),
OPERATION:DELIVER,
TYPE-OF-SERVICE:REGULAR,
TRACE:(MPM:(IA:12,1,0,52,0,45)
DATE:1979-03-29-11:46-08:00,
ACTION:ORIGIN)),
DOC:<<document>>)
5. (ID:、(mpm: (アイオワ: 12、1、0、52、0、45) 取引: 37、)CMD: (メールボックス: 操作: サービスのタイプは配送してください: (ホスト: ユーザ: : (アイオワ: 12、3、0、52、0、45)が網で覆うmpm: アルパ、ポート: ISIB、45、コーエン)、通常であることで、以下をたどってください(mpm: (アイオワ: 12、1、0、52、0、45)DATE:1979-03-29-11時46分から8時0分、動作: 起源))、DOC: <<ドキュメント>>、)
Postel [Page 45]
ポステル[45ページ]
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
6. PROPLIST:(
ID:PROPLIST:(
MPM:PROPLIST:(
IA:12,1,0,52,0,45),
ENDLIST
TRANSACTION:37)
ENDLIST,
6. PROPLIST: (ID: PROPLIST:、(mpm: PROPLIST: (アイオワ: 12、1、0、52、0、45) ENDLIST取引: 37) ENDLIST
CMD:PROPLIST(
MAILBOX:(PROPLIST:(
MPM:PROPLIST(
IA:12,3,0,52,0,45),
ENDLIST
NET:ARPA,
HOST:ISIB,
PORT:45,
USER:Cohen ),
ENDLIST
OPERATION:DELIVER,
TYPE-OF-SERVICE:REGULAR,
TRACE:(PROPLIST:MPM:
(PROPLIST:
IA:12,1,0,52,0,45)
ENDLIST
DATE:1979-03-29-11:46-08:00,
ACTION:ORIGIN)),
ENDLIST
ENDLIST
DOC:<<document>>)
ENDLIST
CMD: PROPLIST、(メールボックス: (ENDLIST操作: 配送してください、サービスのタイプ: 通常です、以下をたどってください(PROPLIST: mpm: (PROPLIST:アイオワ:12、1、0、52、0、45)ENDLIST DATE:1979-03-29-11時46分から8時0分、動作: 起源)、ENDLIST ENDLIST DOC: PROPLIST: (ユーザ: mpm: PROPLIST(アイオワ: 12、3、0、52、0、45)、ENDLISTネット: アルパ、ポート: ホスト: ISIB、45、コーエン)、<<は>>を記録します)ENDLIST
[Page 46] Postel
[46ページ] ポステル
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
Example 2: Delivery and Acknowledgment
例2: 配送と承認
The following are 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に。
+-----------------------------------------------------------------+ | A B | | sending --> originating --> relay --> destination --> receiving | | user MPM MPM MPM user | | | | D C | | originating <-- relay <-- destination | | MPM MPM MPM | +-----------------------------------------------------------------+
+-----------------------------------------------------------------+ | B| | 発信-->由来-->リレー-->の目的地-->受信| | ユーザMPM MPM MPMユーザ| | | | D C| | 由来している<--リレー<--目的地| | mpm、mpm、mpm| +-----------------------------------------------------------------+
Transmission Path
トランスミッション経路
Figure 6.
図6。
Postel [Page 47]
ポステル[47ページ]
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
A. Between the originating MPM and the relay MPM.
A. 由来しているMPMとリレーMPMの間で。
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIB"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"OPERATION", NAME:"DELIVER"
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
ENDLIST
ENDLIST
NAME:"DOC", <<document>>
ENDLIST
PROPLIST: 名前: 「ID」、PROPLIST: 名前: 「mpm」、PROPLIST: PROPLIST、「名前: 名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名する」という取引」と、整数: 37ENDLISTは: "CMD"と命名します: 名前: 「メールボックス」、PROPLIST: 名前: 「mpm」、PROPLIST: 名前..アイオワ..名前..45インチ..命名..ネット..命名..アルパ..名前..ホスト..名前..命名..ポート..名前..45インチ..命名..ユーザ..名前..コーエン..名前..操作..名前..配送..名前..タイプ..サービス..名前..通常..名前..跡..記載 PROPLIST: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください。」と、: 「1979年3月29日-11時47.5分から8時0分」名前: 「起源」ENDLIST ENDLIST ENDLIST名: 名前: 「動作」、"DOC"<<ドキュメント>>ENDLISTは命名します。
[Page 48] Postel
[48ページ] ポステル
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
B. Between the relay MPM and the destination MPM.
B. リレーMPMと目的地MPMの間で。
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIB"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"OPERATION", NAME:"DELIVER"
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:48-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
ENDLIST
ENDLIST
NAME:"DOC", <<document>>
PROPLIST: 名前: 「ID」、PROPLIST: 名前: 「mpm」、PROPLIST: PROPLIST、「名前: 名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名する」という取引」と、整数: 37ENDLISTは: "CMD"と命名します: 名前: 「メールボックス」、PROPLIST: 名前: 「mpm」、PROPLIST: 名前..アイオワ..名前..45インチ..命名..ネット..命名..アルパ..名前..ホスト..名前..命名..ポート..名前..45インチ..命名..ユーザ..名前..コーエン..名前..操作..名前..配送..名前..タイプ..サービス..名前..通常..名前..跡..記載 PROPLIST: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、: 名前: 「1979年3月29日-11時47.5分から8時0分」名: 「動作」、「起源」ENDLIST PROPLISTは命名します: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 2、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください。」と、名前: "DOC"、<<ドキュメント>>は: 名前: 「1979年3月29日-11時48分から8時0分」名: 「動作」、「リレー」ENDLIST ENDLIST ENDLISTと命名します。
Postel [Page 49]
ポステル[49ページ]
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
ENDLIST
ENDLIST
C. Between the destination MPM and the relay MPM.
C. 目的地MPMとリレーMPMの間で。
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:1993
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,1,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIE"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"ACKNOWLEDGE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,3,0,52,0,45"
ENDLIST
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"ERROR-CLASS", INDEX:0
NAME:"ERROR-STRING", NAME:"Ok"
NAME:"TRAIL",
PROPLIST: 名前: 「ID」、PROPLIST: 名前: 「mpm」、PROPLIST: PROPLIST、「名前: 名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名する」という取引」と、整数: 1993ENDLISTは: "CMD"と命名します: 名前: 「メールボックス」、PROPLIST: 名前: 「mpm」、PROPLIST: 」 「名前: 「アイオワ」と、整数: 「ENDLISTが命名する45インチ: 」 10、1、0、52、0、ネット」は命名します: 「アルパ」名: 「ホスト」と、名前: "ISIE"は命名します: 名前: 「ポート」、「45インチの名前: 」 ユーザ」は以下を命名する」*mpm*ENDLIST名: 「操作」、名前: 名前: 「参照」、PROPLISTは「承認します」: 名前: 「mpm」、PROPLIST: PROPLIST、「名前: 名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名する」という取引」と、整数: 37ENDLISTは: 「アドレス」と命名します: 名前: 「mpm」、PROPLIST: 「整数: 名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名する」というユーザ」と、名前: 「コーエン」ENDLISTは命名します: 「サービスのタイプ」と、名前: 「通常」の名前: インデックス: 0名: 「誤りストリング」という「誤りクラス」は命名します: 「間違いありません、な」名前: 「引きずってください」
[Page 50] Postel
[50ページ] ポステル
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:48-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:51.567-08:00"
NAME:"ACTION", NAME:"DESTINATION"
ENDLIST
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:52-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
ENDLIST
ENDLIST
ENDLIST
以下を記載してください。 PROPLIST: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、: 名前: 「1979年3月29日-11時47.5分から8時0分」名: 「動作」、「起源」ENDLIST PROPLISTは命名します: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 2、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、: 名前: 「1979年3月29日-11時48分から8時0分」名: 「動作」、「リレー」ENDLIST PROPLISTは命名します: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、名前: 「目的地」ENDLIST ENDLIST名: 名前: 「1979年3月29日-11時51.567分から8時0分」名: 「動作」、「跡」は記載します: PROPLIST: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください。」と、: 名前: 「1979年3月29日-11時52分から8時0分」名: 「動作」、「起源」ENDLIST ENDLIST ENDLIST ENDLISTは命名します。
Postel [Page 51]
ポステル[51ページ]
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
D. Between the relay MPM and the originating MPM.
D. リレーMPMと由来しているMPMの間で。
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:1993
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,1,0,52,0,45"
ENDLIST
NAME:"NET", NAME:"ARPA"
NAME:"HOST", NAME:"ISIE"
NAME:"PORT", NAME:"45"
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"ACKNOWLEDGE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"TRANSACTION", INTEGER:37
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:"10,3,0,52,0,45"
ENDLIST
NAME:"USER", NAME:"Cohen"
ENDLIST
NAME:"TYPE-OF-SERVICE", NAME:"REGULAR"
NAME:"ERROR-CLASS", INDEX:0
NAME:"ERROR-STRING", NAME:"Ok"
NAME:"TRAIL",
LIST:
PROPLIST:
PROPLIST: 名前: 「ID」、PROPLIST: 名前: 「mpm」、PROPLIST: PROPLIST、「名前: 名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名する」という取引」と、整数: 1993ENDLISTは: "CMD"と命名します: 名前: 「メールボックス」、PROPLIST: 名前: 「mpm」、PROPLIST: 」 「名前: 「アイオワ」と、整数: 「ENDLISTが命名する45インチ: 」 10、1、0、52、0、ネット」は命名します: 「アルパ」名: 「ホスト」と、名前: "ISIE"は命名します: 名前: 「ポート」、「45インチの名前: 」 ユーザ」は以下を命名する」*mpm*ENDLIST名: 「操作」、名前: 名前: 「参照」、PROPLISTは「承認します」: 名前: 「mpm」、PROPLIST: PROPLIST、「名前: 名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名する」という取引」と、整数: 37ENDLISTは: 「アドレス」と命名します: 名前: 「mpm」、PROPLIST: 「整数: 名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名する」というユーザ」と、名前: 「コーエン」ENDLISTは命名します: 名前: 「通常」の名前: 「誤りクラス」という「サービスのタイプ」は索引をつけます: 名前: 「間違いありません、な」名前: 0名: 「誤りストリング」、「道」は記載します: PROPLIST:
[Page 52] Postel
[52ページ] ポステル
August 1980
Internet Message Protocol
Examples & Scenarios
1980年8月のインターネットメッセージプロトコルの例とシナリオ
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,1,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:47.5-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:48-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:51.567-08:00"
NAME:"ACTION", NAME:"DESTINATION"
ENDLIST
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,3,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:52-08:00"
NAME:"ACTION", NAME:"ORIGIN"
ENDLIST
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:"10,2,0,52,0,45"
ENDLIST
NAME:"DATE", NAME:"1979-03-29-11:52.345-08:00"
NAME:"ACTION", NAME:"RELAY"
ENDLIST
ENDLIST
ENDLIST
ENDLIST
名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 1、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、: 名前: 「1979年3月29日-11時47.5分から8時0分」名: 「動作」、「起源」ENDLIST PROPLISTは命名します: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 2、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、: 名前: 「1979年3月29日-11時48分から8時0分」名: 「動作」、「リレー」ENDLIST PROPLISTは命名します: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、名前: 「目的地」ENDLIST ENDLIST名: 名前: 「1979年3月29日-11時51.567分から8時0分」名: 「動作」、「跡」は記載します: PROPLIST: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 3、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください」と、: 名前: 「1979年3月29日-11時52分から8時0分」名: 「動作」、「起源」ENDLIST PROPLISTは命名します: 名前: 「mpm」、PROPLIST: 「名前: 「アイオワ」、「10 2、0、52、0、何45インチも、ENDLISTは以下を命名します」と命名してください、そして、デートしてください。」と、: 名前: 「1979年3月29日-11時52.345分から8時0分」名: 「動作」、「リレー」ENDLIST ENDLIST ENDLIST ENDLISTは命名します。
Postel [Page 53]
Postel [Page 53]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
[Page 54] Postel
[Page 54] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7. SPECIFICATION SUMMARY
7. SPECIFICATION SUMMARY
7.1. Message Fields
7.1. Message Fields
All keywords used in this protocol are to be recognized independent of case.
All keywords used in this protocol are to be recognized independent of case.
action: NAME (one of)
"ORIGIN" | "RELAY" | "FORWARD" | "DESTINATION"
action: NAME (one of) "ORIGIN" | "RELAY" | "FORWARD" | "DESTINATION"
address: PROPLIST (one of)
address: PROPLIST (one of)
NAME: "MPM", <mpm-identifier>
NAME: "USER", <user>
NAME: "MPM", <mpm-identifier> NAME: "USER", <user>
or
or
NAME: "NET", <net>
NAME: "HOST", <host>
NAME: "PORT", <port>
NAME: "USER", <user>
NAME: "NET", <net> NAME: "HOST", <host> NAME: "PORT", <port> NAME: "USER", <user>
answer: BOOLEAN
answer: BOOLEAN
city: NAME
city: NAME
command: PROPLIST
NAME: "MAILBOX", <mailbox>
NAME: "OPERATION", <operation>
<<arguments>>
NAME: "ERROR-CLASS", <error-class> (only in replies)
NAME: "ERROR-STRING", <error-string> (only in replies)
NAME: "TRACE", <trace>
command: PROPLIST NAME: "MAILBOX", <mailbox> NAME: "OPERATION", <operation> <<arguments>> NAME: "ERROR-CLASS", <error-class> (only in replies) NAME: "ERROR-STRING", <error-string> (only in replies) NAME: "TRACE", <trace>
country: NAME
country: NAME
document: <<document>>
document: <<document>>
error-class: INDEX
error-class: INDEX
error-string: NAME
error-string: NAME
host: NAME
host: NAME
Postel [Page 55]
Postel [Page 55]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
handling-stamp: PROPLIST
NAME: "MPM", <mpm-identifier>
NAME: "DATE", <date>
NAME: "ACTION", <action>
handling-stamp: PROPLIST NAME: "MPM", <mpm-identifier> NAME: "DATE", <date> NAME: "ACTION", <action>
identification: LIST
NAME: "MPM", <mpm-identifier>
NAME: "TRANSACTION", <transaction-number>
identification: LIST NAME: "MPM", <mpm-identifier> NAME: "TRANSACTION", <transaction-number>
internet-address: NAME
internet-address: NAME
mailbox: PROPLIST (some of)
NAME: "MPM", <mpm-identifier>
NAME: "NET", <net>
NAME: "HOST", <host>
NAME: "PORT", <port>
NAME: "USER", <user>
NAME: "ORG", <organization>
NAME: "CITY", <city>
NAME: "STATE", <state>
NAME: "COUNTRY", <country>
NAME: "ZIP", <zip-code>
NAME: "PHONE", <phone-number>
<<other-items>>
mailbox: PROPLIST (some of) NAME: "MPM", <mpm-identifier> NAME: "NET", <net> NAME: "HOST", <host> NAME: "PORT", <port> NAME: "USER", <user> NAME: "ORG", <organization> NAME: "CITY", <city> NAME: "STATE", <state> NAME: "COUNTRY", <country> NAME: "ZIP", <zip-code> NAME: "PHONE", <phone-number> <<other-items>>
message: PROPLIST
NAME: "ID", <identification>
NAME: "CMD", <command>
NAME: "DOC", <document> (only in deliver)
message: PROPLIST NAME: "ID", <identification> NAME: "CMD", <command> NAME: "DOC", <document> (only in deliver)
mpm-identifier: PROPLIST (one of)
mpm-identifier: PROPLIST (one of)
NAME: "IA", <internet-address>
NAME: "IA", <internet-address>
or
or
NAME: "X121", <x121-address>
NAME: "X121", <x121-address>
net: NAME
net: NAME
operation: NAME (one of)
"DELIVER" | "ACKNOWLEDGE
| "PROBE" | "RESPONSE
| "CANCEL" | "CANCELED"
operation: NAME (one of) "DELIVER" | "ACKNOWLEDGE | "PROBE" | "RESPONSE | "CANCEL" | "CANCELED"
organization: NAME
organization: NAME
phone-number: NAME
phone-number: NAME
[Page 56] Postel
[Page 56] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
port: NAME
port: NAME
state: NAME
state: NAME
trace: LIST
<handling-stamp>
...
trace: LIST <handling-stamp> ...
trail: LIST
<handling-stamp>
...
trail: LIST <handling-stamp> ...
transaction-number: INTEGER
transaction-number: INTEGER
type-of-service: NAME (one or more of)
"REGULAR" | "FORWARD" | "GENDEL" | "PRIORITY"
type-of-service: NAME (one or more of) "REGULAR" | "FORWARD" | "GENDEL" | "PRIORITY"
user: NAME
user: NAME
x121-address: NAME
x121-address: NAME
zip-code: NAME
zip-code: NAME
Postel [Page 57]
Postel [Page 57]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7.2. Deliver Message
7.2. Deliver Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"DELIVER"
NAME:"TYPE-OF-SERVICE", NAME:<type-of-service>
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
NAME:"DOC", <<document>>
ENDLIST
PROPLIST: NAME:"ID", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"CMD", PROPLIST: NAME:"MAILBOX", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"NET", NAME:<net> NAME:"HOST", NAME:<host> NAME:"PORT", NAME:<port> NAME:"USER", NAME:<user> NAME:"ORG", NAME:<organization> NAME:"CITY", NAME:<city> NAME:"STATE", NAME:<state> NAME:"COUNTRY", NAME:<country> NAME:"ZIP", NAME:<zip-code> NAME:"PHONE", NAME:<phone-number> <<other-items>> ENDLIST NAME:"OPERATION", NAME:"DELIVER" NAME:"TYPE-OF-SERVICE", NAME:<type-of-service> NAME:"TRACE", LIST: PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST ENDLIST NAME:"DOC", <<document>> ENDLIST
[Page 58] Postel
[Page 58] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7.3. Acknowledge Message
7.3. Acknowledge Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:"*MPM*"
NAME:"NET", NAME:<net>
NAME:"PORT", NAME:<port>
NAME:"HOST", NAME:<host>
ENDLIST
NAME:"OPERATION", NAME:"ACKNOWLEDGE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"TYPE-OF-SERVICE", NAME:<type-of-service>
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST: NAME:"ID", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"CMD", PROPLIST: NAME:"MAILBOX", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"USER", NAME:"*MPM*" NAME:"NET", NAME:<net> NAME:"PORT", NAME:<port> NAME:"HOST", NAME:<host> ENDLIST NAME:"OPERATION", NAME:"ACKNOWLEDGE" NAME:"REFERENCE", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"ADDRESS", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"USER", NAME:<user> ENDLIST NAME:"TYPE-OF-SERVICE", NAME:<type-of-service> NAME:"ERROR-CLASS", INDEX:<error-class> NAME:"ERROR-STRING", NAME:<error-string> NAME:"TRAIL", LIST: PROPLIST: NAME:"MPM",
Postel [Page 59]
Postel [Page 59]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST NAME:"TRACE", LIST: PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST ENDLIST ENDLIST
[Page 60] Postel
[Page 60] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7.4. Probe Message
7.4. Probe Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"PROBE"
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
PROPLIST: NAME:"ID", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"CMD", PROPLIST: NAME:"MAILBOX", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"NET", NAME:<net> NAME:"HOST", NAME:<host> NAME:"PORT", NAME:<port> NAME:"USER", NAME:<user> NAME:"ORG", NAME:<organization> NAME:"CITY", NAME:<city> NAME:"STATE", NAME:<state> NAME:"COUNTRY", NAME:<country> NAME:"ZIP", NAME:<zip-code> NAME:"PHONE", NAME:<phone-number> <<other-items>> ENDLIST NAME:"OPERATION", NAME:"PROBE" NAME:"TRACE", LIST: PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST ENDLIST ENDLIST
Postel [Page 61]
Postel [Page 61]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7.5. Response Message
7.5. Response Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"RESPONSE"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
PROPLIST: NAME:"ID", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"CMD", PROPLIST: NAME:"MAILBOX", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"NET", NAME:<net> NAME:"HOST", NAME:<host> NAME:"PORT", NAME:<port> NAME:"USER", NAME:"*MPM*" ENDLIST NAME:"OPERATION", NAME:"RESPONSE" NAME:"REFERENCE", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"ADDRESS", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"USER", NAME:<user> ENDLIST NAME:"ERROR-CLASS", INDEX:<error-class> NAME:"ERROR-STRING", NAME:<error-string> NAME:"TRAIL", LIST: PROPLIST: NAME:"MPM", PROPLIST:
[Page 62] Postel
[Page 62] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST NAME:"TRACE", LIST: PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST ENDLIST ENDLIST
Postel [Page 63]
Postel [Page 63]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7.6. Cancel Message
7.6. Cancel Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:<user>
NAME:"ORG", NAME:<organization>
NAME:"CITY", NAME:<city>
NAME:"STATE", NAME:<state>
NAME:"COUNTRY", NAME:<country>
NAME:"ZIP", NAME:<zip-code>
NAME:"PHONE", NAME:<phone-number>
<<other-items>>
ENDLIST
NAME:"OPERATION", NAME:"CANCEL"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
PROPLIST: NAME:"ID", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"CMD", PROPLIST: NAME:"MAILBOX", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"NET", NAME:<net> NAME:"HOST", NAME:<host> NAME:"PORT", NAME:<port> NAME:"USER", NAME:<user> NAME:"ORG", NAME:<organization> NAME:"CITY", NAME:<city> NAME:"STATE", NAME:<state> NAME:"COUNTRY", NAME:<country> NAME:"ZIP", NAME:<zip-code> NAME:"PHONE", NAME:<phone-number> <<other-items>> ENDLIST NAME:"OPERATION", NAME:"CANCEL" NAME:"REFERENCE", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"TRACE", LIST: PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date>
[Page 64] Postel
[Page 64] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST ENDLIST ENDLIST
Postel [Page 65]
Postel [Page 65]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7.7. Canceled Message
7.7. Canceled Message
PROPLIST:
NAME:"ID",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"CMD",
PROPLIST:
NAME:"MAILBOX",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"NET", NAME:<net>
NAME:"HOST", NAME:<host>
NAME:"PORT", NAME:<port>
NAME:"USER", NAME:"*MPM*"
ENDLIST
NAME:"OPERATION", NAME:"CANCELED"
NAME:"REFERENCE",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", NAME:<internet-address>
ENDLIST
NAME:"TRANSACTION", INTEGER:<transaction-number>
ENDLIST
NAME:"ADDRESS",
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"USER", NAME:<user>
ENDLIST
NAME:"ERROR-CLASS", INDEX:<error-class>
NAME:"ERROR-STRING", NAME:<error-string>
NAME:"TRAIL",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
PROPLIST: NAME:"ID", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"CMD", PROPLIST: NAME:"MAILBOX", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"NET", NAME:<net> NAME:"HOST", NAME:<host> NAME:"PORT", NAME:<port> NAME:"USER", NAME:"*MPM*" ENDLIST NAME:"OPERATION", NAME:"CANCELED" NAME:"REFERENCE", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", NAME:<internet-address> ENDLIST NAME:"TRANSACTION", INTEGER:<transaction-number> ENDLIST NAME:"ADDRESS", PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"USER", NAME:<user> ENDLIST NAME:"ERROR-CLASS", INDEX:<error-class> NAME:"ERROR-STRING", NAME:<error-string> NAME:"TRAIL", LIST: PROPLIST: NAME:"MPM", PROPLIST:
[Page 66] Postel
[Page 66] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
NAME:"TRACE",
LIST:
PROPLIST:
NAME:"MPM",
PROPLIST:
NAME:"IA", INTEGER:<internet-address>
ENDLIST
NAME:"DATE", NAME:<date>
NAME:"ACTION", NAME:<action>
ENDLIST
...
ENDLIST
ENDLIST
ENDLIST
NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST NAME:"TRACE", LIST: PROPLIST: NAME:"MPM", PROPLIST: NAME:"IA", INTEGER:<internet-address> ENDLIST NAME:"DATE", NAME:<date> NAME:"ACTION", NAME:<action> ENDLIST ... ENDLIST ENDLIST ENDLIST
Postel [Page 67]
Postel [Page 67]
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
7.8. Data Element Summary
7.8. Data Element Summary
CODE NAME STRUCTURE LENGTH ---- ---- --------- ------
CODE NAME STRUCTURE LENGTH ---- ---- --------- ------
0 NOP CODE(1) 1
0 NOP CODE(1) 1
1 PAD CODE(1),COUNT(3),DATA(C) C+4
1 PAD CODE(1),COUNT(3),DATA(C) C+4
2 BOOLEAN CODE(1),TRUE-FALSE(1) 2
2 BOOLEAN CODE(1),TRUE-FALSE(1) 2
3 INDEX CODE(1),INDEX(2) 3
3 INDEX CODE(1),INDEX(2) 3
4 INTEGER CODE(1),INTEGER(4) 5
4 INTEGER CODE(1),INTEGER(4) 5
5 EPI CODE(1),COUNT(3),INTEGER(C) C+4
5 EPI CODE(1),COUNT(3),INTEGER(C) C+4
6 BITSTR CODE(1),COUNT(3),BITS(C/8) C/8+4
6 BITSTR CODE(1),COUNT(3),BITS(C/8) C/8+4
7 NAME CODE(1),COUNT(1),NAME(C) C+2
7 NAME CODE(1),COUNT(1),NAME(C) C+2
8 TEXT CODE(1),COUNT(3),TEXT(C) C+4
8 TEXT CODE(1),COUNT(3),TEXT(C) C+4
9 LIST CODE(1),COUNT(3),ITEMS(2),DATA(C-2) C+4
9 LIST CODE(1),COUNT(3),ITEMS(2),DATA(C-2) C+4
10 PROPLIST CODE(1),COUNT(3),PAIRS(1),DATA(C-1) C+4
10 PROPLIST CODE(1),COUNT(3),PAIRS(1),DATA(C-1) C+4
11 ENDLIST CODE(1) 1
11 ENDLIST CODE(1) 1
12 S-TAG CODE(1),INDEX(2) 3
12 S-TAG CODE(1),INDEX(2) 3
13 S-REF CODE(1),INDEX(2) 3
13 S-REF CODE(1),INDEX(2) 3
14 ENCRYPT CODE(1),COUNT(3),ALG-ID(1),
KEY-ID(2),DATA(C-3) C+4
14 ENCRYPT CODE(1),COUNT(3),ALG-ID(1), KEY-ID(2),DATA(C-3) C+4
The numbers in parentheses are the number of octets in the field.
The numbers in parentheses are the number of octets in the field.
[Page 68] Postel
[Page 68] Postel
August 1980
Internet Message Protocol
August 1980 Internet Message Protocol
REFERENCES
REFERENCES
[1] Cerf, V., "The Catenet Model for Internetworking," Information
Processing Techniques Office, Defense Advanced Research Projects
Agency, IEN 48, July 1978.
[1] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
[2] Postel, J., "DOD Standard Internet Protocol," USC/Information
Sciences Institute, IEN 128, NTIS number AD A079730, January 1980.
[2] Postel, J., "DOD Standard Internet Protocol," USC/Information Sciences Institute, IEN 128, NTIS number AD A079730, January 1980.
[3] Postel, J., "DOD Standard Transmission Control Protocol,"
USC/Information Sciences Institute, IEN 129, NTIS number AD
A082609, January 1980.
[3] Postel, J., "DOD Standard Transmission Control Protocol," USC/Information Sciences Institute, IEN 129, NTIS number AD A082609, January 1980.
[4] Postel, J., "Assigned Numbers," RFC 762, USC/Information Sciences
Institute, January 1980.
[4] Postel, J., "Assigned Numbers," RFC 762, USC/Information Sciences Institute, January 1980.
[5] 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.
[5] 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.
[6] Neigus, N., "File Transfer Protocol for the ARPA Network,"
RFC 542, NIC 17759, SRI International, August 1973.
[6] Neigus, N., "File Transfer Protocol for the ARPA Network," RFC 542, NIC 17759, SRI International, August 1973.
[7] Bhushan, A., K. Progran, R. Tomlinson, and J. White,
"Standardizing Network Mail Headers," RFC 561, NIC 18516,
September 1973.
[7] Bhushan, A., K. Progran, R. Tomlinson, and J. White, "Standardizing Network Mail Headers," RFC 561, NIC 18516, September 1973.
[8] Myer, T., and D. Henderson, "Message Transmission Protocol,"
RFC 680, NIC 32116, 30 April 1975.
[8] Myer, T., and D. Henderson, "Message Transmission Protocol," RFC 680, NIC 32116, 30 April 1975.
[9] 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.
[9] 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.
[10] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192,
February 1979.
[10] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192, February 1979.
[11] Braaten, O., "Introduction to a Mail Protocol," Norwegian
Computing Center, INWG 180, August 1978.
[11] Braaten, O., "Introduction to a Mail Protocol," Norwegian Computing Center, INWG 180, August 1978.
[12] Crocker, D., E. Szurkowski, and D. Farber, "An Internetwork Memo
Distribution Capability - MMDF," Sixth Data Communications
Symposium, ACM/IEEE, November 1979.
[12] Crocker, D., E. Szurkowski, and D. Farber, "An Internetwork Memo Distribution Capability - MMDF," Sixth Data Communications Symposium, ACM/IEEE, November 1979.
Postel [Page 69]
Postel [Page 69]
August 1980
Internet Message Protocol
References
August 1980 Internet Message Protocol References
[13] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed
Specification of an Inter-site Message Protocol," 8 July 1975.
[13] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed Specification of an Inter-site Message Protocol," 8 July 1975.
[14] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW
Working Note 24, Bolt Beranek and Newman, October 1978.
[14] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW Working Note 24, Bolt Beranek and Newman, October 1978.
[15] White, J., "A Proposed Mail Protocol," RFC 524, NIC 17140, SRI
International, 13 June 1973.
[15] White, J., "A Proposed Mail Protocol," RFC 524, NIC 17140, SRI International, 13 June 1973.
[16] White, J., "Description of a Multi-Host Journal," NIC 23144, SRI
International, 30 May 1974.
[16] White, J., "Description of a Multi-Host Journal," NIC 23144, SRI International, 30 May 1974.
[17] White, J., "Journal Subscription Service," NIC 23143, SRI
International, 28 May 1974.
[17] White, J., "Journal Subscription Service," NIC 23143, SRI International, 28 May 1974.
[18] Levin, R., and M. Schroeder, "Transport of Electronic Messages
Through a Network," Teleinformatics 79, Boutmy & Danthine (eds.)
North Holland Publishing Co., 1979.
[18] Levin, R., and M. Schroeder, "Transport of Electronic Messages Through a Network," Teleinformatics 79, Boutmy & Danthine (eds.) North Holland Publishing Co., 1979.
[19] Earnest, L., and J. McCarthy, "DIALNET: A Computer Communications
Study," Computer Science Department, Stanford University, August
1978.
[19] Earnest, L., and J. McCarthy, "DIALNET: A Computer Communications Study," Computer Science Department, Stanford University, August 1978.
[20] Crispin M., "DIALNET: A Telephone Network Data Communications
Protocol," DECUS Proceedings, Fall 1979.
[20] Crispin M., "DIALNET: A Telephone Network Data Communications Protocol," DECUS Proceedings, Fall 1979.
[21] Caulkins, D., "The Personal Computer Network (PCNET) Project: A
Status Report," Dr. Dobbs Journal of Computer Calisthenics and
Orthodontia, v.5, n.6, June 1980.
[21] Caulkins, D., "The Personal Computer Network (PCNET) Project: A Status Report," Dr. Dobbs Journal of Computer Calisthenics and Orthodontia, v.5, n.6, June 1980.
[22] Postel, J., "NSW Transaction Protocol (NSWTP)," USC/Information
Sciences Institute, IEN 38, May 1978.
[22] Postel, J., "NSW Transaction Protocol (NSWTP)," USC/Information Sciences Institute, IEN 38, May 1978.
[23] Haverty, J., "MSDTP -- Message Services Data Transmission
Protocol," RFC 713, NIC 34739, April 1976.
[23] Haverty, J., "MSDTP -- Message Services Data Transmission Protocol," RFC 713, NIC 34739, April 1976.
[24] Haverty, J., "Thoughts on Interactions in Distributed Services,"
RFC 722, NIC 36806, 16 September 1976.
[24] Haverty, J., "Thoughts on Interactions in Distributed Services," RFC 722, NIC 36806, 16 September 1976.
[25] Postel, J., "A Structured Format for Transmission of Multi-Media
Documents," RFC 767, USC/Information Sciences Institute,
August 1980.
[25] Postel, J., "A Structured Format for Transmission of Multi-Media Documents," RFC 767, USC/Information Sciences Institute, August 1980.
[26] ISO-2014, "Writing of calendar dates in all-numeric form,"
Recommendation 2014, International Organization for
Standardization, 1975.
[26] ISO-2014, "Writing of calendar dates in all-numeric form," Recommendation 2014, International Organization for Standardization, 1975.
[Page 70] Postel
[Page 70] Postel
August 1980
Internet Message Protocol
References
August 1980 Internet Message Protocol References
[27] ISO-3307, "Information Interchange -- Representations of time of
the day," Recommendation 3307, International Organization for
Standardization, 1975.
[27] ISO-3307, "Information Interchange -- Representations of time of the day," Recommendation 3307, International Organization for Standardization, 1975.
[28] ISO-4031, "Information Interchange -- Representation of local time
differentials," Recommendation 4031, International Organization
for Standardization, 1978.
[28] ISO-4031, "Information Interchange -- Representation of local time differentials," Recommendation 4031, International Organization for Standardization, 1978.
[29] CCITT-X.121, "International Numbering Plan for Public Data
Networks," Recommendation X.121, CCITT, Geneva, 1978.
[29] CCITT-X.121, "International Numbering Plan for Public Data Networks," Recommendation X.121, CCITT, Geneva, 1978.
[30] Postel, J., "NSW Data Representation (NSWB8)," USC/Information
Sciences Institute, IEN 39, May 1978.
[30] Postel, J., "NSW Data Representation (NSWB8)," USC/Information Sciences Institute, IEN 39, May 1978.
[31] Cohen, D., "On Holy Wars and a Plea for Peace," IEN 137,
USC/Information Sciences Institute, 1 April 1980.
[31] Cohen, D., "On Holy Wars and a Plea for Peace," IEN 137, USC/Information Sciences Institute, 1 April 1980.
[32] Hofstadter, D., "Godel, Escher, Bach: An Eternal Golden Braid,"
Basic Books, New York, 1979..
[32] Hofstadter, D., "Godel, Escher, Bach: An Eternal Golden Braid," Basic Books, New York, 1979..
[33] Harrenstien, K., "Field Addressing," ARPANET Message, SRI
International, October 1977.
[33] Harrenstien, K., "Field Addressing," ARPANET Message, SRI International, October 1977.
[34] Postel, J., "Out-of-Net Host Address for Mail," RFC 754,
USC/Information Sciences Institute, April 1979.
[34] Postel, J., "Out-of-Net Host Address for Mail," RFC 754, USC/Information Sciences Institute, April 1979.
[35] Shoch, J., "On Inter-Network Naming, Addressing, and Routing,"
IEEE Computer Society, COMPCON, Fall 1978.
[35] Shoch, J., "On Inter-Network Naming, Addressing, and Routing," IEEE Computer Society, COMPCON, Fall 1978.
[36] National Bureau of Standards, "Data Encryption Standard," Federal
Information Processing Standards Publication 46, January 1977.
[36] National Bureau of Standards, "Data Encryption Standard," Federal Information Processing Standards Publication 46, January 1977.
[37] Diffie, W., and M. Hellman, "New Directions in Cryptology," IEEE
Transactions on Information Theory, IT-22, 6, November 1976.
[37] Diffie, W., and M. Hellman, "New Directions in Cryptology," IEEE Transactions on Information Theory, IT-22, 6, November 1976.
[38] Rivest, R., A. Shamir, and L. Adleman, "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems" Communications
of the ACM, Vol. 21, Number 2, February 1978.
[38] Rivest, R., A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" Communications of the ACM, Vol. 21, Number 2, February 1978.
[39] Merkle, R., and M. Hellman, "Hiding Information and Signatures in
Trapdoor Knapsacks," IEEE Transactions of Information Theory,
IT-24,5, September 1978.
[39] Merkle, R., and M. Hellman, "Hiding Information and Signatures in Trapdoor Knapsacks," IEEE Transactions of Information Theory, IT-24,5, September 1978.
Postel [Page 71]
Postel [Page 71]
一覧
スポンサーリンク
