RFC 1123 (FTP section)
Network Working Group J.
Postel (ISI)
Request for Comments: 1121 L. Kleinrock (UCLA)
V.
Cerf (NRI)
B.
Boehm (UCLA)
September
1989
Act One - The Poems
訳者まえがき
この文書は、RFC 1123を非公式に日本語訳したものです。翻訳の誤り、誤解、語学能力の欠如、などから、訳者が気づかなかった誤りが存在します。また、ニュアンスなどが原文と異なります。翻訳の際、語を補った方がわかりやすいと判断した場合には、/* */で囲んだ形で補ってある場合もあります。
この文書の利用は、概要をつかむためのみに使用してください。公式の場での質問や、回答、その他の利用の際には、必ず原文を参照してください。この翻訳版の配布条件は、原文の配布条件に従います。（原文では、配布自由となっています）
この文書の位置づけ
This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.この文書は自由に配布して構わない。
4.1 ファイル転送プロトコル(FILE TRANSFER PROTOCOL) -- FTP
4.1.1 始めに
ファイル転送プロトコル、ＦＴＰはインターネットにおいて、主要なファイル転送の標準である。現在の仕様はRFC-959[FTP:1]に含まれている。
ＦＴＰは、制御とデータ転送それぞれのＴＣＰ接続を同時に使用する。FTPのプロトコルは、多くの機能が含まれているが、これらのいくつかは、常に実装されているというわけではない。しかしながら、いろいろなのＦＴＰ機能の中で、最低一つは実装された機能が存在する。RFC-959で定義されている最小の実装はあまりに貧弱すぎるので、ここでは、もう少し高機能なものを、最小の実装として定義する。
インターネットのユーザーは、長い間、ＦＴＰの実装の不備により、不要な重荷を背負ってきた。ＦＴＰは小さく、つまらない仕事でなくてはならないという誤った意見に、プロトコルの実装者は煩わされてきた。この考え方は間違えている。なぜなら、ＦＴＰはユーザーインターフェースを持っている。なぜなら、ＦＴＰは通信とオペレーティングシステムで発生しうるエラーのすべての種類を（正しく）処理する必要がある。そして、なぜなら、ＦＴＰは世界中に存在する膨大な種類のファイルシステムを正しく処理する必要があるためである。
4.1.2. プロトコルの概説
4.1.2.1 ローカル形式（LOCAL Type）: RFC-959 3.1.1.4章
ＦＴＰはTYPE I(「イメージ」、もしくはバイナリ形式）を、TYPE L 8(「ローカル」、論理長８ビットのバイト形式）と同じようにサポートしなくてはならない。
コンピュータの主記憶が８の倍数でないｍビットを持っている場合は、TYPE L ｍもまたサポートしてもよい。
ディスカッション:
「TYPE L 8」コマンドは、メモリが例えば３６ビットを１ワードどするコンピュータと、８ビットを１バイトとするコンピュータとの間で、バイナリ形式のデータを転送するときにしばしば使用する必要があるかもしれない。８ビットを１バイトとするコンピュータにおいては、TYPE L 8 は、TYPE Iと同じである。
「TYPE L m」は、ｍ×２のワード長を持ったコンピュータにおいて、ネイティブモードのバイナリファイルが正しく転送されることを保証するために時々指定される。しかし、このコマンドは、これらのコンピュータで「TYPE I」を使用したときと同じ動作をする。
4.1.2.2 Telnet形式の制御: RFC-959 3.1.1.5.2章
TYPE NとTYPE Tが区別されないようなホストにおいては、TYPE
T とTYPE N
は同じ処理が行われるように実装されなくてはならない。
ディスカッション:
これは、TYPE NとTYPE Tとが区別されるようなホストとの間の相互操作
を簡便に行うことが出来るようにするための用意である。
多くのホストが、ファイルが印刷されるときに形式を制御できるように
テキストファイルを内部的にはASCII制御コード(LF,BS,FF等）が使用で
きる形式のASCII文字の並びとして表現している。そのようなホストに
おいては、「印刷される」ファイルとその他のファイルに違いはない。
しかし、レコード形式のファイルを使用しているコンピュータでは、印
刷されるファイルに特別な制御コード、例えば
ASAキャリッジコントロ
ールを必要とする。上記のようなホストにおいては、ＦＴＰはTYPE
Nと
TYPE Tを区別して使用することができる。
4.1.2.3 ページ構造: RFC-959 3.1.2.3章 及び 付録Ｉ
一般的に、ページ構造を実装することは推奨されない。しかし、ホストシス
テムが「ランダムアクセス」や「穴ぼこ」ファイルを使用するＦＴＰを必要
とする場合は、そのホストだけで使用できるような形式を定義するのではな
く、ページ構造を使用しなくてはならない。
4.1.2.4 データ構造の変形:
RFC-959 3.1.2章
レコード形式とファイル形式間でのＦＴＰ転送は、対象となるホスト上で結
果を使用しやすいように変換可能でなくてはならない。
ディスカッション：
RFC959では、レコード形式と、ファイル形式とが変換可能であるように
厳密に要求している。しかし、実際には、効率と便利さがしばしばそれ
を妨げている。そのために要求する制限をゆるめた。ファイルを転送す
る目的には二つある。一つは、対象となるホスト上での作業のため、も
う一つは、単に保管する為である。保管する目的であれば、変換可能で
あれという要求は重要である。作業をするためには、対象となるホスト
上で作成されるファイルは、対象となるホスト上のアプリケーションプ
ログラムの形式であることが求められる。
問題となる例として、レコード形式を使用しているオペレーティングシ
ステムが、正確に各レコード８０バイトの何かのデータファイルを要求
する場合を考えてみる。そのようなホストに対してデータをストアする
場合、/*そのホストで動作する*/ＦＴＰサーバーは、それぞれの行、も
しくはレコードを８０バイトになるように水増ししなくてはならない。
後にファイルを受信するような場合、厳密に変換可能にはならない。
4.1.2.5 データ接続の管理: RFC-959 3.3章
STREAMモードを使用するユーザー側ＦＴＰ/*(ＦＴＰクライアント)*/は、そ
れぞれの転送コマンドの前にPORTコマンドを送り、デフォルトではないデー
タポートを予約すべきである。
ディスカッション：
これは、ＴＣＰ接続がクローズしてから、そのソケットペアが再利用可
能になるまで長い時間がかかる場合でも、一つのＦＴＰ接続で複数の転
送を可能にするために必要とされる。
＊ ストリームモード以外の転送モードが使用された場合、PORTコマンドの
送信は、データ転送の接続が転送と転送の間で見捨てられることにより
避ける事が出来る。
4.1.2.6 PASVコマンド: RFC-959 4.1.2章
ＦＴＰサーバーは、PASVコマンドを実装しなくてはならない。
もし、別の重複した転送が一回の接続中で行われる場合、それぞれの転送コ
マンドの前に、重複しないポートの対を得るために新規にPASVコマンドを発
行しなくてはならない。
実装について:
PASVコマンドの応答コード２２７の形式は、あまり標準化はされてい
ない。 特に、ＦＴＰクライアントはRFC959の40ページに示されている
ような括弧があると決めてかかる事ができない（そして、実際、43ペ
ージの図３では括弧がついていない）。その結果、PASVの応答を解釈
するユーザー側ＦＴＰ/*（ＦＴＰクライアント)*/プログラムは、ホス
トとポート番号の最初の数字を探さなくてはならない。
ちなみに、ホスト番号のh1,h2,h3,h4はサーバーの動作するホストのＩ
Ｐアドレスとなり、そして、p1,p2はPASVコマンドが予約した標準では
ないデーター転送ポートである。
4.1.2.7 LISTとNLSTコマンド: RFC-959 4.1.3章
NLSTコマンドにより返されるデータは、サーバーがそれ以降、個々のファイ
ルのデータ転送を行う際の引数として使用できるような、正しいパス名の単
純な一覧でなくてはならない。
LSTや、NLSTにより返されるデータは、暗黙にTYPE
ANが使用される、但し、
現在のタイプがEBCDICの場合は、暗黙にTYPE ENが使用される。
ディスカッション:
多くのＦＴＰクライアントは、NLSTにより得たパス名のリストを使用
することにより、putやgetをワイルドカード指定で行うためのマクロ
コマンドを持っている。
「複数put」はクライアントだけで実現されるが、「複数get」はサー
バーとの協調動作を必要とする。
LISTとNLSTの暗黙のTYPE指定はは既存のユーザー側FTP/*(ＦＴＰクラ
イアント)*/、特に、「複数get」と互換性を持つように設計された。
4.1.2.8 SITEコマンド: RFC-959 4.1.3章
サーバーＦＴＰは、標準でない機能を使用するために、新しい固有コマンド
を作ったり、既存のコマンドに標準でない拡張をもたせたりするのではな
く、SITEコマンドを使用すべきである。
4.1.2.9 STOUコマンド: RFC-959 4.1.3章
STOUコマンドは、/*サーバー内部で*/重複しないようなファイル名でファイ
ルを保存する。サーバーがSTOUコマンドを受け取ると、サーバー側ＦＴＰは
転送に先立ってクライアントに応答する「125 Transfer
Starting」か、
「150 Opening Data Connection」メッセージ内で、実際に保存されるファ
イル名を返さなくてはならない（RFC959に記述されている応答コード250は
誤りである)。
これらのメッセージの正確な書式は、以下のようになる。
125 FILE: pppp
150 FILE: pppp
ppppで表現されているところには、ファイルが書かれる際の重複しないパス
名となる。
4.1.2.10 ＴｅｌｎｅｔのEnd-of-lineコード: RFC-959, 34ページ
/*ＦＴＰを*/実装するときに、制御接続からの一回の読み込みで読み込めた
領域が、一つのコマンドの区切り（TelnetのEOLシーケンス)であると決めつ
けてしまってはいけない。
ディスカッション：
DISCUSSION:
このようにして、サーバー、もしくはユーザー側ＦＴＰはコマンドを処
理、もしくは応答それぞれを行う前に、完全なTelnetのEOLシーケンス
を受信するまで、コントロール接続から、データを読みこまなくてはな
らない。逆にいえば、一回のコントロール接続からの読み込みには、複
数のＦＴＰコマンドが含まれているかもしれない。
4.1.2.11 ＦＴＰ応答: RFC-959 4.2章, 35ページ
サーバー側ＦＴＰは、コントロール接続に対して正しい書式の応答だけを返
さなくてはいけない。RFC959では（以前の版のＦＴＰの仕様と異なり）、
「勝手に作った」応答メッセージを含められないようにしている。
サーバー側ＦＴＰは、RFC959に定義されている応答コードを当てはめるよう
にすべきである。しかし、サーバー側ＦＴＰは続く4.2章にある規則に従う
ならば、必要なときに異なる応答コードを使用することができる。実装時、
応答コードを4xxにするか、5xxにするか選ぶ場合、サーバー側ＦＴＰは
失敗したＦＴＰ操作が、しばらく後でもういちど行えば成功する可能性があ
ると予想されるばあいには、4xx(一時的な失敗）を返すべきである。
ユーザー側ＦＴＰは、サーバー側ＦＴＰが標準ではない応答コードを使用し
ているときに発生する問題点を避けるため、処理の続行を判断するときには
応答コードの３桁の数値のうち、一番上の桁だけを使用すべきである。
ユーザーＦＴＰは複数行にわたる応答を処理出来なくてはならない。もし、
実装時に行数の制限があり、その制限を越えるような場合、ユーザー側ＦＴ
Ｐは制限を越えた行から複数行応答の最後の行までを無視するような形で復
旧させなくてはならない。
ユーザーＦＴＰは応答コード421，("Service
not available, closing
control connection")に対して特別な処理をすべきではない。しかし、サー
バーからのコントロール接続のクローズは検知すべきである。
ディスカッション:
厳密に応答の規則に従ったサーバーの実装は、しばしばユーザープログ
ラムのハングを引き起こす。
注目すべき点として、RFC959は、以前のＦＴＰの仕様にみられた応答規
則の曖昧さを排除してあり、それに従うべきである。
クライアントデーモンに正しくファイル転送が使用できるようにするた
めには、ＦＴＰの一時的な失敗と、恒久的な失敗を区別すして、応答コ
ードを正しく選ぶことが重要である。これらのプログラムは転送の失敗
に対して、再試行するかどうかを決めるために応答コードを使用してい
る。一時的なエラーが発生したときに、恒久的な失敗のためのコード
(5xx)を応答すると、これらのプログラムは中止する必要がないのに中
止してしまう。
応答コードの意味がRFC-959での記述に合っているのであれば、RFC959
のテキストをそのままに使用することにより、均質性が向上する。しか
し、サーバー側ＦＴＰを実装する人は、必要であれば、システム依存の
情報を応答の文字列中に含めてもよい。
4.1.2.12 接続: RFC-959 5.2章
RFC959のこの章の第二段落にある言葉"and
the port used"は間違えている。
（以前から）そして、それらは無視されるべきである。
マルチホームなサーバーホストにおいては、デフォルトのデータ転送ポート
(L-1)
は対応するコントロール接続と同じローカルＩＰアドレスを持つポー
トＬに接続されなければならない。
ユーザー側ＦＴＰは、ＳＹＮＣＨとコントロール接続に対するＩＰ以外の
いかなるＴｅｌｎｅｔ制御コードを送信してはいけない。特に、コントロー
ル接続でＴｅｌｎｅｔオプションのネゴシエーションを試みてはいけない。
しかし、サーバーＦＴＰはDONT/WONTを送信する等の方法でＴｅｌｎｅｔネ
ゴシエーションを受け取り、拒否できなくてはいけない。
ディスカッション:
RFCでは、「サーバーとユーザープロセスは[コントロール接続上で]
Ｔｅｌｎｅｔプロトコルの慣習に従う」と書かれているが、これは、
Ｔｅｌｎｅｔのオプションネゴシエーションを使用するという意図で述
べられたものではない。
4.1.2.13 最小の実装; RFC-959 5.1章
根本となるファイルシステムやオペレーティングシステムにおいて許されな
い場合を除き、すべてのサーバー側ＦＴＰと、ユーザー側ＦＴＰで以下のコ
マンドをサポートしなくてはならない。
タイプ : ASCII
Non-print, IMAGE, LOCAL 8
モード : ストリーム
構造 : ファイル, レコード*
コマンド:
USER, PASS, ACCT,
PORT, PASV,
TYPE, MODE, STRU,
RETR, STOR, APPE,
RNFR, RNTO, DELE,
CWD, CDUP, RMD, MKD, PWD,
LIST, NLST,
SYST, STAT,
HELP, NOOP, QUIT.
*
レコード構造は、ホストのファイルシステムがレコード構造をサポートす
る場合にのみ要求される。
ディスカッション:
供給者はよりプロトコルのより大きなサブセットを実装することを促
される。例えば、プロトコルでは頑強性に関する重要な機能があり、
これらはインターネット使用者の助けになるが、実装されているシステ
ムは多くはない。
ファイルシステムにレコード構造を持たないホストにおいても、STRU
R
コマンドを受諾し、正確にバイトのストリームで記録しても構わない。
4.1.3 仕様について
4.1.3.1 標準でないコマンド
ＦＴＰでは、Ｘで始まるコマンドを「実験的な」コマンドとしての使用を許
している。もし、これらのコマンドが後に標準として採用された場合、Ｘが
ついた形式も実装され続けるべきである。現在のところ、これはディレクト
リ関連コマンドでそうなっている。
RFC-959 「実験的コマンド」
* MKD XMKD
* RMD XRMD
* PWD XPWD
* CDUP XCUP
* CWD XCWD
すべてのＦＴＰの実装において、これらの両方を単純にコマンド検索テーブ
ルのエントリを拡張し、同じと認識できるようにすべきである。
実装について:
ユーザーＦＴＰは、Ｘつきの形式だけが実装されたサーバーに対してア
クセスできるようにモードスイッチを設けたり、以下の手順にしたがっ
て自動的に識別できるようにすることができる。もし、上記のコマンド
をRFC-959形式で発行し、応答コード500か502で失敗した場合、実験形
式で試行しする。応答コードがそれ以外で失敗した場合、ユーザーに
判断を仰ぐ。
4.1.3.2 アイドルタイムアウト
サーパー側のＦＴＰプロセスは、サーバーがコマンドもデーター転送も行わ
れていないようなアクティブではない状態が長く続いたときに、プロセスを
終了させ、コントロール接続をクローズするようなアイドルタイムアウトを
持つべきである。アイドルタイムアウト時間は設定可能であり、デフォルト
の時間は最低５分程度でべきである。
＊ クライアント側のＦＴＰプロセス（RFC959では"User-PI"、ユーザープロト
コルインタプリタ）は、それがプログラムから発行された場合のみ、応答時
にタイムアウトを必要とするだろう。
ディスカッション:
タイムアウトなしでは、もし、対応するクライアントがコントロール接
続をクローズする前にクラッシュしてしまった時に、サーバーＦＴＰの
プロセスがいつまでも残ってしまう。
4.1.3.3 データと制御の協調動作
ディスカッション:
ユーザーはデータ転送中にいつでもSTATコマンドを送ることが可能であ
り、サーバーは、例えば今までに送信済みのバイト数などの状況をすぐ
に応答するようにＦＴＰの設計者は意図した。同じように、ABORコマン
ドはデータ転送中にいつでも使用できるべきであった。
残念ながら、いくつかの小型機上のオペレーティングシステムはそのよ
うな協調動作が難しく、また、ほかのいくつかの実装では、最低限の問
題解決を探した結果として、データ接続と、コントロール接続の協調動
作を許していない。そのような小型のサーバーでさえも、データ転送中
のSTATもしくはABORコマンドを受け取る準備をして、/*その応答を*/延
期するようにしなくてはならない。
4.1.3.4 ＦＴＰのリスタート機構
RFC959の４０〜４１ページにある、応答コード110の記述は間違っている。
正しい説明は以下の通りである。受信側ＦＴＰから、ユーザー側ＦＴＰにコ
ントロール接続を通して送信される応答メッセージは以下の形式を持つ。
110 MARK ssss = rrrr
ここで、
＊ ssssはデータストリーム中のリスタートマーカーの位置に現れたテキス
ト文字列であり、送信側の、ファイルシステム中の位置を符号化したも
のである。
＊ rrrrは、対応する受信側のファイルシステムの位置を符号化したもので
ある。
ファイルシステムとネットワークの実装により固有の符号化は受信側、送信
側のいずれかにおいて、常に同じ方法で生成され、処理される。
リスタートが実装されたＦＴＰにおいては、データストリーム中に、リスタ
ートマーカーを受け取ることになる。リスタートマーカーは、その出現した
場所に関する情報をrrrrという形で符号化する前に、データ中の適当な記憶
領域に挿入される。
リスタートマーカーを送信する側のＦＴＰは、例えば、応答コード110が来
るまでデータ送信を待つなど、同期的に応答コード110が返されることを期
待した動作をしてはいけない。
２つの新しい応答コードを、データのリスタート時、エラーがあったときの
ために定義する。
554 Requested action not taken: invalid REST parameter.
応答コード554は、RESTコマンドに続くＦＴＰのコマンドで返される。
この応答は、サーバーＦＴＰ上の指定されたファイルが、入力された
RESTコマンドで位置決めすることができないことを示している。
555 Requested action not taken: type or stru mismatch.
応答コード555
は、APPEコマンドか、RESTコマンドに続くFTPのコマン
ドで返される。この応答は、現在の転送パラメータ（TYPEとSTRU)と指
定されたファイルの形式との間で矛盾があることを示している。
ディスカッション:
FTP
のリスタート機構では、データストリーム中にリスタートマーカー
を含める必要があるため、そのデータ転送においてブロックモードか、
圧縮モードが要求される。リスタートマーカーの頻度は少なくてもよい
だろう。
リスタートマーカーはデータストリーム中のある場所を示している。し
かし、受信側は、堅牢にデータの書き込みをおこなうためにデータに何
かの変換を加えるかもしれない。一般に、受信側が符号化するときには、
FTP
のデータストリーム中のどこでもこの変換を行えるようにするため
には、何かの状態に関する情報を含まなくてはならない。
たとえば、TYPE Aの転送において、いくつかの受信側ホストはCR+LFの
並びを一つのLF文字に変換してディスクに貯える。もし、リスタート
マーカーがCRとLFの間にあった場合、受信側は、rrrrの複号化におい
て、「ＣＲは受信したが、破棄された」という状態からリスタートに
よる転送を始めなくてはならない。
リスタートマーカーは、データのタイプに関わらず印刷可能なアスキー
文字列として符号化されることが要求されている。
RFC-959
では、リスタートの情報が、「ユーザーに返される」と述べて
ある。これを文字面通りにとってはいけない。一般的に、ユーザー側
FTP は、リスタート情報（ssss,rrrr)を、例えばリスタート制御ファイ
ルへの追加などの不揮発性の記憶領域に記録する。空のリスタート制御
ファイルは、ファイルの転送開始時に作成され、転送が成功したときに
自動的に削除される。このファイルの名前は、転送するファイル名と、
ホスト名が簡単に類推できるようにしておくことが推奨されている。こ
れは多くのテキストエディタでバックアップファイルを作成するときに
使われているような手法である。
FTP のリスタートは、３つのケースがある。
(1) ユーザーからサーバーへの転送
ユーザー側FTP
は、データストリームのなかの適当な場所にリスタ
ートマーカー<ssss>を挿入する。サーバーFTP
がマーカーを受信す
すると、それまでのデータをディスクに記録し、そのファイルシス
テム上の位置と変換状態をrrrrの形に符号化する。その後、コント
ロール接続を経由して「110 MARK ssss = rrrr」の応答を返す。ユ
ーザー側FTP は、(ssss,rrrr）のペアをそのリスタート制御ファイ
ルに付け加えていく。
転送をリスタートするために、ユーザー側ＦＴＰは最後の（ssss,
rrrr）ペアをリスタート制御ファイルから読み出し、ユーザー側の
ファイルシステムの位置を調整し、FTP
サーバーに対して「REST
rrrr」コマンドを送信する。
(2) サーバーからユーザーへの転送
サーバー側FTP
は、データストリームのなかの適当な場所にリスタ
ートマーカー<ssss>を挿入する。ユーザー側FTP
がマーカーを受信
すると、それまでのデータをファイルに記録し、そのファイルシス
テム上の位置と変換状態をrrrrの形に符号化する。その後、コント
ロール接続を経由して「110 MARK ssss = rrrr」の応答を返す。ユ
ーザー側FTP は、(ssss,rrrr）のペアをそのリスタート制御ファイ
ルに付け加えていく。
転送をリスタートするために、ユーザー側FTP
は、最後の（ssss,
rrrr）ペアをリスタート制御ファイルから読み出し、ファイルシス
テム上の位置と変換情報をrrrrから調整し、FTP
サーバーに対して
「REST ssss」を送信する。
(3) サーバーからサーバへの「第三者による」転送
送信側のFTP
サーバーは、データストリーム中の適当な場所にリス
タートマーカーを<ssss>を挿入する。リスタートマーカーを受信す
ると、受信側のFTP
サーバーはそれまでのデータをファイルに記録
し、そのファイルシステム上の位置と変換状態をrrrrの形に符号化
する。そして、コントロール接続を介して、「110
MARK ssss = rr
rr」の応答をユーザーに返す。ユーザー側FTP
はそのリスタート制
御ファイルに(ssss,rrrr)のペアを付け加えていく。
転送をリスタートするためには、ユーザー側FTP
は、最後の（ssss,
rrrr）ペアをリスタート制御ファイルから読み出し、送信側FTP
サ
ーバーに対して「REST ssss」を送信し、受信側FTP
サーバーに対
して「REST rrrr」を送信する。
4.1.4 FTP/ユーザーインタフェース
この章では、ユーザー側FTP
プログラムでのユーザーインタフェースについ
て考察する。
4.1.4.1 パス名の仕様
FTP
が多様な環境下で使用できるために、ユーザー側FTP
は接続先のパス名
がどのような文字列でも良いように実装しなくてはならない。つまり、その
形式と内容はクライアント側のオペレーティングシステム上で使用されてい
るものに限定されない。
ディスカッション：
特に、接続先のパス名は任意の長さが許され、そして、空白(0x20)を含
むすべての表示可能な文字が使用可能である。RFC959では、CR、LFを除
くすべての７ビットのアスキー文字がパス名に含まれることを許してい
る。
4.1.4.2 「QUOTE」 コマンド
ユーザー側FTP
プログラムは、サーバーに対して任意の文字列を送信し、す
べての応答メッセージをユーザーに対して表示するためのコマンドとして
「QUOTE」コマンドを実装しなくてはならない。
「QUOTE」コマンドを使いやすくするため、ユーザー側FTP
は、ユーザーが
入力したコマンドを保存しておき、データ転送が開始したときにまとめて送
るのではなく、ユーザーがコマンドを入力するとすぐ制御コマンドを送信す
るようにすべきである。
ディスカッション:
「QUOTE」コマンドは、SITEやALLOなどシステム特有のコマンドに対し
てユーザーがアクセスできるようにするため、また、ユーザー側FTP
で
実装されていない新しい機能や付加機能を使用するために重要である。
たとえば、「QUOTE」コマンドは区別が必要なホストに表示ファイルを
送信するとき、「TYPE A T」を指定するときに、たとえ、ユーザー側
FTPがTYPEコマンドを認識しない場合でも有効である。
4.1.4.3 ユーザーへの結果表示
ユーザー側FTP
は、ユーザーに対して受信したすべてのエラー応答の全文を
表示すべきでる。ユーザー側FTP
は、問題の解析のために「おしゃべり」モ
ードを用意して、送信したすべてのコマンドと、すべての応答コードと応答
文字を表示できるようにすべきである。
4.1.4.4 同期の維持
ユーザー側FTP
はサーバーとの間のコマンド同期を維持するために、そのス
テートマシンは応答の欠落や予期しない応答を許すようにすべきである。
4.1.5 FTP 要求仕様一覧
| | | | |推| |
| | | | |奨| |
| | | | |し| |
| |必|推|許|な|禁|脚
| |須|奨|可|い|止|注
機能 | 章 | | | | | |
-------------------------------------------|---------------|--|--|--|--|--|--
TYPE NとTYPE Tが同じなら、同じ実装をする |4.1.2.2 | |ｘ| | | |
可能ならレコードとファイル形式が変換可能 |4.1.2.4 | |ｘ| | | |
UserはストリームモードでPORTコマンドを送信 |4.1.2.5 | |ｘ| | | |
サーバーFTPはＰＡＳＶを実装する |4.1.2.6 |ｘ| | | | |
PASVは転送毎に必要 |4.1.2.6 |ｘ| | | | |
NLSTの応答はRETRコマンドで使用可能 |4.1.2.7 |ｘ| | | | |
LISTとNLSTでの暗黙のTYPE |4.1.2.7 | |ｘ| | | |
非標準コマンドにSITEを使用 |4.1.2.8 | |ｘ| | | |
STOUは使用するパス名を応答する |4.1.2.9 |ｘ| | | | |
コマンドの区切りとしてTCPのREAD境界を使用 |4.1.2.10 | | | | |ｘ|
サーバーは正しい応答形式のみを送信 |4.1.2.11 |ｘ| | | | |
可能ならユーザー定義応答コードを使用 |4.1.2.11 | |ｘ| | | |
4.2章にある新しい応答コードを使用 |4.1.2.11 | | |ｘ| | |
クライアントは応答コードの上位一桁だけ使用 |4.1.2.11 | |ｘ| | | |
クライアントは複数行応答を処理する |4.1.2.11 |ｘ| | | | |
クライアントは応答コード421を特殊処理する |4.1.2.11 | | | |ｘ| |
標準データポートは制御接続と同じIPアドレス |4.1.2.12 |ｘ| | | | |
クライアントのSYNCとIP以外のTelnetCmds使用 |4.1.2.12 | | | | |ｘ|
Telnetのオプションのネゴシエーション |4.1.2.12 | | | | |ｘ|
サーバーはTelnetオプションの処理 |4.1.2.12 |ｘ| | | | |
「実験的」ディレクトリコマンドの処理 |4.1.3.1 | |ｘ| | | |
サーバーでのアイドルタイムアウト |4.1.3.2 | |ｘ| | | |
タイムアウト時間の調節 |4.1.3.2 | |ｘ| | | |
リスタートマーカでの受信チェックポイント |4.1.3.4 | |ｘ| | | |
送信側は応答コード110を同期的に処理 |4.1.3.4 | | | | |ｘ|
| | | | | | |
サポートする形式 | | | | | | |
ASCII - Non-Print (AN) |4.1.2.13 |ｘ| | | | |
ASCII - Telnet (AT) （ANと同じなら） |4.1.2.2 | |ｘ| | | |
ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |ｘ| | |
EBCDIC - (どのような形式でも) |959 3.1.1.2 | | |ｘ| | |
IMAGE |4.1.2.1 |ｘ| | | | |
LOCAL 8 |4.1.2.1 |ｘ| | | | |
LOCAL m |4.1.2.1 | | |ｘ| | |2
| | | | | | |
サポートするモード: | | | | | | |
ストリームモード |4.1.2.13 |ｘ| | | | |
ブロックモード |959 3.4.2 | | |ｘ| | |
| | | | | | |
サポートする構造: | | | | | | |
ファイル |4.1.2.13 |ｘ| | | | |
レコード |4.1.2.13 |ｘ| | | | |3
ページ |4.1.2.3 | | | |ｘ| |
| | | | | | |
| | | | | | |
サポートするコマンド: | | | | | | |
USER |4.1.2.13 |ｘ| | | | |
PASS |4.1.2.13 |ｘ| | | | |
ACCT |4.1.2.13 |ｘ| | | | |
CWD |4.1.2.13 |ｘ| | | | |
CDUP |4.1.2.13 |ｘ| | | | |
SMNT |959 5.3.1 | | |ｘ| | |
REIN |959 5.3.1 | | |ｘ| | |
QUIT |4.1.2.13 |ｘ| | | | |
| | | | | | |
PORT |4.1.2.13 |ｘ| | | | |
PASV |4.1.2.6 |ｘ| | | | |
TYPE |4.1.2.13 |ｘ| | | | |1
STRU |4.1.2.13 |ｘ| | | | |1
MODE |4.1.2.13 |ｘ| | | | |1
| | | | | | |
RETR |4.1.2.13 |ｘ| | | | |
STOR |4.1.2.13 |ｘ| | | | |
STOU |959 5.3.1 | | |ｘ| | |
APPE |4.1.2.13 |ｘ| | | | |
ALLO |959 5.3.1 | | |ｘ| | |
REST |959 5.3.1 | | |ｘ| | |
RNFR |4.1.2.13 |ｘ| | | | |
RNTO |4.1.2.13 |ｘ| | | | |
ABOR |959 5.3.1 | | |ｘ| | |
DELE |4.1.2.13 |ｘ| | | | |
RMD |4.1.2.13 |ｘ| | | | |
MKD |4.1.2.13 |ｘ| | | | |
PWD |4.1.2.13
|ｘ| | | | |
LIST |4.1.2.13 |ｘ| | | | |
NLST |4.1.2.13
|ｘ| | | | |
SITE |4.1.2.8 | | |ｘ| | |
STAT |4.1.2.13 |ｘ| | | | |
SYST |4.1.2.13 |ｘ| | | | |
HELP |4.1.2.13 |ｘ| | | | |
NOOP |4.1.2.13 |ｘ| | | | |
ユーザーインタフェース: |
| | | | | |
パス名は自由 |4.1.4.1 |ｘ| | | | |
「QUOTE」コマンドの処理 |4.1.4.2 |ｘ| | | | |
制御コマンドの即時送信 |4.1.4.2 | |ｘ| | | |
ユーザーへエラーメッセージを表示 |4.1.4.3 | |ｘ| | | |
「おしゃべり」モード |4.1.4.3 | |ｘ| | | |
サーバーとの接続を維持 |4.1.4.4 | |ｘ| | | |
脚注:
(1) For the values shown earlier.
(2) ここで、mはメモリのビット長。
(3) ホストがレコード構造のファイルシステムを有する場合。それ以外の場合はオプシ
ョン。
Copyright 1996 by Jarle (jgaa) Aase