この文書はRFC128の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。

Network Working Group                                          J. Postel
Request for Comments: 128                                            UCLA
Category: C.2, D.                                       Computer Science
NIC #5844                                                     21 April 71
Obsoletes: none
Updates: none


                                 BYTES
                                 バイト


   It is somewhat unclear what to do with the Byte size parameter now
   allowed by the 2nd level protocol.  I can conceive of an
   implementation in which the 3rd level programs never see this
   parameter.  Crocker implies in RFC 123 that control of this parameter
   is given to the 3rd level programs and that both sender and receiver
   may specify values of the byte size to the NCP.
   現在、第２レベルプロトコルのバイトサイズパラメータで何をするべきかは
   幾分不明確です。私は第３レベルプログラムが決してこのパラメータを見な
   い実装を想像できます。CrockerはＲＦＣ１２３で、このパラメータの制御
   が第３レベルプログラムに与えられ、送信者と受信者の両方がＮＣＰにバイ
   トサイズ値を指定してよいことを暗示します。

   There are at least two interpretations if the sender and receiver
   specify different byte sizes.
   もし送信者と受信者が異なったバイトサイズを指定するなら少なくとも２つ
   の解釈があります。

   I.  The first is that the connection is illegal.
   I.  最初は接続が誤りであるということです。

   II. The second is that the NCP must parse the data stream on receipt
       from the network and into a buffer according to be byte size of
       the sender, and subsequently parse the data stream on transfer
       from the buffer to the receiver.  In this second case there are
       two sub cases.
   II. 第２はＮＣＰがネットワークから受信したデータストリームを解析し
       バッファに送信側のバイトサイズで入れ、ついでバッファから受信者
       に送るためにデータストリームの解析をします。この２番目の場合に、
       さらに２つに場合分けできます。

       A. One is to consider bits as the basic unit.
       A. ある人は１ビットを基本単位と考えるはずです。

          For example, if the sender specified byte size = 5 and the
          receiver specified byte size = 3 then
          例えば、もし送信者がバイトサイズ＝５を指定し、受信者がバイトサ
          イズ＝３を指定したなら。

          Receiver                   NCP                    Sender
          受信者                    ＮＣＰ                  送信者

          -+---+---+---+---+      +--------+      +-----+-----+---
           |000|001|010|011| <--- | Buffer | <--- |00000|10100|11
          -+---+---+---+---+      +--------+      +-----+-----+---


       B. The other is to consider bytes as the significant unit and pad
          (on the right or left?) or truncate to make things fit, or
          other transformation.
       B. 他の人がバイトを意味のある単位考え、詰め物をする（右か左に？）
          か、あるいは適合するように切り詰めるか、他の変換を考えます。


   At UCLA-Computer Science we are contemplating allowing sender and
   receiver to specify different byte sizes and consider bits as the
   basic unit (Case II.A.).  This does not rule out our considering the
   second subcase (Case II.B.).  We may allow 3rd level programs to
   specify a library or user supplied routine to perform the
   transformation between sender and receiver bytes.  Perhaps these
   transformation routines would be written in the Data Reconfiguration
   Language.
   ＵＣＬＡコンピュータサイエンスにおいて我々は送信者と受信者が異なるバ
   イトサイズを指定できると考え、ビットを基本単位と考えています（ケース
   ＩＩＡ）。これは２番目の場合（ケースＩＩＢ）を否定しません。我々はラ
   イブラリかユーザ供給ルーチンが、第３レベルプログラムに送信と受信バイ
   ト間での変換を明示することを許すかもしれません。多分これらの変換ルー
   チンはデータ再設定言語で書かれるでしょう。

         [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Duncan de Waal 03/98 ]
       [ このＲＦＣは９８年３月にダンカン・ドゥ・ワールにより機械可読 ]
       [ 形式にされオンラインＲＦＣアーカイブに入れられました ]