RFC454 日本語訳
0454 File Transfer Protocol - meeting announcement and a new proposeddocument. A.M. McKenzie. February 1973. (Format: TXT=78966 bytes) (Updates RFC0354) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. McKenzie Request for Comments: 454 BBN NIC: 14333 16 February 1973
コメントを求めるワーキンググループA.マッケンジー要求をネットワークでつないでください: 454BBN NIC: 14333 1973年2月16日
FILE TRANSFER PROTOCOL
ファイル転送プロトコル
Meeting Announcement and a New Proposed Document
ミーティング発表と新しい提案されたドキュメント
Attached is a new proposal for a File Transfer Protocol. The document is an extensive update to RFC 354 and, I believe, incorporates solutions to most of the objections to RFC 354.
File Transferプロトコルのための新規案件を付けます。 私は、ドキュメントがRFC354への大規模なアップデートであり、RFC354への反論の大部分にソリューションを取り入れると信じています。
It now seems appropriate to make another attempt to reach final agreement on FTP. Accordingly, I am calling a meeting of interested parties, to be held at BBN on March 16, for discussion of this and other proposals.
FTPで最終合意に達する別の試みをするのは今、適切に思えます。 それに従って、私はこれと他の提案の議論のために利害関係者の3月16日にBBNで開催されるべきミーティングを召集しています。
This note is directed to the network community at large, rather than specifically to the old FTP committee, because I don't believe that the FTP committee membership includes all the individuals who have contributed to the current state of FTP design. Nevertheless, it is intended that the meeting proceed from the current state, rather than bringing new members up-to-speed. Prospective attendees should therefore be familiar with at least the following documents:
この注意は特に古いFTP委員会にというよりむしろ全体のネットワーク共同体に向けられます、私が、FTP委員会の会員資格がFTPデザインの現状まで貢献したすべての個人を含んでいると信じていないので。 それにもかかわらず、ミーティングが促進するために起きていている新しいメンバーを連れて来るより現状からむしろ進んでいることを意図します。 したがって、将来の出席者は少なくとも以下のドキュメントに詳しいはずです:
RFC 354
RFC 385
RFC 414
RFC 418
RFC 438
RFC354RFC385RFC414RFC418RFC438
Anyone wishing to attend this meeting should contact Alex McKenzie (NIC Ident aam) at BBN, 50 Moulton Street, Cambridge, Mass. 02138. My telephone number is:
このミーティングに出席したがっているだれでもBBN、50モールトン通り、ケンブリッジ、マサチューセッツ州でアレックス・マッケンジー(NIC Ident aam)に連絡するべきです。 02138. 私の電話番号は以下の通りです。
(617) 491-1850 ext.441
(617)491-1850ext.441
When there is some indication of the number of individuals planning to attend, a meeting room will be reserved and more specific information will be directed to attendees.
出席するのを計画している個体数のいくつかのしるしがあるとき、会議室は予約されるでしょう、そして、より特定の情報は出席者に向けられるでしょう。
McKenzie [Page 1] RFC 454 File Transfer Protocol July 1972
マッケンジー[1ページ]RFC454ファイル転送プロトコル1972年7月
PROPOSED FILE TRANSFER PROTOCOL
提案されたファイル転送プロトコル
This document is the outcome of a meeting held 25 January 1973 in Cambridge, Massachusetts, by the following people:
このドキュメントは以下の人々によるケンブリッジ(マサチューセッツ)の会っている保持された1973年1月25日の結果です:
Abhay Bhushan (MIT - DMCG)
Abhay Bhushan(MIT--DMCG)
Bob Bressler (BBN - NET)
ボブBressler(BBN--ネット)
Bob Clements (BBN - TENEX)
ボブ・クレメンツ(BBN--TENEX)
Alex McKenzie (BBN - NET)
アレックス・マッケンジー(BBN--ネット)
Nancy Neigus (BBN - NET)
ナンシーNeigus(BBN--ネット)
Ken Pogran (MIT - MULTICS)
ケンPogran(MIT--MULTICS)
Marc Seriff (MIT - DMCG)
マークSeriff(MIT--DMCG)
The basis of the document is RFC 354 with considerations drawn from RFC's 385, 414, 418, and 438 and personal communication with network participants.
ドキュメントの基礎は、RFCの385、414、418、および438からの問題が描かれているRFC354とネットワーク関係者との個人的なコミュニケーションです。
McKenzie [Page 2] RFC 454 File Transfer Protocol July 1972
マッケンジー[2ページ]RFC454ファイル転送プロトコル1972年7月
PROPOSED FILE TRANSFER PROTOCOL
提案されたファイル転送プロトコル
INTRODUCTION
序論
The File Transfer Protocol (FTP) is a protocol for file transfer between 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)はHOSTsの間のファイル転送のためのプロトコル(端末のIMPsを含んでいて)です、ARPAコンピュータNetwork(アルパネット)で。 FTPのプライマリ機能は、ファイルをHOSTsに効率的に、そして確かに移して、リモートファイル機構の便利な使用を許すことです。
The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to 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 a user at a terminal, is designed mainly for use by programs.
FTPの目的はリモート・コンピュータの間接的であるか暗黙(プログラムを通した)の使用、HOSTsの中のファイルストレージシステムの変化からユーザを保護する3、)および4が)確かに効率的にデータを移すよう奨励するためにファイル(コンピュータ・プログラム、そして/または、データ)、2を)共有する促進する1です)。 直接端末のユーザが使用可能ですが、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) 初期の接続プロトコル(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における特別な意味があるものにすぎません。
II.A Terminology
II.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 is zero).
ASCIIは7104年にNIC#定義されるUSASCII文字集合です。 FTPでは、ASCII文字は、1つの8ビット・コードセットの下半分になるように定義されます(すなわち、最も重要なビットはゼロです)。
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 server-FTP process to
provide access controls.
Accessが制御するアクセス制御はシステムの使用と、そして、そのシステムのファイルへのユーザのアクセス権を定義します。 アクセス制御が、ファイルの権限のないか偶然の使用を防ぐのに必要です。 それはアクセス制御を提供するサーバFTPプロセスの特権です。
McKenzie [Page 3] RFC 454 File Transfer Protocol July 1972
マッケンジー[3ページ]RFC454ファイル転送プロトコル1972年7月
byte size The byte size specified for the transfer od 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.
バイトサイズが転送odデータに指定したバイトサイズ。 データ接続はこのバイトサイズで開かれます。 データ接続バイトサイズは、必ずシステムに保存されるデータがことであるバイトサイズであるというわけではなく、データ構造に関連しないかもしれません。
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 condition that defines the end of
a file being transferred.
EOF、移されるファイルの端を定義するファイル終了条件。
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 from
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システムか転送プロセスのどちらかの失敗などのある誤りから克服できるエラー回復A手順。 FTPに、エラー回復は、与えられたチェックポイントでファイル転送を再開することを伴うかもしれません。
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コマンドは処理されます。
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.C.
モード、モードはどのデータでデータ接続で移すかことです。 モードはEORとEOFを含むデータの形式を定義します。 FTPで定義された転送モードはセクションIII.Cで説明されます。
NVT The Network Virtual Terminal as defined in the
ARPANET TELNET Protocol.
ARPANET TELNETプロトコルで定義されるNVT Network Virtual Terminal。
McKenzie [Page 4] RFC 454 File Transfer Protocol July 1972
マッケンジー[4ページ]RFC454ファイル転送プロトコル1972年7月
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 NVFS concept at this
time.
NVFSのネットワークの仮想のファイルシステム。 標準のコマンドとパス名コンベンションと共に標準のネットワークファイルシステムを定義する概念。 FTPはこのとき、NVFS概念を部分的に受け入れるだけです。
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 the file
systems he wishes to use.
パス名Pathnameは、ユーザがファイルを特定するためにファイルシステムに入力しなければならない文字列になるように定義されます。 通常、パス名はデバイス、そして/または、ディレクトリ名と、ファイル名仕様を含んでいます。 FTPはまだ一般的なパス名コンベンションを指定していません。 各ユーザは彼が使用したがっているファイルシステムのファイル命名規則に続かなければなりません。
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 acknowledgement (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プロセスは、解釈して、ユーザコマンドに応じて、データ接続を開始しなければなりません。
server site A HOST site which has a server-FTP process.
サーバFTPプロセスがあるサーバサイトA HOSTサイト。
server-TELNET A TELNET process which listens on a specified
socket for an ICP initiated by a user-TELNET, and
performs 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の間の全二重通信経路。 標準のアルパネットInitial Connectionプロトコル(ICP)でTELNET接続は確立されます。
McKenzie [Page 5] RFC 454 File Transfer Protocol July 1972
マッケンジー[5ページ]RFC454ファイル転送プロトコル1972年7月
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 processes 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プロトコルによると、働きます)。
II.B The FTP Model
II.B FTPモデル
With the above definitions in mind, the following model (shown in Figure 1) may be diagramed for an FTP service.
上の定義が念頭にある場合、以下のモデル(図1では、目立つ)はFTPサービスのために図解されるかもしれません。
In the model described in Figure 1, the user-TELNET initiates the TELNET connections. 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接続の上のコマンドに対応して標準の回答をサーバからユーザに送ります。
McKenzie [Page 6] RFC 454 File Transfer Protocol July 1972
マッケンジー[6ページ]RFC454ファイル転送プロトコル1972年7月
The FTP commands specify the parameters for the data connection (data socket, byte size, transfer mode, representation type, and format) and the nature of file system operation (store, retrieve, append, delete, etc.). The user-FTP process or its designate should "listen" on 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 connections, 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) wishing 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.
FTPコマンドがデータ接続(データソケット(バイトサイズ)はモード、表現タイプ、および形式を移す)とファイルシステム・オペレーションの本質にパラメタを指定する、(店、検索、追加、削除、など) または、ユーザFTPプロセス、それ、指定、指定されたデータソケットで「聴くべきであり」、指定されたデータ接続パラメタによると、データ接続とデータ転送に着手するのは、サーバの責任です。 データソケットがTELNET接続でFTPコマンドを開始するのと同じHOSTにある必要はないことに注意されるべきですが、ユーザか彼のユーザFTPプロセスが指定されたデータソケットの「聴いてください」を確実にしなければなりません。 第3HOSTsへのそのようなファイル転送に関する実例はデバイス、または、添付の入出力デバイスからTIPまでファイルを送りたがっている大型-HOSTユーザ(実際にTIPユーザであるかもしれない)です。 また、それが注意されるべきである、その2つの1歳のデータ接続、発信、もう片方、受信してください、そして、同時に、存在してもよいです。
TELNET
Connections
+-----+ +-------+ +------+ +------+ +-------+ +-----+
| File|<->|Server-|<->|Server|<----------|User |<->|User- |<->|File |
|Sys | |FTP | |TELNET| FTP Cmds |TELNET| |FTP | |Sys- |
| -tem| |Process| | |---------->| | |Process| | tem |
+-----+ | | +------+FTP Replies+------+ | | +-----+
| | | |
| |<------------------------------->|Data |
| | Data Connection(s) |Socket |
+-------+ +-------+
|
|
+------+
| |
| USER |
| |
+------+
telnetコネクションズ+-----+ +-------+ +------+ +------+ +-------+ +-----+ | ファイル| <->|サーバ| <->|サーバ| <、-、-、-、-、-、-、-、-、--、|ユーザ| <->|ユーザ| <->|ファイル| |Sys| |FTP| |telnet| FTP Cmds|telnet| |FTP| |Sys| | -tem| |プロセス| | |、-、-、-、-、-、-、-、-、--、>|、| |プロセス| | tem| +-----+ | | +------+ FTP回答+------+ | | +-----+ | | | | | |<------------------------------->|データ| | | データ接続|ソケット| +-------+ +-------+ | | +------+ | | | ユーザ| | | +------+
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使用のためにモデル化します。
McKenzie [Page 7] RFC 454 File Transfer Protocol July 1972
マッケンジー[7ページ]RFC454ファイル転送プロトコル1972年7月
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 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, prior to sending a transfer request command. 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 reply, 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 or after initiating the data connection.
転送要求命令を送る前に、ユーザの現場は指定されたデータソケットで「聴かれるものとします」。 FTP要求コマンドはデータ転送の方向、およびデータ接続を確立する際に使用されることであるソケット番号(変であるか同等の)を決定します。 要求を検索してください。または、適切な店を受けるときのサーバ、指定されたバイトサイズ(デフォルトバイトサイズは8ビットである)で指定された利用者データソケットにデータ接続を開始して、回答にファイル転送が続くかもしれないのを示させるでしょう。 この回答の前に、サーバで、回答はデータ接続のためのサーバソケットを示すべきです。 ユーザは、彼のデータ転送のセキュリティを確実にするのにこのサーバソケット情報を使用するかもしれません。 開始する前かデータ接続を開始した後に、サーバはこの回答を送るかもしれません。
The byte size for the data connection is specified by the BYTE command. It is not required by the protocol that servers accept all possible byte sizes. The use of various byte sizes is for efficiency in data transfer and servers may implement only those byte sizes for which their data transfer is efficient. It is, however, required that servers implement at least the byte size of 8 bits.
データ接続のためのバイトサイズはBYTEコマンドで指定されます。 サーバが可能なバイトが大きさで分けるすべてを受け入れるのがプロトコルによって必要とされません。 データ転送で様々なバイトサイズの使用は効率のためのものです、そして、サーバはそれらのデータ転送が効率的であるそれらのバイトサイズだけを実装するかもしれません。 しかしながら、サーバが、少なくともバイトが8ビットのサイズであると実装するのが必要です。
After the data transfer is completed, it is the server's responsibility to close the data connection, except when the user is sending the data. In stream mode the sender must close the data connection to indicate EOF, i.e., completion of the transfer. Closing the connection is a server option except under the following conditions:
データ転送が完成した後に、データ接続を終えるのは、サーバの責任です、ユーザがデータを送る時を除いて。 ストリームモードで、送付者は、EOF、すなわち、転送の完成を示すためにデータ接続を終えなければなりません。 接続を終えるのは、以下の条件以外のサーバオプションです:
McKenzie [Page 8] RFC 454 File Transfer Protocol July 1972
マッケンジー[8ページ]RFC454ファイル転送プロトコル1972年7月
1) The server receives an abort command from the user.
1) サーバはユーザから中止コマンドを受け取ります。
2) The socket or the byte size specification is changed by the
user.
2) ソケットかバイトサイズ仕様がユーザによって変えられます。
3) The TELNET connections are closed.
3) TELNET接続は閉じられます。
4) An irrecoverable error condition occurs.
4) 回復しがたいエラー条件は起こります。
It should be noted that if none of the above conditions occur it is possible to maintain two simultaneous data connections, for send and receive.
上記の状態のいずれも現れないなら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 representa- tions 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 be desirable to convert characters into the standard NVT-ASCII representation when transmitting text between dissimilar systems. The sending and receiving sites would have to perform the necessary transformations between the standard representation and their internal representations.
HOSTを受ける際にデータを送付HOSTの記憶装置から記憶装置まで移します。2台のシステムのデータストレージrepresenta- tionsが異なっているので、しばしば、データに、ある変換を実行するのが必要です。 '例えば、一般に、NVT-ASCIIで、異系統PDP-10'sの異なったデータ保存表現は36ビットの単語で正当化されるように残っている5人の7ビットのASCII文字としてNVT-ASCIIを保存します。 360は8ビットのEBCDICコードとしてNVT-ASCIIを保存します。 Multicsは36ビットの単語による4つの9ビットのキャラクタとしてNVT-ASCIIを保存します。 異なったシステムの間にテキストを伝えるときの標準のNVT-ASCII表現にキャラクタを変換するのは望ましいかもしれません。送受信サイトは標準の表現と彼らの内部の表現の間の必要な変換を実行しなければならないでしょう。
A different problem in representation arises when transmitting binary data (not character codes) between HOST systems with different word lengths. 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) to store the 32-bit bytes right-justified in a 36-bit word in the latter sys- tem. 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 type representations. Transforma- tions desired beyond this limited capability should be performed by the user directly or via the use of the Data Reconfiguration (DRS, RFC #138, NIC #6715). Additional representation types may be defined later if there is a demonstrable need.
異なった語長でバイナリ・データ(キャラクタコードでない)をHOSTシステムの間に伝えるとき、表現における異なった問題は起こります。 それはいつも送付者がどうデータを送るべきであるかをクリアするというわけではないことであり、受信機店はそれです。 32ビットの語長システムから36ビットの語長システムまでの伝えることの32ビットのバイトであるときに、例えば、後者のsys- temの36ビットの単語でまさしく正当な32ビットのバイトを保存するのは望ましいかもしれません(効率と有用性の理由による)。 どのような場合でも、ユーザには、データ表現と変形関数を指定するオプションがあるべきです。 FTPが非常に限られたデータ型表現に備えることに注意されるべきです。 この限られた能力を超えて必要なTransforma- tionsは直接かData Reconfiguration(DRS、RFC#138、NIC#6715)の使用でユーザによって実行されるべきです。 明白な必要があれば、追加表現タイプは後で定義されるかもしれません。
Data representations are handled in FTP by a user specifying a representation type. The type may also imply a transfer byte size. For example, in ASCII representation, the transfer byte size should be 8 bits, and any other byte size specification will result in
データ表現はFTPで表現タイプを指定するユーザによって扱われます。 また、タイプは転送バイトサイズについて暗示するかもしれません。 転送バイトサイズは、例えば、ASCII表現では、サイズ仕様がもたらす8ビットと、いかなる他のバイトであるべきです。
McKenzie [Page 9] RFC 454 File Transfer Protocol July 1972
マッケンジー[9ページ]RFC454ファイル転送プロトコル1972年7月
cancellation of the transfer request. In image and Local Byte representations any byte size is possible. The following data representation types are currently defined in FTP:
転送要求のキャンセル。 イメージとLocal Byte表現では、サイズはどんなバイト、可能です。 以下のデータ表現タイプは現在、FTPで定義されます:
1. ASCII The sender converts data from its internal character
representation to the standard NVT 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 the default type, and it is recom-
mended that this type be implemented by all.
1. 送付者のASCIIは内部の文字表示から標準のNVT ASCIIフォームまでデータを変換します。 受信機は標準形式から内部のそれ自身のフォームまでデータを変換します。 標準形式でデータを移します。 転送バイトサイズは8ビットでなければなりません。 このタイプはテキストファイルの転送に使用されるでしょう。 これはデフォルトタイプです、そして、直されて、このタイプがすべてによって実装されるのは、recomです。
2. EBCDIC The sender transfers data using the EBCDIC character
code and 8-bit transfer byte size. This type may be
used for efficient transfer of EBCDIC files between
systems which use EBCDIC for their internal character
representation.
2. 送付者のEBCDICは、EBCDlC文字コードと8ビットの転送バイトサイズを使用することでデータを移します。 このタイプは彼らの内部の文字表示にEBCDICを使用するシステムの間のEBCDICファイルの効率的な転送に使用されるかもしれません。
3. Image The sender transforms data from contiguous bits to
bytes for transfer. The receiver transforms the
bytes into bits, storing them contiguously indepen-
dent of the byte size chosen for data transfer. With
record structure and block mode, the server might
need to pad each record for convenient storage. This
padding is allowed at the end of a record, and should
be remembered by the server so it will be stripped
off when the file is retrieved by the user. The pad-
ding transformation should be well publicized by the
server in case the user processes his file at the
server site. 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.
3. 送付者が隣接のビットからバイトまでのデータを変えるイメージは移されます。 バイトは受信機によってビットに変えられて、近接してそれらを保存すると、データ転送に選ばれたバイトサイズの減少はindepenされます。 記録的な構造とブロックモードで、サーバは、便利なストレージのための各記録を水増しする必要があるかもしれません。 この詰め物が記録の終わりに許容されていて、サーバによって覚えていられるべきであるので、ファイルがユーザによって取られるとき、それは全部はぎ取られるでしょう。 ユーザがサーバサイトで彼のファイルを処理するといけないので、パッド鐘の音変換はサーバによってよくピーアールされるべきです。 Imageタイプへの典型的な用途は、同様のマシンの間の実行可能プログラムの転送と、2進(非テキストの)のデータの転送です。 このタイプが何らかのバイトサイズのためにすべてによって実装されるのは、お勧めです、望ましくは、8ビットのバイトサイズを含んでいて。
4. Local Byte This representation allows for efficient storage,
use, and retrieval of data. The manner 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 by 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
4. ローカルのByte This表現は効率的なストレージ、使用、およびデータ検索を考慮します。 変成しているデータがことである方法はデータ転送、および使用される特定のHOSTのためにバイトサイズに依存します。 異なったバイトサイズの変換体系はすべてのサーバサイトによってよくピーアールされることです。 この変換はinvertible(すなわち、ファイルが、ある転送バイトサイズを使用することで保存されるなら、同じファイルはサイズと表現がタイプする同じバイトを使用することで回収可能であるに違いない)でしょう。 表現の動向をおさえるのは、ユーザの責任です。
McKenzie [Page 10] RFC 454 File Transfer Protocol July 1972
マッケンジー[10ページ]RFC454ファイル転送プロトコル1972年7月
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 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.
サイズが彼の転送に使用したタイプとバイト。 Local Byteタイプの典型的な用途はファイルの効率的なストレージと検索、および構造化されたバイナリ・データの転送中です。 Imageタイプに、このタイプはバイトサイズのために同じであるかもしれません(コンピュータ語長の整数倍か要素です)。
Representation type may also be affected by another attribute, the format. For example, some printers can use ASA (Fortran) vertical format control procedures to transform printed data of type ASCII or EBCDIC. Currently format may take one of two values.
また、表現タイプは別の属性、形式で影響を受けるかもしれません。 例えば、いくつかのプリンタが、タイプASCIIかEBCDICに関する印字データを変えるのにASA(Fortran)垂直書式コントロール手順を用いることができます。 現在の、形式は2つの値の1つを取るかもしれません。
1. Unformatted The representation type as specified is unaffected by
any format transformations. This is the default
value.
1. Unformattedされて、指定されるとしての表現タイプはどんな形式変換でも影響を受けないです。 これはデフォルト値です。
2. Printfile The server is to transform data of either ASCII or
EBCDIC type in accordance with ASA (Fortran) vertical
format control standards. The data is to be
transferred in 8-bit bytes.
2. Printfile、サーバはASA(Fortran)垂直書式制御基準に応じてASCIIかEBCDICタイプのどちらかに関するデータを変えることです。 データは8ビットのバイトで移すことです。
A discussion of the ASA vertical format control appears in NWG/RFC 189, Appendix C, and in Communications of the ACM, Vol. 7, No. 10, p. 606, October 1964. According to the ASA vertical format control standards, the first character of a formatted record is not printed but determines vertical spacing as follow:
ASA垂直書式コントロールの議論はNWG/RFC189、Appendix CとACMのCommunicationsに現れます、Vol.7、No.10、p。 606 1964年10月。 ASA垂直書式制御基準によると、書式付きレコードの最初のキャラクタは、印刷されませんが、続くとき、行送りを決定します:
Character Vertical Spacing before printing
印刷の前のキャラクターVertical Spacing
Blank One line
0 Two lines
1 To first line of the next page
+ No advance
空白のOne系列0Twoは次のページ+ノー進歩のTo1最初の系列を裏打ちします。
In addition to the above four, there are more characters (defined in Appendix C, RFC 189) which represent an IBM extension to the ASA standard.
上の4に加えて、IBMの拡大をASA規格に表すより多くのキャラクタ(Appendix C、RFC189では、定義される)があります。
It should be noted that a serving host need not accept all represen- tation types and/or byte sizes, but it must inform the user request- ing an unacceptable type or size of this fact by sending an appropri- ate reply.
給仕のホストがタイプ、そして/または、バイトが大きさで分けるすべてのrepresen- tationを受け入れませんが、返答しなければならないことをappropriを送るのによるこの事実の容認できないタイプかサイズが食べたユーザ要求ingに知らせなければならないことに注意されるべきです。
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
現時点に直接FTPで支えられた唯一のファイル構造が記録的な構造です。 しかしながら、記録的な構造の使用は義務的ではありません。 彼のファイルの記録的な構造のないユーザはそうであるべきです。
McKenzie [Page 11] RFC 454 File Transfer Protocol July 1972
マッケンジー[11ページ]RFC454ファイル転送プロトコル1972年7月
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 dis- carded by the receiver.
できる、いずれでも彼のファイルを保存して、取るために、HOST記録的な構造化ファイルを送りたがっているユーザは適切なFTP'STRU'コマンドを送らなければなりません(デフォルト仮定は記録的な構造ではありません)。 給仕HOSTは記録的な構造を受け入れる必要はありませんが、それは、適切な回答を送ることによって、この事実をユーザに知らせなければなりません。 データ・ストリームにおけるどんな記録的な構造情報も次に、受信機によって不-cardedされるかもしれません。
All data transfers 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 of files with record structures. Records may be of zero length but they must be contained in file boundaries. The relation- ship between files and records is hierarchical but an EOF does not imply an EOR.
すべてのデータ転送がEOFと共に終わらなければなりません。 EOFはデータ転送モードで定義されます。 また、記録的な構造を持っているファイルに関しては、EORは転送モードで定義されます。 記録的な構造があるファイルの転送に定義されたEORを持っている転送モードと表現タイプ組み合わせだけを使用してもよいです。 記録はゼロ・レングスのものであるかもしれませんが、ファイルの限界にそれらを含まなければなりません。 ファイルとレコードの間の関係船は階層的ですが、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 signaled by closing
the data connection. Any representation type and
byte size may be used in the stream mode with file
structure, but use of record structure limits the
type to ASCII or EBCDIC with or without Printfile
format. The convention is that the ASCII character
CR (Carriage Return, Code 15 (octal)) followed by LF
(Line Feed, Code 12 (octal)) indicates an EOR for
ASCII representation type, and the EBCDIC character
NL (New Line, Code 15 (hex)) indicates an EOR for
EBCDIC type. This is the default mode, and it is
recommended that this mode be implemented by all.
1. ファイルを流してください。バイトの指定されたバイトサイズのストリームとして、伝えられます。 データ接続を終えることによって、EOFは合図されます。 どんな表現タイプとバイト、サイズはファイル構造でストリームモードで使用されるかもしれませんがも、記録的な構造の使用はPrintfile形式のあるなしにかかわらずタイプをASCIIかEBCDICに制限します。 コンベンションはLF(Feedを裏打ちしてください、Code12(8進))によって続かれたASCII文字CR(キャリッジReturn、Code15(8進))がASCII表現タイプのためにEORを示して、EBCDlC文字NL(新しい線、Code15(魔法をかける))がEBCDICタイプのためにEORを示すということです。 これはデフォルトモードです、そして、このモードがすべてによって実装されるのは、お勧めです。
2. Text The file is ASCII text transmitted as a sequence of
8-bit bytes in the ASCII representation type, and
optional Printfile format. Record structures are
allowed in this mode. The EOR and EOF are defined by
the presence of special "TELNET-control" codes (,ost
significant bit set to one) in the data stream. The
EOR code is 192 (octal 300, hex CO). The EOF code is
193 (octal 301, hex C1). The byte size for transfer
is 8 bits.
2. テキスト、ファイルはASCII表現タイプ、および任意のPrintfile形式の8ビットのバイトの系列として伝えられたASCIIテキストです。 記録的な構造はこのモードで許容されています。 EORとEOFはデータ・ストリームにおける、特別な「telnetコントロール」コード(ost重要なビットは1つにセットした)の存在によって定義されます。 EORコードは192(8進300、十六進法CO)です。 EOFコードは193(8進301、十六進法C1)です。 転送のためのバイトサイズは8ビットです。
(For ASCII type, text and stream modes are almost identical.)
(ASCIIタイプにおいて、テキストとストリームモードはほとんど同じです。)
McKenzie [Page 12] RFC 454 File Transfer Protocol July 1972
マッケンジー[12ページ]RFC454ファイル転送プロトコル1972年7月
Comparing the two, the advantages of "stream" mode are:
2を比較して、「ストリーム」モードの利点は以下の通りです。
1) The receiver need not scan the incoming bytes.
1) 受信機は入って来るバイトをスキャンする必要はありません。
2) It is usable with all data types.
2) それはすべてのデータ型で使用可能です。
and the disadvantages are:
1) Closing the data connection under error conditions can be
misconstrued as an EOF in stream mode when in fact the data
transfer was interrupted. In text mode the EOF is sent expli-
citly.
そして、損失は以下の通りです。 1) 事実上、データ転送が中断されたとき、ストリームモードでエラー条件の下でデータ接続を終えるのにEOFを誤解できます。 テキストモードで、expli- citlyをEOFに送ります。
2) If record structure is specified in stream mode then CRLF
implies EOR, and in order for CRLF to be sent as valid data it
must be transformed, e.g., into CR NUL LF or LF CR.
2) 記録的な構造がストリームモードで指定されるなら、CRLFはEORを含意します、そして、有効データとしてCRLFを送るためにそれを変えなければなりません、例えば、CR NUL LFかLF CRに。
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 reli-
able). Record structures are allowed in this mode,
and any representation type or byte size may be used.
3. ファイルを妨げてください。一連のデータ・ブロックが1ヘッダーバイト以上先行したので、送られます。 ヘッダーバイトはカウント分野、および記述子コードを含んでいます。 カウント分野はバイトで表現されるデータ・ブロックの全長を示します、その結果、次のデータ・ブロックの始まりを示します(フィラービットが全くありません)。 記述子コードは最後のファイルブロック(EOF)、最後のレコード・ブロック(EOR)、再開マーカー(セクションIII.Dを見る)、または疑わしいデータを定義します(すなわち、移されるデータは、誤りについて疑われて、できるreliではありません)。 記録的な構造はこのモードで許容されています、そして、どんな表現タイプやバイト、サイズは使用されるかもしれません。
The header consists of the smallest integral number
of bytes whose length is greater than or equal to 24
bits. Only the _least_ significant 24 bits (right-
justified) of header shall have information; the
remaining most significant bits are "don't care"
bits. 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ビット以上である最もわずかな不可欠のバイト数から成ります。 _重要な24ビット(まさしく正当な)のヘッダーがそうするものとする_最少だけが情報を持っている、。 残っている最上位ビットは「気にかけないでください」というビットです。 24ビットのヘッダー情報では、16下位のビットはバイト・カウントを表すものとします、そして、8高位のビットが以下に示すように記述子コードを表すものとします。
Integral data bytes >= 24
+---------------+---------------+--------------+
| Don't care | Descriptor | Byte Count |
| 0 to 231 bits | 8 bits | 16 bits |
+---------------+---------------+--------------+
不可欠のデータ・バイト>=24+---------------+---------------+--------------+ | 気にかけないでください。| 記述子| バイト・カウント| | 0〜231ビット| 8ビット| 16ビット| +---------------+---------------+--------------+
McKenzie [Page 13] RFC 454 File Transfer Protocol July 1972
マッケンジー[13ページ]RFC454ファイル転送プロトコル1972年7月
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.
コード意味---- ------- 0 データの普通のブロック。 データ・ブロックの1つの端がEORです。 データ・ブロックの2端はEOFです。 3は、データにおける誤りが妨げると疑いました。 4データ・ブロックが再開マーカーです。
In the use of block mode it is possible for two or
more conditions requiring different descriptor codes
(suspected errors and either end of record or end of
file) to exist simultaneously. Such a possibility
may be handled by sending a separate EOR or EOF block
with a zero byte count. (This is allowed by the pro-
tocol.)
ブロックモードの使用で、異なった記述子コード(疑われた誤りと記録の終わりかファイルの終りのどちらか)を必要とする2つ以上の状態に、同時に存在するのは可能です。 そのような可能性は、ゼロがある別々のEORかEOFブロックにバイト・カウントを送ることによって、扱われるかもしれません。 (これは親tocolによって許容されています。)
The restart marker is embedded in the data stream as
an integral number of 8-bit bytes (representing
printable ASCII characters) right-justified in an
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
+----------+------------+
| | Marker Char|
| | 8 bits |
+----------+------------+
7ビットの2バイト+----------+------------+ | | マーカー炭| | | 8ビット| +----------+------------+
For byte size of 16 bits or more, two or 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 not exactly fit an
integral byte, the unused character slots should con-
tain 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)のtainをだますべきです。 例えば、36ビットのバイトサイズで6キャラクタマーカーを送るために、以下の36ビットの3バイトを送るでしょう:
McKenzie [Page 14] RFC 454 File Transfer Protocol July 1972
マッケンジー[14ページ]RFC454ファイル転送プロトコル1972年7月
+-------------+-------------+---------------+
| Don't care | Descriptor | |
| 12 bits | code=4 | Byte count=2 |
+-------------+-------------+---------------+
+-------------+-------------+---------------+ | 気にかけないでください。| 記述子| | | 12ビット| コード=4| バイト・カウント=2| +-------------+-------------+---------------+
+----+---------+---------+--------+---------+
| | 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
4. 掛け金
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.
ファイルは標準のHaspによって圧縮されたデータの形式(ボブ・ブレーデン、UCLAによって発行されるドキュメント)の8ビットのバイトの系列として送られます。 このモードは印刷ファイルのためのデータのかなりの要約を実現します。 記録的な構造はHaspモードで許容されています。
The following matrix summarizes the legal combinations of file transfer parameters. The decimal integers represent legal byte sizes for each particular STRU-MODE-TYPE-FORM grouping absence of a number implies illegality. Note that HASP mode is not included since it has never been defined.
以下のマトリクスはファイル転送パラメタの法的な組み合わせをまとめます。 数の欠如を分類するそれぞれの特定のSTRU-MODE-TYPE-FORMが違法性を含意するので、10進整数は法的なバイトサイズを表します。 それが決して定義されないで以来HASPモードが含まれていないことに注意してください。
STRU F | R
+-------------------------------+-----+-----+------+
TYPE |\ MODE | | | |
| \ | | | |
| \ S T B | S | T | B |
| FORM +--------+-----+---------+-----+-----+------+
A | U | 8 | 8 | 8 | 8 | 8 | 8 |
| +--------+-----+---------+-----+-----+------+
| P | 8 | 8 | 8 | 8 | 8 | 8 |
----+------+--------+-----+---------+-----+-----+------+
E | U | 8 | | 8 | 8 | | 8 |
| +--------+-----+---------+-----+-----+------+
| P | 8 | | 8 | 8 | | 8 |
----+------+--------+-----+---------+-----+-----+------+
I | U | 1-255 | | 1-255 | | |1-255 |
----+------+--------+-----+---------+-----+-----+------+
L | U | 1-255 | | 1-255 | | |1-255 |
----+------+--------+-----+---------+-----+-----+------+
STRU F| R+-------------------------------+-----+-----+------+ タイプ|\モード| | | | | \ | | | | | \S t B| S| T| B| | フォーム+--------+-----+---------+-----+-----+------+ A| U| 8 | 8 | 8 | 8 | 8 | 8 | | +--------+-----+---------+-----+-----+------+ | P| 8 | 8 | 8 | 8 | 8 | 8 | ----+------+--------+-----+---------+-----+-----+------+ E| U| 8 | | 8 | 8 | | 8 | | +--------+-----+---------+-----+-----+------+ | P| 8 | | 8 | 8 | | 8 | ----+------+--------+-----+---------+-----+-----+------+ 私| U| 1-255 | | 1-255 | | |1-255 | ----+------+--------+-----+---------+-----+-----+------+ L| U| 1-255 | | 1-255 | | |1-255 | ----+------+--------+-----+---------+-----+-----+------+
McKenzie [Page 15] RFC 454 File Transfer Protocol July 1972
マッケンジー[15ページ]RFC454ファイル転送プロトコル1972年7月
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 the 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 octal codes 41 through 176 (i.e., not including codes 0 through 37 and the characters SP and DEL). The marker could represent a bit-count, a record-count, or any other information by which 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.
再開手順はデータ転送のブロックモードのためだけに定義されます。 それは、何らかのマーカー情報で特別なマーカーコードをデータ・ストリームに挿入するために送付者にデータを要求します。 マーカー情報は、送付者だけに意味を持っていますが、印刷可能なASCII文字から成らなければなりません。 印刷可能なASCII文字は、41〜176(すなわち、キャラクタのコード0〜37、SP、およびDELを含んでいない)に8進コードになるように定義されます。 マーカーはしばらくカウント、レコード・カウント、またはシステムがデータチェックポイントを特定するかもしれないいかなる他の情報も表すことができました。 再開手順を実装するなら、データの受信機は、次に、受電方式にこのマーカーの対応する位置を示して、この情報をユーザに返すでしょう。
In the event of a system failure, the user can restart the data transfer by identifying the marker point with the FTP restart pro- cedure. The following examples illustrate the use of the restart procedure.
システム障害の場合、ユーザは、FTP再開親cedureとマーカーポイントを同一視することによって、データ転送を再開できます。 以下の例は再開手順の使用を例証します。
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
corresponding 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 last server marker by sending a restart command
with the server's marker code as its argument. The restart com-
mand 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 occurred.
1. サーバがデータの送付者であるときに、サーバFTPプロセスは便利なデータポイントでのデータ・ストリームに適切なマーカーブロックを指し込みます。 ユーザFTPプロセスは、データを受信して、ファイルシステムで対応するデータがポイントであるとマークして、最後に知られている送付者と受信機マーカー情報をユーザに伝えます。 システム障害の場合、ユーザかユーザFTPプロセスが、議論として最後のサーバマーカーでサーバのマーカーコードで再開コマンドを送ることによって、サーバを再開します。 再開com- mandをTELNET接続の上に伝えられて、コマンドがすぐにあとに続く、(保存するか、検索、)、システム障害が起こったとき実行されていた。
2. When user is the sender of data, the user-FTP process inserts the
appropriate marker block in the data stream. The server-FTP pro-
cess, receiving the data, marks the corresponding data point in
its file system. The server does not store this marker but con-
veys 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接続の上で適切な回答コードでユーザへの最後に知られている送付者と受信機マーカー情報をまやかしveysにします。 そして、ユーザかユーザFTPプロセスが最初の例で説明されたそれと同じ方法で転送を再開します。
McKenzie [Page 16] RFC 454 File Transfer Protocol July 1972
マッケンジー[16ページ]RFC454ファイル転送プロトコル1972年7月
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 involve sending the FTP commands, interpret- ing the replies received and transferring data over the data connec- tion 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コマンドと回答が伝えられるTELNET接続は標準のサーバソケットへのICPを通してユーザFTPプロセスによって開始されます。 次に、FTPコマンドはユーザからサーバまで伝えられます、そして、回答はサーバからユーザまで伝えられます。 伝達関数がFTPを送ることを伴うユーザ・ファイルは、指定された方法によるデータconnec- tionの上で回答が受けたingと移すデータを解釈するように命令します。 サーバファイル転送機能は、FTPコマンドを受け入れて、解釈することを伴います、回答を送って、データ接続をセットアップして、データを移して。
McKenzie [Page 17] RFC 454 File Transfer Protocol July 1972
マッケンジー[17ページ]RFC454ファイル転送プロトコル1972年7月
IV.A FTP Commands
IV.A FTPコマンド
FTP commands are ASCII strings terminated by the ASCII character sequence CRLF (Carriage Return followed by Line Feed). The command codes themselves are ASCII alphabetic characters terminated by the ASCII character 'space' (octal code 40). For convenience, the com- mand codes are defined to be four (or less) ASCII alphanumeric char- acters (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 sequences 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文字'スペース'(8進コード40)によって終えられたASCII英字です。 便利において、com- mandコードは、4(それほど)のASCIIの英数字の炭のacters(両方の大文字と小文字英字を含んでいる)になるように定義されます。 セクションV.Bでコマンドの詳細な構文を指定します、そして、セクションV.Cで回答系列について議論します、そして、このセクションでコマンドコードとコマンドの意味論について説明しますが、コマンドの使用を例証するシナリオをセクションV.Dに提供します。
FTP commands may be partitioned as those specifying access-control identifiers, data transfer parameters, or FTP service requests. Cer- tain commands (such as ABOR, STAT, BYE) may be sent over the TELNET connections while a data transfer is in progress. Some servers may not be able to monitor the TELNET and data connections simultane- ously, in which case these commands should be preceded by a TELNET SYNC to awaken the server. (For other servers this may not be neces- sary and the SYNC will be ignored.)
FTPコマンドはアクセス制御識別子、データ転送パラメタ、またはFTPサービスのリクエストを指定するものとして仕切られるかもしれません。 データ転送が進行している間、Cer- tainコマンド(ABOR、STAT、BYEなどの)をTELNET接続の上に送るかもしれません。 いくつかのサーバがTELNETとデータ接続simultane- ouslyをモニターできないかもしれない、その場合、これらのコマンドは、サーバに目を覚まさせるためにTELNET SYNCによって先行されるはずです。(これは他のサーバのための、neces- saryでないかもしれなく、SYNCは無視されるでしょう。)
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 identify-
ing the user. The user identification is that which 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 a password
and/or an account command may also be required by some servers.
Servers may allow a new USER command to be entered at any point in
order to change the accounting information. All parameters are
unchanged and any file transfer in progress is completed under the
old account.
ユーザ名前(USER)--議論分野はASCIIストリングがユーザのingを特定するということです。 ユーザ登録名はファイルシステムへのアクセスのためのサーバによって必要とされるそれです。 通常、このコマンドはTELNET接続が作られた(いくつかのサーバがこれを必要とするかもしれません)後にユーザによって伝えられた最初のコマンドになるでしょう。 また、パスワード、そして/または、アカウントコマンドの形の追加識別情報はいくつかのサーバによって必要とされるかもしれません。 サーバは課金情報を変えるために任意な点で入られるべき新しいUSERコマンドを許容するかもしれません。 すべてのパラメタが変わりがありません、そして、進行中のどんなファイル転送も古いアカウントの下で終了しています。
Password (PASS) - The argument field is an ASCII string identify-
ing the user's password. This command must be immediatly preceded
by the user name command, and, for some sites, completes the user'
s identification for access control. Since password information
is quite sensitive, it is desirable in general to "mask" it or
suppress type out. It appears that the server has no foolproof
way to achieve this. It is therefore the responsibility of the
user-FTP process to hide the sensitive password information.
パスワード(PASS)--議論分野はASCIIストリングがingにユーザのパスワードを特定するということです。 'このコマンドは、コマンドというユーザ名が調停して先行しなければならなくて、アクセスコントロールのためにユーザ's識別をいくつかのサイトに終了します。 パスワード情報がかなり機密であるので、一般に、それに「マスクをかける」か、または外でタイプを抑圧するのが望ましいです。 サーバにはこれを達成する絶対に安全な方法が全くないように見えます。 したがって、機密のパスワード情報を隠すのは、ユーザFTPプロセスの責任です。
McKenzie [Page 18] RFC 454 File Transfer Protocol July 1972
マッケンジー[18ページ]RFC454ファイル転送プロトコル1972年7月
Account (ACCT) - The argument field is an ASCII string identifying
the user's account. The command is not necessarily related to the
USER command, as some sites may require an account for login and
others only for specific access, such as storing files. In the
latter case the command may arrive at any time. There are two
reply codes to differentiate these cases for the automaton: When
account information is required for login and the server receives
another command which he buffers, the legal response is reply code
331 when an account is required for a specific transfer requested,
the reply code 433 is returned and the request command is flushed.
アカウント(ACCT)--議論分野はユーザのアカウントを特定するASCIIストリングです。 コマンドは必ずUSERコマンドに関連するというわけではありません、いくつかのサイトがログインのためのアカウントと特定のアクセスのためだけの他のものを必要とするとき、ファイルを保管するのなどように。 後者の場合では、コマンドはいつでも、到着するかもしれません。 オートマトンのためのこれらのケースを差別化するために、2つの回答コードがあります: 会計情報がログインに必要であり、サーバが彼がバッファリングする別のコマンドを受け取るとき、アカウントが要求された特定の転送に必要であるときに、法的な応答は回答コード331です、そして、回答コード433は返されます、そして、要求コマンドは紅潮しています。
Reinitialize (REIN) - This command terminates a USER, flushing all
I/O and account information, except to allow any transfer in pro-
gress to be completed. All parameters are reset to the default
setting and the TELNET connection is left open. A USER command is
expected to follow.
このコマンドがUSERを終えて、すべての入出力を洗い流して、Reinitializeして(REIN)、情報(許容するのを除いた完成するべき親gressのどんな転送も)であることを説明します。 すべてのパラメタが既定の設定にリセットされます、そして、TELNET接続は開くままにされます。 USERコマンドが続くと予想されます。
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. For "hot card-reader" mode
the REIN command should be used instead.
ログアウトしてください(BYE)--このコマンドはUSERを終えます、そして、ファイル転送であるなら、いずれかの進歩、閉鎖でないのにおけるTELNET接続は終えませんか? ファイル転送が進行していると、接続は、結果応答において開いたままで残って、そして近くで残りのようになるでしょう。 「熱いカードリーダ」モードのために、REINコマンドは代わりに使用されるべきです。
An unexpected close on the TELNET connection will cause the server
to take the effective action of an abort (ABOR) and a logout
(BYE).
サーバはTELNET接続での予期していなかった閉鎖でアボート(ABOR)の効果的な行動を取るでしょう、そして、aはログアウトします(BYE)。
IV.A.2 Transfer Parameter 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 the last specified value, or if no value has been specified, the standard default value as stated 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
すべてのデータ転送パラメタには、デフォルト値があります、そして、デフォルトパラメタ値が変えるだけことであるならデータ転送パラメタを指定するコマンドを必要とします。 デフォルト値は最後に指定された値か値が全く指定されていないかどうかということです、ここで述べられるとしての標準省略時解釈値。 これは、サーバが適切なデフォルト値を「覚えていなければならないこと」を含意します。 FTPサービスのリクエストに先行しなければならないのを除いて、コマンドは順不同であるかもしれません。 以下のコマンドはデータ転送パラメタを指定します。
Byte size (BYTE) - The argument is an ASCII-represented decimal
integer (1 through 255), specifying the byte size for the data
connection. The default byte size is 8 bits. The byte size is
always 8 bits in the ASCII and EBCDIC representation types. A
server may reject specific byte size/type combinations by sending
an error reply code in response to a transfer request command.
バイトサイズ(BYTE)--議論はASCIIによって表された10進整数(1〜255)です、データ接続にバイトサイズを指定して。 デフォルトバイトサイズは8ビットです。 バイトサイズは、いつもASCIIにおける8ビットとEBCDIC表現タイプです。 サーバはエラー応答を送るのによるサイズ/タイプ組み合わせが転送要求命令に対応してコード化する特定のバイトを拒絶するかもしれません。
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
データソケット(SOCK)--議論はデータソケットがデータ接続に使用されるHOST-ソケット仕様です。 2個のデータソケット、サーバからユーザともう片方までの1はユーザを支持しているかもしれません。
McKenzie [Page 19] RFC 454 File Transfer Protocol July 1972
マッケンジー[19ページ]RFC454ファイル転送プロトコル1972年7月
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).
サーバデータ転送に。 aはソケットと数が定義する同等のソケットを送ります。変なソケット番号が定義する、aはソケットを受けます。 デフォルトHOSTはTELNET接続が作られているユーザHOSTです。 デフォルトデータソケットは、UがTELNET ICPで使用されるソケット番号であるところの(U+4)と(U+5)です、そして、ソケット(U+2)と(U+3)の上にTELNET接続があります。
Listen (LSTN) - The argument is a single ASCII character code to
specify the direction of the socket that the server must allocate
for use as a data connection. The server is to "listen" on the
allocated socket when an appropriate transfer command is given.
The following codes are assigned:
(LSTN)を聴いてください--議論はサーバが使用のためにデータ接続として割り当てなければならないソケットの方向を指定するただ一つのASCII文字コードです。 「サーバは適切な転送命令を与えるとき、割り当てられたソケットで聴く」ことです。 以下のコードは割り当てられます:
S - send
R - receive
S--Rを送ってください--受信してください。
Representation Type (TYPE) - The argument is a single ASCII char-
acter code specifying the representation types described in Sec-
tion III.B. The following codes are assigned for type:
表現Type(TYPE)--議論は次のコードがタイプのために割り当てられるSec- tion III.B.で説明された表現タイプを指定するASCII炭acterがコード化するシングルです:
A - ASCII
I - Image
L - Local Byte
E - EBCDIC
A--ASCII I--イメージL--地方のバイトE--EBCDIC
The default representation type is ASCII.
デフォルト表現タイプはASCIIです。
Format (FORM) - The argument is a single ASCII character code
specifying the formats described in Section III.B. The following
codes are assigned for format:
形式(FORM)--議論は次のコードが形式のために割り当てられるセクションIII.B.で説明された形式を指定するただ一つのASCII文字コードです:
U - Unformatted
P - Printfile
U--PをUnformattedしました--、Printfile
The default format is Unformatted.
省略時書式はUnformattedです。
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 ecord structure)
R - Record structure
F(ファイル(ecord構造がない)R)は構造を記録します。
The default structure is File (ie. no records).
デフォルト構造はFile(ie記録がない)です。
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文字コードです:
McKenzie [Page 20] RFC 454 File Transfer Protocol July 1972
マッケンジー[20ページ]RFC454ファイル転送プロトコル1972年7月
S - Stream (bytes, close is EOF)
B - Block (header with descriptor and count)
T - Text (TELNET control code for EOR, EOF)
H - Hasp (specially formatted compressed data)
S--ストリーム(バイト、近くに、EOFがある)B--ブロック(記述子とカウントがあるヘッダー)T(テキスト(EOR、EOFのためのTELNET制御コード)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 com- mand will normally be a pathname. The syntax of pathnames must con- form to server site conventions (with standard defaults applicable), except that ASCII characters must be used (in conformance with the TELNET Protocol). The suggested default handling is to use the last specified device, directory or file name, or the standard default defined for local users. The command 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 sent over the data connection. The follow- ing commands specify FTP service requests:
FTP軍管区はユーザによって要求されたファイル転送かファイルシステム機能を定義します。 通常、FTPサービスcom- mandの議論はパス名になるでしょう。 パス名の構文はサーバサイトコンベンション(標準省略時解釈が適切の)にフォームをだまさなければなりません、ASCII文字を使用しなければならないのを除いて(TELNETプロトコルとの順応で)。 提案されたデフォルト取り扱いは地元のユーザのために定義された最後に指定されたデバイス、ディレクトリ、ファイル名、または標準省略時解釈を使用することです。 」 コマンド、およびいくつかにサーバを改名してください。そのaを除いて、コマンドが順不同であるかもしれない、「」 コマンドから改名して、続かなければならない、「「保存」コマンドの前に「割り当て」コマンドを必要としてもよいです。 FTP軍管区に対応して移すと、いつもデータ接続の上にデータを送るものとします。 尾行ing命令はFTPサービスのリクエストを指定します:
Retrieve (RETR) - This command achieves the transfer of a copy of
the file specified in the pathname, from server to user site. The
status and contents of the file at the server site shall be unaf-
fected.
(RETR)を検索してください--このコマンドはパス名で指定されたファイルのコピーの転送を実現します、サーバからユーザの現場まで。 サーバサイトのファイルの状態とコンテンツはunaf- fectedになるでしょう。
Store (STOR) - This command achieves the transfer of a copy of a
file from user to server site. If the file specified in the path-
name 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 the
pathname does not already exist.
(STOR)を保存してください--このコマンドはファイルのコピーのユーザからサーバサイトまでの転送を実現します。 経路名で指定されたファイルがサーバサイトに存在しているなら、コンテンツを移されるファイルのコンテンツに取り替えるものとします。 パス名で指定されたファイルが既に存在していないなら、新しいファイルはサーバサイトで作成されます。
Append (with create) (APPE) - This command achieves the transfer
of data from using to serving site. If the file specified in the
pathname exists at the server site, then the data transferred
shall be appended to that file, otherwise the file specified in
the pathname shall be created at the server site.
追加、(作成、)、(APPE)--このコマンドは使用からサイトに役立つまでのデータ転送を実現します。 パス名で指定されたファイルがサーバサイトに存在しているなら、移されたデータをそのファイルに追加するものとします。さもなければ、サーバサイトでパス名で指定されたファイルを作成するものとします。
Allocate (ALLO) - This command may required by some servers to
reserve sufficient storage to accommodate the new file to be
transferred. The argument 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
(ALLO)を割り当ててください--移すために新しいファイルを収容できるくらいのストレージを控えるのがいくつかのサーバによって必要とされて、このコマンドはそうするかもしれません。 議論分野はファイルのために予約されるためにバイト(バイトサイズコマンドで指定されたサイズの)のストレージの数を表す10進整数になるでしょう。 これ
McKenzie [Page 21] RFC 454 File Transfer Protocol July 1972
マッケンジー[21ページ]RFC454ファイル転送プロトコル1972年7月
command shall be followed by a store or append command. The ALLO
command should be treated as a NO-OP (no operation) by those
servers which do not require that the maximum size of the file be
declared beforehand.
コマンドは、店があとに続いているか、またはコマンドを追加するものとします。 ALLOコマンドはファイルの最大サイズがあらかじめ宣言されるのを必要としないそれらのサーバによってノーオプ(操作がない)として扱われるべきです。
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
data checkpoint. This command shall be immediately followed by
the appropriate FTP service command which shall cause file
transfer to resume.
(REST)を再開してください--議論分野は再開されるかでどのファイル転送がことであるサーバマーカーの代理をします。 このコマンドは指定されたデータチェックポイントへのファイルの上に原因ファイル転送ではなく、「空間」をします。 ファイル転送が再開する適切なFTP軍管区はすぐに、このコマンドのあとに続くものとします。
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がすぐにこのコマンドのあとに続かなければならない、「」 新しいファイルパス名を指定するコマンドに改名します。
Rename to (RNTO) - This command specifies the new pathname of the
file specified in the immediately preceding "rename from" command.
Together the two commands cause a file to be renamed.
(RNTO)との改名、--、このコマンドがすぐに前で指定されたファイルの新しいパス名を指定する「」 コマンドから、改名します。 2つのコマンドはファイルを一緒に、改名します。
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 are 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接続を閉店させてはいけませんが、データ接続は閉店するかもしれません。 サーバは適切な回答を送るべきです。
Delete (DELE) - This command causes the file specified in the
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)を削除してください--このコマンドで、サーバサイトでパス名で指定されたファイルを削除します。 してください。付加的なレベルの保護が望まれている、(質問などのように「あなたが本当に削除したいか、」、)、ユーザFTPプロセスはそれを提供するべきです。
List (LIST) - This command causes a list to be sent from server to
user site. If the pathname specifies a directory, the server
should transfer a list of files in the specified directory. If
the pathname specifies a file then server should send current
information on the file. A null argument implies the user's
current working or default directory. The data transfer is over
the data connection in type ASCII or type EBCDIC. (It is the user
's responsibility to ensure the correct parameters.)
リスト(LIST)--このコマンドで、サーバからユーザの現場にリストを送ります。 パス名がディレクトリを指定するなら、サーバは指定されたディレクトリのファイルのリストを移すべきです。 パス名がファイルを指定するなら、サーバはファイルに関する現行情報を送るべきです。 空の項はユーザの現在の運用かデフォルトディレクトリを含意します。 タイプASCIIかタイプEBCDICというデータ接続の上にデータ転送があります。 (正しいパラメタを確実にするのは、ユーザの責任です。)
NList (NLST) - This command causes a directory listing to be sent
from server to user site. The pathname should specify a directory
and the server will return a stream of names of files and no other
information. The data will be transferred in ASCII or EBCDIC type
over the data connection as valid pathname strings separated by
NList(NLST)--このコマンドはサーバからユーザの現場に送るためにリストアップされているディレクトリを引き起こします。 パス名はディレクトリを指定するべきです、そして、サーバはファイルの名前にもかかわらず、他の情報がないストリームを返すでしょう。 ASCIIでデータを移すだろうか、またはEBCDICは有効なパス名ストリングとしての接続が分離したデータの上でタイプします。
McKenzie [Page 22] RFC 454 File Transfer Protocol July 1972
マッケンジー[22ページ]RFC454ファイル転送プロトコル1972年7月
CRLF. This command will allow automatic copying of an entire
directory when used with the appropriate transfer commands.
CRLF。 適切な転送命令と共に使用されると、このコマンドは全ディレクトリの自動コピーを許すでしょう。
Status (STAT) - This command shall cause a status response to be
sent over the TELNET connection in form of a reply. The command
may be sent during a file transfer (preceded by a TELNET SYNC) in
which case the server will respond with the status of the opera-
tion in progress, or it may be sent between file transfers. In
the latter case 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 a partial pathname is given,
the server may respond with a list of file names or attributes
associated with that specification. If no argument is given, the
server should return general status information about the server
FTP process. This should include current values of all transfer
parameters and the status of connections.
状態(STAT)--このコマンドで、回答の形におけるTELNET接続の上に状態応答を送るでしょう。 オペラtionの状態が進行していた状態でサーバがどのケースを反応させるかでファイル転送の間、コマンドを送るかもしれませんか(TELNET SYNCによって先行されています)、またはファイル転送の間にそれを送るかもしれません。 後者の場合では、コマンドはパス名などの議論分野を持っているかもしれません。 議論がパス名であるなら、TELNET接続のときにASCIIでデータを移すものとするのを除いて、コマンドは「リスト」コマンドに類似しています。 部分的なパス名を与えるなら、サーバはその仕様に関連しているファイル名か属性のリストで反応するかもしれません。 議論を全く与えないなら、サーバはサーバFTPプロセスの一般的な状態情報を返すべきです。 これは接続のすべての転送パラメタと状態の現行価値を含むべきです。
Help (HELP) - This command shall cause the server to send helpful
information regarding its implementation status over the TELNET
connection to the user. The command may take an argument (e.g.
any command name) and return more specific information as a
response. The reply is type 100, general system status. It is
suggested that HELP be allowed before entering a USER command.
助けてください(ヘルプ)--このコマンドで、サーバはユーザとのTELNET接続の上に実装状態に関する役立つ情報を送るものとします。 コマンドは、主張(例えばどんなコマンド名も)を取って、応答として、より特定の情報を返すかもしれません。 回答はタイプ100、一般的なシステム状態です。 USERコマンドを入力する前にヘルプが許容されていることが提案されます。
Mail File (MLFL) - The intent of this command is to enable a user
site to mail data (in form of a file) to another user at the
server site. It should be noted that the files to be mailed are
transmitted via the data connection in ASCII or EBCDIC type. (It
is the user's responsibility to ensure that the type is correct.)
These files should be appended to the destination user's mail by
the server in accordance with serving HOST mail conventions. The
mail may be marked as sent from the particular using HOST and the
user specified by the 'USER' command. The argument field may con-
tain one or more system or NIC idents (it is recommended that mul-
tiple ident be allowed so the same mail can easily be sent to
several users), or it may be empty. If the argument field is
empty or blank (one or more spaces), then the mail is destined for
a printer or other designated place for site mail. A NIC ident
refers to the standard identification described in the NIC Direc-
tory of Network Participants. A serving host may keep a table
mapping NIC indents into system idents, although NIC idents are
not required in the implementation. A system ident is the user's
normal identification at the serving host. The use of system
idents would allow a network user to send mail to other users who
do not have NIC identification but whose system ident is known.
File(MLFL)に郵送してください--このコマンドの意図はユーザの現場がデータ(ファイルの形の)をサーバサイトの別のユーザに郵送するのを可能にすることです。 郵送されるファイルがASCIIにおけるデータ接続で送られることに注意されるべきであるか、またはEBCDICはタイプします。 (タイプが確実に正しくなるようにするのは、ユーザの責任です。) メールコンベンションにHOSTに役立つのに応じて、サーバは目的地ユーザのメールにこれらのファイルを追加するべきです。 メールは'USER'コマンドで指定された特定の使用HOSTとユーザから送るようにマークされるかもしれません。 議論分野がより多くのtain1システムかNIC identsをだますかもしれませんか(mul- tiple identが容易に同じメールを数人のユーザに送ることができるように許容されているのは、お勧めです)、またはそれは空であるかもしれません。 議論分野が人影がないか、または空白であるなら(1つ以上の空間)、メールはサイトメールのためのプリンタか他の集合場所に運命づけられています。 NIC identはNetwork ParticipantsのNIC Direc- toryで説明された標準の識別について言及します。 給仕のホストはテーブルにNICインデントをシステムidentsに写像させ続けるかもしれません、NIC identsが実装では必要ではありませんが。 システムidentは給仕のホストでのユーザの通常の識別です。 システムidentsの使用で、ネットワーク利用者はNIC識別を持っていませんが、システムidentが知られている他のユーザにメールを送ることができるでしょう。
McKenzie [Page 23] RFC 454 File Transfer Protocol July 1972
マッケンジー[23ページ]RFC454ファイル転送プロトコル1972年7月
Mail (MAIL) - This command allows a user to send mail that is not
in a file over the TELNET connection. The argument field may con-
tain one or more system or NIC idents, or it may be empty. The
idents are defined as above for the MLFL command. After the
'MAIL' command is received, the server is to treat the following
lines as text of the mail sent by the user. The mail text is to
be terminated by a line containing only a single period, that is,
the character sequence ".CRLF" in a new line. It is suggested
that a modest volume of mail service should be free; i.e., it may
be entered before a USER command.
メール(メール)--このコマンドで、ユーザはTELNET接続の上にファイルにないメールを送ることができます。 議論分野がより多くのtain1システムかNIC identsをだますかもしれませんか、またはそれは空であるかもしれません。 identsはMLFLコマンドのために同じくらい上で定義されます。 'メール'コマンドが受け取られていた後に、サーバはユーザによって送られたメールの原本として以下の系列を扱うことです。 メールテキストは復帰改行にすなわち、ただ一つの期間だけ、キャラクタシーケンス".CRLF"を含む系列によって終えられることです。 穏やかなメールサービスのボリュームが無料であるべきであると示唆されます。 すなわち、それはUSERコマンドの前に入られるかもしれません。
IV.A.4 Miscellaneous Commands
IV.A.4の種々雑多なコマンド
NoOP (NOOP) - This command does not affect any parameters or pre-
viously entered command. The server simply sends a no-op reply.
NoOP(NOOP)--このコマンドは少しのパラメタやプレviouslyの入力されたコマンドにも影響しません。 サーバは単にオプアートがない回答を送ります。
Quote (QUOT) - This command allows the user to talk directly to
the FTP-server. After parsing this command, the user-FTP process
will pass without examination all succeeding liners until the NQUO
command is received. Between these two commands the server will
respond appropriately to his implementation and the user's
requests.
(QUOT)を引用してください--ユーザはこのコマンドで直接FTPサーバと話すことができます。このコマンドを分析した後に、NQUOコマンドが受け取られているまで、ユーザFTPプロセスは試験なしで続くすべてのライナーを通過するでしょう。 これらの2つのコマンドの間では、サーバは適切に彼の実装とユーザの要求に応じるでしょう。
NoQuote (NQUO) - This command returns the user and server
processes to normal interactive mode. Both QUOT and NQUO have
reply codes to be sent by th server process to the user process to
ensure agreement on the current mode.
NoQuote(NQUO)--このコマンドはユーザとサーバプロセスを正常な会話型に返します。 QUOTとNQUOの両方には送られる回答コードがある、現在のモードの協定を確実にするユーザ・プロセスへのサーバ第プロセス。
The quote commands provide a convenient method of testing server- implemented experimental commands. The names of the latter should begin with an X, and can be listed in the system HELP reply. It should be noted that the official command set is expandable; sugges- tions should go first to Alexander A. McKenzie (BBN).
引用コマンドは実験的なコマンドであると実装された便利な検査手技サーバを提供します。 後者の名前は、Xと共に始まるべきであり、システムヘルプ回答で記載できます。 公式のコマンドセットが拡張可能であることに注意されるべきです。 sugges- tionsは最初に、アレクサンダー・A.マッケンジー(BBN)のものになるはずです。
IV.B FTP Replies
IV.B FTP回答
The server sends FTP replies over the TELNET connection in response to user FTP commands. The FTP replies constitute the acknowledgment or completion code (including errors). The FTP-server replies are formatted for human or program interpretation. Single line replies consist of a leading three-digit numeric code followed by a space, followed by a one-line text explanation of the code. For replies that contain several lines of text, the first line will have a lead- ing three-digit numeric code followed immediately by the ASCII char- acter "-" (Hyphen, Code 55 (octal)) and possibly some text. All succeeding continuation lines except the last are constrained not to begin with three digits; the last line must repeat the numeric code of the first line and be followed immediately by a space.
サーバはユーザFTPコマンドに対応してTELNET接続の上にFTP回答を送ります。 FTP回答は承認か完了コードを構成します(誤りを含んでいて)。 FTPサーバ回答は人間かプログラム解釈のためにフォーマットされます。 単線回答はコードの1系列のテキスト説明があとに続いたスペースがあとに続いた主な3ケタの数字コードから成ります。 テキストのいくつかの系列を含む回答のために、最初の系列で、すぐASCII炭のacter「-」(ハイフン、コード55(8進))とことによると何らかのテキストがリードのingの3ケタの数字コードのあとに続くでしょう。 最終以外の続くすべての継続行が3ケタで始まらないのが抑制されます。 最終ラインを最初の系列の数字コードを繰り返して、すぐスペースはあとに続かなければなりません。
McKenzie [Page 24] RFC 454 File Transfer Protocol July 1972
マッケンジー[24ページ]RFC454ファイル転送プロトコル1972年7月
For example:
例えば:
100-First Line
Continuation Line
Another Line
100 Last Line
最初に100は別の線100最終ラインに継続行を裏打ちします。
The numeric codes are assigned by groups and for ease of interpreta- tion by programs in a manner consistent with other protocols such as the RJE protocol. The three digits of the code are to be interpreted as follows:
数字コードはグループとRJEプロトコルなどの他のプロトコルと一致した方法によるプログラムによるinterpreta- tionの容易さのために割り当てられます。 コードの3ケタは以下の通り解釈されることです:
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 acknowledgment.
000 これらの回答は、純粋に有益であり、どちらも積極的で否定的な承認を構成しません。
1xx Informative replies to status inquiries. These constitute a
positive acknowledgment to the status command.
1xx Informativeは資産調査に答えます。 これらは状態コマンドに肯定応答を構成します。
2xx Positive acknowledgment of previous command or other success-
ful action.
前のコマンドか他の成功ful動作の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 correctly fulfilling it.
4xx Unsuccessfulは返答します。 要求は正しく指定されますが、サーバはそれを正しく実現させるのを失敗しています。
5xx Incorrect or illegal command. The command or its parameters
were invalid or incomplete from a syntactic viewpoint, or the
command is inconsistent with a previous command. The command
in question has been completely ignored.
5xx Incorrectか不正コマンド。 コマンドかそのパラメタが、構文の観点から無効であるか、不完全でした、またはコマンドは前のコマンドに反しています。 問題のコマンドは完全に無視されました。
6xx-9xx Reserved for future expansion.
今後の拡張のための6xx-9xx Reserved。
McKenzie [Page 25] RFC 454 File Transfer Protocol July 1972
マッケンジー[25ページ]RFC454ファイル転送プロトコル1972年7月
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 results.
x6x RJEは結果になります。
x7x-x9x Reserved for future expansion.
今後の拡張のために予約されたx7x-x9x。
c) The final digit specifies a particular message type. Since the
code is designed for an automation 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 delimited by a numeric code and CRLF (or group
of text lines bounded by coded lines) that is sent by the server
is intended to be a complete reply message. It should be noted
that the text of replies is intended for a human user. Only the
reply codes and in some instances the first line of text are
intended for programs.
サーバによって送られる数字コードとCRLF(テキスト系列のグループはコード化された系列でバウンドした)によって区切られたそれぞれのTELNET系列は完全な応答メッセージであることを意図します。 回答のテキストが人間のユーザのために意図することに注意されるべきです。 回答コードだけとある場合に最初のテキスト行はプログラムのために意図します。
The assigned reply codes relating to FTP are:
FTPに関連する割り当てられた回答コードは以下の通りです。
000 General information message (site, time of day, etc.). 010 Message from system operator. 030 Server availability information. 050 FTP commentary or user information. 100 System status reply. 110 System busy doing... 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. 233 User is "logged out". Parameters reinitialized.
000一般情報メッセージ(サイト、時刻など)。 システムオペレーターからの010メッセージ。 030 サーバ有用性情報。 050 FTP論評かユーザー情報。 100システム状態回答。 110 システムの忙しい… 150は状態回答151ディレクトリリスト回答をファイルします。 200 持続コマンドは正しく受信されました。 201 ABORTは要求された通り活動を終えました。 202は無視された要求、進行中のどんな活動も中止しません。 230ユーザは「ログインされます」。 続くかもしれません。 231ユーザは「ログアウトされます」。 サービスは終わりました。 232 転送であるときに、ログアウトコマンドが注意されて、して、完成するでしょう。 233ユーザは「ログアウトされます」。 パラメタは再初期化されました。
McKenzie [Page 26] RFC 454 File Transfer Protocol July 1972
マッケンジー[26ページ]RFC454ファイル転送プロトコル1972年7月
250 FTP file transfer started correctly. 251 FTP Restart-marker reply.
250FTPファイル転送は正しく始まりました。 251FTP Restart-マーカー回答。
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 '=')
テキストは以下の通りです。 マークyyyyはyyyyがユーザのデータ・ストリームマーカー(あなたのもの)であるmmmmと等しいです、そして、mmmmはサーバの同等なマーカー(私のもの)です。(マーカーと'='の間の空間に注意します)
252 FTP transfer completed correctly. 253 Rename completed. 254 Delete completed. 255 FTP server data socket reply
252 正しく終了するFTP転送。 253 完成されて、改名します。 254 完成されて、削除します。 255FTPサーバデータソケット回答
Text is: SOCK nnnn
where nnnn is a decimal integer representing
the server socket for data connection
テキストは以下の通りです。 nnnnがデータ接続のためのサーバソケットを表す10進整数であるSOCK nnnn
256 Mail completed.
300 Connection greeting message, awaiting input.
301 Current command incompleted (no CRLF for long time).
330 Enter password
331 Enter account (if account required as part of login
sequence).
350 Enter mail, terminate by a line with only a '.'
400 This service not implemented.
401 This service not accepting user now, goodbye.
430 Log-on time or tries exceeded, goodbye.
431 Log-on unsuccessful. Usre and/or password invalid.
432 User not valid for this service.
433 Cannot transfer files without valid account. Enter account.
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.
454 FTP: Cannot connect to your data socket.
455 FTP: File system error not covered by other reply codes.
456 FTP: Name duplication rename failed.
457 FTP: Transfer parameters in error.
500 Last command line completely unrecognized.
501 Syntax of last command is incorrect.
502 Last command incomplete, parameters missing.
123456789012345678901234567890123456789012345678901234567890123456789012
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).
完成した256メール。 300 入力を待つ接続あいさつメッセージ。 301 現在のコマンドは(長い時間のCRLFがありません)を不完成しました。 330はパスワード331Enterアカウントに入ります(アカウントがログイン系列の一部として必要であるなら)。 '350はメールを入力して、'.'サービスが実装しなかった400Thisだけと共に系列で終わってください。 401 現在ユーザを受け入れないこのサービス、さようなら。 430 時間かトライが超えていたログオン、さようなら。 431は失敗していた状態でログオンします。 Usre、そして/または、パスワード病人。 このサービスには、有効でない432ユーザ。 433は有効なアカウントなしでファイルを移すことができません。 勘定を記帳してください。 434 外では、ログアウトしますオペレータ動作で無理矢理の。 サイトに電話をしてください。 435 外では、ログアウトしますシステム問題で無理矢理の。 436はさようならを停止する修理します。 450FTP: ファイルが見つからない。 451FTP: アクセス拒否をファイルしてください。 452FTP: 不完全なファイル転送データ接続は閉じました。 453FTP: ファイル転送の不完全で、不十分な集積スペース。 454FTP: あなたのデータソケットに接続できません。 455FTP: 他の回答コードでカバーされなかったシステム誤りをファイルしてください。 456FTP: 複製が改名する名前は失敗しました。 457FTP: パラメタを間違って移してください。 500はコマンドラインを持続します。完全に認識されていません。 持続コマンドの501構文は不正確です。 パラメタが消えて、502は不完全な状態でコマンドが続きます。 123456789012345678901234567890123456789012345678901234567890123456789012 503は最後に無効(無視される)の、そして、不法なパラメタ組み合わせを命令します。 504はコマンド病人、このとき可能でない動作が続きます。 505 持続コマンドは不法に前のコマンドと衝突します。
McKenzie [Page 27] RFC 454 File Transfer Protocol July 1972
マッケンジー[27ページ]RFC454ファイル転送プロトコル1972年7月
506 Requested action not implemented by the server. 507 Catchall error reply. 550 Bad pathname specification (e.g., syntax error).
506は、動作が、サーバで. 507Catchallがエラー応答であると実装しなかったよう要求しました。 550 悪いパス名仕様(例えば、構文エラー)。
V. DECLARATIVE SPECIFICATIONS
V。 宣言的な仕様
In order to make FTP workable without needless error messages, the following minimum implementation is required for servers:
FTPを不必要なエラーメッセージなしで実行可能にして、以下の最小の実装がサーバに必要です:
TYPE -- ASCII (with 8-bit bytes)
MODE -- Stream
STRUCTURE -- File
Record (with ASCII type and CRLF for EOR)
FORM -- Unformatted
COMMANDS -- USER, BYE, SOCK
TYPE, BYTE, MODE, STRU, FORM
for the default values
RETR, STOR
NOOP
TYPE--ASCII(8ビットのバイトがある)MODE--ストリームSTRUCTURE--ファイルRecord(EORのためのASCIIタイプとCRLFと)FORM--Unformatted COMMANDS--USER、BYE、SOCK TYPE、BYTE、MODE、STRU、デフォルトのためのFORMはRETRを評価します、STOR NOOP
The initial default values for transfer parameters are:
転送パラメタのための初期のデフォルト値は以下の通りです。
TYPE -- ASCII
BYTE -- 8
MODE -- Stream
STRU -- File
FORM -- Unformatted
タイプ--ASCIIバイト--8モード--ストリームSTRU--ファイルフォーム--Unformatted
V.A Connections
V. コネクションズ
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. Servers may specify that interaction over the TEL- NET connections be line-at-a-time with local echo. The server is not obliged to provide remote echo and may ignore TELNET control charac- ters; he should not, however, return error response to the latter. All editing of command lines similarly must be local. The TELNET connections shall be closed by the user site upon completion of use and receipt of the last server reply.
サーバサイトのサーバFTPプロセスはサーバ-TELNETを通してSocket3で「聴かれるものとします」。 ユーザの現場のユーザかユーザFTPプロセスが、アルパネットの標準の初期の接続プロトコル(ICP)をサーバソケット3に実行しながら、ユーザ-TELNETを通して全二重TELNET接続を開始するものとします。 サーバは、TEL NET接続の上の相互作用が一度にローカルエコーがある系列であると指定するかもしれません。 サーバは、リモートエコーを提供するのは強いられないで、TELNETコントロールcharac- tersを無視するかもしれません。 しかしながら、彼は後者への誤り応答を返すべきではありません。 コマンドラインのすべての編集が同様に地方でなければなりません。 TELNET接続は使用の完成と最後のサーバ回答の受領に関するユーザの現場によって閉店させられるものとします。
The user site must "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
ユーザの現場は指定されたデータソケットかソケットで「聴かれなければならない」(aが発信します、そして、aはソケットを受けます)。 サーバサイトは、指定されたデータソケットとバイトサイズを使用することでデータ接続を開始するものとします。 接続とデータソケットが使用したデータの方向はそうでしょう。
McKenzie [Page 28] RFC 454 File Transfer Protocol July 1972
マッケンジー[28ページ]RFC454ファイル転送プロトコル1972年7月
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 ensue the security of data transfer. This can be done at any time prior to the first transfer of data over a data connection. It should be emphasized that the user-FTP should not wait for a 255 (server data socket) reply before doing the "listen", since there is no guarantee that the reply will arrive before the user site receives the initiating RFC. The security check can be done when the reply arrives and the data connection closed if it was made to a socket other than the one specified.
FTP軍管区で、断固としています。 サーバは、ユーザが続くことができるようにサーバデータソケットを示しながら、ユーザに返信するものとします。データ転送の保証。 データ接続の上の最初のデータ転送の前にいつでも、これができます。 ユーザFTPがして、ユーザの現場が開始しているRFCを受ける前にそこ以来の「聴いてください」が保証にならない回答が到着するという前の255(サーバデータソケット)回答を待つべきでないと強調されるべきです。 回答が到着するとき、セキュリティチェックができました、そして、それをもの以外のソケットにしたなら閉店させたデータ接続は指定しました。
The data connection shall be closed by the server site under the con- ditions described in Section III.A. If the server wishes to close the connection in modes where that is not required, it is recommended that the close be sent immediately after the file transfer is com- pleted rather than after a new transfer command is received, because the user or server may have to test the state of the socket before doing a "listen" or "init". The server should in general send a reply before closing the data connection to avoid problems at the user end, though, for reasons stated above, the user-FTP should not wait for the reply before doing his close.
データ接続はditionsがサーバがそれが必要でなく、ファイル転送がcom- pletedである新しい転送命令が受け取られていた後よりむしろ直後閉鎖を送るのがお勧めであるモードにおける接続を終えたがっているセクションIII.A. Ifで説明したまやかしの下のサーバサイトによって閉店させられるものとします、「聴いてください」か「イニット」をする前にユーザかサーバがソケットの状態をテストしなければならないかもしれないので。 ユーザ終わりに問題を避けるためにデータ接続を終える前に一般に、サーバは返信するべきです、彼の閉鎖をする前に、ユーザFTPが上に述べられた理由で回答を待つべきではありませんが。
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で説明されます。 コマンド構文はここで指定されます。
The commands begin with a command code followed by an argument field. The command codes are four or less ASCII alphabetic characters. Upper and lower case alphabetic characters are to be treated identi- cally. Thus any of the following may represent the retrieve command:
議論分野がコマンドコードのあとに続いていて、コマンドは始まります。 コマンドコードは4つ以下のASCII英字です。 大文字と小文字英字は扱われたidenti警察署であることです。 したがって、以下のどれかは検索コマンドを表すかもしれません:
RETR Retr retr ReTr rETr
RETR Retr retr ReTr rETr
This also applies to any symbols representing parameters values, such as A or a for ASCII TYPE. The command codes and the argument fields are separated by one or more spaces.
また、これはASCII TYPEのためのAかaなどのパラメタ値を表すどんなシンボルにも適用されます。 コマンドコードと議論野原は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 syn- tax 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で続きました)。 syn税の以下のセクションで、議論分野のすべてのキャラクタがASCII文字であると強調されるべきです。 したがって、10進整数は、ASCIIが10進整数を表したことを意味するものとします。
McKenzie [Page 29] RFC 454 File Transfer Protocol July 1972
マッケンジー[29ページ]RFC454ファイル転送プロトコル1972年7月
The following are all the currently defined FTP commands:
↓これはすべて、現在定義されたFTPコマンドです:
USER <username> CRLF
ユーザ<ユーザ名>CRLF
PASS <password> CRLF
<パスワード>CRLFを渡してください。
ACCT <acctno> CRLF
ACCT<acctno>CRLF
REIN CRLF
たづなCRLF
BYE CRLF
さようならCRLF
BYTE <byte size> CRLF
BYTE<バイトサイズ>CRLF
SOCK <HOST-socket> CRLF
ソックス<ホストソケット>CRLF
LSTN <direction> CRLF
LSTN<方向>CRLF
TYPE <type code> CRLF
TYPE<タイプコード>CRLF
FORM <form code> CRLF
FORM<フォームコード>CRLF
STRU <structure code> CRLF
STRU<構造コード>CRLF
MODE <mode code> CRLF
MODE<モードコード>CRLF
RETR <pathname> CRLF
RETR<パス名>CRLF
STOR <pathname> CRLF
STOR<パス名>CRLF
APPE <pathname> CRLF
APPE<パス名>CRLF
ALLO <decimal integer> CRLF
ALLOの<の10進整数>CRLF
REST <marker> CRLF
<マーカー>CRLFを休ませてください。
RNFR <pathname> CRLF
RNFR<パス名>CRLF
RNTO <pathname> CRLF
RNTO<パス名>CRLF
ABOR CRLF
ABOR CRLF
DELE <pathname> CRLF
DELE<パス名>CRLF
LIST <pathname> CRLF
リスト<パス名>CRLF
NLST <pathname> CRLF
NLST<パス名>CRLF
McKenzie [Page 30] RFC 454 File Transfer Protocol July 1972
マッケンジー[30ページ]RFC454ファイル転送プロトコル1972年7月
STAT <pathname> CRLF
スタット<パス名>CRLF
HELP <string> CRLF
<ストリング>CRLFを助けてください。
MLFL <users> CRLF
MLFL<ユーザ>CRLF
MAIL <users> CRLF
メール<ユーザ>CRLF
NOOP CRLF
NOOP CRLF
QUOT CRLF
QUOT CRLF
NQUO CRLF
NQUO CRLF
The syntax of the above argument fields (using BNF notation where applicable) is:
上の議論分野(適切であるところでBNF記法を使用する)の構文は以下の通りです。
<username> ::= <string>
<ユーザ名>:、:= <ストリング>。
<password> ::= <string>
<パスワード>:、:= <ストリング>。
<acctno> ::= <string>
<acctno>:、:= <ストリング>。
<string> ::= <empty>/<char>/<char><string>
<ストリング>:、:= <の空の>/<炭の>/<炭の><ストリング>。
<char> ::= any of the 128 ASCII characters except CR and LF.
<炭の>:、:= CRとLF以外の128人のASCII文字のいずれも。
<marker> ::= <pr string>
<マーカー>:、:= <prストリング>。
<pr string> ::= <empty>/<pr char>/<pr char> <pr string>
<prストリング>:、:= <の空の>/<pr炭の>/<pr炭の><prストリング>。
<pr char> ::= any ASCII code 33 through 126
<pr炭の>:、:= どんなASCIIコード33〜126
<byte size> ::= any decimal integer 1 through 255.
<バイトサイズ>:、:= どんな10進整数1〜255。
<HOST-socket> ::= <socket>/HOST number>,<socket>
<ホストソケット>:、:= <ソケット>/HOST番号>、<ソケット>。
<HOST number> ::= a decimal integer specifying an ARPANET HOST
<HOST番号>:、:= ARPANET HOSTを指定する10進整数
<socket> ::= decimal integer between 0 and (2**32)-1
<ソケット>:、:= (2**32) 0と-1の間の10進整数
<direction> ::= S/R
<方向>:、:= S/R
<form code> ::= U/P
<フォームコード>:、:= U/P
<type code> ::= A/E/I/L
<タイプは>をコード化します:、:= A/E/I/L
<structure code> ::= F/R
<構造コード>:、:= F/R
McKenzie [Page 31] RFC 454 File Transfer Protocol July 1972
マッケンジー[31ページ]RFC454ファイル転送プロトコル1972年7月
<mode code> ::= S/B/T/H
<モードコード>:、:= S/B/T/H
<pathname> ::= <string>
<パス名>:、:= <ストリング>。
<decimal integer> ::= <digit>/<digit><decimal integer>
<の10進整数>:、:= <の>/<のケタの>の<の10進ケタ整数>。
<digit> ::= 0|1|2|3|4|5|6|7|8|9
<ケタ>:、:= 0|1|2|3|4|5|6|7|8|9
<empty> ::= the null string (specifies use the default).
<の空の>:、:= ヌルストリング、(使用を指定する、デフォルト)
<users> ::= <user>|<user,<users>
<ユーザ>:、:= <ユーザ>|<ユーザ、<ユーザ>。
<user> ::= <empty>|<NIC ident>|<sys ident>
<ユーザ>:、:= <空です。>|<NIC ident>|<sys ident>。
<NIC ident> ::= <string>
<NIC ident>:、:= <ストリング>。
<sys ident> ::= <string>
<sys ident>:、:= <ストリング>。
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 or 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番目のクラスの回答はいつでも到着するかもしれない情報的、そして、自然発生的な回答です。 これらの回答は自然発生的であるとして以下に記載されています。
McKenzie [Page 32] RFC 454 File Transfer Protocol July 1972
マッケンジー[32ページ]RFC454ファイル転送プロトコル1972年7月
COMMAND-REPLY CORRESPONDENCE TABLE
コマンド回答通信テーブル
COMMAND SUCCESS FAIL ------- ------- ---- USER 230,330 430-432,500-505,507 PASS 230,331 430-432,500-507 ACCT 230 430-432,500-507 REIN 232,233 401,436,500-507 Secondary Reply 300 BYE 231,232 430-432,500-505,507 BYTE 200,331 500-507 SOCK 200,331 500-505,507 LSTN 255,331 500-507 TYPE 200,331 500-507 FORM 200,331 500-507 STRU 200,331 500-507 MODE 200,331 500-507
コマンド成功は失敗します。------- ------- ---- ユーザ23万330 430-432,500-505,507パス23万331 430-432,500-507ACCT230 430-432,500-507たづな232,233 401,436,500-507セカンダリ回答300不戦勝231,232 430-432,500-505,507バイト200,331 500-507ソックス200,331 500-505,507LSTN255,331 500-507タイプ20万331 500-507フォーム20万331 500-507STRU200,331 500-507モード200,331 500-507
RETR 250,331 433,450,451,454,455,500-505,507,550
Secondary Reply 252 452
STOR 250,331 433,451,454,455,457,500-505,507,550
Secondary Reply 252 452,453
APPE 250,331 433,451,454,455,457,500-507,550
Secondary Reply 252 452,453
ALLO 200,331 500-507
REST 200,331 500-507
RNFR 200,331 433,450,451,455,500-507,550
RNTO 253,331 433,450,451,455,456,500-505,507,550
ABOR 201,202,331 500-507
DELE 254,331 433,450,451,455,500-507,550
LIST 250,331 433,450,451,454,455,457,500-507,550
Secondary Reply 252 452
NLST 250,331 433,450,451,454,455,457,500-507
Secondary Reply 252 452
STAT 100,110,150, 450,451,454,455,500-507,550
151,331
HELP 000,030,050, 500-507
331
MLFL 250,331 433,450,451,454,455,457,500-507
Secondary Reply 252 452,453
MAIL 331,350 433,450,451,455,500-507
Secondary Reply 256
NOOP 200 500-505,507
QUOT 200,331 500-507
NQUO 200 500-505,507
RETR250,331 433,450,451,454,455,500-505,507,550のセカンダリ回答252 452STOR250,331 433,451,454,455,457,500-505,507,550のセカンダリ回答252 45万2453APPE250,331 433,451,454,455,457,500-507,550のセカンダリ回答252 45万2453異200,331 500-507休息200,331 500-507RNFR200,331 433,450,451,455,500-507,550RNTO253,331 433,450,451,455,456,500-505,507,550ABOR201,202,331 500-507DELE254,331 433,450,451,455,500-507; 550は250,331 433,450,451,454,455,457,500-507,550 セカンダリ回答252 452NLST250,331 433,450,451,454,455,457,500-507のセカンダリ回答252 452スタット100,110,150を記載します、500-507 331のMLFL250,331 433,450,451,454,455,457,500-507のセカンダリ回答252 45万2453メール331,350 433,450,451,455,500-507セカンダリ回答256NOOP200 500-505,507QUOT20万331 500-507NQUO200 500-505,507、450,451,454,455,500-507,550 151,331支援000,030,050
Spontaneous 0xx,300,301 400,401,434-436 Replies 251,255
自然発生的な0xx、300,301 400,401,434-436の回答251,255
McKenzie [Page 33] RFC 454 File Transfer Protocol July 1972
マッケンジー[33ページ]RFC454ファイル転送プロトコル1972年7月
V.D Typical FTP Scenarios
V.のD典型的なFTPシナリオ
1. TIP User wanting to transfer file from HOST X to local printer:
1. 移したがっているTIP UserがHOST 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:
b) 以下のコマンドと回答を交換します:
TIP HOST X
--- ------
チップホスト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.
以下に注意してください。 TIPユーザはライン・モードでいるべきです。
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 mediat-
ing user-FTP process. The following may be a typical scenario.
The user-FTP prompts are shown in parentheses, '---->' represents
commands from HOST U to HOST S, and '<----' represents replies
from HOST S to HOST U.
一般に、ユーザはmediat- ingユーザFTPプロセスを通してサーバに伝えるでしょう。 ↓これは典型的なシナリオであるかもしれません。 'ユーザFTPプロンプトは括弧に示されます'----'>'はHOST S、およびHOST Uから'<'までのコマンドを表します。----'HOST SからHOST Uまでの回答を表します'。
McKenzie [Page 34] RFC 454 File Transfer Protocol July 1972
マッケンジー[34ページ]RFC454ファイル転送プロトコル1972年7月
Local Commands by User Action Involved ---------------------- ---------------
動作がかかわったユーザによるローカルのコマンド---------------------- ---------------
ftp (host) multics CR ICP to HOST S, socket 3,
establishing TELNET connections.
username Doe CR USER Doe CRLF ---->
<---- 330 password CRLF
password mumble CR PASS mumble CRLF ---->
<---- 230 Doe logged in. CRLF
retrieve (local type) ASCII CR
(local pathname) test 1 CR User-FTP opens local file in ASCII.
(for.pathname) test.p11 CR RETR test.p11 CRLF
<---- 255 SOCK 1233 CRLF
Server makes data connection to (U+4).
<---- 250 File transfer starts CRLF
<---- 252 File transfer complete CRLF
type ImageCR TYPE I CRLF ---->
<---- 200 Command OK CRLF
byte 36CR BYTE 36 CRLF ---->
<---- 200 Command OK CRLF
store (local type) image CR
(local pathname) file dump CR User-FTP opens local file in Image.
(for.pathname) >udd>cn>fd CR STOR >udd>cn>fd CRLF ---->
<---- 451 Access denied CRLF
terminate <---- 231 Doe logged out CRLF
Server closes all connections.
HOST Sのftp(ホスト)multics CR ICP、TELNET接続ユーザ名ドウCR USERドウCRLFを設立するソケット3----><。---- 330パスワードCRLFパスワードもぐもぐCR PASSもぐもぐCRLF----><。---- 230 ドウはログインしました。 CRLFは(ローカルのタイプ)ASCII CRの(ローカルのパス名)テスト1つのCR User-FTPを検索します。ASCIIにおけるローカルファイルを開きます。 (for.pathname) test.p11 CR RETR test.p11 CRLF<。---- 255 SOCK1233CRLF Serverは(U+4)との接続にデータを作ります。 <、-、-、-- 250ファイル転送はCRLF<を始動します。---- 252 ファイル転送の完全なCRLFはImageCR TYPE I CRLFをタイプします。----><。---- 200 コマンドOK CRLFバイト36CRバイト36CRLF----><。---- 200コマンドOK CRLF店(ローカルのタイプ)イメージCR(ローカルのパス名)ファイルダンプCR User-FTPはImageのローカルファイルを開きます。 (for.pathname) >udd>cn>fd CR STOR>udd>cn>fd CRLF----><。---- 451 アクセス拒否CRLFは<を終えます。---- 231 ドウはCRLF Server閉鎖からすべての接続を登録しました。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie 03/00 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via Genie03/00によるオンラインRFCアーカイブへの]
McKenzie [Page 35]
マッケンジー[35ページ]
一覧
スポンサーリンク
