RFC42 日本語訳
0042 Message Data Types. E. Ancona. March 1970. (Format: TXT=5247 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group E.I. Ancona Request for Comments: 42 M.I.T. Lincoln Laboratory 31 March 1970
コメントを求めるワーキンググループE.I.アンコナの要求をネットワークでつないでください: 42 マサチューセッツ工科大学リンカーン研究所1970年3月31日
Message Data Types
メッセージデータ型
Proposal:
提案:
We propose that the first eight bits of a normal message be reserved for a message data type. Adoption of this convention does not in any way signify agreement as to the actual data types to be used. It merely establishes the convention that the first eight bits of every normal message are not available for user data.
私たちは、正常なメッセージの最初の8ビットがメッセージデータ型のために予約されるよう提案します。 このコンベンションの採用は何らかの方法で実際のデータ型に関する使用されるべき協定を意味しません。 それは単に、利用者データに利用可能な状態であらゆる正常なメッセージの最初の8ビットがそうでないコンベンションを設立します。
Discussion:
議論:
Socket Port | | | ____________ | V V / \ V / \ |=| /==| | -------(+)->|Y|-->< | | |=| \==| | | PROCESS | | | |=| /==| | -------(-)->|X|<--< | | |=| \==| | \ / \____________/
ソケットポート| | | ____________ | V V/\V/\|=| /==| | -------(+)->|Y| --><|、| |=| \==| | | プロセス| | | |=| /==| | -------(-)->|X| <--<、|、| |=| \==| | \ / \____________/
It is important that conventions regarding the contents of messages be set up early so that there will not be a large proliferation of such conventions between every pair of programs running on the network.
メッセージのコンテンツに関するコンベンションがネットワークで動くすべての組のプログラムの間には、そのようなコンベンションの大きい増殖がないように早く設立されるのは、重要です。
As network usage grows, network languages may develop for specifying both the syntax and semantics of messages. However, even before such conventions are developed, a simple way of describing such a specification is by means of a message type which both sender and receiver know how to interpret.
ネットワーク用法が成長するとき、ネットワーク言語は、構文とメッセージの意味論の両方を指定するために展開するかもしれません。 しかしながら、そのような仕様を説明する簡単な方法は送付者と受信機の両方が、どのようにが解釈するかを知っているメッセージタイプによってそのようなコンベンションが開発されてさえいる前です。
It is important that currently running programs still run with this convention; thus, we propose that two system programs be written which initially put in and test and remove the type information from the message. Let us call these two programs X and Y, for lack of
現在動くプログラムがこのコンベンションと共にまだ動いているのは、重要です。 したがって、私たちは、2つのシステムプログラムが書かれているよう提案します(初めは、メッセージからタイプ情報を入れて、テストして、取り除きます)。 これらの2つのプログラムを不足のためのXとYと呼びましょう。
Ancona [Page 1] RFC 42 Message Data Types March 1970
1970年のアンコナの[1ページ]RFC42メッセージデータ型行進
better names. In general, X and Y will perform transformations on the data, e.g., change character sets or number formats. As network usage grows, X and Y might become table driven with the table specified by the user.
より良い名前。 一般に、XとYがデータに変換を実行して、例えば、変化は、文字集合か数の書式です。 ネットワーク用法が成長するのに従って、XとYはテーブルの上に置くことのようにテーブルがユーザによって指定されている状態で動かされたなるかもしれません。
Standard Types and Local Types:
標準体型とローカルのタイプ:
We propose to distinguish between two kinds of message data types: standard and local.
私たちは、2種類のメッセージデータ型を見分けるよう提案します: 標準であって地方です。
Since our two transformation programs cannot be expected to perform a transformation between every possible data representation and the data representation of the machine they are running on, and also since the addition of a data representation should not necessarily involve a change to X or Y, we propose that only a fixed number of message types have meaning throughout the network. These are standard types.
私たちの2つの変換プログラムがそれらが動いているマシンのあらゆる可能なデータ表現とデータ表現の間の変換を実行することを期待できないで、データ表現の追加が必ずまた、XかYへの変化を伴うべきであるというわけではないので、私たちは、固定数のメッセージタイプだけがネットワーク中に意味を持っているよう提案します。 これらは標準体型です。
There are two classes of local types: MYLOCAL and YOURLOCAL. A message type MYLOCAL n implies: this is type n of the set of types of the sending host. YOURLOCAL n implies: this is type n of the set of types of the receiving host.
2つのクラスのローカルのタイプがあります: MYLOCALとYOURLOCAL。 タイプMYLOCAL nが含意するメッセージ: これは送付ホストのタイプのセットのタイプnです。 YOURLOCAL nは以下を含意します。 これは受信ホストのタイプのセットのタイプnです。
Conventions:
コンベンション:
A possible implementation of standard and local types is to define standard type 0 to be YOURLOCAL and standard type 1 to be MYLOCAL. In these cases, the second byte would be the local type number.
標準の、そして、ローカルのタイプの可能な実装がYOURLOCALになるように標準体型0を定義することであり、標準体型はMYLOCALである1です。 これらの場合では、2番目のバイトは地方の形式数でしょう。
Local type 0 would mean user-specified, i.e., the message contents are unchanged and unchecked. Installations would define their own local type numbers and these would normally be available from the Network Information Center.
すなわち、メッセージ内容は、ローカルのタイプ0は、ユーザによって指定されていることを意味して、変わりがなくて、抑制されません。 インストールは地元の形式数を定義するでしょう、そして、通常、これらはNetworkインフォメーション・センターから利用可能でしょう。
Thus initially, all messages sent to currently running programs will be type 0, n and all messages received from currently running programs will be type 1, n where n is the local type number of the character set of the installation.
したがって、初めは現在プログラムを動かすのに送られたすべてのメッセージがタイプにな0、nるでしょう、そして、現在プログラムを動かすのから受け取られたすべてのメッセージがnがインストールの文字集合の地方の形式数であるタイプにな1、nるでしょう。
Examples of Possible Standard Types:
可能な標準体型の例:
0. YOURLOCAL 1. MYLOCAL 2. U.S. Ascii 3. EBCDIC 4. Mod 33 TTY Ascii
0. YOURLOCAL1。 MYLOCAL2。 米国アスキー3。 EBCDIC4。 モッズ風の33TTYアスキー
Ancona [Page 2] RFC 42 Message Data Types March 1970
1970年のアンコナの[2ページ]RFC42メッセージデータ型行進
5. Load table driven translator table #n. If, in the future, the X and Y transformation boxes are table driven, this gives the table. The table number n is stored in the second byte of the message. 6. Use table driven translator table #n. 7. Network standard graphics message.
5. テーブルのやる気満々の翻訳者テーブル#nを積み込んでください。 将来XとY変換箱が動かされたテーブルであるなら、これはテーブルを与えます。 表番号nはメッセージの2番目のバイトで保存されます。 6. テーブルのやる気満々の翻訳者テーブル#nを使用してください。 7. 標準のグラフィックスメッセージをネットワークでつないでください。
Examples of Local Types:
ローカルのタイプに関する例:
1. Local Character sets, e.g., Lincoln writer, DEC Ascii, etc. 2. Graphics local messages, e.g., TX-2 Apex display executive calls, GSAM.
1. 地方のキャラクターセット、例えば、リンカーン作家、12月のアスキーなど 2. GSAM、グラフィックスのローカルのメッセージであり、例えば、テキサスの-2Apexディスプレイ幹部社員は電話をします。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Robbie Bennet 11/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロビーBennet11/98によるオンラインRFCアーカイブへの]
Ancona [Page 3]
アンコナ[3ページ]
一覧
スポンサーリンク