RFC128 Bytes

0128 Bytes. J. Postel. April 1971. (Format: TXT=2745 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

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.

   There are at least two interpretations if the sender and receiver
   specify different byte sizes.

   I.  The first is that the connection is illegal.

   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.

       A. One is to consider bits as the basic unit.

          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.

   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



Postel                                                          [Page 1]

RFC 128                          Bytes                        April 1971


   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 ]













































Postel                                                          [Page 2]

一覧

 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 

スポンサーリンク

MERGE テーブルの既存データ行を更新または新規に追加する

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

上に戻る