RFC607 日本語訳
0607 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg. January 1974. (Format: TXT=8652 bytes) (Obsoleted by RFC0624) (Updated by RFC0614) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Request for Comments: 607 Mark Krilanovich NIC # 21255 George Gregg references: RFC #542 UCSB Jan 1974
コメントのために以下を要求してください。 607 マークKrilanovich NIC#21255ジョージグレグ参照: RFC#542UCSB1974年1月
Comments on the File Transfer Protocol
ファイル転送プロトコルのコメント
There are several aspects of the File Transfer Protocol that constitute serious drawbacks. Some of these are quite basic in nature, and imply substantial design changes; these will be discussed in a later RFC. Others could be remedied with very little effort, and this should be done as soon as possible.
重大な欠点を構成するFile Transferプロトコルのいくつかの局面があります。 これらの或るものは、現実にかなり基本的であり、かなりの設計変更を含意します。 後のRFCでこれらについて議論するでしょう。 非常に小さい取り組みで他のものを治すことができました、そして、できるだけ早く、これをするべきです。
Following is a list of those problems that can be easily solved, together with their proposed solutions:
以下に、それらの提案されたソリューションと共に容易に解決できるそれらの問題のリストがあります:
1. Once a server has been told to be "passive" with regard to establishment of data connections, there is no way for the user to make him "active" again. SOLUTION: define a new command, with a command verb of "ACTV", to mean that the server is to issue a CONNECT rather than a LISTEN on the data socket. If the server is already "active", the command is a no op. "ACTV" is to have the same reply codes as "PASV".
1. サーバがデータ接続の設立に関して「受け身である」ようにいったん言われると、ユーザが再び「アクティブ」に彼を作る方法が全くありません。 ソリューション: 新しいコマンドを定義してください、"ACTV"のコマンド動詞でaがaよりむしろ接続する問題にはサーバがあることを意味するために、データソケットの上に聴いてください。 サーバが既に「アクティブである」なら、コマンドはノーです。オプアート。 "ACTV"には、"PASV"と同じ回答コードがあることになっています。
2. Design of an FTP server would be simpler if all command verbs were the same length, and design of an FTP user would be simpler if either all command verbs were the same length, or if multiple blanks were allowed following the verb. SOLUTION: replace the only three-letter verb, "BYE", with a four-letter one, such as "QUIT", and constrain future command verbs to be four letters long.
2. FTPサーバの設計はすべてのコマンド動詞が同じ長さであるなら、より簡単でしょうに、そして、動詞に従って、すべてのコマンド動詞が同じ長さであった、または複数の空白が許容されているなら、FTPユーザのデザインは、より簡単でしょうに。 ソリューション: 「さようなら」、4文字のもので、「やめてください」などのように唯一の3文字の動詞を取り替えてください、そして、長い間将来のコマンド動詞が4個の手紙であることを抑制してください。
3. The order of the handshaking elements following a file transfer command is left unspecified. After sending a STOR command, for example, a user process has no way of knowing which to wait for first, the "250 FILE TRANSFER STARTED" reply, or establishment of the data connection. SOLUTION: specify that the server is to send a "250" reply before attempting to establish the data connection. If it is desired to check if the user is logged in, if the file exists, or if the user is to be allowed access to the file, these checks must be made before any reply is sent. The text of the "250" reply would perhaps be more appropriate as "250 OPENING DATA CONNECTION", since it comes before actual data transfer begins. If the server wishes to send an error reply in the event that the data connection cannot be opened, it is to be sent in lieu of the "252 TRANSFER COMPLETE" reply.
3. ファイル転送命令に従うハンドシェイク要素の注文を不特定のままにします。 STORコマンドを送った後に、ユーザ・プロセスに、例えば、データ接続についてどれが最初にの待ち、「始められた250ファイル転送」に関して返答するか、そして、設立を知る方法が全くありません。 ソリューション: サーバがデータ接続を確立するのを試みる前に「250」回答を送ることであると指定してください。 ユーザがログインされるかどうかチェックすることをそれを望んでいるか、ファイルが存在しているか、またはファイルへのアクセスをユーザに許すつもりであるなら、どんな回答も送る前にこれらのチェックをしなければなりません。 実際前に来て以来の「250の初めのデータ接続」データ転送が始まるのに従って、「250」回答のテキストは恐らくより適切でしょう。 データ接続を開くことができないならサーバがエラー応答を送りたいなら、それは「252は完全な状態で移し」回答の代わりに送られることになっています。
4. Some hosts currently send an error reply on receipt of a command that is unimplemented because it is not needed (e.g., "ACCT" or "ALLO"). Even though the text of the reply indicates that the command has been ignored, it is obviously impossible for a user process to know that there is no real "error". SOLUTION: require that any server that does not support a particular command because it is not needed in that system must return a success reply.
4. ホストの中には現在それは必要でないので非実装されるコマンド(例えば、"ACCT"か「異」)を受け取り次第エラー応答を送る人もいます。 回答のテキストは、コマンドが無視されたのを示しますが、ユーザ・プロセスには、どんな本当の「誤り」もないのを知るのは明らかに不可能です。 ソリューション: それはそのシステムで必要でないので特定のコマンドをサポートしないどんなサーバも成功回答を返さなければならないのを必要であってください。
5. There is no specified maximum length of a TELNET line, user name, password, account, or pathname. It is true that every system implementing an FTP server likely has different maxima for its own parameters, but it is nearly impossible for the writer of an FTP user (which must converse with many FTP servers) to construct an indefinite length buffer. Typically some
5. TELNET系列、ユーザ名、パスワード、アカウント、またはパス名のどんな指定された最大の長さもありません。 FTPサーバを実装するあらゆるシステムがおそらくそれ自身のパラメタのための異なったmaximaを持っているのが、本当ですが、FTPユーザ(多くのFTPサーバと話さなければならない)の作家が無期長さのバッファを構成するのは、ほとんど不可能です。 通常いくつか
-1- arbitrary maximum must be chosen. SOLUTION: specify a maximum length for TELNET lines, user names, passwords, account numbers, and pathnames. This is to be done after conducting a poll of serving sites concerning their individual maxima.
-1 -任意の最大を選ばなければなりません。 ソリューション: TELNET系列、ユーザ名、パスワード、口座番号、およびパス名に最大の長さを指定してください。 それらの個々のmaximaに関して給仕サイトの投票を行った後に、これをすることになっています。
6. The notion of allowing continuation lines to start with arbitrary text solves a minor problem for a few server FTP implementers at the expense of creating a major problem for all user FTP implementers. The logic needed to decode a multi-line reply is unnecessarily complex, and made an order of magnitude more so by the fact that multi-line replies are allowed to be nested. SOLUTION: assign a unique (numeric) reply code, such as "009", to be used on all lines of a multi-line reply after the first.
6. すべてのユーザFTP implementersのために大した問題を作成することを犠牲にして継続行が任意のテキストから始まるのを許容するという概念はいくつかのサーバFTP implementersのための小さな問題を解決します。 マルチ系列回答を解読するのに必要である論理を、不必要に複雑であり、マルチ系列回答が入れ子にすることができるという事実は1桁よりそうにします。 ソリューション: ユニークな(数値)回答コードを割り当ててください、「9インチ、すべてで使用されるには、マルチ系列の台詞は1日以降、返答します」などのように。
7. Given that multi-line replies are allowed to be nested, the fact that the maximum allowed level of nesting is left unspecified creates a hardship for implementers of user FTPs. This hardship is somewhat easily solved on a machine that has hardware stacks, but not so for other machines. SOLUTION: specify a maximum level of nesting of multi-line replies.
7. マルチ系列回答が入れ子にすることができるなら、巣篭もりのレベルが許容された最大が不特定のままにされるという事実はユーザFTPのimplementersのために苦労を作成します。 この苦労は、他のマシンのためにいくらか容易にハードウェアスタックを持っているマシンの上で解決されていますが、したがって、解決されるというわけではありません。 ソリューション: 最大のレベルのマルチ系列回答の巣篭もりを指定してください。
8. In blocked mode, the protocol states that "all end-of-record markers (EOR) are explicit, including the final one." This prohibits sending data between the final end of record and the end of file, but does not specify what the receiver of data is to do if this rule is broken. That is, should the intervening data be discarded or treated as a new (final) record? SOLUTION: specify that if an end-of-file marker is not immediately preceded by an end-of-record marker, the intervening data is to be discarded.
8. 妨げられたモードで、「最終的なものを含んでいて、すべての記録のエンドマーカー(EOR)が明白です。」と、プロトコルは述べます。 これは、記録の最後の終わりとファイルの終りの間にデータを送るのを禁止しますが、この規則が壊れているなら、データの受信機が何をすることになっているかを指定しません。 すなわち、介入しているデータは、捨てられるべきですか、新しい(最終的な)記録として扱われるべきですか? ソリューション: 介入しているデータがファイルの終りマーカーがすぐに記録のエンドマーカーによって先行されていないなら、捨てられることであると指定してください。
A major complaint about the protocol concerns the fact that the writer of an FTP user process must handle a considerable number of special cases merely to determine whether or not the last command sent was successful. It is admitted that the protocol is well-defined in all the following areas, but it is important to realize that the characteristic "well-defined" is necessary, but not sufficient; for many reasons, it is very desirable to employ the simplest mechanism that satisfies all the needs. Following is a list of those drawbacks that unduly complicate the flow chart of an FTP user process:
プロトコルに関する主要な苦情は、FTPユーザ・プロセスの作家が多数の特別なケースを扱わなければならないという事実が、持続コマンドが発信したかどうかが、うまくいったことを単に決定するのが関係があります。 プロトコルが以下のすべての領域で明確であることが認められますが、独特の「明確」が必要ですが、十分でないとわかるのは重要です。 種々の理由で、すべての需要を満たす最も簡単なメカニズムを使うのは非常に望ましいです。 以下に、FTPユーザ・プロセスのフローチャートを過度に複雑にするそれらの欠点のリストがあります:
9. Different commands have different success reply codes. A successful "USER" command, for example, returns a "230" whereas a successful "BYTE" command returns a "200". The concept that success replies should have an even first digit and failure replies an odd first digit does not apply, as "100, means success for "STAT", and "402" means failure for "BYTE". SOLUTION: specify that any command must return a reply code beginning with some unique digit, such as "2", if successful, and anything other than that digit if not successful.
9. 異なったコマンドには、異なった成功回答コードがあります。 例えば、うまくいっている「ユーザ」コマンドは「230」を返しますが、うまくいっている「バイト」コマンドは「200」を返します。 同等の最初のケタと失敗回答が変な最初のケタに成功回答にはあるべきであるという概念は適用されません、「100、「スタット」、および「402」のための手段成功は「バイト」のために失敗を意味する」とき。 ソリューション: どんなコマンドも何らかのユニークなケタで始まる回答コードを返さなければならないと指定してください、あれほど、「2インチで、うまくいく、そのケタかうまくいくのを除いた何、でも」
10. Some commands have multiple possible success reply codes, e.g., "USER", "REIN", and "BYE". It is undesirable for an FTP user to be required to keep a list of reply codes for each command, all of which mean "command accepted, continue". SOLUTION: same as for (9.) above. The desire to communicate more specific information than simply "yes" or "no", such as the difficulty in the login procedure that some sites do not need all the parameters, may be solved by having, for example, "238" mean "PASSWORD ACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "PASSWORD ACCEPTED, ACCOUNT NOW NEEDED" The important point is that the idea of "command accepted" is conveyed by the initial "2", and that finer gradations of meaning can be deduced by the user process, if desired.
10. いくつかのコマンドには、複数の可能な成功回答コード、例えば、「ユーザ」があります、そして、「手綱で御してください」と「さようなら。」 FTPユーザがそれのすべてが「コマンドを受け入れて、続いてください」と意味する各コマンドのために回答コードのリストを保つのに必要であるのは、望ましくありません。 ソリューション: 上の(9)のように、同じです。 重要なポイントがいくつかのサイトがすべてのパラメタを必要とするというわけではなくて、例えば、「238」に「パスワードは受け入れて、あなたは現在、ログインされます」と意味させることによって解決されるかもしれなくて、「237」が「パスワードは受け入れました、現在必要であるアカウント」を意味するというログイン手順における困難などの単に「はい」か「いいえ」より特定の情報を伝えるためには、「コマンドは受け入れた」考えが初期の「2インチに、そんなによりきめ細かに、ユーザ・プロセスで意味の段階を推論できます、望まれているなら」伝えられるということであるという願望。
-2-
-2-
11. There are several types of replies that are extraneous from the point of view of a user FTP process, and their reply codes have no characteristic that makes them easily distinguishable. For example, "010 message from operator" and "050 FTP commentary" are superfluous to a user process, and "000 announcing FTP" (in place of "300" greeting) is not. SOLUTION: specify that any reply that has meaning only to a human user and not to a user process must have a reply code beginning with a unique digit, such as "0". The continuation line reply code proposed in (8.) above falls into this category, and therefore must start with the same unique digit.
11. いくつかのタイプのユーザFTPプロセスの観点から異質な回答があります、そして、それらの回答コードには、それらを容易に区別可能にする特性が全くありません。 例えば、「オペレータからの010メッセージ」と「050FTP論評」はユーザ・プロセスに余計です、そして、「000発表FTP」(「300」挨拶に代わった)は余計ではありません。 ソリューション: 意味しか持っていないどんな回答もユニークなケタで始まる回答コードをユーザ・プロセスではなく、人間のユーザに持たなければならないと指定してください、「0インチ」などのように。 継続行回答コードは、滝の上で(8)でこのカテゴリに提案して、したがって、同じユニークなケタから始まらなければなりません。
12. The notion of a server sending a "000 announcing FTP" or a "020 expected delay" immediately after completion of the ICP if input cannot be accepted right away is another instance of multiple reply codes having the same meaning to a user process. SOLUTION: require that the server send a reply with a "020" reply code in the situation cited. If it is desired to communicate more detailed information, the text of the reply may used for this purpose.
12. すぐ入力を受け入れることができないならサーバがICPの完成直後「000発表FTP」か「020予想どおりの遅延」を送るという概念は同じ意味をユーザ・プロセスに持っている複数の回答コードの別のインスタンスです。 ソリューション: サーバが「状況における回答コードが引用した20インチ」と共に返信するのを必要であってください。 より詳細な情報を伝えるのが必要であるなら、このために使用されて、回答のテキストは必要です。
In addition to the above mentioned weaknesses in the protocol, the following is believed to be a typographical error:
プロトコルの上記の弱点に加えて、以下は誤字であると信じられています:
13. Reply code "331" is cited as a possible success reply code for the commands "BYTE", "SOCK", "PASV", "TYPE", "STRU", "MODE", "ALLO", "REST", "SITE", AND "STAT". This reply code means "ENTER ACCOUNT" (if required as part of login sequence), and perhaps should be "332 LOGIN FIRST, PLEASE". This is especially indicated by the fact that "332" is not listed anywhere in the command-reply correspondence table.
13. 可能な成功回答コードはコマンド「バイト」、「ソックス」、"PASV"、「タイプ」、"STRU"、「モード」、「異」、「休息」、「サイト」、および「スタット」のために回答コード「331」に挙げられます。 「勘定を記帳し」て(必要ならログイン系列の一部として)、この回答コード手段は恐らく「332は最初に、ログインしてください」ということであるべきです。 「332」がコマンド回答通信テーブルで何処にも記載されていないという事実によってこれは特に示されます。
-3-
-3-
一覧
スポンサーリンク