RFC614 日本語訳

Network Working Group                                   K. Pogran (MIT-Multics)
Request for Comments: 614                                   N. Neigus (BBN-NET)
NIC #21530                                                             Jan 1974
References: RFC #607, RFC #542

Pogran(MIT-Multics)がコメントのために要求するワーキンググループK.をネットワークでつないでください: 614 N.のNeigusの(BBNネット)のNIC#21530 1974年1月参照箇所: RFC#607、RFC#542

    Response to RFC 607, "Comments on the File Transfer Protocol"

RFC607への応答、「ファイル転送プロトコルのコメント」

Mark Krilanovich and George Gregg have pointed out a number of "sticky"
issues in the current File Transfer Protocol. Although we don't agree
with all of their proposed protocol modifications, we do feel that each
of the points they have raised should be given some thought by everyone
concerned about FTP. Each numbered paragraph in the discussion below is a
comment on the identically-numbered paragraph in RFC 607.

マークKrilanovichとジョージ・グレグは現在のFile Transferプロトコルの多くの「ねばねばする」問題を指摘しました。 彼らの提案されたプロトコル変更のすべてに同意しませんが、私たちは、FTPに関して心配している皆によって考えられた何かがそれぞれそれらが上げたポイントに与えられるべきであると感じます。 以下での議論におけるそれぞれの番号付のパラグラフはRFC607の同様に番号付のパラグラフのコメントです。

1. Instructions to the Server to be "passive" are defined to apply only
to the next single file transfer operation, after which the Server
reverts to active mode. RFC 607 does, however, point out a drawback in
the present specification, in that there is no way for a user to "change
his mind": once he has told a server to be "passive", he has to initiate
some file transfer operation. The suggested solution is a welcome one. We
suggest that the text of the "successful reply" to the ACTV command
indicate whether the server had previously been in "active" or "passive"
mode, viz:

1. 「受け身である」Serverへの指示は、次の一列で転送操作だけに適用するために定義されます。(その時、Serverはアクティブなモードに戻りました後)。 しかしながら、RFC607は現在の仕様で欠点を指摘します、ユーザが「気が変わる」方法が全くないので: 「受け身である」ようにいったんサーバに言うと、彼は何らかのファイル転送操作を開始しなければなりません。 提案された解決法は歓迎されたものです。 私たちは、ACTVコマンドへの「うまくいっている回答」のテキストが、以前に、サーバがつまり「アクティブである」か「受動」のモードであったかを示すことを提案します:

200 MODE CHANGED TO ACTIVE

200 アクティブに変わるモード

or

または

200 MODE IS ALREADY ACTIVE

200 モードは既にアクティブです。

It is important to note that once some servers "listen" on a connection
in response to a PASV command, they no longer can examine the Telnet
control connection for the possible arrival of an ACTV command. User-FTP
programs should precede the ACTV command with a SYNC sequence to ensure
that the server will see the ACTV command.

いくつかのサーバが接続のときにいったんPASVコマンドに対応して「聴かれる」と、もうACTVコマンドの可能な到着のためのTelnetコントロール接続を調べることができないことに注意するのは重要です。 ユーザFTPプログラムは、サーバがACTVコマンドを見るのを保証するためにSYNC系列によるACTVコマンドに先行するはずです。

2. While the length of an FTP command -- either three or four characters
-- might often be irrelevant to a system which interacts over Telnet
connections on a line-at-a-time basis, we can see how a variable command
length might be harder for a character-at-a-time system to handle,
especially for a server implemented in assembly language. Quite a bit is
gained, and nothing seems to be lost, by requiring that FTP commands be
four characters, so we agree with the suggestion in RFC 607.

2. FTPコマンドの長さ(3か4つのキャラクタ)はしばしば一度に系列ベースにTelnet接続の上に相互作用するシステムと無関係であるかもしれませんが、私たちは一度にキャラクタシステムには、可変コマンドの長さは扱うのがどうより困難であるかもしれないかを見ることができます、特にアセンブリ言語で実装されたサーバのために。 かなりのビットを獲得します、そして、何も失われるように思えません、私たちがRFC607での提案に同意してFTPコマンドが4つのキャラクタであることを必要とすることによって。

3. While the FTP document may be somewhat ambiguous in its specification
of the order of the handshaking which takes place following a file
transfer command, such an order does exist as far as is possible for the
two asynchronous processes described in "The FTP Model" (section II. B of
RFC 542) -- the Telnet Control process (Protocol Interpreter) and the
Data Transfer process. The user is required to "listen" on the data
connection before sending the transfer command.  Upon receipt of the
command the server should first check that the status of the file
specified by the argument to the file transfer command is okay, and, if
so, attempt to open the data connection. If there are file system
problems, no attempt should be made to open the connection. In this way,

3. FTPドキュメントがファイル転送命令に従って、行われるハンドシェイクの秩序の仕様でいくらかあいまいであるかもしれない間、そのような注文は同じくらい遠くに可能であるように「FTPモデル」で説明された2つの非同期なプロセスのために存在しています。(セクションII。 RFC542のB) -- Telnet Controlプロセス(プロトコルInterpreter)とData Transferは処理します。 転送命令を送る前にユーザがデータ接続のときに「聴くこと」が必要です。 コマンドを受け取り次第、サーバは、最初に、議論でファイル転送命令に指定されたファイルの状態が承認と、そうだとすれば、データ接続を開く試みであることをチェックするべきです。 ファイルシステム問題があれば、接続を開くのを試みを全くするべきではありません。 このように

                                    -1-

-1-

the primary response to the command gives an accurate picture of the
transfer status -- i. e., connection opened and transfer started (250),
or connection not opened because of file problems (450, 451, 455, 457) or
connection problems (454). The secondary reply follows the conclusion of
the transfer, and describes its success or failure.

接続は開きました、そして、コマンドへの一次応答は転送状態の正確な画像を与えます--i.e.転送が(250)を始めたか、または接続はファイル問題(450、451、455、457)か接続問題(454)で開きませんでした。 セカンダリ回答は、転送の結論に続いて、成否について説明します。

If a particular FTP implementation cannot monitor the data connection and
the Telnet control connection simultaneously, then it must establish a
timeout waiting for the data connection RFC. In addition, a minimum
interval should be specified for which all servers must wait before
deciding that the data connection cannot be opened. We suggest that this
interval be no shorter than fifteen seconds.

特定のFTP実装が同時にデータ接続とTelnetコントロール接続をモニターできないなら、それはデータ接続RFCを待つタイムアウトを設立しなければなりません。 さらに、すべてのサーバがデータ接続を開くことができないと決める前に待たなければならない最小間隔は指定されるべきです。 私たちは、この間隔が15秒ほど短くないと示唆します。

4. The protocol states that servers should return "success", replies to
commands such as ACCT and ALLO which were irrelevant to them. We
recommend that the protocol say "must" rather than "should".

4. プロトコルは、サーバが「成功」、それらに、無関係であったACCTやALLOなどのコマンドに関する回答を返すべきであると述べます。 私たちは、プロトコルが“should"よりむしろ“must"を言うことを勧めます。

5. Specification of maximum lengths for lines, pathnames, etc.  is a fine
idea, as is the suggestion of a Server poll.  Typical values for the
present Multics implementation (provided by Ken Pogran) are as follows:

5. 系列、パス名などのための最大の長さの仕様はServer投票の提案のようにすばらしい考えです。 現在のMultics実装(ケンPogranによって提供される)のための典型的な値は以下の通りです:

Telnet lines: 256
User names: 32
Passwords: 8
Account Numbers: (na)
Pathnames: 168 (yes, 168)

telnet系列: 256 ユーザ名: 32のパスワード: 8 数を説明してください: (Na) パス名: 168 (はい168)

6. We strongly disagree with Mark on this point. The algorithm a user-FTP
should use goes something like this:

6. 私たちはこのポイントに関して強くマークと意見を異にします。 ユーザFTPが使用するべきであるアルゴリズムはこのように進んでいます:

a. Examine the first four characters of the reply.  
b. If the fourth character is a space, the reply is not a multi-line reply.  
c. If the fourth character is a hyphen, the reply is a multi-line reply,
and the text portion of this line and succeeding lines should be reported
to the user if this is desired.
d. On each succeeding line, if the first four characters are not the
three digits of the original reply code followed by a space, the line is
entirely a text line and should either be reported to the user or
discarded.
e. If the first four characters on the line are the three digits of the
reply code followed by space, this line is the last line of the reply.

a。 回答の最初の4つのキャラクタを調べてください。. b。 スペース、回答は4番目のキャラクタがそうであるならマルチ系列ではありません。回答c。 4番目のキャラクタがハイフンであるなら、回答はマルチ系列回答です、そして、これが望まれているなら、この系列と続く系列のテキスト部分はユーザに報告されるべきです。. d。 続く各系列では、系列は、最初の4つのキャラクタがスペースがあとに続いた元の回答コードの3ケタでないなら、完全にテキスト系列であり、ユーザに報告されるべきであったか、または. eを捨てました。 系列の最初の4つのキャラクタがスペースがあとに続いた回答コードの3ケタであるなら、この系列は回答の最終ラインです。

This algorithm seems simple enough, if nesting of replies is not required
(see comments on paragraph 7, below). This sort of continuation-line
convention provides a number of benefits to the person coding a server.
Consider the problem of providing a directory listing, in response to a
STAT command whose argument is the pathname of a directory. If the FTP
Telnet control connection is treated as a pseudo-typewriter (as most
ordinary Telnet connections are), the writer of an FTP Server may be able
to "borrow" the code from the system command which provides directory
status (listing) information, as follows (in a pseudo-PL/l syntax):

回答の巣篭もりは必要でないなら(以下でパラグラフ7のコメントを見てください)、このアルゴリズムは十分簡単に見えます。 この種類の継続行コンベンションは人のコード化への多くの利益にサーバを提供します。議論がディレクトリのパス名であるSTATコマンドに対応してリストアップされているディレクトリを提供するという問題を考えてください。 FTP Telnetコントロール接続が疑似タイプライタとして扱われるなら(ほとんどの普通のTelnet接続がそうように)、FTP Serverの作家はディレクトリ状態(記載する)に情報を提供するシステム・コマンドからコードを「借りることができるかもしれません」、以下の通りです(疑似PL/l構文で):

call write_out_line ("151- Directory listing follows") ;
call list_directory_contents (directory_pathname);
call write_out_line ("151 Directory listing complete");

呼び出しは_出ている_系列を書きます(「151ディレクトリリストは続きます」)。 リスト_をディレクトリ_コンテンツ(ディレクトリ_パス名)と呼んでください。 呼び出しは_出ている_系列(「完全な状態で記載する151ディレクトリ」)を書きます。

                                    -2-

-2-

The same can be done for the file status reply (code 150).  Otherwise, a
program must be written which performs the function of the
directory-listing command, but uses a special output format. If the
implementor of an FTP Server wants to be "nice" and list file attributes,
as well as file names, in the directory listing (as many
directory-listing commands do), this could be a fairly big job. If
already-written software can be borrowed and incorporated into the FTP
Server, the implementor of the FTP Server can put more of his effort into
doing a better job of building the "guts" of the FTP Server.

ファイル状態回答(コード150)のために同じくらいができます。 さもなければ、ディレクトリリストコマンドの機能を実行しますが、特別な出力形式を使用するプログラムを、書かなければなりません。 FTP Serverの作成者が「良く」、ファイル属性をリストアップしたいなら、ファイル名と同様に、これはディレクトリリスト(多くのディレクトリをリストアップするコマンドがそうするように)では、かなり大きい仕事であるかもしれません。 既に書かれたソフトウェアを借りて、FTP Serverに組み入れることができるなら、FTP Serverの作成者はFTP Serverの「腸」を建てるより良い仕事をするのに彼の一層の取り組みをそそぐことができます。

7. It is not obvious why multi-line replies are allowed to be nested to
an arbitrary depth. Only truly spontaneous replies may nest inside other
replies -- and it is easy to convince yourself that they will only nest
to depth one. It was envisioned that some messages from "the system"
might not allow the "exterior" multi-line message to finish; the scenario
might go something like this:.

7. マルチ系列回答がなぜ任意の深さに入れ子にすることができるかは、明白ではありません。 本当に自然発生的な回答だけが他の回答で巣ごもるかもしれません、そして、巣ごもるだけであると自分に深さ1まで納得させるのは簡単です。 それはそうでした。思い描かれて、或るものが「システム」から通信するのが終わる「外」のマルチ系列メッセージを許容しないかもしれません。 シナリオはこのように続くかもしれません:

151- Directory listing follows:
a1pha.p11
alpha
rfc.runoff
mailbox
010- From Operator:
010 Emergency shutdown in 5 mins. due to hardware probs.
beta.fortran
foo.lisp
151 Directory listing complete.
It has been pointed out to us that:

151ディレクトリリストは続きます: Operatorからのa1pha.p11アルファrfc.runoffメールボックス010: 010 5minsハードウェアprobs完全な状態で記載するbeta.fortran foo.lisp151ディレクトリへの支払われるべきものの緊急操業停止。 以下のことと私たちに指摘されました。

a. Messages from "the system" in general cannot be guaranteed to come at
the beginning of a line.

a。 系列の始めに来るために一般に、「システム」からのメッセージを保証できません。

b. It may be difficult to modify "the system" to preface such messages
with an appropriate FTP reply code.

b。 適切なFTP回答コードでそのようなメッセージについて前書きするように「システム」を変更するのは難しいかもしれません。

Therefore, we propose that, since user-FTP implementations must handle
multi-line replies, system messages "splattered" into the middle of
replies need not be escorted by FTP reply codes. The user-FTP thus need
not detect and handle "nested" FTP replies.

したがって、私たちは、ユーザFTP実装がマルチ系列回答を扱わなければならないので回答の途中に「はね散った」システムメッセージがFTP回答コードによってエスコートされる必要はないよう提案します。 その結果、ユーザFTPは、「入れ子にされた」FTP回答を検出して、扱う必要はありません。

8. RFC 607 proposes that any data between the last end-of-record marker
of a file and the end-of-file marker be discarded. We agree. The sender
of the data has clearly violated the protocol, and the receiver cannot
divine the sender's original intent.

8. RFC607は、ファイルの最後の記録のエンドマーカーとファイルの終りマーカーの間のどんなデータも捨てられるよう提案します。 私たちは同意します。 データの送付者は明確にプロトコルに違反しました、そして、受信機は送付者の当初の意図を占うことができません。

9-11. The suggestion that reply codes beginning with the digit "2" be
taken as successful, and all others be taken as failures, severely
restricts use of the available "reply code space". We agree that the
present scheme is disorganized and requires far too much "intelligence"
on the part of a user-ftp automaton. With the present scheme, unless the
automaton's reply-interpretation is table-driven, it is extremely likely
to make a mistake. We feel that the whole reply code strategy should be
redesigned; some of the ideas proposed in RFC 607 could fit in with such
a redesign, but we do not think that Mark's suggestion is the way to go.

9-11. 回答がコード化するケタで始まる提案、「2インチ、うまくいくとして取ってください、すべての他のものが失敗として取られ、厳しく利用可能な「回答コードスペース」の使用を制限する、」 私たちは、現在の体系が狂って、ユーザ-ftpオートマトン側の遠くにあまりに多くの「知性」を必要とするのに同意します。 現在の体系で、それはオートマトンの回答解釈がテーブルによる駆動でないなら、誤りを非常にしそうです。 私たちは、全体の回答コード戦略が再設計されるべきであると感じます。 RFC607で提案された考えのいくつかがそのような再設計と合うことができましたが、私たちは、マークの提案が行く方法であると思いません。

                                      -3-

-3-

12. 000 and 020 are used by the Server to indicate that it has heard and
answered the ICP to socket 3, but cannot accept file transfer commands
yet. 020 was intended to indicate how much of a time delay could be
expected, while 000 was ambiguous on this point. We suggest that the two
be merged to mean "I am here; please wait a specified or unspecified
amount of time"; then, 300 would clearly mean "I am ready; you may now
send me commands".

12. 000と020は、ソケット3にICPを聞いて、答えましたが、まだファイル転送命令を受け入れることができないのを示すのにServerによって使用されます。 020が、時間遅れのどのくらいを予想できたかを示すことを意図しました、000はこのポイントであいまいでしたが。 私たちは、2が「私はここにいます」と意味するために合併されていることを提案します。 「指定されたか不特定の時間を待ってください」。 次に、300は、「私は準備ができています」と明確に意味するでしょう。 「あなたは現在、コマンドを私に送ることができます。」

13. There is no typographical error here. A TENEX representative
suggested that, rather than give a "fail" reply to a particular request
because the user is not logged in, a server might ask for his account
number (or ask him to log in) and then proceed with the previous request,
which has been held in abeyance. While this may be convenient for a
server, it is not necessary, and certainly ambiguous to hold a command in
abeyance while obtaining an account number.  Since any server may spring
this on a user, all user-FTP implementations must be able to cope with
this twist, which adds a good deal of required complication to the
"minimal" user-FTP implementation. We propose that the 331 reply be
eliminated, and that the server forget the requested operation and return
a 4XX reply if an account is needed.

13. 誤字が全くここにありません。 TENEX代表がユーザがログインされないので「失敗してください」という回答を特定の要求に与えるよりむしろそれを勧めて、サーバは、彼の口座番号(ログインに彼を招く)を求めて、次に、前の要求を続けるかもしれません。(それは、停止しているとして保持されました)。 サーバはこれが都合がよいかもしれませんが、停止しているとしてコマンドを保持するのは、口座番号を得ている間必要でなくて、確かに、あいまいです。 どんなサーバもこれをユーザに急に持ち出すかもしれないので、すべてのユーザFTP実装がこのねじれに対処できなければなりません。(それは、「最小量」のユーザFTP実装に多くの必要な複雑さを加えます)。 私たちは、アカウントが必要であるなら、サーバが331回答が排除されて、要求された操作を忘れて、4XX回答を返すよう提案します。

Jon Postel has remarked that "mail text should follow the same limit as
commands and long 'lines' of mail text have been trouble for some FTP
Servers." We agree. In fact, mail transmitted over the FTP Telnet control
connection has other problems, too: Since FTP is (nominally, at least)
supposed to be usable from TIPs, Multics implemented its standard
character erase and line kill conventions on the control connection for
the convenience of TIP users (it was actually easier to have those
conventions in effect than to turn them off!). Of course, no erase/kill
processing was done on the data connection. The intent of the MAIL
request was to allow users at terminals to access an FTP Server directly
and transmit mail; it was presumed that mail-sending automata which
gathered the mail to be sent into a file would use the MLFL command and
transmit the mail over the data connection.  Presumably, long lines would
not be a problem, and, of course, no erase/kill conventions would be in
effect. Well, at least one major system (TENEX) has a mail-sending
automaton which transmits mail over the Telnet control connection using
the MAIL command - even though it has previously gathered the mail into a
file!  Line-length considerations could be a severe problem here, and the
fact that the Multics line-kill character is the at-sign (@) caused grief
in reading mail from TENEX users who included their "return address" in
TENEX's SNDMSG syntax, as USERNAME@HOST. We propose that mail-sending
automata be required to use MLFL, rather than MAIL.

「メールテキストはコマンドの、そして、長い'メールテキストの行はいくつかのFTP Serversのための問題です'として同じように限界に続くべきです。」と、ジョン・ポステルは述べました。 私たちは同意します。 事実上、また、FTP Telnetコントロール接続の上に伝えられたメールは他の問題を持っています: 以来FTPがそうである、(名目上は、少なくとも)、TIPsから使用可能であると思われて、その標準のキャラクタ抹消と系列であると実装されたMulticsはコントロール接続のときにTIPユーザの都合のためにコンベンションを殺します(それらのコンベンションを有効にするのは実際にそれらをオフにするより簡単でした!)。 もちろん、データ接続のときに/が処理するのを殺さない抹消を全くしました。 メール要求の意図は端末のユーザが直接FTP Serverにアクセスして、メールを伝えるのを許容することでした。 ファイルの中に送られるメールを集めたメールを送るオートマトンがMLFLコマンドを使用して、データ接続の上にメールを伝えると推定されました。 おそらく、長い系列は問題でないでしょう、そして、もちろん、どんな抹消/獲物コンベンションも有効でないでしょう。 さて、少なくとも1台の主要なシステム(TENEX)には、以前に、メールをファイルの中に集めましたが、メールコマンドを使用することでTelnetコントロール接続の上にメールを伝えるメールを送るオートマトンがあります! 行長問題はここの厳しい問題であるかもしれません、そして、Multicsがキャラクタを系列で殺すという事実はサインのTENEXのSNDMSG構文に彼らの「返送先」を含んでいたTENEXユーザからメールを読むことにおける深い悲しみが引き起こされた(@)です、 USERNAME@HOST として。私たちは、メールを送るオートマトンがメールよりむしろMLFLを使用するのに必要であるよう提案します。

                                  -4-

-4-