RFC624 日本語訳

Network Working Group                                  Mark Krilanovich (UCSB)
Request for Comments: 624                                  George Gregg (UCSB)
NIC #22054                                            Wayne Hathaway (AMES-67)
references: RFC 542                                        Jim White (SRI-ARC)
obsoletes: RFC 607                                                   Feb  1974

ネットワークワーキンググループマークKrilanovich(UCSB)はコメントのために以下を要求します。 624 ジョージグレグ(UCSB)NIC#22054ウェインハザウェイ(エームズ-67)参照: RFC542ジム・ホワイト(SRI-ARC)は以下を時代遅れにします。 RFC607 1974年2月

              Comments on the File Transfer Protocol

ファイル転送プロトコルのコメント

This document replaces RFC 607, which was inadvertently released
while still in rough draft form. It would be appreciated if RFC 607
were disregarded, and this document considered the accurate statement
of the authors' opinions.

このドキュメントはRFC607を取り替えます。(まだ荒い手形様式にある間、RFCはうっかりリリースされました)。 RFC607が無視されていて作者の意見の正確な陳述であると考えられたこのドキュメントであればありがたく思うでしょうに。

There are several aspects of the File Transfer Protocol of RFC
542 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.

重大な欠点を構成するRFC542の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 set to the state where he is "passive"
with regard to establishment of data connections, there is no
convenient way for the user to make him "active" again. The
"REIN" command accomplishes this, but affects more than just the
desired active/passive state. 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 or user would be simpler if all
command verbs were the same length. While it is certainly
possible to handle varying length verbs, fixed length string
manipulation is in general easier to write and faster to run than
varying length string manipulation, and it would seem that nothing
is to be gained in this application by allowing varying length
strings. 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サーバかユーザのデザインはすべてのコマンド動詞が同じ長さであるなら、より簡単でしょうに。 確かに、長さの動詞、一般に、固定長文字列処理がそうであることがハンドルの異なるのに可能である間、より書きやすくて異なるより実行するのにおいて速い長さは操作を結びます、そして、長さのストリングを変えるのを許容することによってこのアプリケーションで何も獲得してはいけないように思えるでしょう。 ソリューション: 「さようなら」、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は完全な状態で移し」回答の代わりに送られることになっています。

                                 -1-

-1-

4. Some hosts currently send an error reply on receipt of a
command that is unimplemented because it is hot 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 the success
reply for that command.

4. ホストの中には現在必要な状態で暑いので非実装されるコマンド(例えば、"ACCT"か「異」)を受け取り次第エラー応答を送る人もいます。 回答のテキストは、コマンドが無視されたのを示しますが、ユーザ・プロセスには、どんな本当の「誤り」もないのを知るのは明らかに不可能です。 ソリューション: それはそのシステムで必要でないので特定のコマンドをサポートしないどんなサーバもそのコマンドのための成功回答を返さなければならないのを必要であってください。

5. There is no specified maximum length of a TELNET command line,
TELNET reply 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 inconvenient,
at least in some systems, for the writer of an FTP user (which
must converse with many FTP servers) to construct an indefinite
length buffer. Similar difficulties confront the writer of a
server FTP. SOLUTION: specify a maximum length for TELNET
command lines, TELNET replies, user names, passwords, account
numbers, and pathnames. This is to be done after conducting a
Poll of serving sites concerning their individual maxima. If
Network mail is to be included in FTP, the mail text, if sent over
the TELNET connection, is to be subject to the same line length
maximum.

5. TELNETコマンドライン、TELNET回答系列、ユーザ名、パスワード、アカウント、またはパス名のどんな指定された最大の長さもありません。 FTPサーバを実装するあらゆるシステムがおそらくそれ自身のパラメタのための異なったmaximaを持っているのが、本当ですが、少なくとも作家のいくつかのシステムでは、FTPユーザ(多くのFTPサーバと話さなければならない)は無期長さのバッファを構成するとは不便です。 同様の困難はサーバFTPの作家に立ち向かいます。 ソリューション: TELNETコマンドライン、TELNET回答、ユーザ名、パスワード、口座番号、およびパス名に最大の長さを指定してください。 それらの個々のmaximaに関して給仕サイトのPollを行った後に、これをすることになっています。 メールテキストはNetworkメールがFTPに含まれることであるなら、TELNET接続の上に送るなら同じ行長最大に受けることがあることです。

6. The notion of allowing continuation lines to start with
arbitrary text solves a minor problem for a few server FTP
implementors at the expense of creating a major problem for all
user FTP implementors. 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 arc 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. The reply code used for this purpose must begin with "0"
(it cannot be three blanks, for example), so that it will appear
as extraneous to a user process by virtue of the already existing
rules concerning reply code groupings.

6. すべてのユーザFTP作成者のために大した問題を作成することを犠牲にして継続行が任意のテキストから始まるのを許容するという概念は数人のサーバFTP作成者のための小さな問題を解決します。 マルチ系列回答を解読するのに必要である論理は、不必要に複雑であり、マルチ系列が返答する事実で、よりそうである1つの桁を入れ子にすることができたアークにしました。 ソリューション: ユニークな(数値)回答コードを割り当ててください、「9インチ、すべてで使用されるには、マルチ系列の台詞は1日以降、返答します」などのように。 このために使用される回答コードは「0インチ(例えば、それは3回の空白であるはずがない)、それが回答コード組分けに関する既に既存の規則によるユーザ・プロセスに異質であるとして見えるそう」で始まらなければなりません。

7. If it is the case that the above solution to (6) is not
accepted, the fact that the maximum allowed level of nesting is
left unspecified creates a hardship for implementors of user FTPs.
This hardship is somewhat easily solved on a machine that has
hardware stacks, but not so for other machines. SOLUTION: either
disallow nested replies (preferred), or specify a maximum level of
nesting of multi-line replies.

7. (6)への上のソリューションが受け入れられないのが、事実であるなら、巣篭もりのレベルが許容された最大が不特定のままにされるという事実はユーザFTPの作成者のための苦労を作成します。 この苦労は、他のマシンのためにいくらか容易にハードウェアスタックを持っているマシンの上で解決されていますが、したがって、解決されるというわけではありません。 ソリューション: 入れ子にされた回答(好まれる)を禁じるか、または最大のレベルのマルチ系列回答の巣篭もりを指定してください。

8. The prose descriptions of the meanings of the various reply
codes are in several cases unclear or ambiguous. For example, the
code "020" is explained only as "announcing FTP". It is given as
a reply that can be issued when a server cannot accept input
immediately after an ICP, but its exact meaning is not obvious.
Also. the code "331" is said to mean "ENTER ACCOUNT (if required
as part of login sequence)", but is listed as a possible success
reply for most of the commands. The explanation indicates that it
is only valid in the login sequence, but the command-reply

8. 様々な回答コードの意味の散文記述は、いろいろな場合に不明瞭であるか、またはあいまいです。 例えば、コード、「20インチは単に「FTPを発表します」として説明されます」。 サーバはICP直後入力を受け入れることができるのではなく、正確な意味を受け入れるとき、発行できる回答が明白でないときに、それを与えます。 また. コード「331」は「勘定を記帳します(必要ならログイン系列の一部として)」と意味すると言われていますが、コマンドの大部分の可能な成功回答として記載されています。 説明は、それがしかし、ログイン系列、コマンド回答だけで有効であることを示します。

                                 -2-

-2-

correspondence table implies that it also means, "I can't do that
without an account". SOLUTION: an expanded effort should be made
by those who originated the reply codes to define them more
completely.

通信テーブルは、また、「私はアカウントなしでそれができません」と意味するのを含意します。 ソリューション: 拡張取り組みはそれらをより完全に定義するために回答コードを溯源した人によって作られているべきです。

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 hot
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ユーザ・プロセスの作家が多数の特別なケースを扱わなければならないという事実が、送られた持続コマンドではなく、Whetherがうまくいったことを単に決定するのが関係があります。 プロトコルが以下のすべての領域で明確であることが認められますが、独特の「明確」が十分な状態で必要ですが、熱いとわかるのは重要です。 種々の理由で、すべての需要を満たす最も簡単なメカニズムを使うのは非常に望ましいです。 以下に、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 stated concept
that the first digit would carry this information does not apply,
as "100" means success for "STAT", and "200" means success for
"SOCK". 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. For
example this includes changing the success reply for STAT,
Perhaps to "200".

9. 異なったコマンドには、異なった成功回答コードがあります。 例えば、うまくいっている「ユーザ」コマンドは「230」を返しますが、うまくいっている「バイト」コマンドは「200」を返します。 最初のケタがこの情報を運ぶだろうという述べられた概念は、「スタット」のために「100」手段として成功を適用して、「ソックス」のために「200」手段成功は適用しません。 ソリューション: どんなコマンドも何らかのユニークなケタで始まる回答コードを返さなければならないと指定してください、あれほど、「2インチで、うまくいく、そのケタかうまくいくのを除いた何、でも」 例えば、これは、STAT、Perhapsのための成功回答を「200」に変えるのを含んでいます。

10. Some commands have multiple possible success reply codes,
e.g., "USER" and "REIN". It is undesirable for ah FTP user to be
required to keep a list of reply codes for each command, all of
which mean "command accepted, continue". Again, the stated
concept concerning the first digit fails, as "230" and "330" are
in truth both acknowledgments to a successful "USER" command.
SOLUTION: same as for (9) above. The desire to communicate more
specific information than simply "yes" or "no", such as the
difficulty that some servers do not need all the login parameters,
may be solved by having, for example, "230" mean "PASSWORD
ACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "PASSWORD
ACCEPTED, ACCOUNT NOW NEEDED". Given the solution to (4) above, a
user process becomes much less interested in the difference
between "YOU ARE NOW LOGGED IN" and "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ユーザが各コマンドのために回答コードのリストを保たなければならないのは、望ましくありません。そのすべてが「コマンドを受け入れて、続いてください。」と意味します。 一方、最初のケタに関する述べられた概念は失敗します、「230」と「330」がうまくいっている「ユーザ」コマンドへの実は両方の承認であるので。 ソリューション: 上の(9)のように、同じです。 いくつかのサーバがすべてのログインパラメタを必要とするというわけではないという困難などのように、例えば、「230」に「パスワードは受け入れて、あなたは現在、ログインされます」と意味させることによって、単に「はい」か「いいえ」より特定の情報を伝える願望は解決されるかもしれません、そして、「237」は「パスワードが受け入れました、現在必要であるアカウント」を意味します。 (4)へのソリューションを考えて、ユーザ・プロセスは「あなたは現在、ログインされ」て「現在必要であるアカウント」の間で上では、違いにはるかに関心を持たないようになります。 重要なポイントは「コマンドは受け入れた」考えが初期の「2、および望まれているなら缶がユーザ・プロセスによって推論されることを意味するそんなによりすばらしい段階」によって伝えられるということです。

11. The meanings of the various connection greeting reply codes
are somewhat inconsistent. "300 connection greeting, awaiting
input", if intended as a positive acknowledgments to the ICP,
should be a 200-series reply, or if intended to be purely
informative, a 000-series reply. If the former, then clearly "020
expected delay" is the corresponding negative acknowledgments, and
should be a 400-series reply. It is however unlikely that
notification of an expected delay would be of importance to a user
Process without knowledge of the length of the delay. SOLUTION.:
change "300 connection greeting" to a 000-series reply, perhaps

11. 様々な接続挨拶回答コードの意味はいくらか首尾一貫しません。 肯定応答としてICPに意図するなら、「入力を待つ300接続挨拶」は200シリーズの回答であるべきですか純粋に有益であることを意図するなら、000シリーズが返答します。 前者であるなら、「020予想どおりの遅延」は、明確に、対応する否定応答であり、400シリーズの回答であるべきです。 どんなにありそうもなくても、予想どおりの遅延の通知は遅れの長さに関する知識なしでユーザProcessに重要でしょう。 ソリューション、: 恐らく「300接続挨拶」を000シリーズの回答に変えてください。

                                 -3-

-3-

"011" (preferred), or change "300 connection greeting" to a
200-series reply, perhaps "211", and "020 expected delay" to a
400-series reply, perhaps "411".

恐らく11インチ(好まれる)か、200シリーズの回答への変化「300接続挨拶」と、「211」と、400シリーズへの「020予想どおりの遅延」が恐らく返答します。「「411インチ。」

In addition to the above mentioned weaknesses in the protocol,
the following is believed to be a typographical error:

プロトコルの上記の弱点に加えて、以下は誤字であると信じられています:

12. Reply code "332 LOGIN PLEASE" is not listed anywhere in the
command-reply correspondence table. It Would seem that this would
be a more-information-needed (success) reply for all those
commands which require the user to be logged in. It should also
be stressed that the "332" code is to be used for this purpose, as
many servers currently use other codes, such as "451" and "504",
to mean "LOGIN PLEASE".

12. 「332ログインは喜ばせる」回答コードがコマンド回答通信テーブルで何処にも記載されていません。 それ、Wouldは、これがユーザがログインされるのを必要とするそれらのすべてのコマンドのための必要であるより多くの情報(成功)回答であるように思えます。 また、「332」コードがこのために使用されることであると強調されるべきです、多くのサーバが現在他のコードを使用するとき、「ログインしてください」と意味するために「451」や「504」のように。

                                   -4-

-4-