RFC354 日本語訳
0354 File Transfer Protocol. A.K. Bhushan. July 1972. (Format: TXT=58074 bytes) (Obsoletes RFC0264, RFC0265) (Obsoleted by RFC0542) (Updated by RFC0385, RFC0454, RFC0683) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Abhay Bhushan Request for Comments: 354 MIT-MAC NIC: 10596 July 8, 1972 Categories D.4, D.5, D.7 Obsoletes: RFC 264 and 265
ネットワークワーキンググループAbhay Bhushanはコメントのために以下を要求します。 354 MIT-Mac NIC: 10596 1972年7月8日カテゴリD.4、D.5、D.7は以下を時代遅れにします。 RFC264と265
THE FILE TRANSFER PROTOCOL
ファイル転送プロトコル
I. INTRODUCTION
I. 序論
The File Transfer Protocol (FTP) is a protocol for file
transfer betweet HOSTs (including terminal IMPs), on the ARPA
Computer Network (ARPANET). The primary function of FTP is to
transfer files efficiently and reliably among HOSTs and to allow
the convenient use of remote file storage capabilities.
File Transferプロトコル(FTP)はファイル転送betweet HOSTsのためのプロトコル(端末のIMPsを含んでいて)です、ARPAコンピュータNetwork(アルパネット)で。 FTPのプライマリ機能は、ファイルをHOSTsに効率的に、そして確かに移して、リモートファイル機構の便利な使用を許すことです。
The objectives of FTP are 1) to promote sharing of files
(computer programs and/or data), 2) fo encourage indirect or
implicit (via programs) use of remote computers, 3) to shield a
user from variations in file storage systems among HOSTs, and
4) to transfer data reliably and efficiently. FTP, though usable
directly by user at a terminal, is designed mainly for use by
programs.
FTPの目的はファイル(コンピュータ・プログラム、そして/または、データ)を共有する促進する1、)2)foが、リモート・コンピュータの間接的であるか暗黙(プログラムを通した)の使用、HOSTsの中のファイルストレージシステムの変化からユーザを保護する3、)および4が)確かに効率的にデータを移すよう奨励するということです。 直接端末のユーザが使用可能ですが、FTPは主に使用のためにプログラムで設計されています。
The attempt in this specification is to satisfy the diverse
needs of users of maxi-HOSTs, mini-HOSTs, TIPs, and the
Datacomputer, with a simple, elegant, and easily implemented
protocol design.
この仕様に基づく試みは大型-HOSTs、ミニHOSTs、TIPs、およびDatacomputerのユーザのさまざまの需要を満たすことです、簡単で、上品で、容易に実装しているプロトコルデザインで。
This paper assumes knowledge of the following protocols:
この紙は以下のプロトコルに関する知識を仮定します:
1) The HOST-HOST Protocol (NIC #8246)
1) ホスト兼ホストプロトコル(NIC#8246)
2) The initial Connection Protocol (NIC #7101)
2) 初期のConnectionプロトコル(NIC#7101)
3) The TELNET Protocol (NWG/RFC #318, NIC #9348)
3) telnetプロトコル(NWG/RFC#318、NIC#9348)
II. DISCUSSION
II。 議論
In this section, the terminology and the FTP model are
discussed. The terms defined in this section are only those that
have special significance in FTP.
このセクションで、用語とFTPモデルについて議論します。 このセクションで定義された用語はFTPにおける特別な意味があるものにすぎません。
[Page 1]
The File Transfer Protocol July 8, 1972
[1ページ] ファイル転送プロトコル1972年7月8日
11.A. Terminology
11. A.用語
ASCII The USASCII character set as defined in NIC
#7104. In FTP, ASCII characters are defined
to be the lower half of an eight bit code set
(i.e., the most significant bit es zero).
ASCIIは7104年にNIC#定義されるUSASCII文字集合です。 FTPでは、ASCII文字は、1つの8ビット・コードセット(すなわち、esが合っているゼロ最も重要なビット)の下半分になるように定義されます。
access controls Access controls define users' access
privileges to the use of a system, and to the
files in that system. Access controls are
necessary to prevent unauthorized or
accidental use of files. It is the
prerogative of a user-FTP process to provide
access controls.
Accessが制御するアクセス制御はシステムの使用と、そして、そのシステムのファイルへのユーザのアクセス権を定義します。 アクセス制御が、ファイルの権限のないか偶然の使用を防ぐのに必要です。 それはアクセス制御を提供するユーザFTPプロセスの特権です。
byte size The byte size specified for the transfer of
data. The data connection is opened with
this byte size. Data connection byte size is
not necessarily the byte size in which data
is to be stored in a system, and may not be
related to the structure of data.
バイトサイズがデータ転送に指定したバイトサイズ。 データ接続はこのバイトサイズで開かれます。 データ接続バイトサイズは、必ずシステムに保存されるデータがことであるバイトサイズであるというわけではなく、データ構造に関連しないかもしれません。
data connection A simplex connection over which data is
transferred, in a specified byte size, mode
and type. The data transferred may be a part
of a file, an entire file or a number of
files. The data connection may be in either
direction (server-to-user or user-to server).
指定されたバイトサイズ、モード、およびタイプでデータ接続Aシンプレクス接続をどのデータの上に移すか。 移されたデータはファイル、ファイル全体または多くのファイルの一部であるかもしれません。 または、どちらの方向にはデータ接続があるかもしれない、(サーバからユーザ、ユーザ、-、サーバ)
data socket The socket on which a User-FTP process
"listens" for a data connection.
データソケット、User-FTPプロセスがデータ接続のために「聴かれる」ソケット。
EOF The end-of-file conidition that defines the
end of a file being transferred.
EOF、移されるファイルの端を定義するファイルの終りconidition。
EOR The end-of-record condition that defines the
end of a record being transferred.
移される記録の終わりを定義する記録の終わりが条件とさせるEOR。
error recovery A procedure that allows a user to recover
form certain errors such as failure of either
Host system or transfer process In FTP,
error recovery may involve restarting a file
transfer at a given checkpoint
ユーザがHostシステムか転送のどちらかの失敗などの誤りがIn FTPを処理するのを確信しているフォームを回復できるエラー回復A手順、エラー回復は与えられたチェックポイントでファイル転送を再開することを伴うかもしれません。
FTP commands A set of commands that comprise the control
information flowing from the user-FTP to the
server-FTP process.
Aが設定したユーザFTPからサーバFTPまで流れる制御情報を包括するコマンドのFTPコマンドは処理されます。
[Page 2]
The File Transfer Protocol July 8, 1972
[2ページ] ファイル転送プロトコル1972年7月8日
file An ordered set of computer data (including
programs) of arbitrary length uniquely
identified by a pathname.
パス名によって唯一特定されたAn順序集合に関する任意の長さに関するコンピュータのデータ(プログラムを含んでいる)をファイルしてください。
mode The mode in which data is to be transferred
via the data connection. The mode defines
the data format including EOR and EOF. The
transfer modes defined in FTP are described
in Section III.A.
モード、モードはどのデータでデータ接続で移すかことです。 モードはEORとEOFを含むデータの形式を定義します。 FTPで定義された転送モードはセクションIII.Aで説明されます。
NVT The Network Virtual Terminal as defined in
the ARPANET TELNET Protocol.
ARPANET TELNETプロトコルで定義されるNVT Network Virtual Terminal。
NVFS The Network Virtual File System. A concept
which defines a standard network file system
with standard commands and pathname
conventions. FTP only partially embraces the
NFS concept at this time.
NVFSのネットワークの仮想のファイルシステム。 標準のコマンドとパス名コンベンションと共に標準のネットワークファイルシステムを定義する概念。 FTPはこのとき、NFS概念を部分的に受け入れるだけです。
pathname Pathname is defined to be the character
string which must be input to a file system
by a user in order to identify a file.
Pathname normally contains device and/or
directory names, and file name specification.
FTP does not yet specify a standard pathname
convention. Each user must follow the file
naming conventions of hte file systems he
wishes to use.
パス名Pathnameは、ユーザがファイルを特定するためにファイルシステムに入力しなければならない文字列になるように定義されます。 通常、パス名はデバイス、そして/または、ディレクトリ名と、ファイル名仕様を含んでいます。 FTPはまだ一般的なパス名コンベンションを指定していません。 各ユーザは彼が使用したがっているhteファイルシステムのファイル命名規則に続かなければなりません。
record A sequential file may be structured as a
number of contiguous parts called records.
Record structures are supported by FTP but
are not mandatory.
多くの隣接の部品が、記録と呼んだように記録的なA順編成ファイルは構造化されるかもしれません。 記録的な構造は、FTPによってサポートされますが、義務的ではありません。
reply A reply is an acknowledgment (positive or
negative) sent from server to user via the
telnet connections in response to FTP
commands. The general form of a reply is a
completion code (including error codes)
followed by an ASCII text string. The codes
are for use by programs and the text is for
human users.
回答A回答はFTPコマンドに対応したtelnet接続でサーバからユーザに送られた承認(肯定しているか否定している)です。 回答の一般的なフォームはASCIIテキスト文字列がいうことになった完了コード(エラーコードを含んでいる)です。 プログラムによってコードは使用のためのものです、そして、テキストは人間のユーザのためのものです。
server-FTP process A process or set of processes which perform
the function of file transfer in cooperation
with a user-FTP process. The server-FTP
process must interpret and respond to user
commands and initiate the data connection.
ユーザFTPプロセスと提携してファイル転送の機能を実行するプロセスのサーバFTPプロセスAプロセスかセット。 サーバFTPプロセスは、解釈して、ユーザコマンドに応じて、データ接続を開始しなければなりません。
[Page 3]
The File Transfer Protocol July 8, 1972
[3ページ] ファイル転送プロトコル1972年7月8日
server site A HOST site wich has a server-FTP process.
サーバサイトA HOSTサイトwichには、サーバFTPプロセスがあります。
server-TELNET A TELNET process which listens on a specified
socket for an ICP initiated by a user-TELNET,
and perform in accordance with the ARPANET
TELNET Protocol.
ARPANET TELNETプロトコルによると、ICPのために指定されたソケットの上に聴かれるサーバ-TELNET A TELNETプロセスは、ユーザ-TELNETで開始して、働きました。
TELNET connections The full-duplex communication path between a
user-TELNET and a server-TELNET. The TELNET
connections are established via the standard
ARPANET initial Connection Protocol (ICP).
TELNET接続、ユーザ-TELNETとサーバ-TELNETの間の全二重通信経路。 標準のアルパネット初期のConnectionプロトコル(ICP)でTELNET接続は確立されます。
type The data representation type used for data
transfer and storage. Type implies certain
transformations between the time of data
storage and data transfer. The
representation types defined in FTP are
described in Section III.B.
データ転送とストレージに使用されるデータ表現タイプをタイプしてください。 タイプはデータ保存とデータ転送の時間の間で、ある変換について暗示します。 FTPで定義された表現タイプはセクションIII.Bで説明されます。
user A process on behalf of a human being or a
human being wishing to obtain file transfer
service.
人間かファイル転送サービスを得たがっている人間を代表したユーザAプロセス。
user site A HOST site satisfying any of the following
conditions: 1) The site where a user is
located, 2) a site where a user-FTP process
is located, 3) a site to which a data
connection is made by a server. In the
normal case, the sites defined by 1, 2, and 3
are the same site, but nothing in FTP
requires that this be so.
以下のいずれも条件とさせるユーザの現場A HOSTサイトの満足させること: 1) サイトはサーバによってどのaデータ接続に作られるか。ユーザが位置しているサイト、2) ユーザFTPプロセスが位置しているサイト、3) 正常な場合では、サイトは1を定義しましたが、2、および3は同じサイトですが、FTPにおける何も、これがそうであることを必要としません。
user-FTP process A process or set of precesses which perform
the function of file transfer in cooperation
with a server-FTP process. The user-FTP
process 1) initiates the ICP (via a
user-TELNET, 2) initiates FTP commands and
3) "listens" on the data socket for the data
connection. In some obvious cases (use from
TIPs and other mini-HOSTs) a user-FTP process
will be subsumed under the term "user".
サーバFTPプロセスと提携してファイル転送の機能を実行する「前-課税」のユーザFTPプロセスAプロセスかセット。 ユーザFTPプロセス1)はICPを開始します(ユーザ-TELNETを通して、2は)FTPコマンドと3を開始します)。 データ接続のためのデータソケットで「聴きます」。 いくつかの明白な場合(TIPsと他のミニHOSTsから、使用する)では、ユーザFTPプロセスは「ユーザ」という諸条件で包括されるでしょう。
user-TELNET A TELNET process which initiates an ICP to a
specified server-TELNET socket, and performs
in accordance with the ARPANET TELNET
protocol.
ユーザ-TELNET A TELNETは処理します(指定されたサーバ-TELNETソケットにICPを開始して、ARPANET TELNETプロトコルによると、働きます)。
[Page 4]
The File Transfer Protocol July 8, 1972
[4ページ] ファイル転送プロトコル1972年7月8日
II.B. The FTP Model
II.B.FTPモデル
With the above definitions in mind, the following model
(shown in Figure 1) may be diagrammed for an FTP service.
上の定義が念頭にある場合、以下のモデル(図1では、目立つ)はFTPサービスのために図解されるかもしれません。
TELNET
connections
File Server Server<------------ User User File
Systems<-> FTP <->TELNET FTP Commands TELNET<->FTP <->System
Process ------------> Process
TELNET接続File Server Server<。------------ ユーザユーザファイルシステム<->、FTP、<->、telnet、FTPがtelnet<を命令する、-、システムが処理する>FTP<->。------------>プロセス
Data
<------------------------------>Socket
Data Connection(s) |
|
USER
データ<。------------------------------>ソケットデータ接続| | ユーザ
Notes: 1. The data connection may be in either direction.
注意: 1. どちらの方向にはデータ接続があるかもしれません。
2. The data connection need not exist all of the time.
2. データ接続は絶えず、存在する必要はありません。
3. The distinctions between user-FTP and user-TELNET,
and between server-FTP and server-TELNET may not
be as clear-cut as shown above. For example, a user-
TELNET may be directly driven by the user.
3. ユーザFTPとユーザ-TELNETと、サーバFTPとサーバ-TELNETの区別はそうではありません。上で示されるのと同じくらい明快です。 例えば、ユーザTELNETはユーザによって直接運転されるかもしれません。
FIGURE 1 Model for FTP Use
1図はFTP使用のためにモデル化します。
In the model described in Figure 1, the user-TELNET
initiates the TELNET connection. Standard FTP commands are then
generated by the user and transmitted to the server site via the TELNET
connections. FTP commands are in ASCII, in accordance with NVT
conventions and the TELNET protocol. Note that commands may be initiated
by the user directly through the user-TELNET or via a user-FTP process.
Standard replies are sent from the server to the user in response to the
commands over the TELNET connections.
図1で説明されたモデル、ユーザ-TELNET開始でのTELNET接続。 標準のFTPコマンドは、次に、ユーザが生成されて、TELNET接続でサーバサイトに送られます。 NVTコンベンションとTELNETプロトコルによると、ASCIIにはFTPコマンドがあります。 コマンドがユーザ-TELNET直接を通して、または、ユーザFTPプロセスを通してユーザによって開始されるかもしれないことに注意してください。 TELNET接続の上のコマンドに対応して標準の回答をサーバからユーザに送ります。
The FTP commands specify the parameters for teh data
connection (data socket, byte size, transfer mode, and representation
type), and the nature of file system operation (store, retrieve, append,
delete, etc.). The user-FTP process or its designate should "listen" on
FTPコマンドがtehデータ接続(データソケット(バイトサイズ)はモード、および表現タイプを移す)へのパラメタ、およびファイルシステム・オペレーションの本質を指定する、(店、検索、追加、削除、など) または、ユーザFTPプロセス、それ、指定、「聴くべきです」。
[Page 5]
The File Transfer Protocol July 8, 1972
[5ページ] ファイル転送プロトコル1972年7月8日
the specified data socket, and it is the server's responsibility to initiate the data connection and data transfer in accordance with the specified data connection parameters. It should be noted that the data socket need not be in the same HOST that initiates the FTP commands via the TELNET connection, but the user or his user-FTP process must ensure a "listen" on the specified data socket. A practical example of such file transfer to third HOSTs is a maxi-HOST user (who may actually be a TIP user) whishing to transmit a file to or from an I/O device attached to a TIP. It should also be noted that two data connections, one for send and the other for receive, may exist simultaneously.
指定されたデータソケット、およびそれはそうです。指定されたデータ接続パラメタによると、データ接続とデータ転送に着手するサーバの責任。 データソケットがTELNET接続でFTPコマンドを開始するのと同じHOSTにある必要はないことに注意されるべきですが、ユーザか彼のユーザFTPプロセスが指定されたデータソケットの「聴いてください」を確実にしなければなりません。 第3HOSTsへのそのようなファイル転送に関する実例はデバイス、または、添付の入出力デバイスからTIPまでファイルを送るためにwhishingする大型-HOSTユーザ(実際にTIPユーザであるかもしれない)です。 また、それが注意されるべきである、その2つの1歳のデータ接続、発信、もう片方、受信してください、そして、同時に、存在してもよいです。
The protocol requires that the TELNET connections be open
while data transfer is in progress. It is the responsibility of the user
to close the TELNET connections when finished using the FTP service. The
server may abort data transfer if the TELNET connections are closed.
プロトコルは、データ転送が進行している間TELNET接続がオープンであることを必要とします。 FTPサービスを利用し終わっていると、それはユーザがTELNET接続を終える責任です。 TELNET接続が閉じられるなら、サーバはデータ転送を中止するかもしれません。
III. DATA TRANSFER FUNCTIONS
III。 データ転送機能
Data and files are transferred only via the data connection.
The data transfer of data is governed by FTP data transfer commands
received on the TELNET connections. The data transfer functions include
establishing the data connection to the specified data socket in the
specified HOST (using the specified byte size), transmitting and
receiving data in the specified representation type and transfer mode,
handling EOR and EOF conditions and error recovery (where applicable).
単にデータ接続でデータとファイルを移します。 データのデータ転送はTELNET接続のときに受け取られたFTPデータ転送コマンドで支配されます。 データ転送機能は、指定されたHOST(指定されたバイトサイズを使用する)、伝える、指定された表現タイプ、転送モード、取り扱いEOR、およびEOF状態のデータを受け取って、およびエラー回復(適切であるところ)で指定されたデータソケットにデータ接続を確立するのを含んでいます。
III.A Establishing Data Connection
データ接続を確立するIII.A
The user site shall "listen" on the specified data socket.
The FTP request command determines the direction of data transfer, and
the socket number (odd or even) which is to be used in establishing the
data connection. The server on receiving the appropriate store or
retrieve request shall initiate the data connection to the specified
user data socket in the specified byte size (default byte size is 8
bits) and send a reply indicating that file transfer may proceed. Prior
to this the server should send a reply indicating the server socket for
the data connection. The user may use this server socket information to
ensure the security of his data transfer. The server may send this reply
either before of after initiating the data connection.
ユーザの現場は指定されたデータソケットで「聴かれるものとします」。 FTP要求コマンドはデータ転送の方向、およびデータ接続を確立する際に使用されることであるソケット番号(変であるか同等の)を決定します。 要求を検索してください。または、適切な店を受けるときのサーバ、指定されたバイトサイズ(デフォルトバイトサイズは8ビットである)で指定された利用者データソケットにデータ接続を開始して、回答にファイル転送が続くかもしれないのを示させるでしょう。 この前に、サーバで、回答はデータ接続のためのサーバソケットを示すべきです。 ユーザは、彼のデータ転送のセキュリティを確実にするのにこのサーバソケット情報を使用するかもしれません。 サーバは以前、後にデータ接続を開始するのについてこの回答を送るかもしれません。
The byte size for the data connection is specified by the
TYPE (ASCII is 8 bits), or TYPE and BYTE commands. It is not required by
the protocol that servers accept all possible byte size. The user of
various byte size is for efficiency in data transfer and servers may
implement only those byte size for which their data transfer is
efficient. It is however recommended that servers implement at least the
byte size of 8 bits.
データ接続のためのバイトサイズはTYPE(ASCIIは8ビットである)か、TYPEとBYTEコマンドで指定されます。 サーバがすべての可能なバイトサイズを受け入れるのがプロトコルによって必要とされません。 データ転送で様々なバイトサイズのユーザは効率に賛成します、そして、サーバはそれらの唯一のバイトがそれらのデータ転送が効率的であるサイズであると実装するかもしれません。 しかしながら、サーバが、少なくともバイトが8ビットのサイズであると実装することが勧められます。
[Page 6]
The File Transfer Protocol July 8, 1972
[6ページ] ファイル転送プロトコル1972年7月8日
After the data transfer is completed, it is the server's
responsibility to close the data connection except when the user is
sender of data. The data connection shall be closed under any of the
following conditions:
データ転送が完成した後に、ユーザがデータの送付者である時を除いて、データ接続を終えるのは、サーバの責任です。 データ接続は以下の条件のどれかの下で閉店するものとします:
1) server receives an abort command form user.
1) サーバはアボートコマンドフォームユーザを受けます。
2) EOF in stream mode indicated by closing data connection.
2) データ接続を終えることによって示されたストリームモードによるEOF。
3) the socket or byte size specification is changed.
3) ソケットかバイトサイズ仕様を変えます。
4) any of the TELNET connections are closed.
4) TELNET接続のいずれも閉じられます。
5) an irrecoverable error condition.
5) 回復しがたいエラー条件。
It should be noted that two simultaneous data connections
(for send and receive) may exist. It is a server option, however, to
close the data connection after each instance of file transfer.
それが注意されるべきである、その2つの同時のデータ接続、(発信してくださいといって、受信してください、)、存在するかもしれません。 それは、しかしながら、ファイル転送の各インスタンスの後にデータ接続を終えるためにはサーバオプションです。
III.B Data Representation and Storage
III.Bデータ表現とストレージ
Data is transferred from a storage device in sending HOST to
a storage device in receiving HOST. Often it is necessary to perform
certain transformations on the data because data storage representations
in the two systems are different. For example, NVT-ASCII has different
data storage representations in different systems. PDP-10's generally
store NVT-ASCII as five 7-bit ASCII characters, left justified in a 36
bit word. 360's store NVT-ASCII as 8-bit EBCDIC codes. Multics stores
NVT-ASCII as four 9-bit characters in a 36-bit word. It may desirable to
convert characters into the standard NVT-ASCII representation when
transmitting text between disimilar systems. The sending and receiving
site would have to perform the necessary transformations between the
standard representation and their internal representations.
HOSTを受ける際にデータを送付HOSTの記憶装置から記憶装置まで移します。2台のシステムにおけるデータ保存表現が異なっているので、しばしば、データに、ある変換を実行するのが必要です。 例えば、NVT-ASCIIには、異系統における異なったデータ保存表現があります。一般に、PDP-10のものは36ビットの単語で正当化されるように残っている5人の7ビットのASCII文字としてNVT-ASCIIを保存します。 360は8ビットのEBCDICコードとしてNVT-ASCIIを保存します。 Multicsは36ビットの単語による4つの9ビットのキャラクタとしてNVT-ASCIIを保存します。 それは望ましいかもしれません。標準の表現と彼らの内部の表現の間でdisimilarシステム送付と受信サイトの間のテキストを伝えるとき、標準のNVT-ASCII表現にキャラクタを変換するのが必要な変換を実行しなければならないのが望ましいです。
A different problem in representation arises when
transmitting binary data (not character codes) between HOST systems with
different word length. it is not always clear how the sender should send
data, and the receiver store it. For example, when transmitting 32-bit
bytes from a 32-bit word-length system to a 36-bit word-length system,
it may be desirable (for reasons of efficiency and usefulness) o store
the 32-bit bytes right justified in a 36-bit word in the latter system.
In any case, the user should have the option of specifying data
representation and transformation functions. It should be noted that FTP
provides for very limited data types reprentations. Transformations
desired beyond this limited capability should be performed by the user
directly or via the use of the Data Reconfiguration Service (DRS, RFC
#138, NIC #6715). Additional representation types may be defined later
if there is a demonstrable need.
異なった語長でバイナリ・データ(キャラクタコードでない)をHOSTシステムの間に伝えるとき、表現における異なった問題は起こります。それはいつも送付者がどうデータを送るべきであるかをクリアするというわけではないことであり、受信機店はそれです。 32ビットの語長システムから36ビットの語長システムまでの伝えることの32ビットのバイトであるときに、例えば、それは32ビットのバイト権利が後者のシステムの36ビットの単語で正当化した望ましい(効率と有用性の理由による)o店であるかもしれません。 どのような場合でも、ユーザには、データ表現と変形関数を指定するオプションがあるべきです。 FTPが非常に限られたデータ型reprentationsに備えることに注意されるべきです。 この限られた能力を超えて必要な変換は直接かData Reconfiguration Service(DRS、RFC#138、NIC#6715)の使用でユーザによって実行されるべきです。 明白な必要があれば、追加表現タイプは後で定義されるかもしれません。
[Page 7]
The File Transfer Protocol July 8, 1972
[7ページ] ファイル転送プロトコル1972年7月8日
Data representations are handled in FTP by a user specifying
a representation type. The type may also specify a fixed transfer byte
size. For example in ASCII and Print File representations, the transfer
byte size must be 8 bits. Only in the Image and Local Byte
representations the byte size specified by the BYTE command is to be
used. The following data representation types are currently defined in
FTP:
データ表現はFTPで表現タイプを指定するユーザによって扱われます。 また、タイプは固定転送バイトサイズを指定するかもしれません。 例えば、ASCIIとPrint File表現、転送バイトでは、サイズは8ビットでなければなりません。 ImageとLocal Byte表現だけでは、サイズがBYTEコマンドで指定したバイトは使用されていることです。 以下のデータ表現タイプは現在、FTPで定義されます:
1. ASCII The sender converts data form its internal
character representation to the standard
ARPANET ASCII form. The receiver converts
the data from the standard form to its own
internal form. The data is transferred in
the standard form. The transfer byte size
must be 8 bits. This type would be used for
transfer of text files. This is be default
type, and it is recommended that this type be
implemented by all.
1. 送付者のASCIIは標準のアルパネットASCIIへの内部の文字表示が形成するデータフォームを変換します。 受信機は標準形式から内部のそれ自身のフォームまでデータを変換します。 標準形式でデータを移します。 転送バイトサイズは8ビットでなければなりません。 このタイプはテキストファイルの転送に使用されるでしょう。 これはデフォルトタイプであることです、そして、このタイプがすべてによって実装されるのは、お勧めです。
2. Image The sender transforms data from contiguous
bits to bytes for transfer. The receiver
transforms the bytes into bits, storing them
contiguously independent of the byte size
chosen for data transfer. Typical uses for
the Image type are transfer of executable
programs between like machines, and transfer
of binary (non-text) data. It is recommended
that this type be implemented by all for some
byte size preferably including the 8 bit byte
size.
2. 送付者が隣接のビットからバイトまでのデータを変えるイメージは移されます。 データ転送に選ばれたバイトサイズの如何にかかわらず近接してそれらを保存して、受信機はバイトをビットに変えます。 Imageタイプへの典型的な用途は、同様のマシンの間の実行可能プログラムの転送と、2進(非テキストの)のデータの転送です。 このタイプが望ましくは、8ビットのバイトサイズを含む何らかのバイトサイズのためにすべてによって実装されるのは、お勧めです。
3. Local Byte This representation allows for efficient
storage, use, and retrieval of data. The
mann in which data is to be transformed
depends on the byte size for data transfer,
and the particular HOST being used. The
transformation scheme for different byte size
is to be well publicized b all server sites.
This transformation shall be invertible
(i.e., if a file is stored using a certain
transfer byte size, an identical file must be
retrievable using the same byte size and
representation type). It is the user's
responsibility to keep track of the
representation type and byte size used for
his transfer. Typical uses of the Local Byte
type are in efficient storage and retrieval
of files, and transfer of structured binary
3. ローカルのByte This表現は効率的なストレージ、使用、およびデータ検索を考慮します。 変成しているデータがことであるmannはデータ転送、および使用される特定のHOSTのためにバイトサイズに依存します。 変換はピーアールされた井戸がbであったならサイズがある異なったバイトを計画します。すべてのサーバサイト。 この変換はinvertible(すなわち、ファイルが、ある転送バイトサイズを使用することで保存されるなら、同じファイルはサイズと表現がタイプする同じバイトを使用することで回収可能であるに違いない)でしょう。 サイズが彼の転送に使用した表現タイプとバイトの動向をおさえるのは、ユーザの責任です。 Local Byteタイプの典型的な用途はファイルの効率的なストレージと検索、および構造化されたバイナリーの転送中です。
[Page 8]
The File Transfer Protocol July 8, 1972
[8ページ] ファイル転送プロトコル1972年7月8日
data. This type may be identical to the
image type for byte size which are integral
multiples of or factors of the computer word
length-
データ。 イメージタイプに、このタイプはバイトサイズのために同じであるかもしれません(コンピュータ語長の整数倍か要素です)。
4. Print File- The server site will transform the ASCII
ASCII file in a form suitable for printing at the
server site. The byte size must be 8 bits.
The transformation may not be invertible.
This type is different from ASCII in that
TABs, FFs and other ASCII format effector
characters may be replaced by SPs, LFs, and
other substitute characters. The print file
conversions are to be well publicized by all
server sites. This type would be used when
the file is destined for an ASCII printer.
This type in some systems may be identical to
the ASCII type. It is recommended that this
type be implemented by all.
4. 印刷Fileサーバサイトはサーバサイトで印刷するのに適当なフォームでASCII ASCIIファイルを変えるでしょう。 バイトサイズは8ビットでなければなりません。 変換はinvertibleでないかもしれません。 このタイプはASCIIとTABs、FFs、および他のASCII書式エフェクタキャラクタをSPs、LFs、および他の置換え文字に取り替えるかもしれないという点において異なっています。 印刷ファイル変換はすべてのサーバサイトによってよくピーアールされることです。 ファイルがASCIIプリンタのために運命づけられているとき、このタイプは使用されるでしょう。 ASCIIタイプに、いくつかのシステムのこのタイプは同じであるかもしれません。 このタイプがすべてによって実装されるのは、お勧めです。
5. EBCDIC Print The server site will transform the EBCDIC
File file into a form suitable for printing at the
server site. The byte size must be 8 bits.
the transformation may not be invertible.
This type would be used when the file is
destined for an EBCDIC printer. Only systems
which use EBCDIC for their internal character
representation need accept this type.
5. サーバサイトが望んでいるEBCDIC PrintはEBCDIC Fileファイルをサーバサイトで印刷するのに適当なフォームに変えます。 バイトサイズは8ビットでなければなりません。変換はinvertibleでないかもしれません。 ファイルがEBCDICプリンタのために運命づけられているとき、このタイプは使用されるでしょう。 彼らの内部の文字表示にEBCDICを使用するシステムだけがこのタイプを受け入れなければなりません。
It should be noted that a serving HOST need not accept all
representation types and/or byte size, but it must inform the user of
the fact by sending an appropriate reply.
給仕HOSTがすべての表現タイプ、そして/または、バイトサイズを受け入れる必要はないことに注意されるべきですが、それは、適切な回答を送ることによって、事実をユーザに知らせなければなりません。
III.C File Structure and Transfer Modes
III.Cファイル構造と転送モード
The only file structures supported directly in FTP at the
present time are record structures. However, the use of record
structures is not mandatory. A user with no record structure in his file
should be able to store and retrieve his file at any HOST. A user
wishing to transmit a record structured file must send the appropriate
FTP 'STRU' command (the default assumption is no record structure). A
serving HOST need not accept record structures, but it must inform the
user of this fact by sending an appropriate reply. Any record structure
information in the data stream may subsequently be discarded by the
receiver.
現時点に直接FTPで支えられた唯一のファイル構造が記録的な構造です。 しかしながら、記録的な構造の使用は義務的ではありません。 彼のファイルの記録的な構造のないユーザは、どんなHOSTでも彼のファイルを保存して、取ることができるべきです。記録的な構造化ファイルを送りたがっているユーザは適切なFTP'STRU'コマンドを送らなければなりません(デフォルト仮定は記録的な構造ではありません)。 給仕HOSTは記録的な構造を受け入れる必要はありませんが、それは、適切な回答を送ることによって、この事実をユーザに知らせなければなりません。 データ・ストリームにおけるどんな記録的な構造情報も次に、受信機によって捨てられるかもしれません。
[Page 9]
The File Transfer Protocol July 8, 1972
[9ページ] ファイル転送プロトコル1972年7月8日
All data transfer must end with an EOF. The EOF is defined
by the data transfer mode. For files that have record structures, an EOR
is also defined by the transfer mode. Only the transfer modes and
representation type combinations that have EOR defined may be used for
transfer or files with record structures. Records may be of zero length
but they must be contained in file boundaries. The relationship between
files and records is heirarchical and an EOF implies an EOR.
すべてのデータ転送がEOFと共に終わらなければなりません。 EOFはデータ転送モードで定義されます。 また、記録的な構造を持っているファイルに関しては、EORは転送モードで定義されます。 記録的な構造がある転送かファイルに定義されたEORを持っている転送モードと表現タイプ組み合わせだけを使用してもよいです。 記録はゼロ・レングスのものであるかもしれませんが、ファイルの限界にそれらを含まなければなりません。 ファイルとレコードとの関係はheirarchicalです、そして、EOFはEORを含意します。
The following data transfer modes are defined in FTP:
以下のデータ転送モードはFTPで定義されます:
1. Stream The file is transmitted as a stream of bytes of the
specified byte size. The EOF is signalled by
closing the data connection. Any representation
type and byte size may be used in the stream mode
but record structures are possible only with the
ASCII representation type. The convention is that
the ASCII character CR (Carriage Return, Code 13.)
followed by LF (Line Feed, Code 10.) Indicates an
EOR in stream mode and ASCII representation type.
This is the default mode, and it is recommended
that this mode be implemented by all.
1. ファイルを流してください。バイトの指定されたバイトサイズのストリームとして、伝えられます。 データ接続を終えることによって、EOFは合図されます。 どんな表現タイプとバイト、サイズはストリームモードで使用されるかもしれませんがも、記録的な構造は単にASCII表現タイプで可能です。 コンベンションはLF(線Feed、Code10)でASCII文字CR(キャリッジReturn、Code13)が続いたということです。 ストリームモードとASCII表現タイプによるEORを示します。 これはデフォルトモードです、そして、このモードがすべてによって実装されるのは、お勧めです。
2. Text The file is ASCII text transmitted as sequence of
8-bit bytes in the ASCII representation type.
Record structures are allowed in this mode. The
EOR and EOF are defined by the presence of special
"TELNET-control" codes (most significant bit set
of one) in the data stream. The EOR code is 192
(octal 300, hex C0). The EOF code os 193 (octal
301, hex C1). The byte size for transfer is 8
bits.
2. テキスト、ファイルはASCII表現タイプの8ビットのバイトの系列として伝えられたASCIIテキストです。 記録的な構造はこのモードで許容されています。 EORとEOFはデータ・ストリームにおける、特別な「telnetコントロール」コード(1人の最上位ビットセット)の存在によって定義されます。 EORコードは192(8進300、十六進法C0)です。 EOFはOS193(8進301、十六進法C1)をコード化します。 転送のためのバイトサイズは8ビットです。
3. Block The file is transmitted as a series of data blocks
preceded by one or more header bytes. The header
bytes contain a count field and descriptor code.
The count field indicates the total length of the
data block in bytes, thus marking the beginning of
the next data block (there are no filler bits).
The descriptor code defines last file block (EOF),
last record block (EOR), restart marker (see
section III.D), or suspect data (i.e. the data
being transferred is suspected of errors and is
not reliable). Record structures are allowed in
this mode, and any representation type or byte
size may be used. The header consists of integral
number of bytes whose length is greater than or
equal to 24 bits. Only the least significant 24
bits (right-jusified) of header shall have
3. ファイルを妨げてください。一連のデータ・ブロックが1ヘッダーバイト以上先行したので、送られます。 ヘッダーバイトはカウント分野と記述子コードを含んでいます。 カウント分野はバイトで表現されるデータ・ブロックの全長を示します、その結果、次のデータ・ブロックの始まりを示します(フィラービットが全くありません)。 記述子コードは最後のファイルブロック(EOF)、最後のレコード・ブロック(EOR)、再開マーカー(セクションIII.Dを見る)、または疑わしいデータを定義します(すなわち、移されるデータは、誤りについて疑われて、信頼できません)。 記録的な構造はこのモードで許容されています、そして、どんな表現タイプやバイト、サイズは使用されるかもしれません。 ヘッダーは長さが24ビット以上である不可欠のバイト数から成ります。 ヘッダーの最も重要でない24ビット(まさしくjusifiedされた)だけはそうしてしまうでしょう。
[Page 10]
The File Transfer Protocol July 8, 1972
[10ページ] ファイル転送プロトコル1972年7月8日
information, other must significant bits must be
zero. Of the 24 bits of header information, the
16 low order bits shall represent byte count, and
the 8 high order bits shall represent descriptor
codes as shown below.
情報、他の必須重要なビットはゼロであるに違いありません。 24ビットのヘッダー情報では、16下位のビットはバイト・カウントを表すものとします、そして、8高位のビットが以下に示すように記述子コードを表すものとします。
Integral data bytes > 24
不可欠のデータ・バイト>24
| Must be Zero | Descriptor | Byte Count |
| 0 to 231 bits | 8 bits | 16 bits |
|、Zeroでなければなりません。| 記述子| バイト・カウント| | 0〜231ビット| 8ビット| 16ビット|
The following descriptor codes are assigned:
以下の記述子コードは割り当てられます:
Code Meaning
0 An ordinary block of data.
1 End of data block is EOR.
2 End of data block is EOF.
3 Suspected errors in data block.
4 Data block is a restart marker.
データのMeaning0An普通のブロックをコード化してください。 データ・ブロックの1つの端がEORです。 データ・ブロックの2端はEOFです。 3は、データにおける誤りが妨げると疑いました。 4データ・ブロックが再開マーカーです。
The restart marker is imbedded in the data stream
as integral number of 8-bit bytes (representing
printable ASCII characters) right-justified in
integral number of data bytes greater than 8 bits.
For example if the byte size is 7 bits, the
restart marker byte would be one byte
right-justified per two 7-bit bytes as shown
below:
再開マーカーは整数の整数のデータ・バイトでまさしく正当な8ビット以上の8ビットのバイト(印刷可能なASCII文字の代理をする)としてデータ・ストリームで埋め込まれます。 例えば、バイトサイズが7ビットであるなら、再開マーカーバイトは以下に示すように7ビットの2バイトあたりまさしく正当な1バイトです:
Two 7-bit bytes
7ビットの2バイト
| | Marker Char|
| | 8 bits |
| | マーカー炭| | | 8ビット|
For byte size of 16 bits or more, two more
marker bytes shall be packed right-justified. The
end of the marker may be delimited by the
character SP (code 32.). If marker characters do
no exactly fit an integral byte, the unused
character slots should contain the ASCII character
SP (code 32.). For example, to transmit a six
character marker in a 36-bit byte size, the
following three 36.bit bytes would be sent:
16ビット以上のバイトサイズにおいて、もう2マーカーバイトはまさしく正当な状態で梱包されるものとします。 マーカーの端はキャラクタSP(コード32)によって区切られるかもしれません。 マーカーキャラクタがいいえをまさに不可欠のバイト合われたするなら、未使用のキャラクタスロットはASCII文字SP(コード32)を含むべきです。 例えば、36ビットのバイトサイズで6キャラクタマーカーを送るために、以下の3 36.bitバイトを送るでしょう:
| Zero | Descriptor | |
| 12 bits | code=4 | Byte count=2 |
| ゼロ| 記述子| | | 12ビット| コード=4| バイト・カウント=2|
[Page 11]
The File Transfer Protocol July 8, 1972
[11ページ] ファイル転送プロトコル1972年7月8日
| | Marker | Marker | Marker | Marker |
| | 8 bits | 8 bits | 8 bits | 8 bits |
| | マーカー| マーカー| マーカー| マーカー| | | 8ビット| 8ビット| 8ビット| 8ビット|
| | Marker | Marker | SP | SP |
| | 8 bits | 8 bits | 8 bits | 8 bits |
| | マーカー| マーカー| SP| SP| | | 8ビット| 8ビット| 8ビット| 8ビット|
4 Hasp The file is transmitted as a sequence of 8-bit bytes
in the standard Hasp-compressed data format
(document to be issued by Bob Braden, UCLA). This
mode achieves considerable compression of data for
print files. Record structures are allowed in the
Hasp mode.
4はファイルを掛け金で締めます。標準のHaspによって圧縮されたデータの形式(ボブ・ブレーデン、UCLAによって発行されるドキュメント)の8ビットのバイトの系列として、伝えられます。 このモードは印刷ファイルのためのデータのかなりの要約を実現します。 記録的な構造はHaspモードで許容されています。
III.D Error Recovery and Restart
III.Dエラー回復と再開
There is no provision for detecting bits lost or scrambled
in data transfer. This issue is perhaps handled best at the NCP level
where it benefits most users. However, a restart procedure is provided
to protect user from system failures (such as failure of either HOST,
FTP-process, or the IMP subnet).
データ転送で、なくされているか、またはスクランブルをかけられるビットを検出することへの支給が全くありません。 NCPレベルでほとんどのユーザのためになるところで恐らくこの問題を扱うのは最も良いです。 しかしながら、システム障害(HOST、FTPプロセスかIMPサブネットのどちらかの失敗などの)からユーザを保護するために再開手順を提供します。
The restart procedure is defined only for the block mode of
data transfer. It requires the sender of data to insert a special marker
code in teh data stream with some marker information. The marker
information has meaning only to the sender, but must consist of
printable ASCII characters. The printable ASCII characters are defined
to be codes 33. through 126. (i.e., not including codes 0. through 31.
and the characters SP and DEL). The marker could represent a bit-count,a
record-count, or any other information by wich a system may identify a
data checkpoint. The receiver of data, if it implements the restart
procedure, would then mark the corresponding position of this marker in
the receiving system, and return this information to the user.
再開手順はデータ転送のブロックモードのためだけに定義されます。 それは、何らかのマーカー情報で特別なマーカーコードをtehデータ・ストリームに挿入するために送付者にデータを要求します。 マーカー情報は、送付者だけに意味を持っていますが、印刷可能なASCII文字から成らなければなりません。 印刷可能なASCII文字は、33に126を通したコードになるように定義されます。 (すなわち、キャラクタの31、SP、およびDELを通してコード0を含んでいません。) マーカーがしばらくカウント、レコード・カウントを表すことができましたか、またはwich aシステムによるいかなる他の情報もデータチェックポイントを特定するかもしれません。 再開手順を実装するなら、データの受信機は、次に、受電方式にこのマーカーの対応する位置を示して、この情報をユーザに返すでしょう。
In the event of a system failure, the user can restart the
data transfer by identifying the marker point with the FTP restart
procedure. The following examples Illustrate the use of the restart
procedure.
システム障害の場合、ユーザは、FTP再開手順とマーカーポイントを同一視することによって、データ転送を再開できます。 以下の例のIllustrate、再開手順の使用。
1. When server is the sender of data, the server-FTP process
inserts an appropriate marker block in the data stream at a convenient
data point. The user-FTP process receiving the data, marks the
coressponding data point in its file system and conveys the last known
sender and receiver marker information to the user. In the event of
system failure, the user or user-FTP process restarts the server at the
1. サーバがデータの送付者であるときに、サーバFTPプロセスは便利なデータポイントでのデータ・ストリームに適切なマーカーブロックを指し込みます。 ユーザFTPは、データを受信しながら処理して、ファイルシステムでcoresspondingデータポイントをマークして、最後に知られている送付者と受信機マーカー情報をユーザに伝えます。 プロセスがサーバを再開するシステム障害、ユーザまたはユーザFTP
[Page 12]
The File Transfer Protocol July 8, 1972
[12ページ] ファイル転送プロトコル1972年7月8日
last server marker by sending a restart command with the server's marker code at its argument. The restart command is transmitted over the TELNET connection and is immediately followed by the command (such as store or retrieve) which was being executed when the system failure occured.
議論でサーバのマーカーコードによる再開コマンドを送るのによる最後のサーバマーカー。 再開コマンドをTELNET接続の上に伝えられて、コマンドがすぐにあとに続く、(保存するか、検索、)、システム障害がoccuredされたとき実行されていた。
2. When user is the sender of data, the user-FTP process
inserts the appropriate marker block in the data stream. The server-FTP
process receiving the data, marks the corresponding data point in its
file system. The server does not store this marker but conveys the last
known sender and receiver marker information to the user over the TELNET
connections by appropriate reply codes. The user or the user-FTP process
then restarts transfer in a manner identical to that described in the
first example.
2. ユーザがデータの送付者であるときに、ユーザFTPプロセスは適切なマーカーブロックをデータ・ストリームに指し込みます。 データを受信するサーバFTPプロセス、対応するデータがファイルシステムで指すマーク。 サーバは、TELNET接続の上で適切な回答コードでユーザにこのマーカーを保存しませんが、最後に知られている送付者と受信機マーカー情報を伝えます。 そして、ユーザかユーザFTPプロセスが最初の例で説明されたそれと同じ方法で転送を再開します。
IV. FILE TRANSFER FUNCTIONS
IV。 ファイル転送機能
The TELNET connections on which FTP commands and replies are
transmitted, are initiated by the user-FTP process via an ICP to a
standard server socket. FTP commands are then transmitted from user to
server, and replies are transmitted from server to user. The user file
transfer functions invoive sending the FTP commands, interpreting the
replies received and transferring data over the data connection in the
specified manner. The server file transfer functions involve accepting
and interpreting FTP commands, sending replies, setting up the data
connection, and transferring data.
FTPコマンドと回答が伝えられて、ユーザFTPによって開始されるTELNET接続は標準のサーバソケットへのICPを通して処理します。 次に、FTPコマンドはユーザからサーバまで伝えられます、そして、回答はサーバからユーザまで伝えられます。 FTPを送るユーザ・ファイル伝達関数invoiveが命令します、指定された方法でデータ接続の上に受け取られて、データを移す回答を解釈して。 サーバファイル転送機能は、FTPコマンドを受け入れて、解釈することを伴います、回答を送って、データ接続をセットアップして、データを移して。
IV.A FTP Commands
IV.A FTPコマンド
FTP commands are ASCII terminated by the ASCII
character sequence CRLF (Carriage Return follow by Line Feed). The
command codes themselves are ASCII alpabetic characters terminated by
the ASCII character 'space' (code = 32.). For convenience, the command
codes are defined to be four (or less) ASCII alphanumeric characters
(including both upper and lower case alphabetic characters). The command
codes and the semantics of commands are described in this section, but
the detailed syntax of commands is specified in Section V.b, the reply
sequence are discussed in Section V.C, and scenarios illustrating the
use of commands are provided in Section V.D.
FTPコマンドはASCIIキャラクタシーケンスCRLFによって終えられたASCII(キャリッジReturnは線Feedで続く)です。 コマンドコード自体はASCII文字'スペース'(コード=32)によって終えられたASCII alpabeticキャラクタです。 便利において、コマンドコードは、4つ(それほど)のASCII英数字(両方の大文字と小文字英字を含んでいる)になるように定義されます。 このセクションでコマンドコードとコマンドの意味論について説明しますが、セクションV.でコマンドの詳細な構文を指定します。セクションV.Cでb、回答系列について議論します、そして、コマンドの使用を例証するシナリオをセクションV.Dに提供します。
FTP commands may be partitioned as those specifying
access-control identifiers, data transfer parameters, or FTP service
requests.
FTPコマンドはアクセス制御識別子、データ転送パラメタ、またはFTPサービスのリクエストを指定するものとして仕切られるかもしれません。
[Page 13]
The File Transfer Protocol July 8, 1972
[13ページ] ファイル転送プロトコル1972年7月8日
IV.A.1 Access Control Commands
IV.A.1アクセス制御コマンド
The following commands specify access control identifiers
(command codes are shown in parentheses).
以下のコマンドはアクセス制御識別子を指定します(コマンドコードは括弧に示されます)。
User name (USER) - The argument field is an ASCII string
identifying the user. The user identification is that wich is
required by the server for access to its file system. This
command will normally be the first command transmitted by the
user after the TELNET connections are made (some servers may
require this). Additional identification information in the form
of pasword command may also be required by some servers.
ユーザ名前(USER)--議論分野はユーザを特定するASCIIストリングです。 ユーザ登録名はwichがファイルシステムへのアクセスのためのサーバによって必要とされるということです。 通常、このコマンドはTELNET接続が作られた(いくつかのサーバがこれを必要とするかもしれません)後にユーザによって伝えられた最初のコマンドになるでしょう。 また、paswordコマンドの形の追加識別情報はいくつかのサーバによって必要とされるかもしれません。
Password (PASS) - The argument field is an ASCII string
identifying the user's password. This command must be immediately
preceded by the user name command, and together it completes the
user's identifecation for access control.
パスワード(PASS)--議論分野はユーザのパスワードを特定するASCIIストリングです。 コマンドというユーザ名はすぐにこのコマンドに先行しなければなりません、そして、それはアクセスコントロールのためにユーザのidentifecationを一緒に、完成します。
IV.A.2 Data Transfer Commands
IV.A.2データ転送コマンド
All data transfer parameters have default values, and the
commands specifying data transfer parameters are required only if
the default parameter values are to be changed. The default
value is teh last specified value, or if no value has been
specified, the standard default value specified here. This
implies that the server must "remember" the applicable default
values. The commands may be in any order except that they must
precede the FTP service request. The following commands specify
data transfer parameters.
すべてのデータ転送パラメタには、デフォルト値があります、そして、デフォルトパラメタ値が変えるだけことであるならデータ転送パラメタを指定するコマンドを必要とします。 デフォルト値はtehが最後に値を指定したか、または値が全く指定されていないなら、標準省略時解釈値がここで指定したということです。 これは、サーバが適切なデフォルト値を「覚えていなければならないこと」を含意します。 FTPサービスのリクエストに先行しなければならないのを除いて、コマンドは順不同であるかもしれません。 以下のコマンドはデータ転送パラメタを指定します。
Byte size (BYTE) - The argument is an ASCII-represented decimal
integer (1 through 255), specifying the byte size for the data
connection for local byte and image representation types. The
default byte size is 8 bits. The byte size is always 8 bits in
the ASCII and Print file representation types. A server may
reject specific byte size/type combinations by sending an
appropriate reply.
バイトサイズ(BYTE)--議論はASCIIによって表された10進整数(1〜255)です、地方のバイトとイメージ表現タイプとしてデータ接続にバイトサイズを指定して。 デフォルトバイトサイズは8ビットです。 バイトサイズは、いつもASCIIにおける8ビットとPrintファイル表現タイプです。 サーバは、適切な回答を送ることによって、特定のバイトサイズ/タイプ組み合わせを拒絶するかもしれません。
Data socket (SOCK) - The argument is a HOST-socket specification
for the data socket to be used in data connection. There may be
two data sockets, one from server to user and the other for user
to server data transfer. An odd socket number defines a send
socket and an even socket number defines a receive socket. The
default HOST is the user HOST to which TELNET connections are
made. The default data sockets are (U+4) and (U+5) where U is the
socket number used in the TELNET ICP and the TELNET connections
are on sockets (U+2) and (U+3).
データソケット(SOCK)--議論はデータソケットがデータ接続に使用されるHOST-ソケット仕様です。 2個のデータソケット、サーバからユーザとユーザのためのもう片方からサーバデータ転送までの1があるかもしれません。 aはソケットと数が定義する同等のソケットを送ります。変なソケット番号が定義する、aはソケットを受けます。 デフォルトHOSTはTELNET接続が作られているユーザHOSTです。 デフォルトデータソケットは、UがTELNET ICPで使用されるソケット番号であるところの(U+4)と(U+5)です、そして、ソケット(U+2)と(U+3)の上にTELNET接続があります。
[Page 14]
The File Transfer Protocol July 8, 1972
[14ページ] ファイル転送プロトコル1972年7月8日
Representation Type (TYPE) - The argument is a single ASCII
character code specifying the representation types described in
section III.B. The following codes are assigned for type:
表現Type(TYPE)--議論は次のコードがタイプのために割り当てられるセクションIII.B.で説明された表現タイプを指定するただ一つのASCII文字コードです:
A - ASCII
I - Image
L - Local Byte
P - Print file in ASCII
E - EBCDIC print file
A--私--イメージL--ASCIIの地方のByte P--ASCII Eにおける印刷ファイル--EBCDIC印刷ファイル
The default representation type is ASCII
デフォルト表現タイプはASCIIです。
File Structure (STRU) - The argument is a single ASCII character
code specifying file structure described in section III.C. The
following codes are assigned for structure:
議論はセクションIII.C.で説明されたファイル構造を指定するただ一つのASCII文字コードです。ファイルStructure(STRU)--次のコードは構造に割り当てられます:
F - File (no record structure)
R - Record structure
F(ファイル(記録的な構造がない)R)は構造を記録します。
The default structure is File (i.e., no records).
デフォルト構造はFile(すなわち、記録がない)です。
Transfer Mode (MODE) - The argument is a single ASCII character
code specifying the data transfer modes described in Section
III.C. The following codes are assigned for transfer modes:
Mode(MODE)を移してください--議論は次のコードが転送モードのために割り当てられるセクションIII.C.で説明されたデータ転送モードを指定するただ一つのASCII文字コードです:
S - Stream (bytes, close is EOF)
B - Block (Header with descriptor and count)
T - Text (TELNET control mode for EOR, EOF)
H - Hasp (specially formatted compressed data)
S--ストリーム(バイト、近くに、EOFがある)B--ブロック(記述子とカウントがあるヘッダー)T(テキスト(TELNETはEORのためにモードを制御します、EOF)H)は掛け金で締められます。(特に、フォーマットされた圧縮されたデータ)
The default transfer mode is Stream.
デフォルト転送モードはStreamです。
IV.A.3 FTP Service Commands.
IV.A.3FTPサービスは命令します。
The FTP service commands define the file transfer or the file
system function requested by the user. The argument of an FTP
service command will normally be a pathname. the syntax of
pathnames must conform to server site conventions (with standard
defaults applicable), except that ASCII characters must be used
(in conformance with the TELNET Protool). The suggested default
handling is to use the last specified device directory or file
name, or the standard default defined for local users. The
commands may be in any order except that a "rename from" command,
must be followed by a "rename to" command, and some servers may
require an "allocate" command before a "store" command. The data
when transferred in response to FTP service commands shall always
be over the data connection. The following commands specify FTP
service requests:
FTP軍管区はユーザによって要求されたファイル転送かファイルシステム機能を定義します。 通常、FTP軍管区の議論はパス名になるでしょう。パス名の構文はサーバサイトコンベンション(標準省略時解釈が適切の)に従わなければなりません、ASCII文字を使用しなければならないのを除いて(TELNET Protoolとの順応で)。 提案されたデフォルト取り扱いは最後に指定されたデバイスディレクトリ、ファイル名、または地元のユーザのために定義された標準省略時解釈を使用することです。 」 コマンド、およびいくつかにサーバを改名してください。そのaを除いて、コマンドが順不同であるかもしれない、「」 コマンドから改名して、続かなければならない、「「保存」コマンドの前に「割り当て」コマンドを必要としてもよいです。 FTP軍管区に対応して移すと、データ接続の上にデータがいつもあるものとします。 以下のコマンドはFTPサービスのリクエストを指定します:
[Page 15]
The File Transfer Protocol July 8, 1972
[15ページ] ファイル転送プロトコル1972年7月8日
Retrieve (RETR) - This command achieves the transfer of a copy of
file specified in pathname, from server to user site. The status
and contents of a file at server site shall be unaffected.
(RETR)を検索してください--このコマンドはパス名で指定されたファイルのコピーの転送を実現します、サーバからユーザの現場まで。 サーバサイトのファイルの状態とコンテンツは影響を受けなくなるでしょう。
Store (STOR) - This command achieves the transfer of a copy of
file from user to server site. If file specified in pathname
exists at the server site, then its contents shall be replaced by
the contents of the file being transferred. A new file is created
at the server site if the file specified in pathname does not
already exist.
(STOR)を保存してください--このコマンドはファイルのコピーのユーザからサーバサイトまでの転送を実現します。 パス名で指定されたファイルがサーバサイトに存在しているなら、コンテンツを移されるファイルのコンテンツに取り替えるものとします。 パス名で指定されたファイルが既に存在していないなら、新しいファイルはサーバサイトで作成されます。
Append (with create) (APPE) - This command achieves the transfer
of data from using to serving site. If file specified in pathname
exists at the server site, then the data transferred shall be
appended to that file, otherwise the file specified in pathname
shall be created at the server site.
追加、(作成、)、(APPE)--このコマンドは使用からサイトに役立つまでのデータ転送を実現します。 パス名で指定されたファイルがサーバサイトに存在しているなら、移されたデータをそのファイルに追加するものとします。さもなければ、サーバサイトでパス名で指定されたファイルを作成するものとします。
Rename from (RNFR) - This command specifies the file which is to
be renamed. This command must be immediately followed by a
"rename to" command specifying the new file pathname.
改名、(RNFR)--このコマンドは改名されることであるファイルを指定します。 aがすぐにこのコマンドのあとに続かなければならない、「」 新しいファイルパス名を指定するコマンドに改名します。
Delete (DELE) - This command causes teh file specified in
pathname to be deleted at the server site. If an extra level of
protection is desired (such as the query, "Do you really wish to
delete?"), it should be provided by the user-FTP process.
(DELE)を削除してください--このコマンドで、サーバサイトでパス名で指定されたtehファイルを削除します。 してください。付加的なレベルの保護が望まれている、(質問などのように「あなたが本当に削除したいか、」、)、ユーザFTPプロセスはそれを提供するべきです。
List (LIST) - This command causes a list to be sent from server
to user site. If pathname specifies a directory, the server
should transfer a list of files in the specified directory. If
pathname specifies a file then server should send current
information on the file. This command may be used to obtain the
contents of a file directory (the response should be sent in
ASCII type) or test the existence of a file and its current
status.
リスト(LIST)--このコマンドで、サーバからユーザの現場にリストを送ります。 パス名がディレクトリを指定するなら、サーバは指定されたディレクトリのファイルのリストを移すべきです。 パス名がファイルを指定するなら、サーバはファイルに関する現行情報を送るべきです。 このコマンドは、ファイルディレクトリ(ASCIIタイプで応答を送るべきである)のコンテンツを得るか、またはファイルの存在とその現在の状態をテストするのに使用されるかもしれません。
Allocate (ALLO) - This command my be required by some servers to
reserve sufficient storage to accomodate the new file to be
transferred. The command field shall be a decimal integer
representing the number of bytes (of size specified by the byte
size command) of storage to be reserved for the file. This
command shall be followed by a store or append command. The ALLO
command should be treated as a NO-OP (no operation) by thuse
servers which do not require that the maximum size of the file be
declared beforehand.
(ALLO)を割り当ててください--これが命令する、私、移すために新しいファイルをaccomodateすることができるくらいのストレージを控えるのがいくつかのサーバによって必要とされてください。 コマンド欄はファイルのために予約されるためにバイト(バイトサイズコマンドで指定されたサイズの)のストレージの数を表す10進整数になるでしょう。 このコマンドは、店があとに続いているか、またはコマンドを追加するものとします。 ALLOコマンドはファイルの最大サイズがあらかじめ宣言されるのを必要としないthuseサーバによってノーオプ(操作がない)として扱われるべきです。
Restart (REST) - The argument field represents the server marker
at which file transfer is to be restarted. This command does not
cause file transfer but "spaces" over the file to the specified
(REST)を再開してください--議論分野は再開されるかでどのファイル転送がことであるサーバマーカーの代理をします。 このコマンドは原因ファイル転送ではなく、「空間」を指定へのファイルの上にします。
[Page 16]
The File Transfer Protocol July 8, 1972
[16ページ] ファイル転送プロトコル1972年7月8日
data checkpoint. This command shall be immediately followed by
the appropriate FTP service command which shall cause file
transfer to resume.
データチェックポイント。 ファイル転送が再開する適切なFTP軍管区はすぐに、このコマンドのあとに続くものとします。
Status (STAT) - This command shall cause a status response to be
sent over the TELNET connection in form of a reply. The command
may have an argument field such as a pathname. if the argument
is a pathname, the command is analogous to the "list" command
except that data shall be transferred in ASCII on the TELNET
connection. If no argument is specified, the server should return
general status information about the server FTP process. This may
include service availability, the current settings for the
relevant FTP parameters (including default settings), and the
status of command execution and connections.
状態(STAT)--このコマンドで、回答の形におけるTELNET接続の上に状態応答を送るでしょう。 コマンドには、パス名などの議論分野があるかもしれません。議論がパス名であるなら、TELNET接続のときにASCIIでデータを移すものとするのを除いて、コマンドは「リスト」コマンドに類似しています。 議論が全く指定されないなら、サーバはサーバFTPプロセスの一般的な状態情報を返すべきです。 これは関連FTPパラメタ(既定の設定を含んでいる)、およびコマンド実行と接続の状態にサービスの有用性、現在の設定を含めるかもしれません。
Abort (ABOR) - This command indicates to the server to abort the
previous FTP service command and any associated transfer of data.
The abort command should be preceded by the TELNET SYNCH
condition (indicated by the combination of the DATA MARK and the
INS). No action is to be taken if the previous command has been
completed (including data transfer). The TELNET connections is
not to be closed by the server, but the data connection may be
closed. An appropriate reply should be sent by the server.
(ABOR)を中止してください--このコマンドは、コマンドとデータのあらゆる関連転送を修理するように前のFTPを中止するサーバに示します。 TELNET SYNCH条件(DATA MARKとINSの組み合わせで、示される)は中止コマンドに先行するべきです。 どんな動作も前のコマンドが終了されたなら(データ転送を含んでいて)取られないことです。 サーバでTELNET接続を閉店させてはいけませんが、データ接続は閉店するかもしれません。 サーバは適切な回答を送るべきです。
Logout (BYE) - This command terminates a USER and if file
transfer is not in progress, closes the TELNET connection. If
file transfer is in progress, the connection will remain open for
result response and will then close. During the interim a new
USER command (and no other command) is acceptable.
ログアウトしてください(BYE)--このコマンドはUSERを終えます、そして、ファイル転送であるなら、いずれかの進歩、閉鎖でないのにおけるTELNET接続は終えませんか? ファイル転送が進行していると、接続は、結果応答において開いたままで残って、そして近くで残りのようになるでしょう。 当座の間、新しいUSERコマンド(そして、他のコマンドがない)は許容できます。
An unexpected close on TELNET connection will cause the server to
take the effective action of an abort (ABOR) and a logout (BYE).
サーバはTELNET接続での予期していなかった閉鎖でアボート(ABOR)の効果的な行動を取るでしょう、そして、aはログアウトします(BYE)。
IV.B FTP Replies
IV.B FTP回答
The server sends FTP replies to user over the TELNET
connections in response to FTP commands. The FTP replies constitute the
acknowledgement or completion code (including errors). The FTP-server
replies are formatted for human or program interpretation. The replies
consist of a leading three digit numeric code followed by a space
followed by a text explanation of the code. The numeric codes are
assigned by groups and for ease of interpretation by programs in a
manner consistent with other protocols such as the RJE protocol. The
three digits of the code are to be interpredet as follows:
サーバはTELNET接続の上でFTPコマンドに対応してFTP回答をユーザに送ります。 FTP回答は承認か完了コードを構成します(誤りを含んでいて)。 FTPサーバ回答は人間かプログラム解釈のためにフォーマットされます。 回答はコードに関するテキスト説明があとに続いたスペースがあとに続いた主な3ケタ数字コードから成ります。 数字コードはグループとRJEプロトコルなどの他のプロトコルと一致した方法によるプログラムによる解釈の容易さのために割り当てられます。 コードの3ケタは以下のinterpredetであることです:
[Page 17]
The File Transfer Protocol July 8, 1972
[17ページ] ファイル転送プロトコル1972年7月8日
a) The first digit specifies type of response as indicated below:
a) 最初のケタは以下に示すように応答のタイプを指定します:
000 These replies are purely informative and constitute
neither a positive nor a negative acknowledgement.
000 これらの回答は、純粋に有益であり、どちらも積極的で否定的な承認を構成しません。
1xx informative replies to status inrequiries. These constitute
a positive acknowledgment to the status command.
状態inrequiriesへの1xxの有益な回答。 これらは状態コマンドに肯定応答を構成します。
2xx Positive acknowledgment of previous command or other
successful action.
前のコマンドか他のうまくいっている動作の2xx Positive承認。
3xx Incomplete information. Activity cannot proceed without
further specification and input.
3xx Incomplete情報。 活動はさらなる仕様と入力なしで続くことができません。
4xx Unsuccessful reply. The request is correctly specified
but the server is unsuccessful in corretly fulfilling
it.
4xx Unsuccessfulは返答します。 要求は正しく指定されますが、サーバはそれをcorretlyに実現させるのを失敗しています。
5xx Incorrect or illegal command. The command or its
parameters were invalid or incomplete from a syntactic
viewpoint, or the command its inconsistent with a previous
command. The command in question has been completely
ignored.
5xx Incorrectか不正コマンド。 コマンドかそのパラメタが、構文の観点、またはコマンドによって無効であるか、または不完全でした。それは前のコマンドに矛盾しています。 問題のコマンドは完全に無視されました。
6xx - 9xx Reserved for future expansion.
6xx--今後の拡張のための9xx Reserved。
b) The second digit specifies the general category to which the response refers:
b) 2番目のケタは応答が参照される一般的なカテゴリを指定します:
x00-x29 General purpose replies, not assignable to other
categories.
x00-x29汎用は他のカテゴリに「割り当て-可能」するのではなく、返答します。
x30 Primary access. Informative replies to the "log-on"
attempt.
x30のプライマリアクセサリー 「ログオン」試みに関する有益な回答。
x40 Secondary access. The primary server is commenting on its
ability to access a secondary service.
x40のセカンダリアクセサリー プライマリサーバはセカンダリサービスにアクセスする性能を批評しています。
x5x FTP results.
x5x FTPは結果として生じます。
x6x RJE resutls.
x6x RJE resutls。
x7x-x9x Reserved for future expansion.
今後の拡張のために予約されたx7x-x9x。
[Page 18]
The File Transfer Protocol July 8, 1972
[18ページ] ファイル転送プロトコル1972年7月8日
c) the final digit specifies a particular message type. Since the code is designed for an automaton process to interpret, it is not necessary for every variation of a reply to have a unique number. Only the basic meaning of replies need have unique numbers. The text of a reply can explain the specific reason for that reply to a human user.
c) 最終的なケタは特定のメッセージタイプを指定します。 コードが解釈するオートマトンプロセスのために設計されているので、回答のあらゆる変化にはユニークな数があるのは必要ではありません。 回答の基本的な意味だけには、ユニークな数がなければなりません。 回答のテキストで、その回答の特定の理由が人間のユーザにわかることができます。
Each TELNET line (ended by CRLF) from the server is intended
to be a complete reply message. if it is necessary to continue the text
of a reply onto following lines, then those continuation replies contain
the special reply code of three spaces. It should be noted that text of
replies are intended for a human user. Only the reply codes and in some
instances the first line of text are intended for programs.
サーバからのそれぞれのTELNET系列(CRLFによって終わられる)は完全な応答メッセージであることを意図します。系列に続くのに回答のテキストを続けるのが必要であるなら、それらの継続回答は3つの空間の特別な回答コードを含んでいます。 回答のテキストが人間のユーザのために意図することに注意されるべきです。 回答コードだけとある場合に最初のテキスト行はプログラムのために意図します。
The assigned reply codes relating to FTP are:
FTPに関連する割り当てられた回答コードは以下の通りです。
000 General information message (site, time of day, etc.)
030 Server availibility information.
050 FTP commentary or user information.
100 System status reply.
150 File status reply.
151 Directory listing reply.
200 Last command received correctly.
201 An ABORT has terminated activity, as requested.
202 Abort request ignored, no activity in progress.
230 User is "logged in". may proceed.
231 User is "logged out". Service terminated.
232 Logout command noted, will complete when transfer done.
250 FTP file transfer started correctly.
251 FTP Restart-marker reply
Text is: MARK yyyy = mmmm
where yyyy is user's data stream marker (yours)
and mmmm is server's equivalent marker (mine)
(Note the spaces between the markers and '=').
252 FTP transfer completed correctly.
253 Rename completed.
254 Delete completed.
255 FTP server data socket reply
Text is: SOCK nnnn
where nnnn is decimal integer representing
the server socket for data connection.
300 Connection greeting message, awaiting input.
301 Current command incomplete (no CRLF for long time).
330 Enter password (may be sent with hide-your-input).
400 This service not implemented.
401 This service not accepting users now, goodbye.
430 Log-on time or tries exceeded, goodbye.
431 Log-on unsuccessful. User and/or password invalid.
432 User not valid for this service.
000一般情報メッセージ(サイト、時刻など) 030 サーバavailibility情報。 050 FTP論評かユーザー情報。 100システム状態回答。 150は状態回答をファイルします。 151ディレクトリリスト回答。 200 持続コマンドは正しく受信されました。 201 ABORTは要求された通り活動を終えました。 202は無視された要求、進行中のどんな活動も中止しません。 230ユーザは「ログインされます」。続くかもしれません。 231ユーザは「ログアウトされます」。 サービスは終わりました。 232 転送であるときに、ログアウトコマンドが注意されて、して、完成するでしょう。 250FTPファイル転送は正しく始まりました。 251 FTP Restart-マーカー回答Textは以下の通りです。 マークyyyyはyyyyがユーザのデータ・ストリームマーカー(あなたのもの)であるmmmmと等しいです、そして、mmmmはサーバの同等なマーカー(私のもの)(マーカーと'='の間の空間に注意する)です。 252 正しく終了するFTP転送。 253 完成されて、改名します。 254 完成されて、削除します。 255FTPサーバデータソケット回答Textは以下の通りです。 nnnnがデータ接続のためのサーバソケットを表す10進整数であるSOCK nnnn。 300 入力を待つ接続あいさつメッセージ。 301 現在のコマンド不完全です(長い時間のCRLFがありません)。 330はパスワード(あなたの入力を隠した状態で発信するかもしれない)を入力します。 このサービスが実装しなかった400。 401 現在ユーザを受け入れないこのサービス、さようなら。 430 時間かトライが超えていたログオン、さようなら。 431は失敗していた状態でログオンします。 ユーザ、そして/または、パスワード病人。 このサービスには、有効でない432ユーザ。
[Page 19]
The File Transfer Protocol July 8, 1972
[19ページ] ファイル転送プロトコル1972年7月8日
434 Log-out forced by operator action. Phone site. 435 Log-out forced by system problem. 436 Service shutting down, goodbye. 450 FTP: File not found. 451 FTP: File access denied to you. 452 FTP: File transfer incomplete, data connection closed. 453 FTP: File transfer incomplete, insufficient storage space. 500 Last command line completely unrecognized. 501 Syntax of last command in incorrect. 502 Last command incomplete, parameters missing. 503 Last command invalid (ignored), illegal parameter combination. 504 Last command invalid, action not possible at this time. 505 Last command conflicts illegally with previous command(s). 506 Requested action not implemented by the server.
434 外では、ログアウトしますオペレータ動作で無理矢理の。 サイトに電話をしてください。 435 外では、ログアウトしますシステム問題で無理矢理の。 436はさようならを停止する修理します。 450FTP: ファイルが見つからない。 451FTP: アクセス拒否をファイルしてください。 452FTP: 不完全なファイル転送データ接続は閉じました。 453FTP: ファイル転送の不完全で、不十分な集積スペース。 500はコマンドラインを持続します。完全に認識されていません。 不正確の持続コマンドの501構文。 パラメタが消えて、502は不完全な状態でコマンドが続きます。 503は最後に無効(無視される)の、そして、不法なパラメタ組み合わせを命令します。 504はコマンド病人、このとき可能でない動作が続きます。 505 持続コマンドは不法に前のコマンドと衝突します。 506はサーバによって実装されなかった動作を要求しました。
V. DECLARATIVE SPECIFICATIONS
V。 宣言的な仕様
V.A. Connections
V.A.コネクションズ
The server-FTP process at the server site shall "listen" on
Socket 3, via its server-TELNET. The user or user-FTP process at the
user site shall initiate the full-duplex TELNET connections via its
user-TELNET performing the ARPANET standard initial connection protocol
(ICP) to server socket 3. The TELNET connections shall be closed by the
user site upon completion of use.
サーバサイトのサーバFTPプロセスはサーバ-TELNETを通してSocket3で「聴かれるものとします」。 ユーザの現場のユーザかユーザFTPプロセスが、アルパネットの標準の初期の接続プロトコル(ICP)をサーバソケット3に実行しながら、ユーザ-TELNETを通して全二重TELNET接続を開始するものとします。 TELNET接続は使用の完成のときにユーザの現場によって閉店させられるものとします。
The user site shall "listen" on the specified data socket or
sockets (a send and/or a receive socket). The server site shall initiate
the data connection using the specified data socket and byte size. The
direction of data connection and the data socket used shall be
determined by the FTP service command. The server shall send a reply to
the user indicating the server data socket so that the user may ensure
the security of data transfer. This can be done at any time prior to the
first transfer of data over a data connection.
ユーザの現場は指定されたデータソケットかソケットで「聴かれるものとする」(aが発信します、そして、aはソケットを受けます)。 サーバサイトは、指定されたデータソケットとバイトサイズを使用することでデータ接続を開始するものとします。 接続とデータソケットが使用したデータの方向はFTP軍管区で決定するものとします。 サーバはユーザがデータ転送のセキュリティを確実にすることができるようにサーバデータソケットを示すユーザに返信するものとします。 データ接続の上の最初のデータ転送の前にいつでも、これができます。
The data connection shall be closed by the server site under
the conditions described is Section III.A. The server should in general
send a reply before closing the data connection to avoid problems at the
user end.
状態の下のサーバサイトによって説明されて、閉じられて、接続がそうするものとするデータはユーザ終わりに問題を避けるためにデータ接続を終える前に一般に、サーバが回答を送るべきであるセクションIII.A.です。
V.B. Commands
V.B.コマンド
The commands are ASCII character strings transmitted over
the TELNET connections as described in section IV.A. The command
functions and semantics are described in sections IV.A.1, IV.A.2,
IV.A,3, and IV.A.4. The command syntax is specified here.
コマンドはセクションIV.A.で説明されるようにTELNET接続の上に伝えられたASCII文字列です。指揮の機能と意味論はセクションのIV.A.1、IV.A.2、IV.A、3、およびIV.A.4で説明されます。 コマンド構文はここで指定されます。
[Page 20]
The File Transfer Protocol July 8, 1972
[20ページ] ファイル転送プロトコル1972年7月8日
The commands begin with a command code followed by an
argument field. The command codes are four of less ASCII alphabetic
characters. Upper and lower case alphabetic characters are to be treated
identically. Thus any of the following may represent the retrieve
command:
議論分野がコマンドコードのあとに続いていて、コマンドは始まります。 コマンドコードは、より少ない4つのASCII英字です。 大文字と小文字英字は同様に扱われることです。 したがって、以下のどれかは検索コマンドを表すかもしれません:
RETR Retr retr ReTr rETr
RETR Retr retr ReTr rETr
The command codes and the argument fields are separated by one or more spaces.
コマンドコードと議論野原は1つ以上の空間によって分離されます。
The argument field consists of a variable length ASCII
character string ending with the character sequence CRLF (Carriage
Return immediately followed by Line Feed). In the following section on
syntax it should be stressed that all characters in the argument field
are ASCII characters. Thus a decimal integer shall mean an ASCII
represented decimal integer.
議論分野はキャラクタシーケンスCRLFと共に可変長ASCII文字ストリング結末から成ります(キャリッジReturnはすぐに、線Feedで続きました)。 構文の以下のセクションで、議論分野のすべてのキャラクタがASCII文字であると強調されるべきです。 したがって、10進整数は、ASCIIが10進整数を表したことを意味するものとします。
The following are all the currently defined FTP commands:
↓これはすべて、現在定義されたFTPコマンドです:
USER <user name> CRLF
PASS <password> CRLF
BYTE <byte size> CRLF
SOCK <HOST-socket> CRLF
TYPE <type code> CRLF
STRU <structure code> CRLF
MODE <mode code> CRLF
RETR <pathname> CRLF
STOR <pathname> CRLF
APPE <pathname> CRLF
RNFR <pathname> CRLF
RNTO <pathname> CRLF
DELE <pathname> CRLF
LIST <pathname> CRLF
ALLO <decimal integer> CRLF
REST <marker> CRLF
STAT <pathname> CRLF
ABOR <empty> CRLF
Bye <empty> CRLF
USER<ユーザ名前>CRLF PASS<パスワード>CRLF BYTE<バイトサイズ>CRLF SOCK<HOST-ソケット>CRLF TYPE<タイプコード>CRLF STRU<構造コード>CRLF MODE<モードコード>CRLF RETR<パス名>CRLF STOR<パス名>CRLF APPE; 空の10進<の<マーカー>CRLF STAT<パス名>CRLF RNFR<パス名>CRLF RNTO<パス名>CRLF DELE<パス名>CRLF LIST<パス名>CRLF ALLO<整数>CRLF RESTパス名の>CRLF Bye<空の>>CRLF ABOR<CRLF
The syntax of the above argument fields (using BNF notation
where aplicable) is:
上の議論分野(aplicableであるところでBNF記法を使用する)の構文は以下の通りです。
<username> ::= <string>
<password> ::= <string>
<string> ::= <empty> | <char> | <char><string>
<char> ::= any of the 128 ASCII characters except CR and LF.
<marker> ::= <pr string>
<ユーザ名>:、:= <ストリング><パスワード>:、:= <ストリング><ストリング>:、:= <の空の>。| <炭の>。| <炭の><ストリング><炭の>:、:= CRとLF以外の128人のASCII文字のいずれも。 <マーカー>:、:= <prストリング>。
[Page 21]
The File Transfer Protocol July 8, 1972
[21ページ] ファイル転送プロトコル1972年7月8日
<pr string> ::= <empty> | <pr char> | <pr char><pr string>
<pr char> ::= any ASCII code 33 through 126.
<byte size> ::= any decimal integer 1 through 255.
<HOST-socket> ::= <socket> | <HOST number>,<socket>
<HOST number> ::= a decimal integer specifying an ARPANET HOST.
<socket> ::= decimal integer between o and (2**32)-1
<type code> ::= A|I|L|P|E
<structure code> ::= F|R
<mode code> ::= S|B|T|H
<pathname> ::= <string>
<decimal integer> ::= <digit> | <digit><decimal integer>
<digit> ::= 0|1|2|3|4|5|6|7|8|9|
<empty> ::= the null string (specifies use of default).
<prストリング>:、:= <の空の>。| <pr炭の>。| <pr炭の><prストリング><pr炭の>:、:= どんなASCIIコード33〜126。 <バイトサイズ>:、:= どんな10進整数1〜255。 <ホストソケット>:、:= <ソケット>。| <HOST番号>、<ソケット><HOST番号>:、:= ARPANET HOSTを指定する10進整数、<ソケット>:、:= oと(2**32)-1<タイプコード>の間の10進整数:、:= A|I|L|P|E<はコード>を構造化します:、:= F|R<モードコード>:、:= S|B|T|H<パス名>:、:= <ストリング>の<の10進整数>:、:= <ケタ>。| <<10進整数><ケタ>ケタ>:、:= 0|1|2|3|4|5|6|7|8|9| <の空の>:、:= ヌルストリング(デフォルトの使用を指定します)。
V.C Sequencing of Commands and Replies
コマンドと回答のV.C配列
The communication between the user and server is intended to
be an alternating dialogue. As such, the user issues an FTP
command and the server responds with a prompt primary reply. The
user should wait for this initial primary success of failure
response before sending further commands.
ユーザとサーバとのコミュニケーションは交互の対話であることを意図します。 そういうものとして、ユーザはFTPコマンドを発行します、そして、サーバは迅速なプライマリ回答で反応します。 さらなるコマンドを送る前に、ユーザは失敗応答のこの初期のプライマリ成功を待つべきです。
A second type of reply is sent asynchronously with respect
to user commands. These replies may for example report on the
progress or completion of file transfer and as such are secondary
replies to file transfer commands.
ユーザコマンドに関して2番目のタイプの回答を非同期に送ります。 これらの回答は、例えば、ファイル転送の進歩か完成に関して報告するかもしれなくて、そういうものとしてファイル転送命令に関するセカンダリ回答です。
The third class of replies are informational and spontaneous
replies which may arrive at any time. These replies are listed
below as spontaneous.
3番目のクラスの回答はいつでも到着するかもしれない情報的、そして、自然発生的な回答です。 これらの回答は自然発生的であるとして以下に記載されています。
COMMAND-REPLY CORRESPONDENCE TABLE
コマンド回答通信テーブル
COMMAND SUCCESS FAIL
コマンド成功は失敗します。
USER 230,330 430-432,500-505 PASS 230 430-432,500-505 BYE 231,232 430-432,500-505 BYTE 200 500-506 SOCK 200 500-506 TYPE 200 500-506 MODE 200 500-506 RETR 250 450,451,500-506 Secondary Reply 252 452 STOR 250 451,451,500-506 Secondary Reply 252 452,453 APPE 250 451,451,500-506 Secondary Reply 252 452,453
ユーザ23万330 430-432,500-505パス230 430-432,500-505不戦勝231,232 430-432,500-505バイト200 500-506ソックス200 500-506は200 500-506 モード200 500-506RETR250の450,451,500-506のセカンダリ回答252 452STOR250の451,451,500-506のセカンダリ回答252 45万2453APPE250の451,451,500-506のセカンダリ回答252 45万2453をタイプします。
[Page 22]
The File Transfer Protocol July 8, 1972
[22ページ] ファイル転送プロトコル1972年7月8日
RNFR 200 450,451,500-506 RNTO 253 450,451,500-505 DELE 254 450,451,500-506 LIST 250 450,453,500-506 Secondary Reply 252 452 ALLO 200 500-506 STAT 100,150,151 450,451,500-506 REST 200 500-506 ABOR 201,202 500-505
RNFR200 450,451,500-506RNTO253 450,451,500-505DELE254 450,451,500-506リスト250 450,453,500-506のセカンダリ回答252 452異200 500-506スタット100,150,151 450,451,500-506は500-505に200 500-506 ABOR201,202を休ませます。
Spontaneous 0xx,300,301 400,401,434-436 Replies 251,255
自然発生的な0xx、300,301 400,401,434-436の回答251,255
V.D. Tyical FTP Scenarious
V.D.Tyical FTP Scenarious
1. TIP User wanting o transfer file from FOST X to local printer:
1. o転送が欲しいTIP UserがFOST Xからローカルプリンタまでファイルします:
a) TIP user opens TELNET connections by ICP to HOST X, socket 3.
a) TIPユーザはHOST X、ソケット3にICPによるTELNET接続を開きます。
b) The following commands and replies are exchanged:
TIP HOST X
b) 以下のコマンドと回答を交換します: チップホストX
USER username CRLF -------->
<------- 330 Enter Password CRLF
USERユーザ名CRLF--------><。------- 330はパスワードCRLFに入ります。
PASS password CRLF -------->
<------- 230 User logged in CRLF
PASSパスワードCRLF--------><。------- 230ユーザはCRLFにログインしました。
SOCK 65538 CRLF -------->
<------- 200 Command received OK CRLF
ソックス65538CRLF--------><。------- 200 コマンドはOK CRLFを受けました。
RETR this.file CRLF -------->
<------- 255 SOCK 5533 CRLF
RETR this.file CRLF--------><。------- 255 ソックス5533CRLF
(HOST X initiates data connection to
TIP socket 65538, i.e., PORT 1 receive)
(HOST XはTIPソケット65538にデータ接続を開始します、すなわち、PORT1は受信します)
<------- 250 File transfer started
<。------- 250ファイル転送は始まりました。
BYE CRLF ------_->
<------- 252 File transfer completed
さようならCRLF------_-><。------- 終了する252ファイル転送
c) HOST X closes the TELNET and data connections.
c) HOST XはTELNETとデータ接続を終えます。
Note: The TIP user should be in line mode and can thus use
local TIP editing such as character delete.
以下に注意してください。 TIPユーザは、ライン・モードでいるべきであり、その結果、キャラクタが削除する地方のTIP編集を使用できます。
[Page 23]
The File Transfer Protocol July 8, 1972
[23ページ] ファイル転送プロトコル1972年7月8日
2. User at Host U wanting to transfer files to/from HOST S:
2. 移したがっているHost UのユーザはHOST Sからの/にファイルします:
In general the user would communicate to the server via a
mediating user-FTP process. The following may be a typical
scenario. The user-FTP prompts are shown in parenthesis,
'---->' represents commands from HOST U to HOST S, and
'<----' represents replies from HOST S to HOST U.
一般に、ユーザは仲介のユーザFTPプロセスを通してサーバに伝えるでしょう。 ↓これは典型的なシナリオであるかもしれません。 'ユーザFTPプロンプトは挿入句に示されます'----'>'はHOST S、およびHOST Uから'<'までのコマンドを表します。----'HOST SからHOST Uまでの回答を表します'。
Local Commands by User Action Involved
動作がかかわったユーザによるローカルのコマンド
ftp (host) multics CR ICP to HOST S, socket 3,
establishing TELNET connections.
username Doe CR USER DoeCRLF ---->
<---- 330 passwordCRLF
password mumble CR PASS mumbleCRLF ---->
<---- 230 Doe logged in.CRLF
retrieve (local type ASCIICR
(local pathname) test 1 CR USER-FTP open local file in ASCII.
(for. pathname) test.pl1CR RETR test.pl1 CRLF ---->
<---- 255 SOCK 1233CRLF
Server makes data connection to (U+4).
<---- 250 File transfer startsCRLF
<---- 252 File transfer completeCRLF
type imageCR TYPE |CRLF ---->
<---- 200 Command OKCRLF
byte 36CR BYTE 36CRLF ---->
<---- 200 Command OKCRLF
store (local type) ImageCR
(local pathname) file dumpCR User-FTP opens local file in Image.
(for. pathname) >udd>cn>fdCR STOR >udd>cn>fdCRLF ---->
<---- 451 Access deniedCRLF
terminate BYECRLF
<---- 231 Doe logged outCRLF
Server closes all connections.
HOST Sのftp(ホスト)multics CR ICP、TELNET接続ユーザ名ドウCR USER DoeCRLFを設立するソケット3----><。---- 330passwordCRLFパスワードもぐもぐCR PASS mumbleCRLF----><。---- 230ドウはCRLFが検索するインチを登録しました。(地方のタイプASCIICR(ローカルのパス名)はASCII(. パス名のための)test.pl1CR RETR test.pl1 CRLF--の1つのCR USER-FTPの開いているローカルファイルをテストします--、><、-、-、--、255SOCK 1233CRLF Serverが. (U+4)<にデータ接続を作る-、-、--、250FileがstartsCRLF<を移す-、-、--252 File転送completeCRLFはimageCR TYPEをタイプします| CRLF--(><); 231ドウはoutCRLF Serverを登録しました。200 コマンドOKCRLFバイト36CR BYTE 36CRLF----><、-、-、--200Command OKCRLF店(ローカルのタイプ)ImageCR(ローカルのパス名)ファイルdumpCR User-FTPはImage(. パス名のための)>udd>cn>fdCR STOR>udd>cn>fdCRLF--のローカルファイルを開きます--、><、-、-、--、451Access deniedCRLFがBYECRLF<を終える-、-、--、すべての接続を終えます。
[Page 24]
The File Transfer Protocol July 8, 1972
[24ページ] ファイル転送プロトコル1972年7月8日
ACKNOWLEDGEMENTS
承認
The work on file transfer protocol has involved many people.
This document reports the work of a group rather than the author
alone. The author gratefully acknowledges the conributions of
the following:
ファイル転送プロトコルに対する仕事は多くの人々にかかわりました。 このドキュメントは、作者よりむしろグループの仕事が単独であると報告します。 作者は感謝して以下のconributionsを承認します:
Bob Braden UCLA-CCCN
Arvola Chan MIT-MAC
Bill Crowther BBN-TIP
Eric Harslem RAND
John Heafner RAND
Chuck Holland UCSD
Alex McKenzie BBN (NET)
Bob Metcalfe XPARC
Jon Postel UCLA
Neal Ryan MIT-MAC
Bob Sundberg HARVARD
Ray Tomlinson BBN (TENEX)
Dick Watson SRI-ARC
Jim White SRI-ARC
Richard Winter CCA
ボブブレーデンUCLA-CCCN ArvolaチェンMIT-MACビルクラウザーBBN-チップエリックHarslem底ならし革ジョンHeafner底ならし革チャックオランダUCSDアレックスマッケンジー(ネット)のBBNのボブSundbergハーバードレイトムリンスンボブメトカルフェXPARCジョンポステルUCLAニールライアンMIT-MAC BBN(TENEX)ディックワトソン様アークジムホワイト様アークリチャード冬のCCA
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gottfried Janik 9/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ゴットフリート・ジャニク9/97によるオンラインRFCアーカイブへの]
[Page 25]
[25ページ]
一覧
スポンサーリンク
