RFC172 日本語訳

Network Working Group                           23 June 1971
Request for Comments #172                       Abhay Bhushan, MIT
NIC 6794                                        Bob Braden, UCLA
Categories: D.4, D.5, and D.7                   Will Crowther, BBN
Updates: 114                                    Eric Harslem, Rand
Obsolete: None                                  John Heafner, Rand
                                                Alex McKenzie, BBN
                                                John Melvin, SRI
                                                Bob Sundberg, Harvard
                                                Dick Watson, SRI
                                                Jim White, UCSB

コメント#172Abhay Bhushan、MIT NIC6794ボブ・ブレーデン、UCLAカテゴリを求めるワーキンググループ1971年6月23日の要求をネットワークでつないでください: D.4、D.5、およびD.7ウィル・クラウザー、BBNアップデート: 114 エリックHarslem、底ならし革は以下を時代遅れにします。 ジョンHeafner、底ならし革アレックス・マッケンジー、BBNジョン・メルビン、ボブSundberg、SRIハーバードのディック・ワトソン、SRIジムが空白にしないなにも、UCSB

                    THE FILE TRANSFER PROTOCOL

ファイル転送プロトコル

                                                                [Page 1]

NWG/RFC 172

[1ページ] NWG/RFC172

I. INTRODUCTION

I. 序論

      The file transfer protocol (FTP) is a user-level protocol for file
transfer between host computers (including terminal IMP's), on the ARPA
computer network. The primary function of FTP is to facilitate transfer
of files between hosts, and to allow convenient use of storage and file
handling capabilities of other hosts. FTP uses the data transfer
protocol described in RFC 171 to achieve transfer of data. This paper
assumes knowledge of RFC 171.

ファイル転送プロトコル(FTP)はホストコンピュータの間のファイル転送のためのユーザレベルプロトコル(端末のIMPのものを含んでいて)です、ARPAコンピュータネットワークで。 FTPのプライマリ機能は、ホストの間のファイルの転送を容易にして、ストレージの便利な使用と他のホストのファイル取り扱い能力を許容することです。 FTPはデータ転送を達成するためにRFC171で説明されたデータ転送プロトコルを使用します。 この紙はRFC171に関する知識を仮定します。

      The objectives of FTP are to promote sharing of files (computer
programs and/or data), encourage indirect use (without login or
implicit) of computers, and shield the user from variations in file and
storage systems of different hosts, to the extent it is practical.
These objectives are achieved by specifying a standard file transfer
socket and initial connection protocol for indirect use, and using
standard conventions for file transfer and related operations.

FTPの目的は、ファイル(コンピュータ・プログラム、そして/または、データ)の共有を促進して、コンピュータの間接的な使用(ログインも暗黙のない)を奨励して、異なったホストのファイルとストレージシステムの変化からユーザを保護することです、それが実用的であるという範囲に。 これらの目的は、標準のファイル転送ソケットと初期の接続プロトコルを間接的な使用に指定して、ファイル転送と関連する操作に一般的なコンベンションを使用することによって、達成されます。

II. DISCUSSION

II。 議論

      A file is considered here to be an ordered set of arbitrary
length, consisting of computer (including instructions) data. Files are
uniquely identified in a system by their pathnames. A pathname is
(loosely) defined to be the data string which must be input to the file
system by a network user in order to identify a file. Pathname usually
contains device and/or directory names, and file names in case of named
files. FTP specifications provide standard file system commands, but do
not provide standard naming convention at this time.  Each user must
follow the naming convention of the file system he wishes to use. FTP
may be extended later to include standard conventions for pathname
structures.[1]

コンピュータ(指示を含んでいる)データから成って、ファイルはここで1つの順序集合の任意の長さであると考えられます。 ファイルはそれらのパス名によってシステムで唯一特定されます。 パス名は、ネットワーク利用者がファイルを特定するためにファイルシステムに入力しなければならないデータ列になるように(緩く)定義されます。 通常、パス名は指定されたファイルの場合にデバイス、そして/または、ディレクトリ名と、ファイル名を含んでいます。 FTP仕様は、標準ファイルシステム・コマンドを提供しますが、このとき、一般的な命名規則を供給しません。 各ユーザは彼が使用したがっているファイルシステムの命名規則に続かなければなりません。 FTPは、後でパス名構造への一般的なコンベンションを含むように広げられるかもしれません。[1]

      A file may or may not have access controls associated with it.
The access controls designate the users' access privilege. In the
absence of access controls, the files cannot be protected from
accidental or unauthorized usage. It is the prerogative of a resident
file system to provide protection, and selective access. FTP only
provides identifier and password mechanisms for exchange of access
control information. It should however be noted, that for file sharing,
it is necessary that a user be allowed (subject to access controls) to
access files not created by him.

ファイルには、それに関連しているアクセス制御があるかもしれません。 アクセス制御はユーザのアクセス特権を指定します。 アクセス制御がないとき、偶然の、または、権限のない用法からファイルを保護できません。 それは保護、および選択しているアクセサリーを提供する居住しているファイルシステムの特権です。 FTPは識別子とパスワードメカニズムをアクセス制御情報の交換に提供するだけです。 ユーザが彼によって作成されなかったファイルにアクセスできるのが(アクセス制御を受けることがある)しかしながら、それは注意されるべきです、ファイルのためのそれが共有されて必要です。

      FTP does not restrict the nature of information in the file. For
example, a file could contain ASCII text, binary data computer program,
or any other information. A provision for indicating data structure
(type and byte size) exists in FTP to aid in parsing, interpretation,
reconfiguration, and storage of data. To facilitate indirect usage, the
cooperating file transfer processes may be disowned "daemon" processes

FTPはファイルの情報の本質を制限しません。 例えば、ファイルはASCIIテキスト、バイナリ・データコンピュータ・プログラム、またはいかなる他の情報も入れてあるかもしれません。 データ構造(タイプとバイトサイズ)を示すことへの支給は構文解析、解釈、再構成、およびデータ記憶で支援するFTPで存在しています。 間接的な用法、協力を容易にするために、ファイル転送プロセスは縁を切っている「デーモン」プロセスであるかもしれません。

                                                                [Page 2]

NWG/RFC 172

[2ページ] NWG/RFC172

which "listen" to agreed-upon sockets, and follow the standard initial
connection protocol for establishing a full-duplex connection. It should
be noted that FTP could also used directly by logging into a remote
host, and arranging for file transfer over specific sockets.

ソケットに同意して、全二重接続を確立するための標準の初期の接続プロトコルに従うために「聴きます」。 また、直接リモートホストにログインすることによって使用されて、特定のソケットの上にファイル転送を準備して、FTPがそうすることができたことに注意されるべきです。

      FTP is readily extensible, in that additional commands and data
types may be defined by those agreeing to implement them.
Implementation of a subset of commands is specifically permitted, and an
initial subset for implementation is recommended.[2] The protocol may
also be extended to enable remote execution of programs, but no standard
procedure is suggested.

追加コマンドとデータ型がそれらを実装するのに同意するものによって定義されるかもしれないので、FTPは容易に広げることができます。 コマンドの部分集合の実装は明確に受入れられます、そして、実装のための初期の部分集合はお勧めの.[2]です。また、プロトコルはプログラムのリモート実行を可能にするために広げられるかもしれませんが、標準手続きは全く示されません。

      For transferring data, FTP uses the data transfer protocol
specified in RFC 171. As the data transfer protocol does not specify the
manner in which it is to be used by FTP, implementation may vary at
different host sites. Hosts not wishing to separate the data transfer
and file transfer functions, should take particular care in conforming
to the data transfer protocol specifications of RFC 171.

データを移すために、FTPはRFC171で指定されたデータ転送プロトコルを使用します。 データ転送プロトコルがそれがFTPによって使用されることになっている方法を指定しないとき、実装は異なったホストサイトで異なるかもしれません。 ホストがデータ転送とファイル転送機能を切り離したくない場合、RFC171に関するデータ転送プロトコル仕様に従いながら、特定の注意を中に入れるべきです。

      It should be noted, that FTP specifications do not require
knowledge of transfer modes used by data transfer protocol. However, as
file transfer protocol requires the transfer of more than a single
control transaction over the same connection, it is essential that hosts
be able to send control transactions in either 'transparent block' (type
B9) of 'descriptor and counts' (type BA) modes. (Type BB, the indefinite
bit stream mode is not suitable as it limits transfer to singles
transactions.).

それは注意されるべきであり、仕様が知識を必要としないそのFTPはデータ転送プロトコルによって使用されるモードを移します。 しかしながら、ファイル転送プロトコルが同じ接続に関して単一管理トランザクション以上の転送を必要とするとき、ホストがどちらかの'見え透いたブロック'(B9をタイプする)の'記述子とカウント'(BAをタイプする)モードによるコントロールトランザクションを送ることができるのは、不可欠です。 (掲示板をタイプしてください、そして、転送をシングルストランザクションに制限するとき、無期ビットストリームモードは適当ではありません。)

      The use of data transfer aborts (type B6) is neither required, nor
defined in FTP. FTP has its own error terminate which may be used to
abort a file transfer request. FTP also does not define the structure of
files, and there are no conventions on the use of group, record and unit
separators.[3] A file separator is, however, used to indicate the end of
file. It is strongly recommended that default options be provided in
implementation to facilitate use of file transfer service. For example,
the main file directory on disk, a pool directory, user directory or
directory last accessed could serve as standard pathname defaults.
Default mechanisms are convenient, as the user doesn't have to specify
the complete pathname each time he wishes to use the file transfer
service.

データ転送アボート(B6をタイプする)の使用は、FTPで必要でなく、また定義されません。 FTPで、それ自身の誤りは終わります(ファイル転送要求を中止するのに使用されるかもしれません)。 FTPもファイルの構造を定義しません、そして、グループ、記録、およびユニット分離文字.[3]の使用にはコンベンションが全くありません。しかしながら、ファイル分離文字は、ファイルの終りを示すのに使用されます。 省略時のオプションがファイル転送サービスの使用を容易にするために実装に提供されることが強く勧められます。 例えば、ディスク、プールディレクトリ、ユーザディレクトリまたは最後にアクセスされたディレクトリの上の主なファイルディレクトリは標準のパス名デフォルトとして機能できました。 デフォルトメカニズムは便利です、ユーザがファイル転送サービスを利用したがっているたびに完全なパス名を指定する必要はないとき。

III. SPECIFICATIONS

III。 仕様

1.  Data Transfer

1. データ転送

   FTP uses the data transfer protocol described in RFC 171, for
   transferring data and/or control transaction. Both data and control
   transactions are communicated over the same connection.

FTPはデータ、そして/または、コントロールトランザクションを移すためにRFC171で説明されたデータ転送プロトコルを使用します。 データとコントロールトランザクションの両方が同じ接続の上で伝えられます。

                                                                [Page 3]

NWG/RFC 172

[3ページ] NWG/RFC172

2.  Data Transactions

2. データトランザクション

   Data transactions represent the data contained in a file. There is no
   data type or byte size information contained in data transactions.
   The structure of data is instead communicated via control
   transactions. A file may be transferred as one or more data
   transactions. The protocol neither specifies nor imposes any
   limitations on the structure (record, group, etc) or length of file.
   Such limitations may however be imposed by a serving host. The end of
   a file may be indicated either by a file separator (as defined in
   data transfer protocol), or by closing connection (in type B0). In
   particular a serving or using host should not send the ETX, or other
   end of file character, unless such a character is part of the data in
   file (i.e., not provided by system).

データトランザクションはファイルに含まれたデータを表します。 サイズ情報がデータトランザクションに含んだどんなデータ型もバイトもありません。 データ構造は代わりにコントロールトランザクションで伝えられます。 1つ以上のデータトランザクションとしてファイルを移すかもしれません。 プロトコルは、指定しないで、またファイルの構造(記録、グループなど)か長さに少しの制限も課しません。 しかしながら、そのような制限は給仕のホストによって課されるかもしれません。 ファイル分離文字(データ転送プロトコルで定義されるように)、または接続を終えることによって(タイプB0で)、ファイルの端は示されるかもしれません。 給仕かホストを使用する場合、特に、ETXの、または、他のファイルの終りキャラクタは送られるべきではありません、そのようなキャラクタがファイル(すなわち、システムで、提供されない)のデータの一部でないなら。

3.  Control Transactions

3. コントロールトランザクション

   The control transactions may be typified as requests, identifiers,
   and terminates.  A request fulfillment sequence begins with a request
   and ends with receipt of data (followed by End-of-File) or a
   terminate.

トランザクションがそうするコントロールは、要求、識別子として代表されて、終わります。 要求遂行系列は要求で始まります、そして、データ(ファイルのEndによって続かれている)の領収書がある終わりかaが終わります。

3A. Op Codes

3A。 オペコード

   Control transactions are distinguished by their first byte referred
   as op code. A standard set of opcodes is defined below.
   Implementation of a workable[4] subset of opcodes is specifically
   permitted. Additional standard opcodes may be assigned later. Opcodes
   hex 5A (octal 100) through hex FF (octal 377) are for experimental
   use.

コントロールトランザクションはオペコードとして参照されたそれらの最初のバイトによって区別されます。 opcodesの標準セットは以下で定義されます。 opcodesの実行可能な[4]部分集合の実装は明確に受入れられます。 追加標準のopcodesは後で割り当てられるかもしれません。 十六進法FF(8進377)を通したOpcodes十六進法5A(8進100)は実験用のためのものです。

                                                                [Page 4]

NWG/RFC 172

[4ページ] NWG/RFC172

       Op Code                   Operation
     Hex    Octal

オペコード、操作十六進法8進

      00     000         Change data type identifier

00 000変化データ型識別子

      01     001         Retrieve Request

01 001は要求を検索します。

      02     002         Store request (replaced if file already
                         exists)

02 002ストア要求(ファイルが既に存在しているなら、取り替えます)

      03     003         Delete request

03 003は要求を削除します。

      04     004         Rename_from request

04 004は要求から_を改名します。

      05     005         Rename_to request

05 005は要求する_を改名します。

      06     006         List_file_directory request

06 006リスト_ファイル_ディレクトリ要求

      07     007         Username identifier

07 007ユーザ名識別子

      08     010         Password identifier

08 010パスワード識別子

      09     011         Error or unsuccessful terminate

09 011誤りか失敗、終わり

      04     012         Acknowledge or successful terminate

012が承認する04、うまくいく、終わり

      0B     013         Append request (add to existing file)

0B013は要求を追加します。(既存ファイルに追加します)

      0C     014

0 C014

   through through       Reserved for standard assignment

Reservedを通して標準割当てにおいて突き抜けます。

      4F     077

4F077

      5A     100

5A100

   through through       Reserved for experimental use

Reservedを通して実験用において突き抜けます。

      FF     377

ff377

                                                                [Page 5]

NWG/RFC 172

[5ページ] NWG/RFC172

3B. Syntax and Semantics

3B。 構文と意味論

3B.1 Data Types

3B.1データ型

   The 'change data type' control transactions identifies the structure
   of data (data type and byte size) in succeeding data transactions.
   This transaction shall contain two more bytes in addition to the
   opcode byte. The first of these bytes shall convey a data type or
   code information and the second byte may convey the data byte size,
   where applicable. This information may be used to define the manner
   in which data is to be parsed, interpreted, reconfigured or stored.
   Change data type need be sent only when structure of data is changed
   from the preceding.

'変化データ型'コントロールトランザクションは続くデータトランザクションでデータ構造を特定します(データ型とバイトサイズ)。 このトランザクションはopcodeバイトに加えたもう2バイトを含むものとします。 これらのバイトの1番目がデータ型を伝えるものとしますか、またはコード情報と2番目のバイトはデータ・バイトサイズを適切であるところに伝えるかもしれません。 この情報は、分析されるか、解釈されるか、再構成されるか、または保存されるデータがことである方法を定義するのに使用されるかもしれません。 先行からデータ構造を変えるときだけ、変化データ型を送らなければなりません。

   Although, a number of data types are defined, specific
   implementations may handle only limited data types or completely
   ignore the data type and byte size descriptors. Even if a host
   process does not "recognize" a data type, it must accept data (i.e.,
   there is no such thing as a data type error.) These descriptors are
   provided only for convenience, and it is not essential that they be
   used. The standard default is to assume nothing about the information
   and treat it as a bit stream (binary data, byte size 1)[5] whose
   interpretation is left to a higher level process, or the user.

多くのデータ型が定義されて、特定の実装は、限られたデータ型だけを扱うか、またはデータ型とバイトサイズ記述子を完全に無視するかもしれませんが。 ホストプロセスがデータ型を「認識しない」でも、それはデータを受け入れなければなりません(すなわち、データ型誤りなんてことがありません。)。 これらの記述子を便利だけに提供します、そして、それらが使用されるのは、不可欠ではありません。 標準省略時解釈は、少し流れるとき、情報に関して何も仮定しないで、それを扱うことです。(バイナリ・データ(サイズ1) [5] 解釈が高レベル処理、またはユーザに任せるバイト)。

   _________________________
   * It is, however, possible that this bit stream is treated like
   ASCII characters in specific instances such as transmitting a file
   to a line printer.

_________________________ * しかしながら、このビットストリームがファイルをラインプリンタに送ることなどの特定のインスタンスにおけるASCII文字のように扱われるのは、可能です。

                                                                [Page 6]

NWG/RFC 172

[6ページ] NWG/RFC172

   The following data type codes are currently assigned. Where a
   byte size is not implicit in data type, it may be provided by the
   second byte.

以下のデータ型コードは現在、割り当てられます。 サイズがデータ型で1バイト、暗に示されていないところに、2番目のバイト単位でそれを提供するかもしれません。

     Hex    Octal

魔法をかけます。

      00     000         1               Bit stream (standard default)

00 000 1ビットストリーム(標準省略時解釈)

      01     001       none              Binary data bytes

01 001 Binaryのいずれ、もデータ・バイトでない

      02     002         8               Network ASCII characters

02 002 8人のネットワークASCII文字

      03     003         8               EBCDIC characters

03 003 8人のEBCDlC文字

      04     004        36               DEC-packed ASCII (five 7-bit
                                         characters, 36th bit 1 or 0)

04 004の36の12月が詰まっているASCII(5つの7ビットのキャラクタ、ビット1または36番目の0)

      05     005         8               Decimal numbers, net. ASCII

05 005 8つの10進数、ネット。 ASCII

      06     006         8               Octal numbers, net. ASCII

06 006 8つの8進数、ネット。 ASCII

      07     007         8               Hexadecimal numbers, net. ASCII

07 007 8つの16進数、ネット。 ASCII

      08     010

08 010

   through through                       Reserved for standard assignment

Reservedを通して標準割当てにおいて突き抜けます。

      4F     077

4F077

      5A     100

5A100

   through through                       Reserved for experimental use

Reservedを通して実験用において突き抜けます。

      FF     377

ff377

3B.2 Requests and Identifiers

3B.2要求と識別子

   Retrieve, delete, name_from, rename_t, and append requests contain a
   pathname, following the op code, in the information field. A pathname
   may also follow the opcode in list_file_directory request.

検索、削除、_を命名する、_をtに改名してください、そして、情報フィールドでパス名を保管していて、オペコードに従って、要求を追加してください。 また、パス名はリスト_ファイル_ディレクトリ要求でopcodeに続くかもしれません。

   A pathname must uniquely identify a file in the serving host. The
   syntax of pathnames and identifying information shall conform to
   serving host conventions, except that standard network ASCII (as
   defined in the TELNET protocol) shall be used.

パス名は給仕のホストで唯一ファイルを特定しなければなりません。 パス名と身元が分かる情報の構文は給仕ホストコンベンションに従うものとして、その標準のネットワークを除いて、ASCII(TELNETプロトコルで定義されるように)は使用されるものとします。

                                                                [Page 7]

NWG/RFC 172

[7ページ] NWG/RFC172

   The store request has a 4-byte (32 bits) 'allocate size' field
   followed by pathname. 'Allocate size' indicates the number of bits of
   storage to be allocated to the file. A size of zero indicates that
   server should use his default.

店要求で、パス名は'サイズを割り当ててください'という4バイト(32ビット)の野原のあとに続きます。 'サイズを割り当ててください'はファイルに割り当てられるストレージのビットの数を示します。 ゼロのサイズは、サーバが彼のデフォルトを使用するべきであるのを示します。

   Retrieve request achieves the transfer of a copy of file specified in
   pathname, from serving to using host. The status and contents of file
   in serving host should be unaffected.

要求を検索してください。ホストを使用するのに役立つのでパス名で指定されたコピーのファイルの転送を達成します。 ホストに役立つことにおけるファイルの状態とコンテンツは影響を受けないはずです。

   Store request achieves the transfer of a copy of file specified in
   pathname, from using to serving host. If file specified in pathname
   exists on serving hosts, then its contents shall be replaced by the
   contents of the file being transferred. A new file is created at the
   serving host, if the file specified in pathname does not exist.

ストア要求はパス名で使用からホストに役立つまで指定されたファイルのコピーの転送を実現します。 ホストに役立つときパス名で指定されたファイルが存在するなら、コンテンツを移されるファイルのコンテンツに取り替えるものとします。 パス名で指定されたファイルが存在していないなら、新しいファイルは給仕のホストで作成されます。

   Append request achieves the transfer of data from using to serving
   host. The transferred data is appended to file specified in pathname,
   at serving host.

要求を追加してください。使用からホストに役立つまでのデータ転送を達成します。 パス名でホストに役立つのに指定されたファイルにわたっているデータを追加します。

   Rename-from and rename-to requests cause the name of the file
   specified in pathname of rename_from to be changed to the name
   specified in pathname of rename_to. A rename_from must always be
   followed by a rename_to request.

そして、改名、-、改名、-、ファイルの名前がパス名で指定した原因が_を改名するよう要求する、パス名で指定された名前に変える、_を改名します。 _必須から、aはいつもあとに続いてください。Aが改名する、要求する_に改名します。

   Delete request causes file specified in pathname to be deleted from
   the serving host. If an extra level of protection is desired such as
   the query "Do you really wish to delete this file?", it is to be a
   local implementation in the using system. Such queries should not be
   transmitted over network connections.

ファイルが給仕のホストから削除されるためにパス名で指定した要求原因を削除してください。 付加的なレベルの保護が「あなたは本当にこのファイルを削除したいですか?」という質問などのように望まれていて、ことであるなら、それによる使用システムの地方の実装です。 そのような質問をネットワーク接続の上に伝えるべきではありません。

   Username and password identifiers contain the respective identifying
   information. Normally, the information will be supplied by the user
   of the file transfer service. These identifiers are normally sent at
   the start of connection.

ユーザ名とパスワード識別子はそれぞれの身元が分かる情報を含んでいます。 通常、情報はファイル転送サービスのユーザによって提供されるでしょう。 通常、接続の始めでこれらの識別子を送ります。

3B.3 Error and Acknowledge Terminates

3B.3誤り、承認、終わり

   The error transactions may have an error code indicated by the second
   descriptor byte. Transmission of an error message in text is also
   permitted. The following error codes are defined.

誤りトランザクションには、2番目の記述子バイトによって示されたエラーコードがあるかもしれません。 また、テキストにおける、エラーメッセージの伝達は受入れられます。 以下のエラーコードは定義されます。

                                                                [Page 8]

NWG/RFC 172

[8ページ] NWG/RFC172

     Error Code (2nd descriptor byte)           Meaning
    Hex    Octal

誤りCode(2番目の記述子バイト)意味Hex Octal

     00     000                 Error condition indicated by computer
                                system (external to protocol)

00 コンピュータ・システムによって示された000エラー条件(議定書の中で述べるためには外部)です。

     01     001                 Name syntax error

01 001名前構文エラー

     02     003                 Access control violation

02 003アクセス制御違反

     03     003                 Abort

03 003は中止になります。

     04     004                 Allocate size too big

04 004はあまりに大きくサイズを割り当てます。

     05     005                 Allocate size overflow

05 005はサイズオーバーフローを割り当てます。

     06     006                 Improper order for transactions

06 トランザクションの006の不適当な注文

     07     007                 Opcode not implemented

07 Opcodeが実装しなかった007

     08     010                 File search failed

08 010ファイル検索は失敗しました。

     09     011                 Error described in text message
                                (ASCII characters follow code)

09 テキストメッセージで説明された011誤り(ASCII文字はコードに従います)

At present, no completion codes are defined for acknowledge. It is
assumed that acknowledge refers to the current request being
fulfilled.

現在のところ完了コードが全く定義されない、承認します。 実現する現在の要求を示しますそれが、認めるそれが思われる。

4. Order of Transactions

4. トランザクションの注文

4A. A certain order of transactions must be maintained in fulfilling
    file transfer requests. The exact sequence in which transactions
    occur depends on the type of request, as described in section
    4B. The fulfilling of a request may be aborted anytime by either
    host, as explained in section 4C.

4A。 実現しているファイル転送要求でトランザクションのある注文を維持しなければなりません。 トランザクションが起こる完全系列はセクション4Bで説明されるように要求のタイプに頼っています。 要求の実現はセクション4 Cで説明されるようにいつでもどちらのホストによっても中止されるかもしれません。

4B. Identifier transactions (change data type, username, and password)
    may be sent by user at any time. The usual order would be a
    username transaction followed by a password transaction at the
    start of the connection. No acknowledge is required, or
    permitted. The identifiers are to be used for default handling,
    and access control.

4B。 識別子トランザクション(変化データ型、ユーザ名、およびパスワード)はいつでも、ユーザによって送られるかもしれません。 普通のオーダーはパスワードトランザクションが接続の始めでいうことになったユーザ名トランザクションです。 必要である、または受入れられますいいえが、認める。 識別子はデフォルト取り扱い、およびアクセスコントロールに使用されることです。

                                                                [Page 9]

NWG/RFC 172

[9ページ] NWG/RFC172

    Retrieve and list_file_directory requests cause the transfer of
    file from server to user. After a complete file has been
    transferred, the server should indicate end-of-file (by sending
    CLS or file separator) to complete the request fulfillment
    sequence, as shown below.

_要求がファイルのサーバからユーザまでの転送を引き起こすファイル_ディレクトリを検索して、リストアップしてください。 完全なファイルを移した後に、サーバは要求遂行系列を完了するために、ファイルの終り(CLSかファイル分離文字を送るのによる)を示すべきです、以下に示すように。

          Read / List_file_directory request
         ------------------------------------->
    User            <File -- data>              Server
         <-------------------------------------
                End of file indication
         <-------------------------------------

_ファイル_ディレクトリ要求を読むか、またはリストアップしてください。------------------------------------->ユーザ<File--データ>Server<。------------------------------------- ファイルの終り指示<。-------------------------------------

    Store and append requests cause the transfer of file from user to
    server. After a complete file has been transferred, the user
    should send an end-of-file indication. The receipt of the file
    must be acknowledged by the server, as shown below.

ファイルのユーザからサーバまでの転送を引き起こしてください。完全なファイルを移した後にユーザがファイルの終り指示を送るべきであるという要求を保存して、追加してください。 以下に示されるようにサーバでファイルの領収書を受け取ったことを知らせなければなりません。

    User          Store / Append request        Server
         ------------------------------------->
                  <File -- data>
         ------------------------------------->
                  End of file indication
         ------------------------------------->
                  Acknowledge
         <-------------------------------------

ユーザストア/は要求Serverを追加します。-------------------------------------><ファイル--データ>。------------------------------------->ファイルの終り指示------------------------------------->は<を承認します。-------------------------------------

    Rename_from request must be followed by a rename_to request. The
    request must be acknowledged as shown below.

aは要求からの_のあとに続かなければなりません。改名、要求する_に改名します。 以下に示すように要求を承諾しなければなりません。

    User          Rename_from request           Server
         ------------------------------------->
                  Rename_to request
         ------------------------------------->
                  Acknowledge
         <-------------------------------------

要求ServerからのユーザRename_------------------------------------->は要求する_を改名します。------------------------------------->は<を承認します。-------------------------------------

    The delete request requires the server to acknowledge it, as shown
    below.

要求を削除してください。以下に示すようにそれを承認するためにサーバを必要とします。

    User              Delete                    Server
         ------------------------------------->
                    Acknowledge
         <-------------------------------------

ユーザはサーバを削除します。------------------------------------->は<を承認します。-------------------------------------

    Error transactions may be sent by either host at any time, and
    these terminate the current request fulfillment sequence.

誤りトランザクションはいつでもどちらのホストによっても送られるかもしれません、そして、これらは現在の要求遂行系列を終えます。

                                                               [Page 10]

NWG/RFC 172

[10ページ] NWG/RFC172

4C. Aborts. Either host may abort a request fulfillment sequence at
    any time by sending an error terminate, or by closing the
    connection (NCP to transmit a CLS for the connection). CLS is a
    more drastic type of abort and shall be used when there is a
    catastrophic failure, or when abort is desired in the middle of a
    long transaction. The abort indicates to the receiving host that
    sender of abort wishes to terminate request fulfillment and is now
    ready to initiate or fulfill new requests. When CLS is used to
    abort, the using host will be responsible for reopening
    connection. The file transfer abort described here is different
    from the data transfer abort which is sent only by the sender of
    data. The use of the data transfer abort is not defined in this
    protocol.

4C。 アボート。 どちらかのホストは、いつでも発信するのによる誤りが終える要求遂行系列を中止するか、または接続(接続のためにCLSを伝えるNCP)を終えることによって、そうするかもしれません。 突発故障があるか、またはアボートが長いトランザクションの中央で望まれているとき、CLSは、より抜本的なタイプのアボートであり、使用されるものとします。 アボートは、新しい要求を要求遂行を終えるというアボート願望のその送付者を受信ホストに示して、開始する準備ができているか、または現在、実現させる準備ができています。 CLSが中止になるのに使用されるとき、使用しているホストは接続を再開させるのに責任があるでしょう。 ここで説明されたファイル転送アボートは単にデータの送付者によって送られるデータ転送アボートと異なっています。 データ転送アボートの使用はこのプロトコルで定義されません。

6.  Initial Connection, CLS, and Access Control

6. 初期の接続、CLS、およびアクセスコントロール

6A. There will be a preassigned permanent socket number[6] for the
    cooperating file transfer process at the serving host. The
    connection establishment will be in accordance with the standard
    initial connection protocol[7], establishing a full-duplex
    connection.

6A。 協力関係を持っているファイル転送プロセスの「前-割り当て」られた本ソケット番号[6]が給仕のホストにあるでしょう。 全二重接続を確立して、標準の初期の接続プロトコル[7]によると、コネクション確立があるでしょう。

6B. The connection will be broken by trading a CLS between the NCP's
    for each of the two connections. Normally, the user will initiate
    CLS.

6B。 接続は、接続2人の各人のためにNCPの間でCLSを取り引きすることによって、調教されるでしょう。 通常、ユーザはCLSを開始するでしょう。

    CLS may also be used by either user or server, to abort a
    transaction in the middle. If CLS is received in the middle of
    transaction, the current request fulfillment sequence will be
    aborted. The using host will then reopen connection.

また、CLSはユーザかサーバのどちらかによって使用されて、中央でトランザクションを中止するかもしれません。 トランザクションの中央にCLSを受け取ると、現在の要求遂行系列を中止するでしょう。 そして、使用しているホストは接続を再開させるでしょう。

6C. It is recommended that identifier (user name and password)
    transactions be sent by user to server , at the start, as this
    would facilitate default handling and access control for the
    entire duration of connection. The identifier transactions do not
    require or permit and acknowledge, and the user can proceed
    directly with requests. If the identifier information is incorrect
    or not received, the server may send an error transaction
    indicating access control, violation, upon subsequent requests.

6C。 識別子(ユーザ名とパスワード)トランザクションがユーザによってサーバに送られるのは、お勧めです、始めで、これが接続の全体の持続時間のためのデフォルト取り扱いとアクセスコントロールを容易にするだろうというとき。 トランザクションが必要であるか、可能にして、または承認しないで、ユーザが直接要求で続かせることができる識別子。 識別子情報が不正確であるか、または受信されていないなら、誤りトランザクションはサーバでアクセスコントロールを示すかもしれません、違反、その後の要求に関して。

NOTES

注意

[1] Alex McKenzie, BBN, is conducting a survey of network file systems
to determine the practicality of standard pathname conventions, and to
disseminate information to network users on host file systems.

[1] アレックス・マッケンジー(BBN)は、一般的なパス名コンベンションの実用性を決定して、ホストファイルシステムで情報をネットワーク利用者に広めるためにネットワークファイルシステムの調査を指導しています。

                                                               [Page 11]

NWG/RFC 172

[11ページ] NWG/RFC172

[2] This initial subset represents control functions necessary for basic
file transfer operations, and some elementary file manipulation
operations. There is no attempt to provide a data management or complete
file management capability.

[2] この初期の部分集合は基本的なファイル転送操作、およびいくつかの基本のファイル操作操作に必要なコントロール機能を表します。 データ管理か完全なファイル管理機能を提供する試みが全くありません。

[3] It is possible that we may, at a later date, assign meaning to these
information separators within FTP.

[3] 私たちが、より後日FTPの中でこれらの情報分離に意味を割り当てるのは、可能です。

[4] A workable subset is any request, plus terminates. Identifiers may
be required in addition when using protected file systems.

[4] 実行可能な部分集合は、どんな要求でありも、終わります。 保護されたファイルシステムを使用するとき、識別子がさらに、必要であるかもしれません。

[5] It is, however, possible that this bit stream is treated like ASCII
characters in specific instances such as transmitting a file to a line
printer.

[5] しかしながら、このビットストリームがファイルをラインプリンタに送ることなどの特定のインスタンスにおけるASCII文字のように扱われるのは、可能です。

[6] It seems that socket 1 has been assigned to logger. Socket 3 seems a
reasonable choice for File Transfer.

[6] ソケット1がきこりに割り当てられたように思えます。 ソケット3はFile Transferに関して正当な選択に見えます。

[7] RFC 165, or any subsequent standard applicable in initial connection
to loggers.

[7] 初期の接続できこりに適切なRFC165、またはどんなその後の規格。

       [ This RFC was put into machine readable form for entry ]
 [ into the online RFC archives by Glenn Forbes Fleming Larratt 5/97 ]

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

                                                               [Page 12]

[12ページ]