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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

複雑なExcelファイルをプログラムで作成する方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る