サイト内関連リンク：
RFC 2577 FTP セキュリティ考察 (日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc959.txt
2006/03/20 0.1.0 初版
ソーシャルブックマーク：
サイト内関連リンク：
RFC 2577 FTP セキュリティ考察 (日本語訳)
この文書は File Transfer Protocol (FTP) の公式な仕様である。この文書の配布は無制限である。
本仕様のこのバージョンには、以下の新しいオプションコマンドが含まれている：
CDUP (親ディレクトリに移動)
SMNT (構造マウント)
STOU (一意保存)
RMD (ディレクトリ削除)
MKD (ディレクトリ作成)
PWD (ディレクトリ表示)
SYST (システム)
この仕様は過去のバージョンと互換性を持つことに注意してほしい。
FTP の目的は、1) ファイル(コンピュータプログラムやデータ)の共有を推進すること、2) リモートコンピュータの間接的利用または暗黙的利用を推進すること、3) ホスト間のファイルシステムの違いからユーザーを保護すること、4) データを確実かつ効率的に転送すること、以上の 4 点である。FTP は端末ユーザーによる直接利用も可能だが、主にプログラムによる使用を意図して設計されている。
この仕様の試みは、最上位ホスト・最低位ホスト・パーソナルワークステーション・TAC の利用者からの様々な要求を、単純で容易に実装できるプロトコル設計によって満たすことである。
この文書は Transmission Control Protocol (TCP) [2] と Telnet Protocol [3] の知識を前提としている。これらの文書は ARPA-Internet protocol handbook [1] に含まれている。
このセクションでは、FTP の歴史・用語・モデルに付いて議論する。このセクションで定義されている用語は FTP において特別な意味を持つものだけである。用語の一部は FTP モデルに特化しているため、読者はこの用語集を参照している間に「FTP モデル」セクションを参照してもよい。
FTP は長年にわたり改良されてきた。付録 III は FTP に関連する RFC 文書の歴史的な編集物である。そこには 1971 年に M.I.T. のホスト上の実装向けに開発された最初のファイル転送メカニズム(RFC 114)と、RFC 141 でのコメントと議論とが含まれている。
RFC 172 はホストコンピュータ間(ターミナル IMP を含む)のファイル転送のためのユーザーレベル指向プロトコルを提供した。追加のレビューを受け、その改定版である RFC 265 が FTP を更新した。また一方で、RFC 281 がさらなる変更を示唆した。1982 年 1 月、RFC 294 において "データ型設定(Set Data Type)" 処理が提案された。
RFC 354 が RFC 264 と RFC 265 とを時代遅れにした。File Transfer Protocol は現在 ARPANET 上のホスト間でファイル転送を行うためのプロトコルとして定義されており、FTP の主要な機能はホスト間の効率的かつ信頼できるファイル転送と、リモートのファイルストレージ能力の有効利用を可能にすることと定義されている。誤りや強調すべき点、このプロトコルへの追加について更なるコメントを RFC 385 が行った一方で、稼動中のサーバー FTP とユーザー FTP とに関するステータスレポートを RFC 414 が提供した。(書き切るには多過ぎる他の RFC の中でも)1973 年に公開された RFC 430 は、FTP に付いてさらなるコメントを提供した。最終的に "公式(official)" の FTP 文書が RFC 454 として 公開された。
FTP の最終バージョンから 1973 年 7 月までの間に多くの重要な変更が行われたが、基本的構造は同じままであった。これらの変更を反映した新しい "公式(official)" 仕様が RFC 542 として公開された。しかしながら古い仕様に基づいた多くの実装は更新されなかった。
1974 年、RFC 607 と RFC 614 とが、引き続き FTP に関するコメントを行った。さらなる設計変更と比較的重要でない改良とを RFC 624 が提案した。1975 年、"Leaving Well Enough Alone" と題された RFC 686 が、FTP の初期・後期全てのバージョン間の差異について議論した。RFC 686 のファイル印刷の話題に関する小さな改定を RFC 691 が提供した。
下層プロトコルが NCP から TCP へと変化したことをきっかけに、TCP 上で利用する FTP の仕様として、前述の活動の中から RFC 765 において不死鳥が生まれた。
FTP 仕様のこのバージョンはいくつかの比較的重要でない文書の間違いを訂正し、一部のプロトコル機能の説明を改善し、いくつかの新しいオプションを追加することを目的としている。
本仕様のこのバージョンには、具体的に以下の新しいオプションコマンドが含まれている。
CDUP - 親ディレクトリへの移動 SMNT - 構造マウント STOU - 一意保存 RMD - ディレクトリ削除 MKD - ディレクトリ作成 PWD - ディレクトリ表示 SYST - システム
この仕様は以前のバージョンと互換性を持つ。以前の仕様に適合して実装されたプログラムは自動的にこの仕様にも適合するはずである。
これまでの定義を念頭に置くと、FTP サービスは以下のように図式化できる。
+-----------+
|+---------+|
||ユーザー || +--------+
||I/F |<--->|ユーザー|
|+----^----+| +--------+
+----------+ | | |
|+--------+| FTP コマンド |+----V----+|
||サーバー|<---------------->|ユーザー ||
|| PI || FTP リプライ || PI ||
|+---^----+| |+----^----+|
| | | | | |
+--------+ |+---V----+| データ接続 |+----V----+| +--------+
|ファイル|<--->|サーバー|<---------------->|ユーザー |<--->|ファイル|
|システム| || DTP || || DTP || |システム|
+--------+ |+--------+| |+---------+| +--------+
+----------+ +-----------+
サーバー側 FTP ユーザー側 FTP
注意：1. データ接続は両方向に使用される
2. データ接続は常時必要なわけではない
図1 FTP 使用のモデル
図 1 のモデルにおいて、ユーザープロトコルインタープリタがコントロール接続を開始する。コントロール接続は Telnet プロトコルに従う。ユーザーの手引きにより user-PI は標準 FTP コマンドを生成し、コントロール接続経由でそれをサーバープロセスへと送信する。(例えば TAC 端末からサーバー側 FTP へとユーザーが直接コントロール接続を確立し、独自に FTP コマンドを生成してもよい。この場合ユーザー側 FTP プロセスを迂回することになる。) コマンドへの応答として、コントロール接続を通してサーバー側 PI からユーザー側 PI へと標準リプライが送信される。
FTP コマンドはデータ接続のためのパラメータ(データポート・転送モード・表現タイプ・構造)と、ファイルシステムの操作(保存・取得・追加・削除など)とを指定する。ユーザー側 DTP またはその代替は指定されたデータポートで "待ち受け(listen)" るべきであり、サーバーがデータ接続を開始し、指定されたパラメータにしたがってデータ転送を開始する。コントロール接続経由で FTP コマンドを発行するホストと同じホストがデータポートを開く必要はないが、ユーザーまたはユーザー側 FTP プロセスは指定のデータポートで "待ち受け(listen)" ることを確実にしなければならないことに注意してほしい。データ接続は送信と受信を同時に行えることにも注意するべきである。
ローカルホストではない 2 ホスト間でファイル転送をしたいとユーザーは考えるかもしれない。その場合ユーザーは 2 台のサーバーとコントロール接続を確立し、その後それらの間のデータ接続を手配する。この方法においてコントロール情報はユーザー側 PI へと渡されるが、データは 2 台のサーバーのデータ転送プロセス間で転送される。このようなサーバー - サーバーの対話のモデルを以下に示す。
コントロール +----------------+ コントロール
+--------->| ユーザー側 FTP |<----------+
| | ユーザー側 PI | |
| | "C" | |
V +----------------+ V
+----------------+ +----------------+
| サーバー側 FTP | データ接続 | サーバー側 FTP |
| "A" |<---------------------->| "B" |
+----------------+ ポート(A) ポート(B) +----------------+
図 2
FTP はデータ転送中にコントロール接続が開かれていることを要求する。実際にコントロール接続を閉じるのはサーバーだが、FTP サービスの利用を終了したときにコントロール接続を閉じる要求を出すのはユーザー側の責任である。コマンドなしにコントロール接続が閉じられた場合、サーバーはデータ転送を中止してもよい。
FTP と Telnet との関係：
コントロール接続上において FTP は Telnet プロトコルを使用する。これは二種類の方法で実現できる：第一は、ユーザー側 PI または サーバー側 PI が自身の機能の中に直接 Telnet プロトコルの規則を実装すること、第二は、ユーザー側 PI またはサーバー側 PI がシステム内の既存の Telnet モジュールを使用することである。
実装の容易さ、コードの共有、モジュールプログラミングなどは第二の方法を支持する。効率性や非依存性などは第一の方法を指示する。実際のところ FTP は Telnet プロトコルにわずかしか依存していないため、第一の方法でも大量のコードを必要とするわけではない。
ファイルはデータ接続経由でのみ転送される。コントロール接続はコマンド(実行されるべき機能を表す)の送信と、それらのコマンドへのリプライ(「FTP リプライ」セクション参照)の送信とに使用される。いくつかのコマンドがホスト間のデータ転送に関連する。そのようなデータ転送コマンドには、データビットが転送される方法を指定する MODE コマンドや、データの表現方法を定義する STRU コマンド・TYPE コマンドも含まれる。基本的にこの転送と表現は独立したものだが、"ストリーム(Stream)" 転送モードはファイル構造の属性に依存するし、"圧縮(Compressed)" 転送モードが使用される場合には、フィラー用バイトの内容はその表現型に依存する。
データは送信側ホストの記憶装置から受信側ホストの記憶装置へと転送される。多くの場合この二つのシステム間のデータ保存形式は異なるため、データに何らかの変換を行う必要がある。例えば NVT-ASCII は異なるシステム上では異なる保存形式を持つ。DEC TOPS-20 は通常 36 ビットワード内に左詰された 7 ビット ASCII 文字として NVT-ASCII を保存する。IBM のメインフレームは 8 ビットの EBCDIC コードとして NVT-ASCII を保存する。Multics は 36 ビットワード内の 9 ビット文字として NVT-ASCII を保存する。異なるシステム間でテキストを送信する場合、標準的な NVT-ASCII 表現へと文字を変換することが望ましい。送信側サイトおよび受信側サイトは、その内部表現と標準的表現との間で必要とされる変換を行うことになる。
異なるワード長を持つホストシステム間で(文字コードではなく)バイナリデータを送信する場合、表現形式に関連する別の問題が発生する。送信側がデータを送信する方法と受信側がそれを保存する方法とは、常に明確なわけではない。例えばワード長が 32 ビットのシステムから 36 ビットのシステムへと 32 ビットバイトのデータを送信する場合、後者のシステムではその 32 ビットバイトを 36 ビットワード内に右詰めして保存することが(効率性や利便性のために)望ましいかもしれない。いずれにしても、データ表現と変換機能とを指定する選択権はユーザーが持つべきである。FTP は非常に限られたデータ型の表現しか提供しないことに注意するべきである。この限られた能力以上の変換は、ユーザーによって直接実行されるべきである。
FTP におけるデータ表現は、表現型を指定するユーザーによって処理される。この表現型は "論理バイト幅(logical byte size)" として言及される解釈のためのバイト幅を(ASCII または EBCDEC として)暗黙的に、または(ローカルバイトとして)明示的に定義する可能性がある。データ接続上を転送される "転送バイト幅(transfer byte size)" と呼ばれるバイト幅とこのバイト幅とは無関係であることに注意してほしい。これら 2 つのバイト幅を混同してはならない。例えば NVT-ASCII の論理バイト幅は 8 ビットである。表現型がローカルバイトの場合、TYPE コマンドの 2 番目のパラメータにその論理バイト幅を指定しなければならない。転送バイト幅は常に 8 ビットである。
これはデフォルトの型であり、全ての FTP 実装によって受け入れられなければならない。両ホストがともに EBCDIC 型のほうが都合のよい場合を除き、これは主にテキストファイルの転送を意図している。
送信側は内部的な文字表現を標準的な 8 ビットの NVT-ASCII 表現へと変換する(Telnet 仕様参照)。受信側はそのデータを標準形式から自分の内部形式へと変換することになる。
テキスト行の終端を表さなければならないところでは、NVT 標準にしたがってシーケンス <CRLF> が使用されるべきである。(「データの表現と保存」の最終セクションにあるファイル構造の議論参照)
標準である NVT-ASCII 表現を使用するということは、データが 8 ビットバイトとして解釈されなければならないということを意味している。
ASCII 型と EBCDIC 型とのための書式パラメータは以下で議論されている。
内部文字表現として EBCDIC を使用するホスト間で効率よく転送することを目的とした型である。
転送中、データは 8 ビットの EBCDIC 文字として表現される。EBCDIC 型と ASCII 型との機能仕様の違いは、その文字コードだけである。
構造を示す目的で EBCDIC 型と共に(レコード終端(構造の議論参照)ではなく)行終端が使用されることは稀であるが、必要な場合には文字 <NL> を使用するべきである。
転送データは 8 ビット幅の転送バイトに詰められた連続ビットとして送信される。受信側サイトはそのデータを連続ビットとして保存しなければならない。保存システムの構造は、何らかの都合のよい境界(バイト・ワード・ブロック)のために、ファイルに(またはレコード構造ファイルの場合は各レコードに)パディングを必要とするかもしれない。このパディングは全てゼロでなければならず、ファイルの終端にのみ現れることが許される。またファイルを取得したときにパディングを取り除くことが出来るように、パディングビットを特定する手段がなければならない。保存サイトのファイルをユーザーが処理できるように、このパディング変換は広く公開されるべきである。
イメージ型は、複数ファイルの効率的な取得と保存、およびバイナリデータの転送を目的としている。全ての FTP 実装がこの型を受け入れられることを推奨される。
データは、必須の第二引数であるバイト幅で指定される論理バイト幅で転送される。そのバイト幅の値は 10 進整数でなければならず、デフォルト値は存在しない。論理バイト幅が転送バイト幅と同じである必要はない。これらのバイト幅が異なる場合、この論理バイトは転送バイトの境界とは無関係に、終端に必要なパディングを付けて連続的に詰められるべきである。
受信側に届いたデータは、その論理バイト幅とその特定のホストとに依存する形で変換される。この変換方法は可逆的(すなわち、同じパラメータを使用すれば同一のファイルを取得できる)でなければならず、FTP の実装者によって広く公開されるべきである。
例えば 36 ビットの浮動小数点数値を 32 ビットワードのホストへと送信する場合、ユーザーはそのデータを 36 ビットの論理バイト幅を持つローカルバイトとして送信することができる。その後受信側ホストは、容易に扱えるようにその論理バイトを保存したいだろう。この例の場合なら、36 ビットの論理バイトを 64 ビットのダブルワードへと置くことで十分なはずである。
別の例として、36 ビットワード幅を持つホスト同士は、TYPE L 36 を使用することで互いにワードでデータを送信することが出来る。そのデータは 8 ビット幅の転送バイトに詰められれ、9 転送バイトが 2 ホストワードを運ぶことになるだろう。
ASCII 型と EBCDIC 型は、共に第二の(任意の)引数を取る。これはファイルに関連する垂直書式の種類を表すためのものである。FTP では以下のデータ表現型が定義されている。
文字ファイルは 1)印刷のため、2)いったん保存して後に取得するため、3)処理するため、このうちの 1 つを目的としてホストへと送信されるだろう。印刷のためにファイルが送信される 1 つ目のケースでは、垂直書式がどのように表現されているのかを受信側ホストが知らなければならない。2 番目のケースでは、ホストにファイルを保存し、その後それを正確に同じ形で取得できなければならない。最後のケースでは、あるファイルをあるホストから別のホストへと移動し、後者のホスト上で過度のトラブルなしにそのファイルを処理できるべきである。ASCII または EBCDIC の形式だけでは、これら全ての条件を満たすことができない。そのためこれらの型は、以下の三つの形式のひとつを特定する第二の引数を持つ。
これは第二の(書式)引数が省略された場合に使用されるデフォルト形式である。Non-print 形式は全ての FTP 実装によって受け入れられなければならない。
ファイルに垂直書式の情報が含まれる必要はない。このファイルが印刷プロセスに渡された場合、印刷プロセスは語間とマージンとに標準的な値を仮定してよい。
一般的にこの形式は、処理されることが目的のファイル、または保存することだけが目的のファイルと共に使用される。
ファイルはプリンタプロセスが適切に解釈するであろう ASCII/EBCDIC の垂直書式制御(すなわち、<CR>・<LF>・<NL>・<VT>・<FF>)を含む。<CRLF> は(正確にこの順序の場合にのみ)行終端を表す。
ファイルは ASA (FORTRAN) の垂直書式制御文字を含む(RFC 740 の Appendix C と、1964 年 10 月の Communications of the ACM, Vol. 7, No. 10, p. 606 とを参照)。ASA 標準にしたがって書式化された行またはレコードでは、先頭の文字は印刷されない。先頭文字は用紙の垂直移動を決定するために使用されるべきものであり、その動作はレコードの残りの部分が印刷される前に行われるべきである。
ASA 標準は以下の制御文字を定義している：
| 文字 | 垂直間隔制御 |
| 空白 | 用紙を 1 行分上に移動する |
| 0 | 用紙を 2 行分上に移動する |
| 1 | 用紙を次ページの先頭まで移動する |
| + | 移動しない、つまり重ね打ちする |
構造化された実体の終わりをプリンタプロセスが判断するための、何らかの手段がなければならないことは明らかである。ファイルがレコード構造(後述)であれば、転送中および保存中に各レコードに明示的に印が付けられるため、これは問題にならない。ファイルがレコード構造を持たない場合、印刷行を区切るために行終端シーケンス <CRLF> が使用される。しかしながら、このような書式制御文字は ASA 制御文字によって上書きされる。
様々な表現型に加えて、FTP はファイル構造の指定も許可している。FTP では 3 つのファイル構造が定義されている：
STRU コマンドが使用されなかった場合にはデフォルトでファイル構造とみなされるが、"テキスト(text)" ファイル(すなわち TYPE ASCII または TYPE EBCDIC を伴うファイル)のためのファイル構造とレコード構造とは共に、全ての FTP 実装によって受け入れられなければならない。ファイルの構造は、ファイルの転送モード(「転送モード」セクションを参照)とそのファイルの解釈・保存との両方に影響するだろう。
ファイルの "本来の(natural)" 構造は、そのファイルを保存するホストに依存するだろう。IBM メインフレームではソースコードファイルは固定長レコードに保存されるが、DEC TOPS-20 では(例えば <CRLF> によって)行単位に区切られた文字のストリームとして保存される。このような本質的に異なるサイト間でのファイル転送を有用なものにするには、一方のサイトのファイルに関する仮定をもう一方のサイトが知る方法がなければならない。
本質的にファイル指向のサイトと、本質的にレコード指向のホストとが存在する。ある構造のファイルを、それと異なる構造の指向を持つホストへと送信する場合に問題が発生する可能性がある。レコード構造のテキストファイルがファイル指向のホストへと送信される場合、そのホストはそのファイルに対し、レコード構造に基づいた内部変換を適用するべきである。明らかにこの変換は便利なものであるべきだが、レコード構造を使用しても同一のファイルを取得できるように、可逆的でなければならない。
ファイル構造を持つファイルをレコード指向のホストへと送信する場合、そのホストがローカルで処理可能なレコードへと、どのような条件でファイルを分割するべきかという問題がある。この分割が必要な場合、FTP 実装は区切り文字として行終端シーケンス(ASCII テキストファイルなら <CRLF>、EBCDIC テキストファイルなら <NL>)を使用するべきである。FTP 実装がこの手法を採用するなら、そのファイルがファイル構造で取得される場合に備え、逆方向に変換する準備が出来ていなければならない。
ファイ構造は STRU コマンドが使用されなかった場合にデフォルトと見なされる構造である。
ファイル構造には内部構造が存在せず、ファイルはデータバイトの連続的なシーケンスと見なされる。
"テキスト(text)" ファイルのために、全ての FTP 実装によってレコード構造が受け入れられなければならない。
レコード構造の場合、ファイルは連続的なレコードから構成される。
不連続なファイルを転送するために、FTP はページ構造を定義している。この種のファイルは時に "ランダムアクセスファイル(random access files)"、または "穴のあるファイル(holey files)" と呼ばれる。これらのファイル群の中には時々、全体としてのファイルに関連する情報(例えばファイルデスクリプタ)や、ファイル中の 1 セクションに関連する情報(例えばページアクセスコントロール)、またはその両方の情報が存在する。ファイルのこれらの区分のことを、FTP ではページと呼ぶ。
様々なページサイズとそれに関連する情報とを提供するために、各ページはページヘッダと共に送信される。ページヘッダは以下の定義済みフィールドを持つ：
全てのフィールドは 1 論理バイトである。この論理バイト幅は TYPE コマンドで指定される。ページ構造に関するさらなる詳細と特別な場合とに関しては、付録 I を参照してほしい。
パラメータに関する注意：送信したファイルと同一のファイルを取得したい場合、そのファイルは同じパラメータで保存・取得しなければならない。逆に言うと FTP 実装は、保存・取得に使用されたパラメータが同じであれば、元のファイルと同じファイルを返さなければならない。
データ転送のメカニズムは、適切なポートへのデータ接続のセットアップと、転送パラメータの選択とから構成される。ユーザー側 DTP とサーバー側 DTP はそれぞれデフォルトのデータポートを持っている。ユーザー側プロセスのデフォルトデータポートはコントロール接続ポート(つまり U)と同じである。サーバー側プロセスのデフォルトデータポートはコントロール接続ポートの直前のポート(つまり L - 1)である。
転送バイト幅は 8 ビットである。このバイト幅は実際に転送されるデータにのみ関係し、ホストのファイルシステム内のデータ表現とは無関係である。
受信側のデータ転送プロセス(これはユーザー側 DTP または第 2 のサーバー側 DTP の可能性がある)は、転送を要求するコマンドを送るのに先立って、データポートで "待ち受け(listen)" なければならない。FTP のリクエストコマンドがデータ転送の方向を決定する。転送リクエストを受信したサーバーは、そのポートに対してデータ接続を開始する。データ接続が確立すると DTP 間でデータ転送が開始され、サーバー側 PI はユーザー側 PI へと確認応答を送信する。
デフォルトのデータポートの使用は全ての FTP 実装がサポートしなければならない。デフォルトではないポートへの変更はユーザー側 PI だけが要求できる。
PORT コマンドを使用することで、ユーザーは代替のデータポートを指定することが出来る。ファイルを TAC ラインプリンタにダンプしたり、第三のホストから取得することをユーザーは望むかもしれない。後者の場合、一方のサーバーは、もう一方のサーバーが開始するであろう接続を "待ち受け(listen)" るように(FTP のコマンドによって)指示される。ユーザー側 PI は一方のサーバー側 PI に対し、もう一方のサーバーのデータポートを示す PORT コマンドを送信する。最後に適切な転送コマンドが両者に送信される。ユーザー側コントローラとこれらのサーバーとの間のコマンド・リプライの正確なシーケンスは「FTP リプライ」セクションで定義されている。
一般に、データ接続の保守(その開始と終了)はサーバーの責任である。例外は、EOF を示すためには閉じられなければならない接続を必要とする転送モードでユーザー側 DTP がデータを送信する場合である。以下のような状況の場合、サーバーがデータ接続を閉じなければならない(MUST)：
これ以外の場合、接続を閉じるのはサーバーの選択となる。サーバーはその結果を 250 リプライまたは 226 リプライによってユーザー側プロセスへ示さなければならない。
デフォルトのデータ接続ポート：デフォルトのデータポートの使用は全ての FTP 実装がサポートしなければならない。デフォルトではないポートへの変更はユーザー側 PI だけが要求できる。
デフォルトではないデータポートの交渉：ユーザー側 PI は PORT コマンドによって、デフォルトではないユーザー側データポートを指定することが出来る。またユーザー側 PI は PASV コマンドによって、サーバーに対してデフォルトではないサーバー側データポートを要求することが出来る。これらのコマンドによってデータ接続の両端において新しいポートを使用することができる。接続はアドレスの組によって定義されるため、異なるデータ接続を得るにはこれらのアクションのどちらかだけで十分である。
データ接続の再利用：ストリームモードのデータ転送を使用する場合、ファイルの終了は接続を閉じることによって示されなければならない。信頼できる通信を保証するために TCP はタイムアウトのための接続記録を保持しなければならないため、セッション中に複数のファイルを転送しようとすると問題が発生する。したがってこの接続をすぐに再開することは出来ない。
この問題の解決策は二つある。ひとつはデフォルト以外のポートを交渉する方法、もうひとつは別の転送モードを使用する方法である。
転送モードについての注釈。接続の終了が正常だったのか早すぎたかのかを判断できないため、本質的にストリーム転送モードは信頼できるものではない。他の転送モード(ブロック、圧縮)は、ファイルの終了を示すために接続を閉じることはない。これらの転送モードは、データ接続の内容を解析することでファイルの終了を判定できる FTP エンコードを持つ。したがってこれらのモードを使用すると、複数のファイルを転送するためにデータ接続を開いたままにしておくことが出来る。
データ転送において次に考慮すべきは、適切な転送モードの選択である。3 つのモードが存在する：データを形式化することで再開処理を可能にするモード、効率的な転送のためにデータを圧縮するモード、ほとんど(あるいは全く)処理を行わずにデータを転送するモードである。最後のモードは、処理の種類を決定するためにその構造属性と相互に影響しあう。圧縮モードにおける表現型は、フィラーバイトを決定する。
全てのデータ転送は、明示的に示されるファイル終端(EOF)か、データ接続を閉じることによる暗黙的なファイル終端(EOF)かによって完了しなければならない。レコード構造を持つファイルでは、最後のものを含む全レコード終端マーカー(EOR)は明示的である。ページ構造で転送されるファイルでは、ページタイプ "最終ページ(last-page)" が使用される。
注意：このセクションのこれ以降においてバイトとは、明示的に他の意味を述べていない限り "転送バイト(transfer byte)" を意味する。
標準化された転送のために、送信側ホストは自身の内部的な行端やレコード端の表現を、転送モードやファイル構造によって規定された表現へと変換し、受信側ホストは自身の内部表現への逆変換を行う。IBM メインフレームのレコードカウントフィールドは他のホストでは認識されない可能性があるため、レコード終端情報は、ストリームモードでは 2 バイトの制御コードとして、ブロックモードまたは圧縮モードではフラグビットとして転送されるだろう。レコード構造を持たない ASCII ファイル内または EBCDIC ファイル内の行端は、それぞれ <CRLF> あるいは <NL> で示されるべきである。一部のシステムにとってこれらの変換は余分な作業を課されることになるため、レコード構造を持たないテキストファイルを転送する同一のシステムは、バイナリ表現とストリームモードとを使用することを望むかもしれない。
FTP では以下の転送モードが定義されている：
データはバイトのストリームとして転送される。使用される表現型に制限は無く、レコード構造も許可される。
レコード構造のファイルの場合、EOR と EOF はそれぞれ 2 バイトの制御コードで表される。この制御コードの 1 バイト目は全ビットが 1 のエスケープ文字である。2 バイト目は、最下位ビットのみ 1 なら EOFを、最下位から 2 番目のビットのみ 1 なら EOF を表す。つまりこのバイトは、EOR なら値 1、EOF なら値 2 となる。下位 2 ビットを共に 1 にする(つまり値 3 にする)ことによって、EOR と EOF とを同時に表すこともできる。全てのビットが 1 のバイトをデータとして扱いたい場合、その次のバイトにも同じ値を繰り返さなければならない。
ファイル構造における EOF は送信側ホストがデータ接続を閉じることによって表され、全てのバイトがデータバイトである。
ファイルは 1 バイト以上のヘッダバイトに続く一連のデータブロックとして転送される。ヘッダバイトにはカウントフィールドと識別子コードとが含まれる。カウントフィールドはデータブロック全体の長さをバイト単位で表し、したがって次のデータブロックの開始位置を表している(フィラービットは無い)。識別子コードは、ファイルの最終ブロック(EOF)、レコードの最終ブロック(EOR)、再開マーカー(エラーの回復と再開のセクションを参照)、不良データ(つまり転送されているデータにはエラーの疑いがあり、信頼できないということ)を定義する。この最後のコードは FTP におけるエラー制御を意図したものではない。これは、特に重要なデータ(例えば地震や気象のデータ)を交換するサイトが、ローカルのエラーを無視してでも全てのデータを送受信したい場合に、転送データのその部分が不良であることを示すために導入されている。このモードではレコード構造が許可されている。また任意の表現型を使用してよい。
ヘッダは 3 バイトである。ヘッダの 24 ビットのうち下位 16 ビットはバイト数を表さなければならず、上位 8 ビットは後述の識別子コードを表さなければならない。
ブロックのヘッダ
+----------------+----------------+----------------+
| 識別子 | バイト数 |
| 8 ビット | 16 ビット |
+----------------+----------------+----------------+
識別子コードは識別子バイト内のビットフラグによって表される。4 つのコードが割り当て済みであり、以下の各コードはバイト内の対応するビットを表した 10 進数値である。
| コード | 意味 |
| 128 | データブロックの終わりは EOR である |
| 64 | データブロックの終わりは EOF である |
| 32 | データブロックにエラーの疑いがある |
| 16 | データブロックは再開マーカーである |
この符号化を用いることで、2 つ以上の状態を表す識別子を 1 つのブロック内に存在させることができる。必要なだけビットを立てればよい。
再開マーカーは 8 ビット幅のバイトの整数値としてデータストリームの中に埋め込まれ、コントロール接続上で使用されている言語(デフォルトでは NVT-ASCII)における印刷可能文字で表現される。再開マーカー内で <SP> (適切な言語における空白文字)を使用してはならない。
例えば 6 文字のマーカーを送信する場合には、以下の内容が送信されるだろう：
+----------+--------+--------+
|識別子 | バイト数 |
|コード= 16| = 6 |
+----------+--------+--------+
+----------+----------+----------+
| マーカー | マーカー | マーカー |
| 8 ビット | 8 ビット | 8 ビット |
+----------+----------+----------+
+----------+----------+----------+
| マーカー | マーカー | マーカー |
| 8 ビット | 8 ビット | 8 ビット |
+----------+----------+----------+
3 種類の情報が送信される：バイト文字列として送信される通常データ、繰り返しまたはフィラーを含む圧縮データ、2 バイトのエスケープシーケンスとして送信される制御情報である。n > 0 バイト(最大 127 バイト)の通常データを送信する場合、その n バイトの前に、最上位ビットが 0 で下位 7 ビットに数値 n を含む 1 バイトを送信する。
バイト文字列：
1 7 8 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| n | | d(1) | ... | d(n) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
^ ^
|---n バイト---|
のデータ
d(1)〜d(n) の n データバイトの文字列
n は正数でなければならない。
データバイト d の n 回の繰り返しからなる文字列を圧縮するには、以下の 2 バイトを送信する：
バイトの繰り返し：
2 6 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0| n | | d |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
n 個のフィラーバイトからなる文字列を 1 バイトに圧縮することが出来る。フィラーバイトの内容は表現型によって異なる。表現型が ASCII または EBCDIC の場合、フィラーバイトは <SP>(空白、ASCII コード 32、EBCDIC コード 64)である。表現型がイメージまたはローカルバイトの場合、フィラーはゼロである。
フィラー文字列：
2 6
+-+-+-+-+-+-+-+-+
|1 1| n |
+-+-+-+-+-+-+-+-+
エスケープシーケンスは 2 バイトであり、1 バイト目はエスケープバイト(全てゼロ)、2 バイト目にはブロックモードで定義されている識別子コードが含まれる。識別子コードはブロックモードにおいてと同じ意味を持ち、後続のバイト文字列に適用される。
わずかな CPU コストで非常に大きな転送帯域幅の増加を得るのに圧縮モードは有効である。これは例えば、RJE ホストによって生成された印刷ファイルのサイズを削減するような場合に最も効果的に利用できるだろう。
データ転送におけるビット落ちやビット化けの検出は提供されない。そのレベルの誤り制御は TCP によって行われる。しかしながらシステム全体の障害(ホストや FTP プロセスや下層ネットワークなどの障害を含む)からユーザーを保護するために、再開手続きが提供されている。
再開手続きはブロックモードと圧縮モードとのためにのみ定義されている。これには、何らかのマーカー情報を伴う特別なマーカーコードをデータの送信者がデータストリームに挿入することを必要とする。このマーカー情報はその送信者にとってのみ意味のあるものだが、デフォルトなら印刷可能な文字から構成され、そうでなければコントロール接続で交渉された言語(ASCII または EBCDIC)から構成されなければならない。このマーカーはビット数やレコード数、あるいはシステムがデータチェックポイントとして認識できる任意の他の情報を表すことができる。再開手続きを実装する受信側システムは、位置に対応するマーカーを受信側システム内に記録し、ユーザーにその情報を返すだろう。
システム障害が発生した場合、FTP の再開手続きと共にこのマーカーポイントを指定することで、ユーザーはデータ転送を再開することができる。以下、例を用いて再開手続きの利用方法を明らかにする。
データ送信者はデータストリームの都合の良い位置に適切なマーカーブロックを挿入する。受信側ホストは、ファイルシステム内の対応するデータ位置を記録し、直接またはコントロール接続を通した 110 リプライの何れか(送信側がだれかによる)によって、最後の既知の送信側・受信側マーカー情報をユーザーに知らせる。システム障害が発生した場合、再開コマンドの引数にサーバーのマーカーコードを送信することで、ユーザーまたはコントローラプロセスは最後のサーバーマーカーから再開しようとする。この再開コマンドはコントロール接続を通して送信され、障害が発生したときに実行中だったコマンド(RETR、STOR、LISTなど)がその直後に続く。
ユーザー側 PI からサーバー側 PI への通信チャネルは、ユーザーから標準サーバーポートへの TCP 接続として確立される。ユーザー側プロトコルインタープリタは、FTP コマンドの送信と、受信したリプライの解釈とに責任を持つ。サーバー側 PI はコマンドを解釈し、リプライを送信し、DTP がデータ接続をセットアップするように仕向け、データを転送する。その後サーバー側 PI は、データ転送の第二者(受け側の転送プロセス)がユーザー側 DTP であればユーザー側 FTP ホストの内部プロトコルに従って管理され、第二者がサーバー側 DTP であればユーザー側 PI からのコマンドに基づいて自身の PI によって管理される。FTP リプライに付いては次のセクションで議論する。このセクションにおけるいくつかのコマンドの説明は、可能性のあるリプライについて明らかにするための手助けになる。
以下のコマンドがアクセスコントロールの識別子を指定する(コマンドコードは括弧内に示されている)。
全てのデータ転送パラメータにはデフォルト値がある。デフォルト値を変更する必要がある場合にのみ、データ転送パラメータを指定するコマンドが必要となる。デフォルト値は最後に指定された値か、値が指定されていなかった場合にはここで述べられているような標準のデフォルト値となる。これは、適切なデフォルト値をサーバーが "覚えて(remember)" おかなければならないということを意味する。FTP サービスの要求前でなければならないことを除き、これらのコマンドは任意の順序で使用されてよい。データ転送パラメータを指定するコマンドは以下の通り：
PORT h1,h2,h3,h4,p1,p2
ここで h1 はインターネットホストアドレスの上位 8 ビットである。
＼ ／
A - ASCII | | N - Non-print
|-><-| T - Telnet 書式制御文字
E - EBCDIC| | C - 改行制御 (ASA)
／ ＼
I - Image
L <バイト幅> -ローカルバイトのバイト幅
FTP サービスコマンドは、ユーザーによって要求されるファイル転送やファイルシステムの機能を定義する。通常、FTP サービスコマンドの引数はパス名である。パス名の文法は、サーバー側サイトの(適用可能で標準的なデフォルトの)慣例と、コントロール接続の言語の慣例とに従わなければならない。推奨されるデフォルトの処理は、最後に指定されたデバイスやディレクトリ、ファイル名を使用するか、ローカルユーザーのために定義されている標準的なデフォルトを使用することである。"rename to" コマンドは "rename from" コマンドの次に来なければならないことと、再開コマンドの次には中断されたサービスコマンド(STOR、RETR など)が来なければならないこととを除き、各コマンドは任意の順序で使用することができる。FTP サービスコマンドへの応答として転送されるデータは、情報を提供する特定のリプライを除き、常にデータ接続を通して送信されるべきである。FTP サービスを要求するコマンドは以下の通り：
(1) の場合、サーバーは(もし開いていれば)データ接続を閉じ、ABOR コマンドが正常に処理されたことを表す 226 リプライを返す。
(2) の場合、サーバーは進行中の FTP サービスを中断し、データ接続を閉じ、サービス要求が異常終了したことを表すために 426 リプライを返す。その後サーバーは、ABOR コマンドが正常に処理されたことを表す 226 リプライを送信する。
コントロール接続上の全ての通信において、ファイル転送プロトコルは Telnet プロトコルの仕様に従う。Telnet の通信に使用される言語は交渉可能なオプションであるため、以下の 2 つのセクションでは "Telnet 言語(Telnet language)" とそれに対応する "Telnet 行末コード(Telnet end-of-line code)" とを参照している。現在のところそれらは NVT-ASCII と <CRLF> とを意味するものと考えてよい。Telnet プロトコルの他の仕様については言及していない。
FTP コマンドは "Telnet 行末コード(Telnet end-of-line code)" で終了する "Telnet 文字列(Telnet strings)" である。コマンドコード自体は、引数が続く場合は <SP> (空白文字)で終了し、そうでなければ Telnet-EOL で終了するアルファベット文字群である。コマンドコードとコマンドの意味はこのセクションで説明されている。コマンドの詳細な文法は「コマンド」セクションで規定されている。リプライシーケンスは「コマンド・リプライのシーケンス」セクションで議論されている。コマンドの使用方法を説明するシナリオは「典型的な FTP シナリオ」セクションで提供されている。
FTP コマンドは、アクセスコントロールの識別を指定するもの・データ転送パラメータを指定するもの・FTP サービス要求を指定するものへと、細分化することが出来る。一部のコマンド(ABOR、STAT、QUIT など)はコントロール接続を通してデータ転送中に送信されてもよい。コントロール接続とデータ接続とを同時に監視できないサーバーが存在するかもしれない。そのような場合、サーバーの注意を引くために何らかの特別なアクションが必要になるだろう。暫定的に以下の方法が推奨されている：
(通常のサーバーはこれらを必要としないだろうが、上記のアクションで異常を起こすべきではない。)
ファイル転送プロトコルのコマンドに対するリプライは、ファイル転送処理における要求と動作との同期を確実にし、ユーザー側プロセスが常にサーバーの状態を知っていることを保証できるように考えられている。各コマンドは少なくとも 1 つのリプライを生成しなければならず、複数であってもよい。後者の場合、複数リプライは簡単に区別できなければならない。さらに一部のコマンド(例えば USER・PASS・ACCT や RNFR・RNTO)は一連の組として実行される。先に実行されたコマンドが成功すれば、それに対するリプライは中間的な状態にあることを表すことになる。この一連の手順の途中で失敗した場合、その手順全体を最初から繰り返す必要がある。
コマンド・リプライのシーケンスに付いての詳細は、後述の状態図に示されている。
FTP リプライは 3 桁の数値(3 文字の英数字として転送される)の後に何らかのテキストが続く形式である。数値は次に入る状態を自動的に判断するためのものであり、テキストは人間の利用者向けである。この 3 桁の数値は、ユーザー側プロセス(ユーザー側 PI)がテキストを調べる必要がないほど十分に符号化された情報を含むことを目的としており、したがってテキストは必要に応じて破棄するか利用者に渡すかしてよい。テキストはサーバーに依存するため、各リプライコードごとに異なるものとなるだろう。
リプライは 3 桁の数値コードを含み、その次に空白文字 <SP>、次にテキスト行(何らかの最大長が定義されている)、そして Telnet 行末コードによって終了するものと定義される。しかしながら 1 行より長い場合もあるだろう。そのような場合、いつそのリプライの読み取りを止めて(つまりコントロール接続からの入力処理を止めて)次の処理を行えばよいのかをユーザープロセスが分かるように、テキスト全体をひとまとめにしなければならない。このためには、後に行が続くことを表すために先頭行に、そして最終行であることを表すために最終行に、それぞれ特別な書式が必要となる。これを満たすために、先頭行と最終行とは共に同じコードでなければならないと決められている。
複数行リプライの先頭行の書式は必須のリプライコードで始まり、その直後にハイフン "-" (マイナス記号としても知られる)、次にテキストが続く。最終行はそれと同じコードで始まり、直後に空白文字 <SP>、任意のテキスト、最後に Telnet 行末コードが続く。
例：
123-First line
Second line
234 A line beginning with numbers
123 The last line
これに対しユーザープロセスは、行頭が同じコードで始まり直後に <SP> (空白文字)が続く行を探しながら、間の全ての行を単純に無視すればよい。間の行が 3 桁の数字で始まる場合、混乱を避けるためにサーバーはその前にパディングを入れなければならない。
この方法は、"人為的に(artificial)" 先頭行と最終行を追加することでリプライ情報(例えば STAT へのリプライなど)に使用できる標準的なシステムルーチンの作成を可能にしている。まれなケースではあるが、このルーチンは 3 桁の数字と空白文字とで始まる行を生成しうるため、各テキスト行の先頭は何らかの無害なテキスト(空白文字など)によってオフセットされるべきである。
この方法は複数行リプライのネストを想定していない。
リプライの 3 桁の数字はそれぞれ特別な意味を持つ。これはユーザープロセスによる非常に単純な応答から非常に複雑な応答までをカバーすることを目的としている。1 桁目の数字は、その応答の成功・失敗・未完了を表す。状態遷移図を参照することで、単純なユーザープロセスはこの 1 桁目を調べるだけで次の行動を決定することができるだろう(予定通り進める・やり直す・縮小するなど)。発生したエラーのおおよその種類(例えばファイルシステムのエラー、コマンドの文法エラーなど)を知りたいユーザープロセスは、2 桁目の数字を調べればよい。3 桁目の数字は情報の詳細なレベルを表すために予約されている(例えば、RNFR コマンドを伴わない RNTO コマンドなど)。
リプライコードの 1 桁目には 5 つの値がある：
2 桁目の数字は以下の機能グループを表している：
3 桁目の数字は、2 桁目の数字によって特定される各カテゴリのより詳細な意味を表す。以下のリプライの一覧でそれらを明らかにする。各リプライにおいてテキストは必須ではないが、推奨はされ、対応するコマンドに従って変更されることさえも許される。一方で、リプライコードは最終セクションの仕様に厳密に従わなければならない。つまりサーバー実装は、ここで説明されているものと少しだけ異なる状況のために新しいコードを作るのではなく、定義済みのコードに適合させるべきだということである。
TYPE や ALLO のように、正常な実行がユーザー側プロセスに新しい情報を提供しないコマンドは、200 リプライを返すだろう。自分のシステムに関係がないという理由でサーバー側 FTP プロセスがコマンドを実装していない場合(例えば TOPS20 サイトでの ALLO コマンド)、それでもユーザープロセスが連続するアクションを継続できるように、肯定完了リプライを返すことが望まれる。そのような場合には 202 リプライが使用される(リプライテキストには例えば "No storage allocation necessary.(領域の割り当ては不要)" が使用される)。逆に、非サイト固有アクションを要求するコマンドが実装されていない場合、その応答は 502 となる。この改良版は、コマンドは実装されているがその引数が実装されていない場合の 504 リプライである。
200 Command okay.
(コマンド成功)
500 Syntax error, command unrecognized.
(文法エラー、そのコマンドは認識されない)
コマンド行が長すぎるといったエラーもこれに含まれて良い。
501 Syntax error in parameters or arguments.
(パラメータや引数の文法エラー)
202 Command not implemented, superfluous at this site.
(そのコマンドはこのサイトでは不要であり、実装されていない)
502 Command not implemented.
(そのコマンドは実装されていない)
503 Bad sequence of commands.
(コマンドの順序が不正)
504 Command not implemented for that parameter.
(そのコマンドに対するその引数は実装されていない)
110 Restart marker reply.
(再開マーカーリプライ)
このテキスト部分は特定の実装に依存するものであってはならず、
以下の形式でなければならない：
MARK yyyy = mmmm
ここで yyyy はユーザープロセスのデータストリームマーカー、
mmmm はそれに対応するサーバー側のマーカーである。
(マーカーと "=" との間の空白文字に注意)
211 System status, or system help reply.
(システム状態、またはシステムヘルプのリプライ)
212 Directory status.
(ディレクトリの状態)
213 File status.
(ファイルの状態)
214 Help message.
(ヘルプメッセージ)
サーバーの使用方法や特定の非標準コマンドの意味を示す。
このリプライは人間のユーザーにとってのみ有用である。
215 NAME system type.
(システムタイプ NAME)
ここで NAME は、Assigned Numbers document に示されている公式な
システム名である。
120 Service ready in nnn minutes.
(サービスは nnn 分以内に利用可能になる)
220 Service ready for new user.
(新しいユーザーに対するサービスの準備完了)
221 Service closing control connection.
(サービスはコントロール接続を閉じようとしている)
適切ならログアウトする。
421 Service not available, closing control connection.
(サービスは利用不可であり、コントロール接続は閉じられようとしている)
シャットダウンしなければならないことをサービスが分かっている場合、
これは任意のコマンドに対するリプライとなりうる。
125 Data connection already open; transfer starting.
(データ接続はすでに開かれている。転送が開始される。)
225 Data connection open; no transfer in progress.
(データ接続は開かれた。実行中の転送はない。)
425 Can't open data connection.
(データ接続を開けない)
226 Closing data connection.
(データ接続は閉じられようとしている)
要求されたファイル操作は成功した(例えばファイル転送や中断)。
426 Connection closed; transfer aborted.
(接続は閉じられた。転送が中断された)
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
(パッシブモードに入る (h1,h2,h3,h4,p1,p2))
230 User logged in, proceed.
(ユーザーはログインした。次の処理を)
530 Not logged in.
(ログインしていない)
331 User name okay, need password.
(ユーザー名は正常。パスワードが必要)
332 Need account for login.
(ログインには課金情報が必要)
532 Need account for storing files.
(ファイルを保存するには課金情報が必要)
150 File status okay; about to open data connection.
(ファイル状態は正常。データ接続を開こうとしている)
250 Requested file action okay, completed.
(要求されたファイル操作は正常に完了した)
257 "PATHNAME" created.
"PATHNAME" が作成された
350 Requested file action pending further information.
(要求されたファイル操作は保留されている。更に情報が必要)
450 Requested file action not taken.
(要求されたファイル操作は実行されない)
ファイルを使用できない(例えば使用中など)
550 Requested action not taken.
(要求された操作は実行されない)
ファイルを使用できない(例えばファイルが見つからない、アクセス不可など)
451 Requested action aborted. Local error in processing.
(要求された操作は中止された。処理中にローカルエラー発生)
551 Requested action aborted. Page type unknown.
(要求された操作は中止された。ページタイプが不明である)
452 Requested action not taken.
(要求された操作は実行されない)
システムに十分な空き領域がない
552 Requested file action aborted.
(要求されたファイル操作は中止された)
現在のディレクトリやデータセットのための)保存領域を超過した
553 Requested action not taken.
(要求された操作は実行されない)
許可されないファイル名
(訳注：上の4.2.1と同じ内容で並び順が違うだけです。訳は省略します。)
110 Restart marker reply.
In this case, the text is exact and not left to the
particular implementation; it must read:
MARK yyyy = mmmm
Where yyyy is User-process data stream marker, and mmmm
server's equivalent marker (note the spaces between markers
and "=").
120 Service ready in nnn minutes.
125 Data connection already open; transfer starting.
150 File status okay; about to open data connection.
200 Command okay.
202 Command not implemented, superfluous at this site.
211 System status, or system help reply.
212 Directory status.
213 File status.
214 Help message.
On how to use the server or the meaning of a particular
non-standard command. This reply is useful only to the
human user.
215 NAME system type.
Where NAME is an official system name from the list in the
Assigned Numbers document.
220 Service ready for new user.
221 Service closing control connection.
Logged out if appropriate.
225 Data connection open; no transfer in progress.
226 Closing data connection.
Requested file action successful (for example, file
transfer or file abort).
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
230 User logged in, proceed.
250 Requested file action okay, completed.
257 "PATHNAME" created.
331 User name okay, need password.
332 Need account for login.
350 Requested file action pending further information.
421 Service not available, closing control connection.
This may be a reply to any command if the service knows it
must shut down.
425 Can't open data connection.
426 Connection closed; transfer aborted.
450 Requested file action not taken.
File unavailable (e.g., file busy).
451 Requested action aborted: local error in processing.
452 Requested action not taken.
Insufficient storage space in system.
500 Syntax error, command unrecognized.
This may include errors such as command line too long.
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
504 Command not implemented for that parameter.
530 Not logged in.
532 Need account for storing files.
550 Requested action not taken.
File unavailable (e.g., file not found, no access).
551 Requested action aborted: page type unknown.
552 Requested file action aborted.
Exceeded storage allocation (for current directory or
dataset).
553 Requested action not taken.
File name not allowed.
不要なエラーメッセージなしに FTP を動作させるために、全てのサーバーに最低限以下の実装が必須である：
型 - ASCII Non-print
モード - ストリーム
構造 - ファイル、レコード
コマンド - USER, QUIT, PORT,
TYPE, MODE, STRU,(デフォルト値のためのもの)
RETR, STOR,
NOOP.
転送パラメータのデフォルト値：
TYPE - ASCII Non-print
MODE - ストリーム
STRU - ファイル
全てのホストは標準的なデフォルトとして上記の値を受け入れなければならない。
サーバー側プロトコルインタープリタは、ポート L で "待ち受ける(listen)" べきである。ユーザーまたはユーザー側プロトコルインタープリタは全二重のコントロール接続を開始するべきである。サーバー側プロセスとユーザー側プロセスは、ARPA-Internet Protocol Handbook [1] で規定されている Telnet プロトコルの慣例に従うべきである。コマンド行の編集を行う義務はサーバーにはなく、サーバーはユーザーホストにおいてそれが行われることを要求してもよい。全ての転送とリプライとが完了した後、コントロール接続はユーザーからの要求に基づいてサーバーによって閉じられるべきである。
ユーザー側 DTP は指定されたデータポート上で "待ち受け(listen)" なければならない。このデータポートはデフォルトのユーザー側ポート(U)か、PORT コマンドで指定されたポートである。サーバーは指定されたユーザー側データポートを使用して、自身のデフォルトデータポート(L-1)からデータ接続を開始するべきである。転送の方向と使用されるポートは、FTP サービスコマンドによって決定される。
デフォルトポートを使用するデータ転送は、全ての FTP 実装によってサポートされなければならないことに注意してほしい。ユーザー側 PI のみが非デフォルトポートの使用を開始することができる。
2 台のサーバー A・B 間でデータを転送する場合(図 2 参照)、ユーザー側 PI である C は、A・B 両方のサーバー側 PI とのコントロール接続を確立する。一方のサーバー(仮に A とする)は次に、転送サービスコマンドを受信したときに接続を開始するのではなく、データポート上で "待ち受ける(listen)" べきであることを伝える PASV コマンドを受信する。ユーザー側 PI がその PASV コマンド(これには待ち受け(listen)ているホストとポートの識別が含まれる)の了承を受信すると、ユーザー側 PI は PORT コマンドによって A のポート a を B へと送信し、それに対してリプライが返される。この時点でユーザー側 PI は、A と B とに対してサービスコマンドを送信することができる。サーバー B が接続を開始し、転送が行われる。このコマンド-リプライのシーケンスを以下に示す。ここで各メッセージは縦方向には同期的であるが、横方向には非同期である。
ユーザー側 PI - サーバー A ユーザー側 PI - サーバー B
------------------ ------------------
C->A : 接続 C->B : 接続
C->A : PASV
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
C->B : PORT A1,A2,A3,A4,a1,a2
B->C : 200 Okay
C->A : STOR C->B : RETR
B->A : ホスト A のポート a に接続
図 3
データ接続は「データ接続の確立」セクションで説明されている条件に基づいて、サーバー側によって閉じられるべきである。ファイルの終了を示すためにデータ接続を閉じる必要がないデータ転送において接続を閉じようとする場合、サーバー側はすぐにそれを行わなければならない。ユーザー側プロセスはデータ接続が "待ち受け(listen)" なければならないかどうかを確認済みであるため、次の転送コマンドまで待機することは許されない(転送要求を送信する前に、ユーザー側は閉じられたデータポート上で "待ち受け(listen)" なければならないことを思い出してほしい)。同じような状況を避けるために、データ接続を閉じた後にサーバーは 226 リプライを返す (または接続を開いたままにする場合は 250 リプライ("file transfer completed(ファイル転送完了)")を返し、ユーザー側 PI は新しい転送コマンドを発行する前にそれらのリプライを待つ)。
相手側によって接続が閉じられようとしていることをユーザー側またはサーバー側が確認したときはいつでも、その接続においてキューイングされている残りの全データを即座に読み取り、自身の側も閉じるべきである。
コマンドは「FTP コマンド」セクションで説明されている通りの Telnet 文字列であり、コントロール接続上を転送される。コマンドの機能と動作は「アクセスコントロールコマンド」「転送パラメータコマンド」「FTP サービスコマンド」「その他のコマンド」の各セクションで説明されている。コマンドの文法はここで規定されている。
コマンドはコマンドコードで始まり、その後に引数フィールドが続く。コマンドコードは 4 文字以下のアルファベットである。アルファベットの大文字・小文字は同じように扱われなければならない。したがって、以下のコマンドは全て取得コマンド(RETR)を表している：
RETR Retr retr ReTr rETr
ASCII 型を表す A または a のような、パラメータ値を表すシンボルにもこれは適用される。コマンドコードと引数フィールドとは 1 つ以上の空白文字で区切られる。
引数フィールドは可変長の文字列から構成され、NVT-ASCII 表現の場合 <CRLF> (復帰・改行)で終了する。他の交渉済み言語の場合には異なる行末文字が使用されても良い。行末コードを受信するまでサーバーが動作を開始しないことに注意するべきである。
NVT-ASCII による文法を以下に示す。引数フィールド内の全ての文字は ASCII 文字であり、ASCII 表現による 10 進整数も含まれている。角括弧はオプションの引数フィールドを表す。オプションが使用されなかった場合、適切なデフォルトが仮定される。
FTP コマンドは以下の通り：
USER <SP> <ユーザー名> <CRLF>
PASS <SP> <パスワード> <CRLF>
ACCT <SP> <課金情報> <CRLF>
CWD <SP> <パス名> <CRLF>
CDUP <CRLF>
SMNT <SP> <パス名> <CRLF>
QUIT <CRLF>
REIN <CRLF>
PORT <SP> <ホスト-ポート> <CRLF>
PASV <CRLF>
TYPE <SP> <型コード> <CRLF>
STRU <SP> <構造コード> <CRLF>
MODE <SP> <モードコード> <CRLF>
RETR <SP> <パス名> <CRLF>
STOR <SP> <パス名> <CRLF>
STOU <CRLF>
APPE <SP> <パス名> <CRLF>
ALLO <SP> <10 進整数>
[<SP> R <SP> <10 進整数>] <CRLF>
REST <SP> <マーカー> <CRLF>
RNFR <SP> <パス名> <CRLF>
RNTO <SP> <パス名> <CRLF>
ABOR <CRLF>
DELE <SP> <パス名> <CRLF>
RMD <SP> <パス名> <CRLF>
MKD <SP> <パス名> <CRLF>
PWD <CRLF>
LIST [<SP> <パス名>] <CRLF>
NLST [<SP> <パス名>] <CRLF>
SITE <SP> <文字列> <CRLF>
SYST <CRLF>
STAT [<SP> <パス名>] <CRLF>
HELP [<SP> <文字列>] <CRLF>
NOOP <CRLF>
上記の引数フィールドの文法を以下に示す(適用可能な場合には BNF 表記を用いている)：
<ユーザー名> ::= <文字列>
<パスワード> ::= <文字列>
<課金情報> ::= <文字列>
<文字列> ::= <文字> | <文字><文字列>
<文字> ::= <CR> <LF> を除く全ての ASCII 文字
<マーカー> ::= <印字可能文字列>
<印字可能文字列> ::= <印字可能文字> | <印字可能文字><印字可能文字列>
<印字可能文字> ::= ASCII コード 33 から 126 の印刷可能文字
<バイトサイズ> ::= <数値>
<ホスト-ポート> ::= <ホスト番号>,<ポート番号>
<ホスト番号> ::= <数値>,<数値>,<数値>,<数値>
<ポート番号> ::= <数値>,<数値>
<数値> ::= 1 から 255 までの 10 進整数
<書式コード> ::= N | T | C
<型コード> ::= A [<sp> <型コード>]
| E [<sp> <型コード>]
| I
| L <sp> <バイトサイズ>
<構造コード> ::= F | R | P
<モードコード> ::= S | B | C
<パス名> ::= <文字列>
<10 新数値> ::= 任意の 10 進整数
ユーザー・サーバー間の通信は、交互の会話となるように意図されている。ユーザー側が FTP コマンドを発行し、サーバー側が速やかに主要なリプライで応答するという形である。新たなコマンドを送信する前に、ユーザーはこの最初の主要な成功または失敗のリプライを待つべきである。
ある種のコマンドは、これも同様にユーザーが待つべき 2 番目のリプライを必要とする。これらのリプライは、例えばファイル転送の進行状況や完了、あるいはデータ接続が閉じられるというようなことを報告するものである。これらはファイル転送コマンドに対する第 2 のリプライである。
通知リプライの重要なグループのひとつに、接続の挨拶がある。通常の環境では、接続が完了したとき、サーバーは 220 リプライ("awaiting input(入力待機中)")を送信するだろう。ユーザーはコマンドを送信する前にこの挨拶メッセージを待つべきである。すぐに入力を受け入れられない場合、サーバーは即座に 120 リプライ("expected delay(遅延を望む)")を送信し、準備が完了した時点で 220 リプライを送信するべきである。こうすることによりユーザーは、応答が遅延したときでもハングアップしたのではないことを知ることができる。
任意のリプライ
時に "システム(the system)" は、ユーザー側に(通常は全てのユーザーに)送られるべきメッセージを自然発生的に生成することがある。例えば "System going down in 15 minutes(システムは 15 分後に停止する)" などである。FTP では、サーバー側からユーザー側へとこのような自然発生的情報を送信する手段は提供されていない。そのような情報は サーバー側 PI にキューイングされ、次のリプライ時にユーザー側 PI へと送信されることが推奨される。
各コマンドに対する成功・失敗のリプライの選択肢を以下に示す。これらは厳密に守られなければならない。リプライ中のテキストはサーバーによって置き換えられてもよいが、コード番号と特定のコマンド・リプライシーケンスとによって課される意味と動作は変更されてはならない。
コマンド-リプライシーケンス
このセクションではコマンド-リプライシーケンスを示す。各コマンドは返される可能性のあるリプライと共にリストされており、さらにコマンドグループもリストされている。準備リプライが先頭に(後続のリプライはインデントされてその下に)示されており、次に肯定リプライ・否定リプライ、最後に、後続のコマンドと共に中間リプライが示されている。このリストは別途示されている状態図の基礎になっている。
接続確立
120
220
220
421
ログイン
USER
230
530
500, 501, 421
331, 332
PASS
230
202
530
500, 501, 503, 421
332
ACCT
230
202
530
500, 501, 503, 421
CWD
250
500, 501, 502, 421, 530, 550
CDUP
200
500, 501, 502, 421, 530, 550
SMNT
202, 250
500, 501, 502, 421, 530, 550
ログアウト
REIN
120
220
220
421
500, 502
QUIT
221
500
転送パラメータ
PORT
200
500, 501, 421, 530
PASV
227
500, 501, 502, 421, 530
MODE
200
500, 501, 504, 421, 530
TYPE
200
500, 501, 504, 421, 530
STRU
200
500, 501, 504, 421, 530
ファイル操作コマンド
ALLO
200
202
500, 501, 504, 421, 530
REST
500, 501, 502, 421, 530
350
STOR
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
STOU
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
RETR
125, 150
(110)
226, 250
425, 426, 451
450, 550
500, 501, 421, 530
LIST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
NLST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
APPE
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 550, 452, 553
500, 501, 502, 421, 530
RNFR
450, 550
500, 501, 502, 421, 530
350
RNTO
250
532, 553
500, 501, 502, 503, 421, 530
DELE
250
450, 550
500, 501, 502, 421, 530
RMD
250
500, 501, 502, 421, 530, 550
MKD
257
500, 501, 502, 421, 530, 550
PWD
257
500, 501, 502, 421, 550
ABOR
225, 226
500, 501, 502, 421
通知コマンド
SYST
215
500, 501, 502, 421
STAT
211, 212, 213
450
500, 501, 502, 421, 530
HELP
211, 214
500, 501, 502, 421
その他のコマンド
SITE
200
202
500, 501, 530
NOOP
200
500 421
ここで、非常に単純な FTP 実装のための状態図を提供する。リプライコードの 1 桁目だけを使用する。FTP コマンドのグループまたは各コマンドシーケンスごとに 1 つの状態図を提示する。
コマンドのグループ分けは、まず各コマンドのモデルを構築し、次に構造上同一のモデルを持つコマンドを集めることで行われている。
各コマンドや各コマンドシーケンスには 3 種類の出力が考えられる：成功(S)、失敗(F)、エラー(E)である。以下の状態図では、"開始(begin)" の意味でシンボル B を、"リプライ待ち(wait for reply)" の意味でシンボル W を使用している。
まず最初に、FTP コマンドの中でも最も大きいグループを表す状態図を示す：
1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+
この状態図は以下のコマンドをモデル化している：
ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, TYPE
もうひとつ別の大きなコマンドグループも、次のような非常によく似た状態図で表される：
3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ --->+---+ +---+
| | |
| | | 4,5 +---+
| 1 | ----------->| F |
----- +---+
この状態図は以下のコマンドをモデル化している：
APPE, LIST, NLST, REIN, RETR, STOR, STOU
このモデルは最初のコマンドグループを表すこともできることに注意してほしい。最初のグループとの唯一の違いは、最初のグループでは 100 番台のリプライは予期されておらず、したがってエラー扱いされるが、二つ目のグループでは 100 番台のリプライは予期されることである(一部のコマンドでは必須である)。100 番台のリプライは各コマンドごとに最大でもひとつだけ許されることを思い出してほしい。
残りの状態図はコマンドシーケンスをモデル化したものであり、その中で最も単純なものは、おそらく以下の名称変更のシーケンスである：
+---+ RNFR +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ RNTO +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+
次の状態図は再開コマンドの単純なモデルである：
+---+ REST +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 3 | | +---+
| 2| --------
| | | |
V | | |
+---+ cmd +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ -->+---+ +---+
| |
| 1 |
------
図中の "cmd" は、APPE または STOR、PETR である。
上記の 3 つのモデルがよく似ていることを指摘しておこう。再開コマンドと名称変更コマンドとの唯一の違いは、第 2 段階での 100 番台のリプライの扱いである。二つ目のグループは 100 番台のリプライを予期している(一部のコマンドでは必須である)。各コマンドごとに 100 番台のリプライは最大でひとつだけ許されることを思い出してほしい。
もっとも複雑なのはログインシーケンスの状態図である。
1
+---+ USER +---+------------->+---+
| B |---------->| W | 2 ---->| E |
+---+ +---+------ | -->+---+
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| | | | |
| --------- |
| 1| | | |
V | | | |
+---+ PASS +---+ 2 | ------>+---+
| |---------->| W |------------->| S |
+---+ +---+ ---------->+---+
| | | | |
3 | |4,5| | |
-------------- -------- |
| | | | |
| | | | |
| -----------
| 1,3| | | |
V | 2| | |
+---+ ACCT +---+-- | ----->+---+
| |---------->| W | 4,5 -------->| F |
+---+ +---+------------->+---+
最後に、コマンド・リプライのやり取りを一般化した状態図を示しておく：
------------------------------------
| |
開始 | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
終了
ホスト U 上のユーザーが、ホスト S との間でファイルを転送する場合：
一般にユーザーは、ユーザー側 FTP プロセスを介してサーバーと通信する。以下に示すのは典型的なシナリオである。ユーザー側 FTP のプロンプトは括弧内に示されている。'---->' はホスト U から ホスト S へのコマンドを表し、'<----' はホスト S からホスト U へのリプライを表している。
ローカルユーザーによるコマンド 行われる動作
ftp (host) multics<CR> ホスト S のポート L に接続し、
コントロール接続を確立
<---- 220 Service ready <CRLF>.
username Doe <CR> USER Doe<CRLF>---->
<---- 331 User name ok,
need password<CRLF>.
password mumble <CR> PASS mumble<CRLF>---->
<---- 230 User logged in<CRLF>.
retrieve (local type) ASCII<CR>
(local pathname) test 1 <CR> ユーザー側 FTP が ASCII 形式で
ローカルファイルを開く
(for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
<---- 150 File status okay;
about to open data
connection<CRLF>.
サーバーがポート U へとデータ接続を
確立
<---- 226 Closing data connection,
file transfer successful<CRLF>.
type Image<CR> TYPE I<CRLF> ---->
<---- 200 Command OK<CRLF>
store (local type) image<CR>
(local pathname) file dump<CR> ユーザー側 FTP がイメージ形式で
ローカルファイルを開く
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
<---- 550 Access denied<CRLF>
terminate QUIT <CRLF> ---->
サーバーが全ての接続を閉じる
FTP のコントロール接続はユーザー側プロセスのポート U と サーバー側プロセスのポート L との間で TCP 経由で確立される。このプロトコルはサーバーのポートに 21 (8 進数 25)を割り当てている。すなわち、L = 21 である。
FTP がページ構造をサポートする理由は、TOPS-20 システム間でファイル(具体的には NLS によって使用されるファイル)の効率的な転送をサポートする必要性に由来している。
TOPS-20 のファイルシステムはページの概念に基づいており、ファイルをページとして扱うときにオペレーティングシステムはもっとも効率がよくなる。多くのアプリケーションがファイルを連続的な文字のストリームと見なせるように、オペレーティングシステムはファイシステムへのインターフェイスを提供している。しかしながら下層のページ構造を直接利用するアプリケーションも少なからず存在し、それらの一部は不連続(holey)ファイルを生成する。
TOPS-20 のディスク上のファイルは 4 つの要素から構成される：パス名、ページテーブル、ページの集合(空もあり得る)、属性の集合である。
パス名は RETR コマンドまたは STOR コマンドにおいて指定される。パス名にはディレクトリ名、ファイル名、拡張子、世代番号(generation number)が含まれる。
ページテーブルには最大で 2**18 のエントリーが含まれる。各エントリーは空(EMPTY)か、ページを指し示すことができる。エントリーが空でなければ、同時にページ固有のアクセスビットが存在する。1 ファイル内の全てのページが同じアクセス保護を持つ必要はない。
1 ページは連続する 512 ワードであり、1 ワードは 36 ビットである。
ファイルデスクリプタブロック(FDB)内にあるファイル属性には、作成時刻、書込み時刻、読込み時刻、書込みバイト幅、ファイル終端ポインタ、読込み回数、書込み回数、バックアップシステムテープ番号などが含まれる。
ページテーブル内のエントリーが連続している必要はないことに注意してほしい。ページテーブル内の使用中のスロット同士の間に、空きスロットがあってもよい。また、ファイル終端へのポインタは単純な数値である。これはファイル内の実際の "最後の(last)" データを指す必要はない。TOPS-20 における順次入出力呼び出しのファイル終端ポインタは最終データの書込み後まで保留されるが、特定のプログラミングシステムが望むのであれば、他の操作ではそうである必要はない。
これらの特別なケース("不連続(holey)" ファイルと、ファイルの終端を指さないファイル終端ポインタと)は、NLS データファイルで実際に発生する。
TOPS-20 のページファイルは次の FTP 転送パラメータで送信することが出来る：TYPE L 36、STRU P、MODE S (実際にはモードは何でもよい)。
各ページはヘッダを持っている。TYPE が L 36 なので、1 論理バイトである各ヘッダフィールドは TOPS-20 の 1 ワードである。
各ヘッダフィールドは以下の通り：
ヘッダの後には「データ長」の長さだけデータワードが続く。現在のところデータ長は、データページで 512、FDB で 31 である。データ長を 512 未満にすることで、ディスクファイルページ内の後続のゼロは破棄される。
UNIX はディレクトリを通常のファイルのように簡単に扱えるツリー状のディレクトリ構造を持っているため、UNIX マシン上の FTP サーバーをディレクトリ作成コマンドを含むように拡張することは有用である。APRA-インターネット上にはツリー構造のディレクトリを持つ他のホスト(TOPS-20 や Multics も含まれる)も存在するため、これらのコマンドは可能な限り一般化されている。
4 つのディレクトリ関連コマンドが FTP に追加されている：
例えば "パス名" が絶対パスの場合や、TOPS-20 に対する "<abso.lute.path>" などのように、"パス名" の文字列がサーバーにとってサブディレクトリ以外の意味を表すのに十分な情報を含む場合を除き、 引数の "パス名" は現在の作業ディレクトリのサブディレクトリとして作成(削除)されるべきである。
MKD MYDIR
CWD MYDIR
この新しいディレクトリは "絶対(absolute)" 名称によってのみ参照できる。例えばディレクトリ <DFRANKLIN> に接続しているときに上記の MKD コマンドが発行された場合、新しいサブディレクトリは <DFRANKLIN.MYDIR> という名前によってのみ参照できる。
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
257 "/usr/dm/pathname" directory created
MKD foo"bar
257 "/usr/dm/foo""bar" directory created
CWD /usr/dm/foo"bar
200 directory changed to /usr/dm/foo"bar
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
521-"/usr/dm/pathname" directory already exists;
521 taking no action.
CWD <some.where>
200 Working directory changed
MKD overrainbow
257 "<some.where.overrainbow>" directory created
CWD overrainbow
431 No such directory
CWD <some.where.overrainbow>
200 Working directory changed
CWD <some.where>
200 Working directory changed to <some.where>
MKD <unambiguous>
257 "<unambiguous>" directory created
CWD <unambiguous>
Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
MIT-Project MAC, 16 April 1971.
Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
(NIC 6794), MIT-Project MAC, 23 June 1971.
Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
UCLA/CCN, 29 September 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
(NIC 7813), MIT-Project MAC, 17 November 1971.
McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
RFC 281 (NIC 8163), BBN, 8 December 1971.
Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
25 January 1972.
Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
MIT-Project MAC, 8 July 1972.
Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
27 November 1972.
Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
Braden, Bob, "Comments on File Transfer Protocol", RFC 430
(NIC 13299), UCLA/CCN, 7 February 1973.
Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
RFC 438 (NIC 13770), BBN, 15 January 1973.
Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
27 February 1973.
McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
16 February 1973.
Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
(NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
12 July 1973.
Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.
Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.
Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
"Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
Ames Research Center, SRI-ARC, 28 February 1974.
Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
(NIC 14573), MIT-DMCG, 21 February 1973.
Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
8 March 1973.
Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
MIT-DMCG, 6 March 1973.
Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
SRI-ARC, 8 March 1973.
White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
SRI-ARC, 8 March 1973.
Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
(NIC 16157), MIT-Multics, 26 June 1973.
Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
RFC 520 (NIC 16819), Illinois, 25 June 1973.
Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
(NIC 17451), UCSD-CC, 22 June 1973.
Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
15 November 1973.
McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
29 November 1973.
Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
Service", RFC 630 (NIC 30237), BBN, 10 April 1974.
Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
UCLA/NMC, 5 June 1974.
Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
SU-AI, 10 May 1975.
Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
28 May 1975.
Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.
Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
31 October 1977.
Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
SRI-KL, 30 December 1977.
Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
10 December 1978.
Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
June 1980.
Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
Commands", RFC 776, BBN, December 1980.
Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
July 1985.
[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook",
Network Information Center, SRI International, March 1982.
[2] Postel, Jon, "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
Specification", RFC 854, ISI, May 1983.
[4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
ISI, April 1985.