RFC438 日本語訳

Network Working Group                                          B. Thomas
Request for Comments: 438                                    B. Clements
NIC: 13770                                                     BBN-TENEX
References:  354,385,414,418                             15 January 1973

コメントを求めるワーキンググループB.トーマスの要求をネットワークでつないでください: 438 B.クレメンツNIC: 13770 BBN-TENEX参照: 3543億8541万4418 1973年1月15日

                     FTP Server-Server Interaction

FTPサーバサーバ相互作用

   The current ARPANET File Transfer Protocol as specified by RFC 354
   and updated by RFC's 385, 414 and 418 allows for "third host"
   participation but does not specify a mechanism by which the process
   at the third site may be the FTP server at that site.  This RFC
   suggests a simple extension to FTP which would allow an FTP user
   process at one site to arrange for FTP server processes at other
   sites to act cooperatively on its behalf.

RFC354によって指定されて、RFCの385、414、および418アップデートされる現在のアルパネットFile Transferプロトコルは、「3番目のホスト」参加を考慮しますが、そのサイトで3番目のサイトのプロセスがFTPサーバであるかもしれないメカニズムを指定しません。 このRFCは1つのサイトのFTPユーザ・プロセスが、他のサイトのFTPサーバプロセスが協力して利益に影響するように手配できるFTPに単純拡大を勧めます。

   Such server-server cooperation may appear to be of limited utility.
   Consider, however, the requirements placed on FTP by a Resource
   Sharing Executive (RSEXEC) program -  a command language interpreter
   which extends the range of a user's commands beyond the boundaries of
   the user's local system.  Among its services such as RSEXEC could
   provide its users with a network-wide file system, perhaps allowing,
   in certain contexts, the use of partially qualified pathnames which
   omit site specification.  Consider, for example the response of the
   RSEXEC to the user command:

そのようなサーバサーバ協力は限られたユーティリティがあるように見えるかもしれません。 しかしながら、Resource Sharing Executive(RSEXEC)プログラムでFTPに置かれた要件を考えてください--ユーザのローカルシステムの限界でユーザのコマンドの範囲を広げるコマンド言語インタプリタ。 RSEXECなどのサービスの中では、ネットワーク全体のファイルシステムをもっているユーザは提供できました、恐らくある文脈でサイト仕様を省略する部分的に適切なパス名の使用を許して。 考えてください、そして、例えば、ユーザへのRSEXECの応答は命令します:

      APPEND (FILE) PROG1.PL1 (TO FILE) PROG2.PL1

(ファイル)PROG1.PL1(ファイルする)PROG2.PL1を追加してください。

   for the case in which the two files are at different sites (PROG1.PL1
   at SITE1, PROG2.PL1 at SITE2) neither of which is the user's site.  A
   straightforward way for the RSEXEC to "perform" the APPEND would be
   to establish FTP control connections to the FTP servers at SITE1 and
   at SITE2, instruct the server at SITE1 to

2個のファイルがそれのどちらもユーザのサイトでない異なったサイト(SITE1のPROG1.PL1、SITE2のPROG2.PL1)にある場合のために。 APPENDがSITE1とSITE2でFTPサーバとのFTPコントロール接続を確立して、SITE1のサーバを命令することになっている「働いてください」へのRSEXECに、簡単な方法

      RETR PROG1.PL1

RETR PROG1.PL1

   using data connection C and instruct the server at SITE2 to

データ接続Cを使用して、SITE2でサーバを命令します。

      APPE PROG2.PL1

APPE PROG2.PL1

   using the same data connection C.

同じデータ接続Cを使用します。

   Unfortunately, at present there is no way within FTP to arrange for
   such server-server cooperation.  This is due primarily to the lack of
   symmetry in the way that FTP treats the ends of data connections
   during connection establishment.  It specifies one end to be the
   "server" end, the other to be the "user" end and specifies different
   means for establishing the connections from the two ends.

残念ながら、そのようなサーバサーバ協力のためにアレンジするFTPの中に道が全く現在のところありません。 これは主として調和の欠如のFTPがコネクション確立の間にデータ接続の終わりを扱う方法でためです。 それは、「サーバ」終わり、「ユーザ」終わりであるもう片方になるように片端を指定して、2つの終わりから接続を確立するための異なった手段を指定します。

Thomas, et. al.                                                 [Page 1]

RFC 438              FTP Server-Server Interaction          January 1973

etトーマス、アル。 [1ページ]RFC438FTPサーバサーバ相互作用1973年1月

   FTP could be modified to support server-server interaction by:

以下でサーバサーバ相互作用をサポートするようにFTPを変更できました。

      1. making the establishment of data connections symmetric, or;

または、1. データ接続の設立を左右対称にする、。

      2. providing a mechanism for instructing a server to establish its
         end of a data connection as if it were a user.

2. まるでそれがユーザであるかのようにデータ接続の終わりを証明するためにサーバを命令するのにメカニズムを提供すること。

   The second alternative probably requires fewer changes to the
   existing protocol.

2番目の代替手段はたぶん既存のプロトコルへの、より少ない変化を必要とします。

   The following proposed extension to FTP uses the second method.   It
   involves the addition of a single new command (LSTN) and minor
   modifications to several existing commands (SOCK, APPE, RETR, STOR):

FTPへの以下の提案された拡大は2番目のメソッドを使用します。 それはただ一つの新しいコマンド(LSTN)といくつかの既存のコマンドへの小さい方の変更(SOCK、APPE、RETR、STOR)の追加にかかわります:

   a. The LSTN (Listen) command requests the FTP server to allocate a
      socket for use as a data connection.  To establish the
      corresponding data connection the server is to "listen" on the
      socket allocated when an appropriate transfer command is given.

a。 LSTN(聴く)コマンドは、データ接続として使用のためのソケットを割り当てるようFTPサーバに要求します。 「対応するデータ接続を証明するために、サーバは適切な転送命令を与えるとき割り当てるソケットで聴く」ことです。

      syntax: LSTN <direction> CRLF

構文: LSTN<方向>CRLF

         where <direction> is either "S" for send or "R" for receive.

<方向>が「S」であるところに、発信してください、「R」、受信してください。

      The server responds to LSTN by:

サーバは以下でLSTNに反応します。

         1. refusing to allocate such a socket, or:

または、1. そのようなソケットを割り当てるのを拒否する、:

         2. sending the user the number of the socket allocated (the 255
            FTP server data socket reply could be used for this
            purpose).

2. ソケットの数が割り当てた(このために255FTPサーバデータソケット回答を使用できました)ユーザを送ること。

   b. Receipt of an appropriate STOR, RETR or APPE command following a
      successful LSTN command causes the server to "listen" for an RFC
      for the socket allocated.   Data transfer may proceed after the
      server receives an RFC for the socket and responds with a matching
      RFC.   Once established, a data connection corresponding to a
      successful LSTN command has the same duration as one established
      in the usual way.

b。 うまくいっているLSTNコマンドに続く適切なSTOR、RETRまたはAPPEコマンドの領収書は、サーバが割り当てられたソケットのためのRFCのために「聴かれること」を引き起こします。 サーバがソケットのためにRFCを受けて、合っているRFCと共に反応した後にデータ転送は続くかもしれません。 いったん設立されると、うまくいっているLSTNコマンドに対応するデータ接続は1つと同じ持続時間を不断のとおり確立させます。

   c. The user may insure the security of his data transfer by using the
      SOCK command to instruct the server to accept an RFC for the
      listening socket only if it is from a specified host and socket.

c。 ユーザは、指定されたホストとソケットから来ている場合にだけ聴取ソケットのためにRFCを受け入れるようサーバに命令するSOCKコマンドを使用することによって、彼のデータ転送のセキュリティを保障するかもしれません。

   d. The SOCK command is modified in two ways:

d。 SOCKコマンドは2つの方法で変更されます:

Thomas, et. al.                                                 [Page 2]

RFC 438              FTP Server-Server Interaction          January 1973

etトーマス、アル。 [2ページ]RFC438FTPサーバサーバ相互作用1973年1月

      1. On success the reply must be the 255 FTP server data socket
         reply; that is, the 255 reply can not be deferred until receipt
         of a data transfer command.  (This is to allow the user to
         transmit the server's response to the program at the third
         site; see the example below.)

1. 成功における、回答は255FTPサーバデータソケット回答であるに違いありません。 データ転送コマンドの領収書まですなわち、255回答を延期できません。 (ユーザはこれで3番目のサイトのプログラムへのサーバの応答を伝えることになっていることができます; 以下の例を見てください。)

      2. After a LSTN command the SOCK command is to be interpreted by
         the server as specification of the acceptable RFC for
         subsequent data transfer command that use the allocated socket.

2. LSTNコマンドの後に、SOCKコマンドは割り当てられたソケットを使用する順次データ転送命令のために許容できるRFCの仕様としてサーバによって解釈されることです。

   With this extension to FTP, the RSEXEC program could accomplish the
   APPEND in the example above as follows:

FTPへのこの拡大で、RSEXECプログラムは以下の上記の例でAPPENDを達成するかもしれません:

        to SITE1:                       to SITE2:

SITE1に: SITE2に:

           .                                .
           .                                .
           .                                .

. . . . . .

   1.                                   LSTN R CRLF
                                        (let X = socket
                                         allocated)

1. LSTN R CRLF(Xは割り当てられたソケットと等しいです)

   2.   SOCK SITE2,X CRLF
        (let Y = socket in 255
         reply from SITE1)

2. ソックスSITE2、X CRLF(YはSITE1から255回答においてソケットと等しいです)

   3.                                   SOCK SITE1,Y CRLF

3. ソックスSITE1、Y CRLF

   4.  RETR PROG1.PL1                   APPE PROG2.Pl1 CRLF

4. RETR PROG1.PL1 APPE PROG2.Pl1 CRLF

          .                                 .
          .                                 .
          .                                 .

. . . . . .

   In closing it is appropriate to note that an experimental RSEXEC
   program of the sort suggested above has been operational on TENEXs
   for about 8 months.  It currently uses a private, resource sharing
   protocol (RSP) that includes file transfer operations.  RSP supports
   server-server cooperation; in RSP data connections are established in
   a symmetric way (alternative 1 above).

最後になりましたが、上に示された種類の実験用RSEXECプログラムがおよそ8カ月TENEXsで操作上であることに注意するのは適切です。 それは現在、ファイル転送操作を含んでいる個人的なリソース・シェアリングプロトコル(RSP)を使用します。 RSPはサーバサーバ協力をサポートします。 RSPデータに、接続は左右対称の方法(上の代替の1)で確立されます。

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Mirsad Todorovac 5/98 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Mirsad Todorovac5/98によるオンラインRFCアーカイブへの]

Thomas, et. al.                                                 [Page 3]

etトーマス、アル。 [3ページ]