RFC 959
Network Working Group J. Postel
Request for Comments: 959 J. Reynolds
ISI
Obsoletes RFC: 765 (IEN 149) October 1985
FILE TRANSFER PROTOCOL (FTP)
ファイル転送プロトコル（ＦＴＰ）
訳者まえがき
この文書は、RFC 1123を非公式に日本語訳したものです。翻訳の誤り、誤解、
語学能力の欠如、などから、訳者が気づかなかった誤りが存在します。また、
ニュアンスなどが原文と異なります。
翻訳の際、語を補った方がわかりやすいと判断した場合には、/* */で囲んだ
形で補ってある場合もあります。
この文書の利用は、概要をつかむためのみに使用してください。公式の場で
の質問や、回答、その他の利用の際には、必ず原文を参照してください。
この翻訳版の配布条件は、原文の配布条件に従います。（原文では、配布自
由となっています）
このメモのステータス
このメモは、ファイル転送プロトコル（ FTP ）の公式な仕様である。このメモは自由に
配布しても構わない。
次の新しい追加命令が、この版で含められる。
CDUP (Change to Parent Directory 〜親ディレクトリへ移動)
SMNT (Structure Mount 〜 構造マウント)
STOU (Store Unique 〜 重複しないファイル名でストア)
RMD (Remove Directory 〜 ディレクトリの削除)
MKD (Make Directory 〜 ディレクトリの作成)
PWD (Print Directory 〜 ディレクトリの表示)
SYST (System 〜 システム名).
この詳述は、以前の版と互換性があることに注意して下さい。
1.イントロダクション
ＦＴＰの目的は、
1) ファイル（コンピュータープログラムやデータ等）を共有することの助けとなり、
2) プログラムを通して、間接的に、もしくは意識せずに遠隔地にあるコンピュータ
を使用することの助けとなり、
3) ホストのファイルの保管システムの変化から使用者を保護し、
4) 確実かつ能率的にデータを移動する
ことである。
ＦＴＰは、（端末装置を使っているユーザーが/*端末装置を使って*/直接使用するこ
とも出来るが）主に/*専用の*/プログラムを通して使われるように設計されている。
この仕様の狙いは、単純で簡単に実装できるプロトコル設計により、大型ホストコン
ピュータ、小型ホストコンピュータ、パーソナルワークステーション、そしてTACの
ユーザーの多様な要求に応えることである。
この資料は、読者が、ＴＣＰ（Transmission Control Protocol）について[2]と、
Telnetプロトコルについて[1]の知識があることを前提としている。
これらについての文書は、ARPA-インターネットプロトコルハンドブック[1]に記載さ
れている。
2. 概説
この章では、歴史と用語、そしてＦＴＰのモデルについて解説する。この章で定義さ
れる用語は、ＦＴＰにおいて特別重要な言葉だけである。これらの言葉は
で限定される言葉は、 FTP で特別の重要性がある人々でだけある。これら用語のい
くつかは、FTPのモデルで特有のものである。読者の中には、用語の解説中にＦＴＰ
モデルの該当する章に行った方が良いと考えるかもしれない。
2.1. 歴史
FTPは長い時間をかけて進化してきた。付録 III は FTP に関係があったＲＦＣ
を年代順にならべたものである。
これらには ＭＩＴにあったホストコンピュータで動作させるために考えられた、
1971年の最初のファイル転送機構(RFC 114)、及び、 RFC141での批評と討論を含
んでいる。
RFC 172 において、ホストコンピュータとのファイル転送に関するユーザーレベ
ルのプロトコルが方向づけられた。（ターミナルＩＭＰを含む）RFC 265におい
てこれが改定され、再度、レビューが加えられ、RFC281で更なる変更が提案され
た。『セットデータタイプ』を使用する処理は 1982年１月に RFC 294 において
提案された。
RFC354は、RFC264とRFC265に替わって使用されるようになった。ファイル転送プ
ロトコル（ＦＴＰ）は、そのときから、ＡＲＰＡＮＥＴ上のホストととの間で能
率的に、かつ、確実にファイルを転送し、そして、リモート側のファイル処理能
力を便利に使用できるようにするための主要な手段としてそのプロトコルが定義
された。RFC414が動作中のサーバーとユーザー側のＦＴＰのステータスレポート
機能を定義するようになるまでの間、RFC385はエラーや、強調すべきポイント、
プロトコルに対する追加に関しての更なる意見を挙げている。
1973年に出されたRFC430(挙げるにあまりある多数のRFC の間で)においてＦＴＰ
にはさらなる意見があがっている。最終的に、RFC454において、「公式な」ＦＴ
Ｐのドキュメントが公開された。
1973年７月までの間、FTP の最後のバージョンからかなりの変更があったが、一
般的な構造は、同じのままであった。RFC 542 は、これらの変更を反映するため
に新しい『公式の』仕様として出版された。しかし、多くの、過去の仕様にに基
づいて実装されたものに関しては、アップデートされていなかった。
1974年に、RFC607とRFC614がFTPに関して意見を述べている。
RFC624では、更なる設計の変更と小さな修正を提案した。1975年にRFC686、「い
いかげんにほっといて」が、初期のバージョンと、後期のバージョンのFTP の違
いについて言及した。
RFC691では、RFC686のファイルの表示の題目に関して、小さな改訂を行なった。
ベースになるプロトコルがNCP からTCP に移行することに後押しされる形で、既
に書かれたような先人のすべての努力をもとに、TCP 上でFTP を使用するための
仕様としてRFC765が不死鳥のように生まれてきたのである。
FTP の仕様に関するこの版は、ささいな文書の誤りを修正し、いくつかのプロト
コルの機能に関する解説を改良し、そして、いくつかの拡張コマンドを新しく加
えるつもりである。
特に、以下の新しいコマンドがこの版の仕様で加えられる。
CDUP - 上位のディレクトリに移動(Change to Parent Directory)
SMNT - 構造マウント(Structure Mount)
STOU - ユニークなファイル名でのファイル蓄積(Store Unique)
RMD - ディレクトリの削除(Remove Directory)
MKD - ディレクトリの作成(Make Directory)
PWD - ディレクトリの表示(Print Directory)
SYST - システム名の表示(System)
この仕様は、以前の版と互換性がある。前の版に準拠した形で実装されているプ
ログラムは、この仕様に自動的に準拠したものになるだろう。
2.2. 用語
ASCII（アスキー）
アスキー(ASCII)文字セットは ARPA-インターネットプロトコルハンドブックで
定義されたものとする。 FTPにおいては、アスキー文字は、８ビットコードセッ
トのうち、前半のみとする。（つまり、最上位ビットがゼロ）
access controls（アクセス制御）
アクセス制御は、ユーザーの特権を定義し、システムとシステムの中のファイル
の使用に対して制限を加える。アクセス制御は、権限のないユーザーによる使用
や、不慮の誤りによる使用を止めるために必要となる。アクセス制御をどう適用
するかは、FTP サーバーの大権である。
byte size（バイト幅）
FTPでは、二つのバイト幅がある。ファイルでの論理的なバイト幅と、データの
転送に使用される転送バイト幅である。転送バイト幅は常に８ビットである。転
送バイト幅は、データがシステムに貯えられる際のバイトサイズである必要も、
データ構造を解析する際に使用する論理的なバイト幅である必要もない。
control connection（コントロール接続）
ユーザー側プロトコルインタプリタ（User-PI)と、サーバー側プロトコルイン
タプリタ(Server-PI)の間で、コマンドとその応答の通信経路となる通信接続経
路。この接続はTelnetのプロトコルに従っている。
data connection（データ接続）
データが指定されたモードと形式で転送される全二重の接続。転送されるデータ
は、ファイルの一部やファイルの全部、もしくは複数のファイルである。その経
路はサーバーのデータ転送プロセス(Server-DTP)とユーザー側のデータ転送プロ
セス(User-DTP)の間、もしくは、二つのサーバー側のデータ転送プロセス
(Server-DTP)の間をつなぐものになる。
data port（データポート）
受け取る側のデータ転送プロセスはデータ接続をオープンするため、データポー
トへ送り側のデータ転送プロセスが接続にくるのを「耳を澄まして」おく。
DTP （データ転送プロセス)
データ転送プロセスはデータ接続を作成し、管理する。データ転送プロセスは
受け取る側にも、送る側にもなりうる。
End-of-Line（行末）
end-of-line シーケンスは、表示する行の分割個所を定義する。そのシー
ケンスはCRに続いてLFである。
EOF（ファイルの終わり）
End-of-Limeの状態は、転送されているファイルの終了を定義する。
EOR（レコードの終わり）
end-of-recordの状態は、転送されているレコードの終わりを定義する。
error recovery（エラー復旧）
ユーザーがホストシステムか転送プロセスの失敗等のようなエラーから復旧可能
にするための手続き。FTP において、エラー復旧は与えられたチェックポイント
でファイル転送を再開させることなどであろう。
FTP commands（FTPコマンド)
ユーザー側のFTPから、サーバー側のＦＴＰプロセスへ送られる制御するための
情報を含んだ命令群。
file（ファイル）
適当な長さを持ち、パス名で固有に識別出来るようにコンピュータ上の情報を編
成したもの（プログラムを含む）。
mode（モード）
ここでのモードとは、データがデータ接続を通して転送去れるときのモードで
ある。モードは、EOR とEOF を含む転送の間の形式を定義する。FTP で定義する
転送モードは「Transmission Modes（転送モード）」の章で解説される。
NVT
NVT (ネットワーク仮想ターミナル)はTelnetプロトコルで定義されたものとす
る。
NVFS
ネットワーク仮想ファイルシステムのこと。標準の命令とパス名の規定を使用し
て、標準的なネットワーク上のファイルシステムを定義する考え方。
page（ページ）
ファイルはページと呼ばれる独立した部分の集合体として構造を持っているかも
しれない。FTP は、連続していないこれらのファイルを、をインデックスがつけ
られた独立したページとして送信することができる。
pathname（パス名）
パス名は、ユーザーにより、ファイルシステムにファイルが入力されるとき、フ
ァイルを識別するための文字列として定義される。普通、パス名は記憶装置名と
ディレクトリ名とファイル名が含まれる。（但し、記憶装置名とディレクトリ名
はどちらか片方が存在しないかもしれない。）FTP は、まだ標準のパス名に関す
る規定を示していない。それぞれのユーザーは、転送する側のファイルシステム
の規定に準じた名前の規定に従わなくてはならない。
PI（プロトコルインタプリタ）
プロトコル解析部。ユーザー側、サーバー側、それぞれ別の役割をもったユー
ザーPI、サーバーＰＩが実装されていなくてはならない。
record（レコード）
シーケンシャルファイルは「レコード」とよばれる連続した部分の集合をもった
構造となっているかもしれない。レコード構造はFTP にサポートされているが、
ファイル自身は必ずしもレコード構造を持っている必要はない。
reply（応答）
応答とは、FTP 命令に対する成功もしくは失敗いづれかの意味を持つ応答通知で
あり、サーバーからユーザーにコントロール接続を介して送られる。一般的な応
答の形式は、（失敗を含む）終了コードとそれに続くテキスト文字列である。コ
ードは、/*FTP クライアント*/プログラムに使われ、テキストは通常人間のユー
ザーのために用意されている。
server-DTP（サーバー側データ転送プロセス）
通常の、「アクティブ」状態のデータコネクションは、listen状態のデータポー
トとのデータ接続を確立する。それは、転送とファイル蓄積のためのパラメータ
を設定し、そのプロトコルインタプリタからの命令によりデータを転送する。デ
ータ転送プロセスは「パッシブ」状態になることが可能であり、そのときにはデ
ータポートで接続を確立するのではなlisten状態で待っていることができる。
server-FTP process（サーバー側FTP プロセス）
ユーザー側FTP プロセスや、可能なら他のサーバーとの間で協調してファイル転
送処理を行なうためのプロセスや、プロセス群。これらの機能は、プロトコルイ
ンタプリタとデータ転送プロセスから構成去れる。
server-PI（サーバー側プロトコルインタプリタ）
サーバー側プロトコルインタプリタはポートＬで「listen」状態となり、ユーザ
ー側プロトコルインタプリタからの接続を受け付け、コントロール通信接続を確
立する。それは、ユーザーからの通常のFTP コマンドを受信し、応答を送信し、
サーバー側データ転送プロセスを管理する。
type（タイプ）
データの転送と蓄積のために使用されるデータを表現する型。タイプは、データ
を転送するときとデータを蓄積するときの間で行われる変換を暗黙のうちに意味
している。FTP で定義されるデータを表現する型はデータ接続の確立
（Establishing Data Connections）の章で記述される。
user（ユーザー）
ファイル転送サービスを受けることを望んでいる人、もしくはプロセス。人間の
ユーザーは、FTP サーバーのプロセスを直接に操作するかもしれない。しかし、
プロトコルの設計が、プログラムによる自動処理を重視するようになってからは
ユーザーFTP プロセスを使用することが推奨されている。
user-DTP（ユーザー側データ転送プロセス）
データ転送プロセスは、データーポート上でサーバーFTPプロセスからの接続に
「耳を澄まして」おく。もし二つのサーバーがそれらの間でデータを転送中なら
ば、ユーザー側データ転送プロセスはアクティブ状態ではない。
user-FTP process（ユーザー側FTPプロセス）
プロトコルインタプリタ、データ転送プロセス、そしてユーザーインタフェース
を含み、一つ以上のＦＴＰサーバーとの協調動作によりファイル転送を行なう機
能の集合体。ユーザーインタフェースは、ユーザーとの命令、応答などの対話に
おいて、各国の言語を使用しても構わない。
user-PI（ユーザー側プロトコルインタプリタ）
ユーザープロトコルインタプリタは、そのコントロールポートＵから、サーバー
FTPプロセスにコントロール接続を確立し、もし、その過程がファイル転送のた
めのものであるなら、ユーザーデータ転送プロセスを管理する
2.3. FTPの原形
これまでで定義したことをもとに、FTP サービスの原形を図式化したものは以下
の（図１に示される）ようなものになると考えられる。
+----------+
|..........| +--------+
|:ユーザー:←−−→|ユーザー|
|:Ｉ／Ｆ :| +--------+
|:...↑...:|
+----------+ | ｜ |
|..........| |....↓....|
|:サーバー:|FTPコマンド |:ユーザー:|
|: PI :←−−−−−→: PI :|
|:...↑...:|FTP応答 |:...↑...:|
| ｜ | | ｜ |
+--------+ |....↓....| |....↓....| +--------+
|ファイル←−−−→:サーバー:| データ |:ユーザー:←−−→|ファイル|
|システム| |: DTP :←−−−−−→: DTP :| |システム|
+--------+ |:........:| 接続 |:........:| +--------+
+----------+ +----------+
サーバーＦＴＰ ユーザーＦＴＰ
備考: 1. データ接続は両方向で使用される。
2. データ接続は常に存在する訳ではない。
図１ ＦＴＰ使用の原形
図１に示されるような雛形においては、ユーザー側のプロトコルインタプリタが
コントロール接続を確立する。コントロール接続はTelnet プロトコルに準拠す
る。ユーザーの使用開始で、ユーザープロトコルインタプリタにより標準のFTP
コマンドが生成され、そしてコントロール接続を介してサーバープロセスに送信
される。（ユーザーは例えば、ＴＡＣターミナルなどからサーバーに直接コント
ロール接続を生成し、ユーザーFTP プロセスの助けを借りることなく標準FTP コ
マンドを生成するかもしれない。）標準応答はコマンドへの応答として、サーバ
ープロトコルインタプリタからユーザープロトコルインタプリタへコントロール
接続を介して送信される。
データ接続のためのパラメータ（データポート、転送モード、データ表現タイプ
とデータ構造）とファイルシステムに対する操作の性質（送信、受信、ファイル
の追加、削除などなど）がFTP コマンドとして示される。ユーザーデータ転送プ
ロセス、もしくはユーザーデータ転送プロセスが指示した機能ブロックは、指定
されたデータポートに「聞き耳をたて(listen)」、サーバがデータコネクション
を確立し、そしてデータ転送が指定されたパラメータにしたがって行われる。
特筆すべきは、データポートはコントロール接続を介してコマンドを送信したホ
ストと同じである必要はないということである。がしかし、ユーザー、もしくは
ユーザー側FTP プロセスは、指定されたデータポートに対して「聞き耳をたてて
(listen)」おかなければならない。また、データポートが送受信、双方同時に使
用されうることもまた特筆すべきである。
ユーザーが対する別の状況では、どちらも自分のところにはない２台のホストの
間でファイルを転送する必要があるかもしれない。ユーザーは二つのサーバ両方
との間に、コントロール接続を設定し、それら２台がデータ接続で接続されるよ
うに手はずを整えればよい。このようにすることにより、制御情報はユーザープ
ロトコルインタプリタを通るが、データはサーバーのデータ転送プロセス間で行
われる。以下は、サーバー・サーバー接続のモデルである。
制御 +----------+ 制御
＋−−−−→ユーザ FTP←−−−−−＋
｜ |ユーザ PI | ｜
｜ | "C" | ｜
↓ +----------+ ↓
+------------+ +------------+
|FTP サーバー| データ接続 |FTP サーバー|
| "A" |←−−−−−−−−−−→| "B" |
+------------+ポートＡ ポートＢ+------------+
図 2
プロトコルによると、コントロール接続がデータ転送の間は接続されている必要
がある。動作状態のサーバーが、ＦＴＰのサービスを中止したとき、コントロー
ル接続を閉じることは、ユーザーが行なわなくてはならない。もし、コントロー
ル接続が指示なして閉じられたとき、サーバーはデータ転送を中止してしまうだ
ろう。
FTP とTelnetの関係：
FTP は、コントロール接続ではTelnetのプロトコルを使用する。これは、これ
は、二つの方法で実現される。一つは、ユーザー側プロトコルインタプリタか、
サーバー側プロトコルインタプリタが自分自身の機能としてＴｅｌｎｅｔプロト
コルのルールを実装することであり、もう一つは、ユーザー側プロトコルインタ
プリタかサーバー側プロトコルインタプリタは、システム中にある既存の
Ｔｅｌｎｅｔモジュールを利用することである。
実装を楽にし、プログラムコードを共有化し、モジュール式プログラムとなるこ
とを考えると、二番目の方法が良いだろう。効率と、機能の独立性を考えると最
初の方法が良いだろう。実際には、ＦＴＰは、Ｔｅｌｎｅｔプロトコルにはほん
の少ししか依存していないため、最初の方法でも巨大なプログラムコードを含む
ようなことはない。
3. データ転送機能
ファイルは、データ接続だけを経由して転送される。コントロール接続は後に解説さ
れるコマンドの通信とその応答（ＦＴＰ応答の章を参照）のために使用される。いく
つかのコマンドはホストとのデータ転送に関連したコマンドである。これらのデータ
転送コマンドは、データのビットがどう転送されるかを決めるMODEコマンドと、デー
タがどのように表現されるのかを決めるSTRUコマンド、TYPEコマンドである。転送と
その表現は基本的には独立しているが、「ストリーム(Stream)」転送モードでは、そ
のファイルの構造に依存している。また、「圧縮(Compressed）」転送モードが使わ
れると、埋め草になるバイト(Filler byte)の性質は表現形式に依存したものになる。
3.1. データの表現と蓄積
データは、送信元のホストの記憶装置から、受信側ホストの記憶装置へと転送さ
れる。これら二つのシステムの間でデータを記憶する時の表現形式に相違がある
ことから、しばしばデータに対して何らかの変換を加える必要がある。例えば、
ＮＶＴ−ＡＳＣＩＩは異なるシステム間で異なるデータ蓄積形式を持っている。
ＤＥＣ ＴＯＰＳ−２０ｓではＮＶＴ−ＡＳＣＩＩ蓄積に５つの７ビットアスキ
ー文字となり、左づめの３６ビットワードを構成する。ＩＢＭの大型コンピュー
タはＮＶＴ−ＡＳＣＩＩを８ビットのＥＢＣＤＩＣコードとなる。Multicsは、
ＮＶＴ−ＡＳＣＩＩを４つの９ビット文字として３６ビットワードを構成する。
異なるシステム間で、文書を転送するとき、標準的なＮＶＴ−ＡＳＣＩ文字に変
換することが望ましい。送信側、受信側のコンピュータは、それらの内部的な表
現形式から標準形式に変換する必要がある。
表現形式にまつわるもう一つの問題は、バイナリデータ（文字コードではなく）
をワード長が異なるコンピュータ間で転送するときに発生する。送信側がどのよ
うにデータを送信し、受信側がどのようにそれを受信するかは常にはっきりとわ
かっているわけではない。例えば、３２ビットのワード長を持ったコンピュータ
から、３６ビットのワード長をもったコンピュータに対して、３２ビット分のバ
イトを送信したとする。効率と便利さのためには、転送された３２ビット分のバ
イトが、３６ビットのワードの中に右づめされるように受信側のコンピュータで
変換されることが望ましいだろう。どのような場合でも、ユーザーはデータの表
現とその変換に関する設定ができるようにすべきである。ＦＴＰはとても限定さ
れたデータの表現形式を提供する。ユーザーが直接実行する転送はこの限定され
た機能の中だけで実現されることが望ましい。
3.1.1. データタイプ
ＦＴＰにおいてデータの表現はユーザーが指定した表現タイプにより実現され
る。このタイプは暗黙に（ASCIIかEBCDIC）指定されるか、明示的に（ローカル
バイト形式）変換時のバイトサイズが、「論理バイト長」として指定される。注
意しなくてはいけないことは、データ接続で転送される大きさである、「転送バ
イト長」と言われるものとは無関係であり、混同してはいけない。例えば、ＮＶ
Ｔ−ＡＳＣＩＩは論理バイト長として８ビットになる。もし、タイプがローカル
バイト形式であれば、ＴＹＰＥコマンドは二番目のパラメータとして論理バイト
長を指定しなくてはならない。転送バイト長は常に８ビットである。
3.1.1.1. ASCII型
この形は標準の形で、すべてのＦＴＰで必ずサポートされていなくてはなら
ない。これは、両方のコンピュータがEBCDICで転送する方が都合がよい場合
を除けば、テキストファイルの主要な転送方法である。
送信側は、データを内部文字表現形式から、標準的な８ビットＮＶＴ−
ＡＳＣＩＩ表現形式に変換する（Ｔｅｌｎｅｔ仕様を参照）。受信側は、標
準形式からその内部形式に変換する。
ＮＶＴ標準に従って、テキスト行の終了を示す必要がある場合には<CRLF>シ
ーケンスが使用される。（データ表現と蓄積の章の最後、ファイル構造の項
目を参照）標準ＮＶＴ−ＡＳＣＩＩを使用するということは、データは８ビ
ットバイトを使用することになる。
ＡＳＣＩＩ形式とＥＢＣＤＩＣ形式の書式パラメータは、以降の章で解説さ
れる。
3.1.1.2. EBCDIC型
このタイプは内部表現形式にＥＢＣＤＩＣを使用しているコンピュータ間で
の効率を考慮されている。
データは転送時に８ビットのＥＢＣＤＩＣ形式で表現される。ＥＢＣＤＩＣ
形式とＡＳＣＩＩ形式の違いは、文字コードの違いだけである。
構造を示すための行末（レコード終わりの対となる−構造に関する部分を参
照）は、ＥＢＣＤＩＣ形式ではめったに使用されないが、必要ならヌル文字
が使用される。
3.1.1.3. イメージ型
データは転送のため８ビットにまとめられ、連続したビットとして送信され
る。受信側コンピュータはデータを連続したビットとしてそれを蓄積する。
蓄積システムの構造によっては、ファイル（もしくはレコード構造をもった
ファイルの場合は各レコード）に適当な単位（バイト、ワード、ブロック）
で埋め草（padding)をする必要があるだろう。この埋め草は、すべてゼロで
なくてはならず、ファイルの終わり（もしくは各レコードの終わり）になく
てはならず、ファイルを参照する必要があったときに埋め草を識別するため
の方法がなくてはならない。埋め草を追加する変換は、蓄積されたコンピュ
ータ上のファイル利用者が処理できるように広く公表されていなくてはなら
ない。
イメージ形式は、効果的な蓄積とファイルの参照、バイナリデータの転送の
為に用意されている。すべてのＦＴＰの実装において、このタイプが使用可
能であることが推奨されている。
3.1.1.4. ローカル形式
データは、二番目の引数として要求されているバイト長をもった論理バイト
長のデータとして送信される。バイト長は、十進整数でなくてはならない。
デフォルトの値は存在しない。論理バイト長は、転送バイト長と同じである
必要性はない。もし、それぞれのバイト長が異なる場合、論理バイトは転送
バイト長の領域や、最後の「埋め草」の必要性に関係なく連続してまとめら
れる。
データが受信側コンピュータに到着すると、そこでの論理バイト長に従って
変換される。変換は、反転可能（同じパラメータが指定されれば、同じファ
イルを受信可能）でなくてはならず、ＦＴＰの作者に広く公開されている必
要がある。
たとえば、ユーザーが３６ビットの浮動小数点数値を３２ビットのホストコ
ンピュータに送信する場合、論理バイト長を３６としてローカル形式で送信
できる。受信側ホストは扱いやすい論理バイト長として蓄積することが予想
される。この例では、３６ビットの論理バイト長を６４ビットのダブルワー
ドとして蓄積すればいいだろう。
他の例としては、３６ビットのホストコンピュータ同士で通信をするときに
TYPE L 36を使用する。データは、８ビット幅を持った転送単位にまとめら
れ、コンピュータの２ワードは、９回の１バイトデータの転送となる。
3.1.1.5. 書式制御
ＡＳＣＩＩ型、ＥＢＣＤＩＣ型は、オプションで２番目の引数を持つことも
出来る。これは、ファイルで使用する改行の書式があれば、それを指定する
ためのものである。以下のデータ表現形式がＦＴＰで定義されている。
文字のファイルは、三つの目的で転送されるであろう。印刷、後で使うとき
のための蓄積、データを使った処理である。もし、ファイルが印刷の目的で
送られたなら、受信側のホストは、どのように縦方向の書式を制御してその
ファイルを表現するかがわからなくてはならない。２番目の場合では、ファ
イルは蓄積したものと同じ形式のものが後で取り出せなくてはならない。最
後の場合、あるコンピュータから別のコンピュータに転送されたファイルは
転送先のホストで問題なく処理できることが望ましいであろう。ＡＳＣＩＩ
またはＥＢＣＤＩＣの指定だけではこれらの目的が分からない。そのため、
これらの形には、二番目の引数として以下のいずれかの書式が指定できる。
3.1.1.5.1. 非印刷
これは、二番目の引数が省略されたときのデフォルトの書式である。非
印刷の書式はすべてのＦＴＰで実装されていなくてはならない。
ファイルには、縦方向の書式制御情報は必要ない。もし、このファイル
が印刷するプロセスに送られたときには、このプロセスはマージンとス
ペーシングのための標準的な値使用するだろう。
普通、この書式はファイルを蓄積だけする場合に使用される。
3.1.1.5.2. Ｔｅｌｎｅｔ書式制御
ファイルは、印刷プロセス処理で適切に処理できるＡＳＣＩＩもしくは
ＥＢＣＤＩＣの縦方向書式制御（例：<CR>、<LF>、<NL>, <VT>, <FF>）
とする。<CRLF>がこの順番であらわれたとき、行末を示している。
3.1.1.5.2. フォートラン改行制御 (ASA)
ファイルは、ＡＳＡ（フォートラン）縦方向書式制御文字を含んでいる
とする。（ＲＦＣ７４０付録Ｃ、Communications of the ACM Vol. 7
No.10 606ページ 1964/10を参照）ＡＳＡ標準に従った行、レコードの
書式制御がなされている場合、最初の文字は印刷されない。その代わり
に、それ（最初の文字）は次のレコードが印刷される前の縦方向の紙送
り量を意味している。
ＡＳＡ標準では、以下の制御文字が指定できる。
文字 縦方向の改行量
ブランク 一行分紙送り
０ ２行分紙送り
１ 改ページ
＋ 改行しない（重ね書き）
明らかに印刷処理のためには構造単位の終わりを区別する必要がある。
もし、ファイルがレコード構造（後述）をもっていれば問題はない。レ
コードは転送と蓄積の時に、はっきりと印がつけられている。もし、フ
ァイルがレコード構造を持っていないときは<CRLF>、行末コードが印刷
行を分けるために使用される。しかし、ＡＳＡ制御はこれらの書式指定
より優先する。
3.1.2. データ構造
さらに異なる表現形式として、ＦＴＰはファイルの構造を指定することができ
る。ＦＴＰでは３つのファイル構造が定義されている。
ファイル構造 内部的な構造を持たず、ファイルはデータバイトの羅列と
してとらえられる。
レコード構造 ファイルは、シーケンシャルレコードとして作成される
ページ構造 ファイルは独立してインデックスされたページとして作成
される。
ファイル構造はSTRUコマンドがなかったときの標準値であり、ファイル構造と、
レコード構造はテキストファイル（例：TYPE ASCII、TYPE EBCDIC のファイル）
においてはすべてのＦＴＰで使用可能でなくてはならない。ファイルの構造は、
ファイルの転送モード（転送モードの章を参照）と、ファイルの蓄積に影響す
る。
ファイルの「自然な」構造は、ホストコンピュータのファイル記録システムに依
存したものになる。ＩＢＭの大型コンピュータ上のソースコードファイルは、通
常、固定長のレコードとなるが、ＤＥＣのＴＯＰＳ−２０では、<CRLF>などで行
単位に分けられた文字の並びとなる。もし、そのような異なるコンピュータ間で
ファイルを便利に転送したいなら、一つのコンピュータは、他のコンピュータの
ファイルをどう扱うかに関する情報が解っているべきである。
いくつかのコンピュータでは、標準的にファイル型をもち、別のコンピュータで
は、レコード型を標準としているため、あるコンピュータの構造型のファイルを
他のコンピュータに転送したときに問題が発生することが予想される。もし、レ
コード構造をもったファイルを、ファイル型のコンピュータに転送したとする
と、送信先のコンピュータは、レコード構造から内部的なファイル構造に変換す
るであろう。明らかに、この変換は便利なものになるであろうが、レコード構造
を使ってこのファイルを取り出すときのためにこの変換は可逆性をもっていなく
てはならない。
ファイル構造をもったファイルが、レコード型のコンピュータに転送されるとき
に、ファイルを受信側が内部的に使用するレコードになるように分割するとき、
どのような基準を使うかが問題となる。もし、この分割が必要ならＦＴＰでは、
行末、すなわちＡＳＣＩＩテキストファイルなら<CRLF>、ＥＢＣＤＩＣテキスト
ファイルなら<NL>を使用するように実装すべきである。もしＦＴＰの実装がこの
技を使うなら、ファイルがファイル構造で取得されるときには、逆方向変換を行
わなくてはならない。
3.1.2.1. ファイル構造
ファイル構造はSTRUコマンドが指定されない時のデフォルトである。
ファイル構造においては、内部構造を持たず、ファイルは１バイト単位のデ
ータの並びととらえられる。
3.1.2.2. レコード構造
レコード構造は「テキスト」ファイル（例えば、ＡＳＣＩＩやＥＢＣＤＩＣ
のタイプ）の為に、すべてのＦＴＰで実装されていなくてはならない。
レコード構造においては、ファイルはシーケンシャルレコードとして作成さ
れる。
3.1.2.3. ページ構造
ページ構造は、ＦＴＰにおいて、不連続なファイルを転送するために定義さ
れている。このタイプのファイルは、しばしば「ランダムアクセスファイ
ル」、もしくは「ｈｏｌｅｙファイル」として知られているものである。こ
れらのファイルでは、しばしば、全体としての情報（ファイルディスクリプ
タなど）、ファイルの断片（ページアクセス制御）のどちらか、もしくは両
方が含まれていることがある。ＦＴＰでは、ファイルの断片のことをページ
と呼んでいる。
さまざまな大きさのページや、結び付けられた情報に備えるため、それぞれ
のページはページヘッダと共に送信される。ページヘッダには、以下のよう
な領域が含まれている。
ヘッダ長
ヘッダ長を含むページヘッダの論理バイト数。最小のヘッダ長は４。
ページインデックス
ファイルのこの断片の論理ページ番号。これはこのページの転送の番号
ではなく、このページのファイル上の位置を示すために使われる。
データ長
ページデータの論理バイト数。最小値は０。
ページ種別
このページの種別。以下のページ種別が使用される。
０ ＝ 最後のページ
これは、ページ構造の転送時に最後のページであることを示す。ヘ
ッダ長は４であり、データ長は０である。
１ ＝ 普通のページ
これは、普通のページであり、ページ単位の制御情報などは含まな
い。ヘッダ長は４である。
２ ＝ ディスクリプタページ
この種別は、ファイル全体としてのディスクリプタ関連情報の転送
に使用される。
３ ＝ アクセス制御ページ
この種別は、追加ヘッダ領域をもち、ページ単位のアクセス制御情
報を持っている。ヘッダ長は５である。
追加フィールド
ページ毎の制御情報のために、追加のヘッダ領域があるかもしれない。
たとえば、ページ単位のアクセス制御などである。
すべての領域は、１論理バイトの長さを持つ。論理バイト長は、ＴＹＰＥコ
マンドで示される。付録Ｉにページ構造のときの概要と仕様が記述されてい
る。
引数に関して注意すべきこととして、ファイルを送信したのと同じ形で受信した
いときには、送信時と受信時に同じ引数を指定する必要がある。逆にいえば、
ＦＴＰの実装においては、送信時、受信時で使われた引数が同じならば、送信し
たファイルと受信したファイルが同じになるようにしなくてはならない。
3.2 データ接続の開始
データ転送のしくみは、転送のための適切なポートとパラメータ選択でデータ接
続を設定することである。
ユーザー側とサーバー側のデータ転送プロセスはデフォルトのデータポートを持
っている。ユーザープロセスのデフォルトのデータポートはコントロール接続の
ポート（例：Ｕ）と同じである。サーバープロセスのデフォルトのデータポート
は、コントロール接続のポートに近いポート（例：Ｌ−１）とする。
転送バイト長は８ビットで１バイトとする。このバイト長は、実際のデータ転送
にだけ関連する。コンピュータファイルシステム上でのデータの表現形式とは関
係しない。
受信側のデータ転送プロセス（これは、ユーザー側データ転送プロセスか、二番
目のサーバー側データプロセス〜/*サーバー・サーバー転送のとき*/となる）は
転送要求コマンドの送信より優先して、データポートに対して「聞き耳をたて
（listen）」ておく。ＦＴＰのコマンド要求で、データ転送の方向を決める。転
送要求を受け取ったサーバーは、データ接続の初期化をポートに対して行う。接
続が成立すると、両方のデータ転送プロセスの間でデータ転送が行われ、サーバ
のプロトコルインタプリタはユーザー側のプロトコルインタプリタに対してコマ
ンド応答を送信する。
すべてのＦＴＰの実装において、デフォルトのデータポートが使用でき、また、
ユーザープロトコルインタプリタだけがデフォルトではないポートに変更するこ
とが出来る。
別なデータポートを使用する為には、ユーザーがＰＯＲＴコマンドを使用する。
ユーザーは、ＴＡＣラインプリンタにファイルをダンプ出力させたかったり、も
う一つ別なホストコンピュータから取得したかったりするだろう。後の場合、ユ
ーザー側プロトコルインタプリタは、コントロール接続を二つのサーバーのプロ
トコルインタプリタに設定する。その後、一方のサーバーは、（ＦＴＰコマンド
で）もう一方が開始する接続に「聞き耳をたてる(listen)」ように通知される。
ユーザー側プロトコルインタプリタは、一方のサーバーのプロトコルインタプリ
タにPORTコマンドを送信し、もう一方のデータポートを指定する。最終的に、両
方は適切な転送コマンドを送られる。操作するユーザーとサーバー群の間でのコ
マンドと応答の正確な順番については、ＦＴＰ応答の章で記述する。
大まかにいえば、データ接続、その接続と終了はサーバー側の責任で行われる。
例外としては、ユーザー側データ転送プロセスが転送状態の時にＥＯＦを指定し
て接続終了を要求した場合である。サーバーは、以下の状態のときにデータ接続
を終了させなくてはならない。
１・転送状態において、サーバーがデータの送信を終了し、ＥＯＦを指定してク
ローズを要求したとき。
２・サーバーがユーザーからＡＢＯＲＴコマンドを受信したとき
３・ユーザーからのコマンドにより、ポート指定に変更があったとき
４・正規な手順、もしくはその他の理由によりコントロール接続がクローズした
とき
５・回復不能なエラーが発生したとき
その他のクローズはサーバー側オプションであり、そのときにはサーバーはユー
ザー側プロセスに対して、２５０か２２６のいずれかを通知しなくてはならな
い。
3.3. データ接続の管理
デフォルトのデータ接続ポート：すべてのＦＴＰの実装では、デフォルトのデー
タ接続ポートをサポートしなくてはならない。そして、ユーザー側プロトコルイ
ンタプリタはデフォルト以外のポートを開始することができる。
非デフォルトのデータポートの決定：ユーザー側プロトコルインタプリタは、
ＰＯＲＴコマンドを使用してデフォルトではないユーザー側データポートを指定
できる。ユーザー側プロトコルインタプリタは、サーバーにＰＡＳＶコマンドを
使用してサーバー側データポートをデフォルトではないものに変更する要求を出
すことができる。接続がアドレスの対として定義されて以降は、これら双方とも、
異なるデータ接続を行う準備が出来たことになり、データ接続の終了時まで新し
いポートを使用できる。
接続の再利用：データ転送において、ストリームモードを使用する場合、ファイ
ル終わりが接続の終了を意味している。これは、もし複数ファイルを単一セッシ
ョンで複数ファイルを転送したいときに問題となる。これはＴＣＰが信頼性をも
った通信を保証するため、接続記録をタイムアウトするまで保持しなくてはなら
ないことに原因がある。この結果、接続はすぐに再度開始することはできない。
これには、二つの解決策がある。一つは、デフォルトではないポートを使う
ことである。もう一つは異なる転送モードを使うことである。
転送モードについて解説する。ストリーム転送モードは、接続が誤って切断
されたのか、そうでないのかの判断が出来ないために、本質的に信頼性がな
い。他の転送モード（ブロックモード、圧縮モード）はファイル終了を示す
ために接続のクローズを使用していない。それらは、ファイルの終了を識別
するに十分なＦＴＰ符号を持っている。その結果、これらのモードを使うこ
とにより、複数のファイル転送でのデータ接続の開始をなくすことができ
る。
3.4. 転送モード
データ転送に関する次の考察は、正しい転送モードの選択についてである。ここ
では３つのモードがある。データを書式にあわせて転送して転送の再開機能を許
すもの、何の処理も行わないか最低限の処理を行ってそのまま送るもの、構造の
属性に関連した処理を行うものである。圧縮モードでは、その表現形式は「埋め
草（ｆｉｌｌｅｒ）」に左右される。
すべてのデータ転送は、明確に指定されたファイル終了（ＥＯＦ）か、データ接
続のクローズに伴って暗黙のうちに指定されたＥＯＦで終了する。レコード構造
を持ったファイルについては、すべてのレコード終了マーク（ＥＯＲ）は、最後
のそれを含めて明らかになっている。ページ構造をもって転送されるファイル
は、ページ種別として「最後のページ（ｌａｓｔ−ｐａｇｅ）」が使われる。
注：この章のこれ以降では、バイトとは、特別に指定がない限り「転送バイト」
を意味する。
標準化された転送のためには送信側コンピュータは、その内部的な行末、レコー
ド末の表現を、転送モードにより規定された表現に変換し、受信側コンピュータ
は、その内部的な表現に逆変換しなくてはならない。ＩＢＭの大型コンピュータ
におけるレコード数フィールドは他のコンピュータに理解されないかも知れな
い、そのため、レコード末の情報は、ストリームモードにおいては２バイトの制
御コードに、ブロックモードや圧縮モードにおいてはそのモードディスクリプタ
のビットにフラグを立てたものに変換する。レコード形式ではないＡＳＣＩＩや
ＥＢＣＤＩＣのファイルは、それぞれ行末を<CRLF>や<NL>で示している。これら
の変換はいくつかのシステム、において負荷の増加を意味している。典型的なシ
ステムでは非レコード構造のテキストファイルはバイナリ表現でストリームモー
ドを転送に使用している。
以下の転送モードがＦＴＰでは定義されている。
3.4.1 ストリームモード
データは、バイトの並びとして転送される。どの表現種別が使われるかの制
限はない。レコード構造も許される。
レコード構造ファイルにおいて、ＥＯＲとＥＯＦはそれぞれ２バイトの制御
コードとして表現される。制御コード最初の１バイトはすべて１、エスケ
ープ文字である。二番目のバイトは、最下位ビットのみオンでＥＯＲ、最下
位から２番目のビットのみオンでＥＯＦである。つまり、ＥＯＲは１という
値、ＯＥＦは２という値である。ＥＯＲとＥＯＦはこの二番目のバイトの、
二つのビットをオンニすることにより同時に表現することができる（値の３
）。もし、すべてのビットが１のバイトがデータとして送信された場合、次
のバイトは制御コードであることを意味する。
もしも、構造がファイル構造なら、ＥＯＦは送信側コンピュータによってデ
ータ接続が閉じられることで指定され、送られたすべてのバイトはデータバ
イトである。
3.4.2 ブロックモード
ファイルは１以上のヘッダバイトに続くデータブロックの並びとして送信さ
れる。ヘッダバイトには、カウントフィールドとディスクリプタコードが含
まれる。カウントフィールドには、データブロックの最大長をバイトで示し
ており、また、次のデータブロックの最初（埋め草（ｆｉｌｌｅｒ）ビット
は持たない）を示している。ディスクリプタコードは、以下を定義してい
る。：ファイルの最後のブロック（ＥＯＦ）、レコードの最後のブロック
（ＥＯＲ）、リスタートマーカー（エラーの復旧と転送再開の章を参照）、
不良マーカー（転送されているデータは、エラーの可能性があり、信頼でき
ない等）である。この最後のコードは、ＦＴＰにおけるエラー制御のために
用意されているものではない。これは、（地震、気象などの）高信頼性を求
めるデータを、（磁気テープリードエラーなどの）各コンピュータ固有の障
害があったにも関わらず、一部のデータに不良の可能性があることを解った
上で、すべてのデータを送受信したいとう要求から生まれたものである。こ
のモードでは、レコード構造が使用でき、すべての表現タイプが使用でき
る。
ヘッダは３バイトから構成される。２４ビットのヘッダのうち、下位の１６
ビットはバイト数を意味し、上位の８ビットは以下に示されるディスクリプ
タコードをあらわしている。
ブロックヘッダ
+----------------+----------------+----------------+
| ディスクリプタ | バイト数 |
| ８ビット | １６ビット |
+----------------+----------------+----------------+
ディスクリプタコードはディスクリプタバイト中のビットのフラグとして示
される。４つのコードがバイト中の対応するビットを示す１０進数として予
約されている。
コード 意味
128 データブロックの終わりがＥＯＲである。
64 データブロックの終わりがＥＯＦである。
32 データブロックにはエラーの可能性がある。
16 データブロックはリスタートマーカーである。
この符号化で、一つ以上のディスクリプタ状態コードが一つのブロックに指
定できる。必要なビットがフラグとしていくつでも立てられる。
リスタートマーカーは増加する数値が、コントロール接続で使用している１
バイト（８ビット）の文字コード（デフォルトでは、ＮＶＴ−ＡＳＣＩＩ）
で印刷可能な文字並びとしてデータストリーム中に挿入される。<SP>（適切
な言語において空白文字の意）は、リスタートマーカーには使用できない。
例えば、６文字のマーカーを送信する場合、以下が送信される。
+--------+--------+--------+
|Descrptr| Byte count |
|code= 16| = 6 |
+--------+--------+--------+
+--------+--------+--------+
| Marker | Marker | Marker |
| 8 bits | 8 bits | 8 bits |
+--------+--------+--------+
+--------+--------+--------+
| Marker | Marker | Marker |
| 8 bits | 8 bits | 8 bits |
+--------+--------+--------+
3.4.3 圧縮モード
送信される情報には、３種類ある。バイト文字として送られる通常データ、
埋め草や、繰り返しを含む圧縮データ、２バイトのエスケープ文字で送られ
る制御情報である。もし、０より大きいｎバイト（最大１２７）の通常デー
タが送信されるとき、最初のビットが０にセットされ、下位の７ビットに数
値のｎが入った１バイトに続いてこれらのｎバイトの通常データが送信され
る。
バイト文字:
1 7 8 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| n | | d(1) | ... | d(n) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
↑ ↑
＋− ｎバイト−＋
のデータ
d(1)からd(n)は、ｎバイトのデータの文字列
ｎは正の値でなくてはならない
ｄという値を持つｎバイトのデータの繰り返しを圧縮するときには、以下の
ような２バイトが送信される。
圧縮されたバイト：
2 6 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0| n | | d |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ｎバイトの連続した埋め草となるようなデータは、連続データの表現種別を
変更すると１バイトに圧縮される。もし、ＡＳＣＩＩかＥＢＣＤＩＣタイプ
なら、埋め草バイトは空白文字（アスキー文字なら３２、ＥＢＣＤＩＣは６
４）である。もしもイメージか、ローカルバイトの時には、ゼロである。
埋め草文字列:
2 6
+-+-+-+-+-+-+-+-+
|1 1| n |
+-+-+-+-+-+-+-+-+
エスケープシーケンスは、２バイトではり、その最初はエスケープバイト
（すべてゼロ）となり、次のバイトはブロックモードで定義されたディスク
リプタコードを含んだものとなる。ディスクリプタコードは、ブロックモー
ドと同じ意味を持ち、後に続くバイト列に適用される。
圧縮モードは、少しのＣＰＵパワーを使用することにより、ネットワーク転
送の帯域幅をおおきく増加させるために有効である。
それは、ＲＪＥホストで作られた印刷ファイルのサイズを縮小するのに特に
効果的である。
3.5. 障害復旧と再開
データ転送において、ビット落ちや化けを発見する方法はない。このレベルの誤
りの制御はＴＣＰにより処理される。しかし、再開手続きは、ユーザーを（ホス
トコンピュータ、ＦＴＰプロセス、ネットワーク障害を含む）システム全体の障
害から守る手段を提供している。
再開手続きは、ブロックモードと圧縮モードでのみ定義される。それは、データ
の送信側で、データ列の中に特別な位置情報を含むマーカーコードを挿入する必
要がある。位置情報は、送信側にだけ意味のある値であるが、デフォルトでは表
示可能な文字か、コントロール接続で使用している文字（ASCIIかEBCDIC)でなく
てはならない。マーカーはビット通番、レコード通番やその他、コンピュータが
データのチェックポイントとして使用できるような情報が指定できるだろう。再
開手続きが実装されているデータの受信側は、受信側のコンピュータで、それに
対応する位置を記録し、この情報を使用者に通知する。
コンピュータの障害が発生すると、使用者はＦＴＰの再開手続きにマーカーの位
置を指定することにより、データの転送を再開出来る。以下に、再開手続きの例
を示す。
データの送信側は、データ列中の適当な場所に適当なマーカーブロックを挿入す
る。受信側は、ファイルシステム中の対応する位置にマーカーを付け、使用者に
最後の送受信側のマーカー情報をユーザーに通知し、直接、もしくはコントロー
ル接続を通して１１０の応答をする（どちらが送信側になるかによる）。障害が
発生すると、使用者、もしくは制御プロセスが、サーバー側のマーカーコードを
引数としたリスタートコマンドで送信された最後のサーバーマーカーで、サーバ
ーを再起動する。リスタートコマンドはコントロール接続を経由して送信され、
その直後に障害が発生したときに行われていた操作のコマンド（RETR,STORか
LIST）が続く。
4. ファイル転送機能
ユーザー側プロトコルインタプリタから、サーバー側プロトコルインタプリタへの通
信経路は、ＴＣＰ接続を使用してユーザー側からサーバー側の標準ポートに開始され
る。ユーザー側のプロトコルインタプリタは、ＦＴＰコマンドの送信と、受信した応
答の解析を行う。サーバー側プロトコルインタプリタは、コマンドの解析、応答の送
信、データ接続とデータ転送のためのデータ転送プロセスの管理を行う。データ転送
の二番目の当事者（受け側転送プロセス）がユーザー側データ転送プロセスなら、そ
れは、ユーザー側ＦＴＰの内部的なプロトコルに従って管理される。もしも、それが
別のサーバー側データ転送プロセスなら、それはユーザー側プロトコルインタプリタ
からのコマンドに従って、別のサーバーのプロトコルインタプリタにより管理され
る。ＦＴＰの応答については次の章で言及する。この章でのいくつかのコマンドの解
説で、使用できる応答についてはっきりとさせる手助けになるだろう。
4.1. FTPコマンド
4.1.1. アクセス制御コマンド
以下のコマンドはアクセス制御関連のものである。（コマンドコードは、括
弧内に示される）
ユーザー名 (USER)
引数には、ユーザーを特定するためのＴｅｌｎｅｔ文字列が入る。
ユーザー識別は、サーバーがそのファイルシステムをアクセスするため
に必要である。このコマンドは、普通、コントロール接続を確立した後
で、ユーザーから最初に送られるであろう（いくつかのサーバーはそう
であることを要求している）。さらに識別情報として、パスワード、課
金（アカウント）コマンドもまた、サーバーによっては必要である。サ
ーバーは、アクセス情報や、課金情報を変更するために、いつでも入力
できるようにしなくてはならない。これは、すでに入力されたユーザー
名、パスワード、課金情報を無効にして、新たにこれらのログインシー
ケンスを繰り返すことを意味する。すべての転送パラメータは変更され
ず、そして、すべての進行中のファイル転送は、以前のアクセス制御パ
ラメータのまま完了する。
パスワード（PASS）
引数には、ユーザーのパスワードを示すＴｅｌｎｅｔ文字列が入る。こ
のコマンドは、ユーザー名コマンドの直後になくてはならず、そして、
いくつかのサイトでは、アクセス制御のためのユーザー識別はこれで終
わりになる。パスワード情報はとても注意深く扱うべきであるから、こ
れは、入力を「隠し」たり、表示されないようにしたりすることが強く
求められる。機密であるパスワード情報を隠すのは、ユーザー側ＦＴＰ
プロセスの責任である。
課金情報（ACCT)
引数には、ユーザーの課金情報を示すＴｅｌｎｅｔ文字列が入る。この
コマンドはユーザーコマンドに関連付けられる必要はない。いくつかの
サイトでは、ログインするために課金情報を必要とするし、書き込み等
の実際の操作の際に指定するところもある。後のケースでは、コマンド
はいつでも送信される可能性がある。
これらのケースで、自動化するために応答コードが異なっている。ログ
インに課金情報が必要な場合、パスワード入力コマンドの成功時応答コ
ードは３３２である。逆に、ログインに課金情報が必要ない場合、成功
時応答コードは２３０である。そして、もし、課金情報が後に行われる
コマンド操作で必要な場合、サーバーは、蓄積するのか、コマンドを破
棄するのかによって、３３２（課金コマンド(ACCT)を受諾するまで中断
）か５３２の応答を返すべきである。
作業ディレクトリ変更（CWD）
このコマンドは、ユーザーに異なるディレクトリやファイルストレージ
のデータセットで作業させたり、ログインや課金情報をやり直させない
ようにするためのものである。同様に転送パラメータは変更されない。
引数は、ディレクトリや、他のシステムに依存したファイルグループを
指定するパスネームである。
親ディレクトリへ移動（CDUP)
このコマンドは、CWDの特殊なケースであり、親ディレクトリの銘々規
則の異なるオペレーティングシステムでのディレクトリ構造間移動のプ
ログラム実装を簡単にするために加えられた。応答コードはCWDのもの
と同じである。付録IIに詳細が記されている。
構造マウント（SMNT）
このコマンドは、ユーザーにログインやアカウント情報を変更すること
なく、異なるファイルシステムデータ構造をマウントさせるためのもの
である。転送パラメータは変更されない。引数は、ディレクトリ、また
は他のシステム依存のファイルグループ指定子である。
再初期化（REIN）
このコマンドはUSERコマンドの終了であり、実行中のファイル転送が終
了するまでを除いて、すべての入出力とアカウント情報をフラッシュす
る。すべてのパラメータはデフォルトの状態にリセットされ、コントロ
ール接続はオープンされたまま残される。これは、ユーザーがコントロ
ール接続をオープンした直後の状態と同じ状態である。USERコマンドが
この状態の後に続く。
ログアウト（QUIT）
このコマンドはUSERコマンドの終了であり、もしもファイル転送が進行
中でなければ、サーバーはコントロール接続を終了する。もし、ファイ
ル転送が進行中なら、その結果を通知するために接続はオープンされた
まま残り、その後、サーバーは接続をクローズする。もし、ユーザープ
ロセスがファイルをいくつかのUSERコマンドを使用して転送する必要が
あり、それぞれについてクローズ、再オープンをしたくないときには、
QUITの代わりにRAINコマンドを使用する。
コントロール接続の予期しないクローズがあったとき、サーバー側では
中断(ABOR)処理とログアウト(QUIT)処理が行われる。
4.1.2. 転送パラメータコマンド
すべてのデータ転送パラメータは、デフォルト値をもっている。そして、デ
ータ転送パラメータを指定するコマンドは、デフォルトのパラメータ値を変
える必要がある時にだけ必要になる。デフォルト値は、最後に指定された値
であり、値が指定されていなければその代わりに標準的な値となる。これは
サーバーは、適切なデフォルト値を「覚えている」必要があることを意味し
ている。コマンドは、どの順番で指定されてもよいが、ＦＴＰのサービスコ
マンドの前になくてはならない。以下にデータ転送パラメータを指定するコ
マンドを示す。
データポート（PORT)
引数は、データ接続で使用されるデータポートを指定するためのホスト
とポートである。ユーザー側とサーバー側のデータポートのために、デ
フォルト値があり、普通はこのコマンドとその応答は不要である。この
コマンドが使われたときには、引数は３２ビットのインターネットホス
トアドレスと、１６ビットのＴＣＰポートアドレスを結合したものにな
る。このアドレス情報は、８ビット毎の領域に分解され、それぞれの領
域は十進数（文字列表現）で転送される。領域はカンマで区切られる。
ポートコマンドは、以下のようになる。
PORT h1,h2,h3,h4,p1,p2
h1 はインターネットホストアドレスの最上位８ビット。
パッシブ (PASV)
このコマンドは、サーバー側のデータ転送プロセスに対して（デフォル
トではない）データポートに「聞き耳を立てて(listen)」おくように指
示し、転送コマンドの受信によって接続を確立するのではなく、接続を
待つようにする。このコマンドの応答には、このサーバーが待っている
(listenしている)ホストとポートアドレスが含まれる。
表現タイプ（TYPE）
引数はデータ表現と蓄積の章で述べられた表現タイプを指定する。いく
つかのタイプは、二番目の引数を使用する。最初の引数は、一文字の
Ｔｅｌｎｅｔ文字であり、二番目の引数がＡＳＣＩＩかＥＢＣＤＩＣか
を示す。ローカルバイト形式の時の二番目のバラメータは、十進整数で
バイトサイズを示す。引数は、空白文字で区切られる。（アスキーコー
ドの３２）
以下のようなコードがタイプとして使用される
A - ASCII ＼ ／ N - Non-Print
｜ ＼ ／ ｜
E - EBCDIC ＋−−×−−＋ T - Telnet 書式制御
｜ ／ ＼ ｜
I - IMAGE ／ ＼ C - ＡＳＡ改行制御
L <バイトサイズ> − ローカルバイト・バイトサイズ
書式パラメータが変更され、その後、最初の引数だけでそれが変更され
たときには、書式パラメータは、NonPrintのデフォルト値に戻される。
ファイル構造（STRU）
引数は、一文字のＴｅｌｎｅｔ文字コードであり、データ表現と蓄積の
章で述べられたファイル構造を示している。
以下のコードが構造として使用される。
F - ファイル（レコード構造を持たない）
R - レコード構造
P - ページ構造
デフォルトの構造はファイル構造である。
転送モード（MODE）
引数は一文字のＴｅｌｎｅｔ文字コードで、転送モードの章で述べられ
たデータの転送モードを示している。
以下のコードが転送モードに使用される。
S - ストリーム
B - ブロック
C - 圧縮
デフォルトの転送モードはストリームである。
4.1.3 ＦＴＰサービスコマンド
ＦＴＰのサービスコマンドは、ユーザーから要求されたファイル転送やファ
イルシステム機能について定義している。ＦＴＰサービスコマンドの引数
は、多くの場合パス名となる。パス名の形式は、サーバー側の（標準的なデ
フォルトが適切である）慣習に従ったもののでなくてはならない。そして、
コントロール接続でのコード体系の慣習に従う。推奨されるデフォルト処理
としては、最後に指定されたデバイス、ディレクトリ、ファイル名を使用す
るか、そのユーザーが定義した標準的なデフォルトを使用する。コマンドは
「rename from」の次に「rename to」コマンドが、リスタートコマンドの次
に、前回中断された（STORやRETRなどの）サービスコマンドが来なくてはい
けないことを除けば、どのような順番で命令しても構わない。ＦＴＰサービ
スコマンドの結果転送されるデータは、いくつかの応答情報を除けば常にデ
ータ接続を経由して送信されるであろう。以下のコマンドがＦＴＰのサービ
スコマンドとして使用される。
取得（RETR)
このコマンドは、ファイル名を指定して、サーバー側データ転送プロセ
スに、別のサーバー側データ転送プロセスや、ユーザー側データ転送プ
ロセスなどのデータ接続の接続先に対して、ファイルの複製を送信させ
る。サーバー側の、ファイルの中身やその状態は影響を受けない。
蓄積（STOR)
このコマンドは、サーバー側データ転送プロセスにデータ接続経由で転
送されてくるデータを受け取り、サーバー側にファイルとしてそのデー
タを蓄えさせる。もし、パス名で指定されたファイルが、サーバー側に
すでに存在する場合、そのないような転送されたデータで上書きされ
る。もし、パス名で指定されたファイルが存在しない場合には、新しい
ファイルがサーバー側に作られる。
ユニーク蓄積（STOU）
このコマンドは、STORと同じような動作をするが、結果として作業中の
ディレクトリに作成されるファイルは、そのディレクトリ内で重複しな
い名前を持ったものになる。応答コード２５０の転送開始応答は、作ら
れるファイルの名前を含まなくてはならない。
追加（と作成） (APPE)
このコマンドは、サーバー側データ転送プロセスにデータ接続経由で転
送されてくるファイルを受け取り、サーバー側に存在するファイルに蓄
えていく。もし、パス名で指定されたファイルがサーバー側に存在する
場合、データはファイルに追加されて行く。そうでなければ、指定され
たファイルがサーバー側に作成される。
割り当て (ALLO)
このコマンドは、転送される新しいファイルのための十分な容量をあら
かじめ用意しておく必要があるサーバーで必要になるだろう。引数は、
ファイルのために予約する容量を十進整数のバイト数（論理バイト長を
使用）で表す。ページ構造やレコード構造で送信されるファイルでは、
最大のレコード数やページ数も（論理バイトで）必要になるだろう。
これは、コマンドの二番目の引数として十進整数を使用する。この二番
目の引数はオプションであるが、使用されるときには、３つのＴｅｌｎ
ｅｔ文字である＜空白＞Ｒ＜空白＞で最初の引数と分けなくてはならな
い。このコマンドに続いて、蓄積(STOR)か追加(APPE)が送信されるだろ
う。ALLOコマンドは、ファイルの最大サイズをあらかじめ明示する必要
のないサーバーにおいては、NOOP（処理なし）と同じように扱われるべ
きである。そして、それらのサーバーでは、最大レコードサイズか、最
大ページサイズだけに注目し、最初の引数はダミーの値として無視すべ
きである。
再開（リスタート）
引数として、どのファイル転送が再開されるべきかを示すサーバーマー
カーを指定する。このコマンドは、ファイル転送を行わないが、ファイ
ルの指定された目印まで読み飛ばす。このコマンドには、すぐにファイ
ル転送を再開させたい適切なファイル転送コマンドが続く。
名前変更元(RNFR)
このコマンドは、名前を変更したいファイルの元の名前を指定する。こ
のコマンドの次には、すぐに名前変更先コマンドが続き、変更先のファ
イル名を指定しなくてはならない。
名前変更先(RNTO)
このコマンドは、直前の名前変更元コマンドで指定されたファイルの新
しい名前を指定する。この二つのコマンドにより、ファイルは名前が変
更される。
中断(ABOR)
このコマンドは、サーバーに以前のＦＴＰサービスコマンドと、関連す
るすべてのデータ転送を中断させる。中断コマンドは、サーバーによる
強制的な承認のためにＦＴＰコマンドの章で述べたような「特別な処
理」を行う必要があるだろう。もし、（ファイル転送を含む）以前のコ
マンドがすでに完了している場合、特別な処理は行われない。コントロ
ール接続はクローズされないが、データ接続はクローズされる。
サーバーがこのコマンドを受け取ったとき、二つの状態がありうる。
（１）ＦＴＰサービスコマンドはすでに終了している。
（２）ＦＴＰサービスコマンドは実行中である。
最初の場合、サーバーは（もし、オープンしていれば）データ接続
をクローズし、サービス要求が異常中止されたことを示すために応
答コード４２６を返す。サーバーはその後、中断コマンドが正常に
処理されたことを示すために２２６の応答を送信する。
削除(DELE)
このコマンドは、指定されたパス名のファイルをサーバー側で削除す
る。もし、特別なレベルの保護が必要なら、（例えば、「本当に消した
いのですか？」とたずねるなど）それは、ユーザー側のＦＴＰプロセス
での機能となる。
ディレクトリ削除(RMD)
このコマンドは、指定されたパス名のディレクトリ（指定が絶対パス名
の時）や、作業中のディレクトリに存在するサブディレクトリ（指定が
相対パス名の時）を削除する。付録IIを参照のこと。
ディレクトリ作成(MKD)
このコマンドは、指定されたパス名のディレクトリ（指定が絶対パス名
の時）や、作業中のディレクトリのサブディレクトリ（指定が相対パス
名の時）を作成する。付録IIを参照のこと。
作業ディレクトリ表示(PWD)
このコマンドは、現在作業中のディレクトリ名を応答として返す。付録
IIを参照のこと。
ファイル一覧(LIST)
このコマンドは、サーバーから、受信側のデータ転送プロセスにファイ
ル一覧を送信する。もし、パス名がディレクトリや、他のファイルグル
ープを指定した場合、サーバーは指定されたディレクトリのファイル一
覧を送信する。もし、パス名がファイルを指定していれば、サーバーは
ファイルの現在の情報を送信する。引数がなければ、ユーザーが現在の
作業ディレクトリ、もしくはデフォルトディレクトリを指定したとみな
す。データ転送は、データ接続を経由して、ASCIIかEBCDICで送信され
る。（ユーザーは適切なASCIIかEBCDICのどちらかをTYPEコマンドで指
定しなくてはならない。）ファイルの情報は、あるコンピュータから別
のコンピュータでおおきく異なるので、この情報はプログラムで自動的
に扱うのには向かないであろうが、人間にとってはいたく便利であろ
う。
名前一覧 (NLST)
このコマンドは、サーバーからユーザー側へディレクトリの一覧を送信
する。パス名として、ディレクトリや、その他システム依存のファイル
グループ指定子が使用できる。省略された時には、作業ディレクトリが
指定されたものとみなされる。サーバーは、ファイル名の羅列を返し、
それ以外の情報は含めない。データは、データ接続を経由して、ASCII
かEBCDICで送信され、有効なパス名の文字列は、<CRLF>か<NL>で区切ら
れる。（繰り返しになるが、ユーザーは、TYPEが正しいかどうかを保証
しなくてはならない。）このコマンドは、返された情報が、相手先プロ
セスのプログラムで自動的にファイルを扱う事を暗に示している。例え
ば、「複数get」機能などである。
SITEパラメータ (SITE)
このコマンドは、あるコンピュータでのファイル転送にとっては不可欠
であるが、プロトコルに含めるには十分に汎用的ではないようなサービ
スをサーバーに提供させるために使用される。これらのサービスの性質
や文法に関する仕様は、HELP SITEコマンドの応答として表示されるこ
とがあるだろう。
システム (SYST)
このコマンドはサーバーのオペレーティングシステムの種類を見極める
ために使用される。応答は、その最初の単語で、
Assigned Number Documentの最新版で一覧されているシステム名称を使
用すべきである。
ステータス(STAT)
このコマンドは、コントロール接続上に、応答の形式で状態応答を送信
する。このコマンドはファイル転送中に送信され（Ｔｅｌｎｅｔ ＩＰ
とＳｙｎｃ信号も同時に−−ＦＴＰコマンドの章を参照）、そのとき、
サーバーは進行中の処理について応答する。これはまた、ファイル転送
中以外にも送信される。このときコマンドは引数を持つ。もし、引数が
パス名なら、コマンドは、データがコントロール接続を経由することを
除けばファイル一覧コマンドと同じである。もし、パス名の一部分が与
えられると、サーバーはその仕様に基づいたファイル名かその属性の一
覧を応答する。
引数が与えられなければ、サーバーはサーバーＦＴＰプロセスに関する
一般的な情報を返す。これには、現在のすべての転送パラメータと、接
続の状態を含んでいるべきである。
ヘルプ(HELP)
このコマンドは、コントロール接続を経由して、サーバーの実装状況関
する情報をユーザーに対して送信する。このコマンドは、（コマンド名
などの）引数が使用でき、応答としてより詳細な仕様に関する情報を返
す。応答コードは、２１１か２１４である。ヘルプは、USERコマンドの
前でも使用できるように推奨されている。サーバーはHELP SITEの応答
などでこの応答をサーバー固有の情報を示すためにも使用できる。
何もしない(NOOP)
このコマンドは、設定や以前に入力されたコマンドに何も影響を及ぼさ
ない。サーバーは、ＯＫの応答を返す以外のどのような処理も行わな
い。
ファイル転送プロトコルでは、コントロール接続を介するすべての通信にお
いて、Ｔｅｌｎｅｔの仕様に従う。Since the language used for Telnet
communication may be a negotiated option, all references in the next
two sections will be to the "Telnet language" and the corresponding
"Telnet end-of-line code".一般に、それはＮＶＴ−ＡＳＣＩＩと<CRLF>の
意味となる。それ以外のＴｅｌｎｅｔプロトコル仕様は例示しない。
ＦＴＰコマンドは「Ｔｅｌｎｅｔ行末」で終了する「Ｔｅｌｎｅｔ文字列」
である。もし、パラメータがあるなら、コマンドコードそれ自身は、空白で
終わるアルファベットになるし、そうでなければ、Ｔｅｌｎｅｔ行末とな
る。このコマンドコードとコマンドの意味は、この章に記されている。コマ
ンドの構文に関する概要は、「コマンド」の章で、応答シーケンスは「コマ
ンドと応答のシーケンス」の章で述べられる。そして、コマンドの使用シナ
リオ例は、「典型的なＦＴＰのシナリオ」の章で述べられる。
ＦＴＰコマンドは、これらの細分化されたアクセス制御指定子、データ転送
パラメータ、またはＦＴＰサービス要求に分けられる。いくつかのコマンド
（ABOR、STAT、QUIT等）はデータ転送が行われている最中に、コントロール
接続経由で送信される。いくつかのサーバーはコントロール接続とデータ接
続を同時に監視できないかもしれず、そのときにはサーバーの注意を引くた
めに特別な処理を必要とする。以下のような手順が試験的に推奨される。
1.ユーザー側のシステムは、Ｔｅｌｎｅｔの「割り込みプロセス(Interrupt
Process)」（ＩＰ）信号をＴｅｌｎｅｔストリームに挿入する。
2.ユーザーシステムは、Ｔｅｌｎｅｔの「同期（Sync)」信号を送信する。
3.ユーザーシステムは、Ｔｅｌｎｅｔストリームにコマンドを挿入する。
4.サーバー側プロトコルインタプリタは、ＩＰを受信した後、Ｔｅｌｎｅｔ
ストリームから、＊正確に一つだけのＦＴＰコマンドを＊を取得する。
（その他のサーバーでは上に示したような処理は必要ないかもしれないが、
この処理により異常が引き起こされてはならない。）
4.2. ＦＴＰ応答
ファイル転送プロトコルコマンドの応答は、ファイル転送処理での要求と動作の
同期を明確にし、そして、サーバーの状態をユーザーが常に把握できることを保
証するために考えられた。すべてのコマンドは最低一つの応答を持つことを保証
しなくてはならないが、二つ以上の応答があるかもしれない。後の場合、複数の
応答は簡単に区別できなくてはならない。さらにＵＳＥＲ、ＰＡＳＳ、ＡＣＣＴ
や、ＲＥＮＦＲ、ＲＮＴＯなどいくつかのコマンドは、連続した一群として発効
される。もし、先行するすべてのコマンドが成功したなら、それらの応答は中間
的な状態であることを示している。これら連続したコマンド中のどこかで失敗し
たとき、それらの連続したコマンドを最初から繰り返さなくてはならない。
コマンド−応答のシーケンスの概要は、後に図示される。
ＦＴＰ応答は、何かの文章が後に続く、３桁の十進数（３文字の英数字として送
信される）から成る。数値は、次にどのような入力をするかを決定する自動処理
のために使われる。文章は人間のユーザーの為に用意されている。３桁の数値は
ユーザー側プロセス（プロトコルインタプリタ）の処理にとって十分な情報を持
ち、続く文章を解析せずに廃棄したり、ユーザーに渡すだけでよいものとなるよ
うに意図されている。特に、文章はサーバー固有であり、それぞれの応答コード
毎に変化する。
応答は、３桁のコード、それに続く空白、それに続く一行の文章（最大の行の長
さが存在しうる）で定義され、Ｔｅｌｎｅｔ行末コードで終了する。しかし、文
章が一行で書き切れない場合が起こりうるだろう。この場合、ユーザー側プロセ
スがどこまで応答を読んで（コントロール接続からの入力を中止するなど）から
次の処理に進めばよいのかを知るために、全部の文章は一まとめにされる。これ
は最初の行に続く行があること、最後の行には最後であることを示すための特殊
な形式であることが求められる。これらの中の最低一つには、やり取りの状態を
示すための適切な応答コードを含めなくてはならない。すべての流派？？を満足
させるために、最初と最後の行のコードは同じであるように決められている。
このように、複数行応答には、最初の行には正確な応答コード、その直後に
続くハイフン「−」（マイナスとも言う）、その後に文章、という形式が要
求されている。最後の行には、同じコードではじまり、直後に空白文字とし
て<SP>、文章があればその文章、そしてTelnetの行末コードが続く。
例：
123-First line (最初の行）
Second line (次の行）
234 A line beginning with Numbers (数字で始まる行）
123 The last line (最後の行）
訳注：括弧内は注釈であり、実際には送信すべきではない。
ユーザー側プロセスは単に、行の先頭に/*最初の行の応答コードと*/同じ応
答コードとその次の文字として<SP>（空白）が来るかどうかを調べ、その間
にある行を無視すればよい。もし、間に入る行に３文字の数字で始まるもの
を置きたいときには、サーバーは混乱を避けるため、その前をあけなくては
ならない。
これは、標準的なシステムルーチンを、最初の行と最後の行で「機械的
に」囲んでしまうという手法が、情報の応答（STATの応答など）で使用
できるということである。まれな場合では、これらのルーチンが３桁の
数値と空白を出力するが、そのときには、それぞれの行を空白などの何
でもない文字を使用してずらさなくてはならない。
この手法でのネスティングした複数行応答は出来ない。
応答におけるこの３文字の数値、それぞれには、特別の意味をもっている。
これは、とても単純な応答をするユーザー側プロセスによるから、高度な応
答をするユーザー側プロセスまでのために考えられている。最初の文字は、
応答が、成功なのか、失敗なのか、不完全なのかを示している。（状態ダイ
アグラムを参照のこと）単純なユーザープロセスはこの最初の桁を見るだけ
で次の処理（このまま続けるのか、もう一度か、中断か）を決定する。どの
ような種類のエラーが発生したか（ファイルシステムエラーなのか、コマン
ド文法エラーなのかなど）の概略を知りたいユーザー側プロセスは、二番目
の桁を調べる。３番目の桁は、一番詳しい情報（RNFRが来ないのにRNTOが来
たなど）のために使用される。
応答コードの最初の桁には、以下の５つの値がある。
1yz 肯定的な事前の応答
要求された処理は開始された。新たなコマンドの処理に進む前に、別の
応答を待つ。（前のコマンドを処理しおわる前に、ユーザー側プロセス
が別なコマンドを送信したのは、プロトコル違反となる、がしかし、サ
ーバー側ＦＴＰプロセスは現在の処理がおわるまで受信したコマンドを
キューイングした）この種類の応答ではコマンドは受け付けられた、そ
して、同時モニタリングの難しい実装においては、ユーザー側プロセス
はデータ接続に注意をはらわなくてはならない。サーバー側ＦＴＰプロ
セスは、１コマンドにつき、最大１つの１ｙｚコマンドを送信する。
2yx 肯定的な完了応答
要求された処理は、正常に終了した。新規の要求が受け付け可能であ
る。
3yz 肯定的な中間応答
コマンドは受け付けられたが、追加情報が来るまでの間、要求された処
理は停止中である。この情報を示すために、ユーザーは別のコマンドを
送信しなくてはならない。この応答はコマンド順序をもつコマンドで使
用される。
4yz 一時的否定的な完了応答
コマンドは、受け付けられず、要求された処理は動作しなかったが、エ
ラー状態は一時的であり、再実行出来る。ユーザーは、必要ならコマン
ドシーケンスを最初からやり直してもよい。
「一時的な」という状態の意味付けは難しく、二つの別個なコンピュー
タ（サーバーとユーザープロセス）が解釈に同意する必要があるときに
は特に難しい。それぞれの４ｙｚ応答群は、微妙に異なる時間を持って
いるが、意図としては、ユーザー側プロセスの再試行をうながすもので
ある。応答が４ｙｚか５ｙｚ（永久否定応答）に属するとき、もしコマ
ンドがコマンド形式やユーザー側サーバー側の条件を変更せずに繰り返
すことができるようならば、４ｙｚを返すことになっている（コマンド
の綴りも同じに、同じ引数を使用、ユーザーはそのファイル操作もユー
ザー名も変更せず、サーバーの実装も変更しないとき）。
5yz 永久否定的応答
コマンドは受け付けられず、要求された処理は行われない。ユーザープ
ロセスが、その要求を（同じ順番で）繰り返すことは推奨されない。い
くつかの「永久的な」エラー状態が修正されたとすれば、人間のユーザ
ーは将来のある時点において、そのユーザープロセスからコマンドシー
ケンスを繰り返して再試行することができるだろう（例えば、綴りを修
正したり、ユーザーがそのディレクトリ状態を変更したりなど）。
以下の機能グループが、２番目の桁に使用されている。
x0z 文法−これらの応答は、文法誤りや、構文上正しいコマンドでも対応機
能が見付からない、実装されていない、不要なコマンド、などに関連す
る。
x1z 情報−これらの応答は、情報の要求、例えばステータスやヘルプなどの
応答であることを示す。
x2z 接続−応答は、コントロール接続やデータ接続に関連する。
x3z 認証と課金−ログイン手続きと課金処理関連の応答である
x4z 未定義
x5z ファイルシステム−これらの応答は、要求された転送やその他ファイル
システム動作でのサーバー側のファイルシステム状態を示す。
３番目の桁には、２番目の桁でのそれぞれの種別毎に、詳細な意味を持たせ
ている。以降で詳解されている応答の種類はで、これらが示されている。そ
れぞれの応答に対応する文章は強制されるものではなく推奨であり、その応
答に関連するコマンドに従って異なるだろう。逆に、応答コードは、直前の
章での仕様に正確に従わなくてはならない。これは、サーバーの実装におい
て、ここで述べられているものと少ししか違わないような状況で新しいコー
ドを作らずに、すでにあるコードに適合させなくてはならないということで
ある。
ＴＹＰＥやＡＬＬＯ等のコマンドの成功は、ユーザー側プロセスに新し
い情報を使わずに２００の応答を返さなくてはならない。もし、例えば
ＴＯＰＳ２０でのＡＬＬＯコマンドなどでコマンドがサーバー側ＦＴＰ
のシステムにそぐわないことにより実装されていない場合、単純なユー
ザープロセスがその後の処理を継続できるように肯定的な完了応答が求
められる。２０２応答がこの場合使用され、例えば応答テキストで
「No storage allocation necessary.」（領域の確保は不要）
などと返す。逆に、もし、コマンドが、コンピュータ環境依存ではない
コマンドを要求し、その機能が実装されていないときには、５０２応答
を返す。コマンドは実装されているが、その引数が実装されていないと
きの応答は、５０４がふさわしい。
4.2.1 機能グループによる応答コードReply Codes by Function Groups
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は、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.2 番号順の応答コード一覧
110 Restart marker reply.
（リスタートマーカー応答）
この場合、文章は正確でなくてはならず、以前の実装が残されていては
ならない。これは
MARK yyyy = mmmm
yyyyは、ユーザープロセスのデータ列中の目印であり、mmmmはサーバー
側で対応する目印である。（マーカーと「＝」の間には空白があること
に注意）
120 Service ready in nnn minutes.
（サービスはnnn分で準備できる？？）
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.
（ヘルプメッセージ）
サーバーの使い方やコマンド、特に標準でないものの意味。この応答は
人間のユーザーにとってのみ便利である。
215 NAME system type.
NAMEは、Assigned Numbers documentによる公式なシステム名称。
220 Service ready for new user.
（新規ユーザーへの準備が完了した）
221 Service closing control connection.
（サービスはコントロール接続をクローズしている）
もし、適切ならログアウトである。
225 Data connection open; no transfer in progress.
（データ接続はオープンした。転送は行われていない）
226 Closing data connection.
（データ接続をクローズしている）
要求されたファイル処理は成功した（例えば、ファイル転送やファイル
アボート？？など）
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
（パッシブモードに入る(h1,h2,h3,h4,p1,p2).）
230 User logged in, proceed.
（ユーザーはログインする。先に進む。）
250 Requested file action okay, completed.
（要求されたファイル操作は問題なく終了した）
257 "PATHNAME" created.
（「PATHNAME」が作成された）
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.
（サービスは有効でない。コントロール接続をクローズする）
このコマンドは、サーバーがシャットダウンしなければならないとき、
どのコマンドの応答ともなりうる。
425 Can't open data connection.
（データ接続をオープンできない）
426 Connection closed; transfer aborted.
（接続はクローズした。転送は中断した。）
450 Requested file action not taken.
（要求されたファイル操作は行われなかった）
ファイルが使用不能（例：ファイルビジー）
451 Requested action aborted. Local error in processing.
（要求された操作は中断した。処理の際にローカルエラーが起こった）
452 Requested action not taken.
（要求された操作は行われなかった）
システムに十分な記憶容量がない。
500 Syntax error, command unrecognized.
（文法エラー、コマンドは認識出来なかった。）
これには、コマンド行が長すぎる等も含まれるだろう。
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.
（要求されたファイル操作は行われなかった）
ファイルが使用不能（例：ファイルが存在しない、アクセス不能）
551 Requested action aborted. Page type unknown.
（要求された操作は中断した。ページタイプが不明）
552 Requested file action aborted.
（要求されたファイル操作は中断した）
（現在のディレクトリや、データセットに）確保された記憶容量を超え
た。
553 Requested action not taken.
（要求された処理は行われなかった）
ファイル名が許されていない。
5. 仕様
5.1. 最小の実装
不要なエラーメッセージなしで動作するＦＴＰをために、以下の最小の実装がす
べてのＦＴＰサーバーで必要になる。
タイプ − ＡＳＣＩＩ、Ｎｏｎ−Ｐｒｉｎｔ
モード − ストリーム
構造 − ファイル、レコード
コマンド− USER, QUIT, PORT,
TYPE, MODE, STRU,
デフォルト値のもの
RETR, STOR,
NOOP.
デフォルトの転送パラメータは、
タイプ − ＡＳＣＩＩ、Ｎｏｎ−Ｐｒｉｎｔ
モード − ストリーム
構造 − ファイル
すべてのホストは、上記のものを、標準的なデフォルトとして受け入れられなく
てはならない。
5.2. 接続
サーバーのプロトコルインタプリタは、ポートＬに「聞き耳をたてる(listen)」
ユーザー、もしくはユーザー側プロトコルインタプリタは、全二重のコントロー
ル接続を確立する。サーバー、ユーザー両方のプロセスは、ＡＲＰＡ−インター
ネットプロトコルハンドブックに示されたＴｅｌｎｅｔプロトコルに従った通信
を行う。サーバーは、コマンド行の編集を行う機能はなく、そして、それはユー
ザー側ホストで行われる。コントロール接続は、すべての転送と応答が完了した
後、ユーザー側の要求によりサーバーによってクローズされる。
ユーザー側データ転送プロセスは、指定されたデータポートに「聞き耳をたてて
(listen)おく。これは、デフォルトのユーザーポート（Ｕ）か、ＰＯＲＴコマン
ドで指定されたポートである。サーバーは、データ接続をそのデフォルトデータ
ポート（Ｌ−１）から、指定されたユーザーのデータポートに対してデータ接続
を確立する。転送の方向と、使用されるポートはＦＴＰサービスコマンドにより
示される。
注意すべきは、ＦＴＰの実装はすべからくデータ転送をデフォルトデータポート
で行えなくてはｎならず、ユーザー側プロトコルインタプリタだけがデフォルト
ではないポートを使用するようにできることである。
データがＡとＢ（図２参照）二つのサーバー間で転送されるとき、ユーザー側プ
ロトコルインタプリタのＣは、両方のサーバーのプロトコルインタプリタとの間
にコントロール接続を設定する。サーバーのうち一つ、例えばＡには、ＰＡＳＶ
コマンドが送られ、転送コマンドを受け取った時にデータ接続を確立するのでは
なくデータポートに「聞き耳をたてて（listen）おくように指示される。 ユー
ザー側プロトコルインタプリタが、聞き耳を立てているホストアドレスとポート
をＰＡＳＶコマンドの了解として受け取ると、ユーザー側プロトコルインタプリ
タは、ＡのポートａをＢに対してＰＯＲＴコマンドとして送信し、応答が返され
る。その後にユーザー側プロトコルインタプリタは、ＡとＢに対して対になるＦ
ＴＰサービスコマンドを送信する。サーバーＢは接続を確立し、転送が行われ
る。以下に示すコマンド−応答シーケンスは、メッセージは縦方向に同期してい
るが、横方向には非同期である。
ユーザーＰＩ−サーバーＡ ユーザーＰＩ−サーバーＢ
−−−−−−−−−−−− −−−−−−−−−−−−
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 : ホストＡとホストＢとが接続
図３
データ接続は、「データ接続の確立」の章で述べたような状況下で、サーバーに
よりクローズされる。もし、クローズする際にファイル終了を示す必要がないデ
ータ転送において、データ接続がクローズされたときには、サーバーはすぐにそ
れをやらなくてはならない。
ユーザープロセスは、データ接続に「聞き耳をたてる(listen)」必要があるなら
そのデータ接続の調査が終わるまで新しいコマンドの送信は許可されず、待たな
くてはならない？？（ユーザーは、転送要求を送る前に、クローズしてあるデー
タポートに対して「聞き耳をたてて(listen)おかなくてなならないことを忘れて
はならない）ここで、競合状態になることを避けるために、サーバーはデータ接
続をクローズした後に、２２６応答を送信する（もしくは、接続が残されたまま
のときには、応答２５０として「ファイル転送終了」を送り、ユーザー側プロト
コルインタプリタは新規の転送コマンドの前に、これらの応答の内の一つを待た
なくてはならない）。
ユーザー側、サーバー側双方がその接続が他の理由によりクローズされたと判断
したときにはいつでも、すぐに接続上に残されたデータを読み取り、両方の側で
クローズしなくてはならない。
5.3. コマンド
コマンドは、ＦＴＰコマンドの章で述べたようにＴｅｌｎｅｔ文字列でコントロ
ール接続上を送信される。コマンド機能と構文はアクセス制御コマンドｍ転送パ
ラメータコマンド、ＦＴＰサービスコマンド、その他のコマンドの章で述べられ
た。（訳注：その他のコマンド..Miscellaneous Commandsなんて無かったよぉ）
コマンド文法がここで示される。
コマンドは、引数領域が続くコマンドコードで始まる。コマンドコードは、４文
字か、それ未満のアルファベット文字である。アルファベットの大文字、小文字
は同じに扱われる。ゆえに、以下に示すものは、すべて「取得(RETR)」コマンド
である。
RETR Retr retr ReTr rETr
これはまた、Ａ、ａ共にＡＳＣＩＩ型を示すという風にパラメータ値指定される
文字にも当てはまる。コマンドコードと引数領域は１文字以上の空白で分けられ
る。
引数領域は、可変長の文字列となり、ＮＶＴ−ＡＳＣＩＩ表現のときには<CRLF>
（キャリッジリターン、ラインフィード）文字シーケンスで終了する。それ以外
の文字コードでは、異なる行末文字が使われるだろう。サーバーは行末コードを
読み取るまで何の処理も行わないということも注意すべきである。
以下で示す文法は、ＮＶＴ−ＡＳＣＩＩである。引数領域にあるすべての文字は
ＡＳＣＩＩ文字で表現された数値を含むＡＳＣＩＩ英数字となる。もし、オプシ
ョンがなかったときには、適切なデフォルト値が暗黙に指定される。
5.3.1. ＦＴＰコマンド
以下にＦＴＰコマンドを示す。
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> <十進整数>
[<SP> R <SP> <十進整数>] <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>
5.3.2. ＦＴＰコマンド引数
上記の引数フィールドは、(using BNF notation where applicable)
<ユーザー名> ::= <文字列>
<パスワード> ::= <文字列>
<課金情報> ::= <文字列>
<文字列> ::= <文字> | <文字><文字列>
<文字> ::= 128種類のアスキー文字のうち、<LF>、<CR>と空白を除くもの
<マーカー> ::= <印刷可能文字列>
<印刷可能文字列> ::= <印刷可能文字> | <印刷可能文字><印刷可能文字列>
<印刷可能文字> ::= アスキーコード33から126までの、印刷できる文字
<バイトサイズ> ::= <数値>
<ホスト−ポート> ::= <ホスト番号>,<ポート番号>
<ホスト番号> ::= <数値>,<数値>,<数値>,<数値>
<ポート番号> ::= <数値>,<数値>
<数値> ::= １から255までの適当な十進整数
（訳注）少なくとも、ホスト番号においては、<数値>に０を含め
ないと、127.0.0.1などが通らない。
<書式コード> ::= N | T | C
<形式コード> ::= A [<sp> <形式コード>]
| E [<sp> <形式コード>]
| I
| L <sp> <バイトサイズ>
<構造コード> ::= F | R | P
<モードコード> ::= S | B | C
<パス名> ::= <文字列>
<十進整数> ::= 適当な十進数の整数
5.4. コマンドと応答のシーケンス
ユーザーとサーバーの通信は、交互に行われる対話に従って行われるように考え
られている。それゆえ、ユーザーがＦＴＰコマンドを発効すると、サーバーは迅
速に主要な返事でそれに応答する。ユーザーは、次のコマンドを送る前に、この
最初の根本的な成功、失敗を待つ必要がある。
いくつかのコマンドは、ユーザーが待たなければならない二つ目の応答がある。
これらの応答は、たとえばファイル転送やデータのクローズなどの進行状況や完
了を通知するものである。ファイル転送コマンドにおいては、二番目の応答があ
る。
情報型の応答で重要なものに接続グリーティングがある。通常、サーバーは、
接続が完了すると「入力待ち」として２２０の応答を送信する。ユーザーは何か
のコマンドを送信する前に、このグリーティングメッセージを待たなければなら
ない。もし、サーバーが入力をすぐには受け取れないとき、すぐに 120「予定さ
れた遅延」応答が返され、準備が出来たときに 220応答が返される。こうするこ
とにより、ユーザーは遅れがあったときでも、ハングアップしたのではないこと
を知る事ができる。
自発的応答
しばしば、「システムは」自発的にユーザーにメッセージを送信する。たと
えば、「システムは１５分後にシャットダウンします」などである。ＦＴＰ
においては、サーバーからユーザーに自発的な情報を送る機能は用意されて
いない。このような情報は、サーバー側プロトコルインタプリタにキューイ
ングされ、次の応答（複数行応答になるかもしれない）でこれを送信するこ
とが望ましい。
以下の表では、それぞれのコマンドごとの成功・失敗の応答を一覧表にしてあ
る。これらは、確実に忠実でなくてはならない。サーバーは応答中の文章を変更
してもよいが、その意味、コード番号により示される動作と指定されたコマンド
応答シーケンスは変更してはならない。
コマンド応答シーケンス
この章では、コマンド−応答シーケンスが提示されている。それぞれのコマ
ンドは、その可能な応答とともに表にされている。コマンドグループも共に
表にされている。準備的な応答が（その予測される成功時応答とそれに続も
のの）先に書かれ、その後に肯定的、否定的完了応答がかかれ、最後に中間
応答が以降に続くシーケンスによるコマンドと共に書かれている。この表の
形式は別記される状態ダイアグラムに基づき書かれている。
接続確立
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
6. 状態ダイアグラム
ここで、とても簡単に考えられたＦＴＰ実装の状態ダイアグラムを示す。応答コード
の最初の一桁だけが使われる。それぞれのＦＴＰコマンドグループやコマンドシーケ
ンスにつき、一つの状態ダイアグラムが存在する。
コマンドのグループ分けは、それぞれのコマンドのモデルを作ることにより考えら
れ、構造上の典型的なモデルを持つコマンドを集めたものである。
それぞれのコマンドやコマンドシーケンスには、３つの可能な出口が考えられる。
成功（Ｓ）、失敗（Ｆ）、誤り（Ｅ）である。状態ダイアグラムにおいては、Ｂとい
う文字を「開始」、Ｗという文字を「応答待ち」として使用している。
最初に示すダイアグラムは、最大のＦＴＰコマンドグループである
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, and TYPE.
他の大きなコマンドのグループは、とても似た構造を持っている。
3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ --->+---+ +---+
| | |
| | | 4,5 +---+
| 1 | ----------->| F |
----- +---+
このダイアグラムは、以下のコマンドをモデル化している
APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
この二番目のモデルは、最初のＦＴＰグループもまた表現している。唯一の違いとし
ては、最初のグループでは、１００番台の応答は予測されず、エラーとして処理する
が、二番目のグループでは、１００番台の応答があることが予期され（いくつかのコ
マンドでは必須）ていることである。１００番台の応答は、コマンドにつき一回だけ
であることを忘れてはならない。
残りのコマンドシーケンスのダイアグラムモデル中でもっとも単純なものは、名前の
変更シーケンスである。
+---+ 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, or RETR.
上の３つのシーケンスは似ていることを書いておく。再開と名前変更は、２回目の
１００番台応答の扱いが異なり、二つ目のグループ（再開）では、１００番台応答を
予期している（いくつかでは必須）である。１００番台の応答はコマンドにつき一回
だけであることを忘れてはならない。
もっとも複雑なダイアグラムは、ログインシーケンスである。
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 |
+---+ +---+------------->+---+
最後に、コマンドと応答の交換の時に使用できる、一般化されたダイアグラムを示し
ておく。
------------------------------------
| |
Begin | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
End
7. 典型的なＦＴＰのシナリオ
ホストＵでのユーザーが、ホストＳに対してファイルを送受信する場合：
一般的に、ユーザーはサーバーにユーザー側ＦＴＰプロセスを介して通信を行う。以
下は典型的なシナリオである。ユーザー側ＦＴＰプロンプトは括弧内、「----->」は
ホストＵからホストＳへのコマンド、「<-------」はホストＳからホストＵへの応答
である。
ユーザーによるコマンド 発生する動作
ftp (host) multics<CR> ホストＳのポートＬに接続し、コントロール接
続を確立
<---- 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> ユーザー側ＦＴＰはASCIIでローカルファイルを
オープン
(for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
<---- 150 File status okay;
about to open data
connection<CRLF>.
サーバーはポートＵに対してデータ接続を作成
<---- 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> ユーザーＦＴＰはImageでローカルファイルをオ
ープン
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
<---- 550 Access denied<CRLF>
terminate QUIT <CRLF> ---->
サーバーはすべての接続をクローズ
8. 接続の確立
ＦＴＰコントロール接続はユーザープロセスのポートＵとサーバープロセスのポート
Ｌとの間でＴＣＰ経由で確立する。このプロトコルは、サービスポート２１（八進数
で２５）が予約されている、つまりＬ＝２１である。
付録Ｉ − ページ構造
ＦＴＰのページ構造サポートの必要性は、ＴＯＰＳ−２０システムのファイル、特に
ＮＬＳに使われるファイルの効果的な転送をサポートするために生まれた。
ＴＯＰＳ−２０のファイルシステムは、ページの考えに基づいている。オペレーティ
ングシステムは、ファイルをページとして扱うときにもっとも効率がよい。オペレー
ティングシステムはファイルシステムとの間のインタフェースを提供し、多くのアプ
リケーションがファイルを連続した文字の並びとして参照している。しかし、いくつ
かのアプリケーションは、ページ構造を直接使用しており、それらのいくつかは「穴
ぼこ」ファイルを作成する。
ＴＯＰＳ−２０のディスクファイルは４要素から構成されている。パス名、ページテ
ーブル、（空白もありうる）ページ群、属性群である。
パス名は、ＲＥＴＲやＳＴＯＲで示される。これは、ディレクトリ名、ファイル名、
ファイル拡張子と生成番号（ファイルバージョン番号？）を含んでいる。
ページテーブルは、最大２の１８乗のエントリを持っている。それぞれのエントリは
空だったり、ページへのポインタである。もし、これが空でなければ、ここにはいく
つかのページ指定のアクセスビットを含んでいる。ファイルのページの内のいくつか
は、何かのアクセス保護をもつ必要はない。
ページは連続した５１２ワードを持ち、それぞれのワードは３６ビットである。
ファイルディスクリプタブロック（ＦＤＢ）のファイルの属性は、作成日付、書き込
み日付、読み出し日付、書き込み時のバイトサイズ、ファイル終わりへのポインタ、
読み込みと書き込みの回数、バックアップシステムのテープ番号などの情報を含む。
ページテーブルにあるエントリは、連続している必要はないことに注意しなくてはな
らない。使用中のページテーブルスロットに挟まれたところに、空のページテーブル
があるかもしれない。また、ファイル終了へのポインタは、単なる数値である。これ
は、実際のファイル中にある「最後の」一つのデータを指している必要はない。普
通、ＴＯＰＳ−２０での順次入出力呼び出しでは、ファイル終了ポインタは最後の一
つのデータが書かれる後まで残されるが、他の操作においては、もし固有のプログラ
ミングシステムが要求すれば、そうはならない。
実際のところ、これらの二つの特殊ケース、「穴ぼこ」ファイルとファイル終了ポイ
ンタがファイルの終了をささない事態は、ＮＬＳのデータファイルで起こっている。
ＴＯＰＳ−２０のページファイルは、ＦＴＰの転送パラメータとして送信できる。
TYPE L 36 , STRU P と MODE S (実際には、どのモードでも使用できる）である。
それぞれのページの情報は、ヘッダを持っている。TYPEがL 36なら、それぞれのヘッ
ダ領域は、論理バイトであり、ＴＯＰＳ−２０ワードである。
ヘッダフィールドは、
Word 0: ヘッダ長
ヘッダ長は５
Word 1:ページインデックス
もし、データがディスクファイルページなら、これはファイルにおけるその
ページのページマップ上の番号である。ファイルの空のページ（穴ぼこ）は
単に送信されなくなるだけである。「穴ぼこ」というのは、ゼロがうめられ
たページではないことに注意が必要である。
Word 2:データ長
このページ中にある、ヘッダのあとに続くデータのワード数。つまり、転送
単位となる全体の長さは、ヘッダ長にデータ長を加えたものとなる。
Word 3:ページタイプ
このチャンク（全体のなかの一部分のこと）が、どのタイプを持っているか
のコード。データページのタイプは３だり、ＦＤＢページのタイプは２。
Word 4:ページアクセス制御
このファイルのページマップ上のページに付けられているアクセスビット。
(This full word quantity is put into AC2 of an SPACS by the program
reading from net to disk.)
ヘッダーの後ろには、データ長分のデータワードが続く。データ長は、今のとこ
ろデータページには５１２、ＦＤＢには３１である。ディスクファイルページの
最後のゼロは廃棄され、そのときには、データ長は５１２以下となる。
付録ＩＩ ディレクトリコマンド
ＵＮＩＸは、ディレクトリを普通のファイルと同じように簡単に操作できるような木
構造のディレクトリ構造を持っていることから、それらの機械でのＦＴＰサーバーに
ディレクトリを作成する処理の拡張を加えると便利である。同じように木構造のディ
レクトリ構造を持っている（ＴＯＰＳ−２０とＭｕｌｔｉｃｓを含む）ＡＲＰＡ−イ
ンターネット上の他のホストコンピュータでは、これらのコマンドは一般的に使用で
きるだろう。
４つのディレクトリコマンドがＦＴＰに加えられた。
MKD pathname
「pathname」という名前のディレクトリを作成する。
RMD pathname
「pathname」という名前のディレクトリを消去する。
PWD
現在作業中のカレントディレクトリを表示する。
CDUP
現在作業中のディレクトリの上位ディレクトリに移動する。
「pathname」という引数は、現在作業中のディレクトリに、サブディレクトリを作成
／消去するものである。但し、「pathname」が（ＵＮＩＸやＭｕｌｔｉｃｓで）絶
対パス名を示していたり、ＴＯＰＳ−２０でパス名が<abso.lute.path>のように指定
されているなど、「pathname」がサーバーにとって他のものを示すのに十分な情報を
含んでいるときは除く。
応答コード
CDUPコマンドは、CWDの特殊なケースであり、上位ディレクトリを示す名前の構
文が異なるオペレーティングシステム間でのディレクトリツリー間の移動に関す
るプログラムの実装を単純化している。CDUPの応答コードは、CWDの応答コード
と同じである。
RMDの応答コードは、そのファイル版であるDELEの応答と同じである。
しかし、MKDの応答コードは、ちょっと複雑である。新規に作成されたディレク
トリは、多分、次にＣＷＤのコマンドに使われることになる。残念ながら、
ＭＫＤの引数は、常にＣＷＤの引数として使用できるわけではない。例えば、
ＴＯＰＳ−２０でのサブディレクトリはただのサブディレクトリ名だけが与えら
れることにより作成される。このとき、ＴＯＰＳ−２０上のサーバーでは、コマ
ンドシーケンスとしての
MKD MYDIR
CWD MYDIR
は失敗する。新しいディレクトリは、その「絶対的な」名前としてだけ参照でき
る。例えば、もし、<DFRANKLIN>というディレクトリに接続しているときに、上
記のコマンドを実行したとき、新しいサブディレクトリは、<DFRANKLIN.MYDIR>
という名前だけが参照できる。
しかし、UNIXとMulticsにおいてさえ、MKDの引数がふさわしくないこともある。
もし、「相対的な」パス名（例えば、パス名が現在のディレクトリにに対して相
対的に解釈される場合）が使用されたとき、ユーザーはそのディレクトリにアク
セスするためには、同じカレントディレクトリにいなければならない。アプリケ
ーションによっては、これが不便となるだろう。どんな場合でもそう言えるわけ
ではないであろうが。
これらの問題を解決するため、ＭＫＤの成功応答は以下の形式とすべきである。
257<space>"<directory-name>"<space><commentary>
これは、サーバーがユーザーに作成されたディレクトリを参照するために使用す
る文字列を教えるものである。ディレクトリ名に入る文字の制限はない。ダブル
クォーテーションが二回続くと、一つのダブルクォーテーションとなる
（「quote-doubling」変換）。
例えば、ユーザーが/usr/dmに接続してあり、サブディレクトリを作成するとき
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
すでに存在する名前でサブディレクトリを作成するとエラーになり、サーバーは
「access denied」エラー応答を返さなくてはならない。
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
521-"/usr/dm/pathname" directory already exists;
521 taking no action.
ＭＫＤの失敗時応答は、ファイルを作成する兄弟コマンドのＳＴＯＲと同じであ
る。また、「access denied」応答は、作成するサブディレクトリと同じファイ
ル名を持つファイルが合ったときにも返される（これは、ＵＮＩＸでのエラーで
あり、ＴＯＰＳ−２０では発生しない）。
本質的に、ＰＷＤコマンドは、ＭＫＤコマンドの成功応答と同じ種類の情報を返
すために、ＰＷＤの成功コマンドにも、応答コード２５７を使用する。
SUBTLETIES
これらのコマンドは、一つの機械から他の機械へサブツリーごと転送するのに便
利であることから、作業中のディレクトリのサブディレクトリとなるＭＫＤの引
数は、相手方のホストに、サブディレクトリではなくなってしまうような情報を
含んでいないかどうかを、よく吟味しなくてはならない。ＴＯＰＳ−２０での架
空の例として、
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>
最初の例では、接続されているディレクトリのサブディレクトリとなっている。
対して、二番目の例では、<unambiguous>という引数はＴＯＰＳ−２０にはその
ディレクトリがトップレベルディレクトリであるということを指定するのに十分
な情報を持ってしまっている。さらに、最初の例では、ユーザーは、新規作成さ
れたディレクトリにアクセスするのに、ＴＯＰＳ−２０から返されてはいないも
のを使用するという約束違反をしている。ここでは、<overrainbow>ディレクト
リでエラーが返されている。これは、ＴＯＰＳ−２０の実装の曖昧さに起因する
ものである。同じような問題は、ＲＭＤコマンドでも発生する。要点は、
絶対、相対パス名指定をするときに、ホスト側の慣習に違反している場合を除き
ホストはＭＫＤ、ＲＭＤコマンドの引数をサブディレクトリとして扱う。ＭＫＤ
の２５７応答は、常に、作成されたディレクトリの絶対パス名を示す。
付録ＩＩＩ ＦＴＰのＲＦＣ
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.
Copyright 1996 by Jarle (jgaa) Aase