

ネットワークワーキンググループ           Internet Engineering Task Force
RFC: 1123                                              R. Braden, Editor
                                                              1989年10月


         インターネットホストの要件: アプリケーションとサポート

Status of This Memo

   This RFC is an official specification for the Internet community.  It
   incorporates by reference, amends, corrects, and supplements the
   primary protocol standards documents relating to hosts.  Distribution
   of this document is unlimited.

概要

   本文書は、インターネットホストソフトウェアの要件を定義、議論する対の
   RFCの一つである。本RFCは、アプリケーションプロトコル及びサポート
   プロトコルをカバーする。対のもう片方のRFC 1122は、通信プロトコルの
   レイヤー、具体的にリンクレイヤー、IPレイヤー、トランスポートレイヤー
   をカバーする。


                                  目次


   1.  はじめに ...................................................    5
      1.1  インターネットアーキテクチャー .........................    6
      1.2  一般的な考慮点 .........................................    6
         1.2.1  継続的なインターネットの発展 ......................    6
         1.2.2  ロバストネス原則 ..................................    7
         1.2.3  エラーのロギング ..................................    8
         1.2.4  環境設定 ..........................................    8
      1.3  本文書の読み方 .........................................   10
         1.3.1  構成 ..............................................   10
         1.3.2  要件 ..............................................   10
         1.3.3  用語 ..............................................   11
      1.4  Acknowledgments ........................................   12

   2.  一般的なアプリケーションの要件 .............................   13
      2.1  ホスト名及び番号 .....................................     13
      2.2  ドメイン名サービスの使用 ...............................   13
      2.3  マルチホームホスト上のアプリケーション .................   14
      2.4  タイプオブサービス .....................................   14
      2.5  一般的なアプリケーションの要件の概要 ...................   15


Internet Engineering Task Force                                 [Page 1]


RFC1123                       INTRODUCTION                  October 1989


   3.  リモートログイン -- Telnetプロトコル .......................   16
      3.1  導入 ...................................................   16
      3.2  プロトコルのウォークスルー .............................   16
         3.2.1  オプションのネゴシエーション ......................   16
         3.2.2  TelnetのGo-Ahead機能 ..............................   16
         3.2.3  制御機能 ..........................................   17
         3.2.4  Telnetの"Synch(同期)"通知 .........................   18
         3.2.5  NVTプリンター及びNVTキーボード ..................     19
         3.2.6  Telnetコマンドの構造 ..............................   20
         3.2.7  TelnetのBinaryオプション ..........................   20
         3.2.8  TelnetのTerminal-Typeオプション ...................   20
      3.3  固有の課題 .............................................   21
         3.3.1  Telnetの行末に関する規定 ..........................   21
         3.3.2  データ入力端末 ....................................   23
         3.3.3  オプションの要件 ..................................   24
         3.3.4  オプションのネゴシエーション ......................   24
         3.3.5  TelnetのLinemodeオプション ........................   25
      3.4  Telnet/ユーザー間のインターフェース ....................   25
         3.4.1  文字集合の透過性 ..................................   25
         3.4.2  Telnetコマンド ....................................   26
         3.4.3  TCP接続のエラー ...................................   26
         3.4.4  デフォルト以外のTelnet接続ポート ..................   26
         3.4.5  出力の廃棄 ........................................   26
      3.5.  Telnetの要件の概要 ....................................   27

   4.  ファイル転送 ...............................................   29
      4.1  FTP(ファイルトランスファープロトコル) ..................   29
         4.1.1  導入 ..............................................   29
         4.1.2.  プロトコルのウォークスルー .......................   29
            4.1.2.1  LOCALタイプ ..................................   29
            4.1.2.2  Telnetのフォーマット制御 .....................   30
            4.1.2.3  ページ構造 ...................................   30
            4.1.2.4  データ構造の変換 .............................   30
            4.1.2.5  データ転送用接続の管理 .......................   31
            4.1.2.6  PASVコマンド .................................   31
            4.1.2.7  LISTコマンド及びNLSTコマンド .................   31
            4.1.2.8  SITEコマンド .................................   32
            4.1.2.9  STOUコマンド .................................   32
            4.1.2.10  Telnetの行末コード ..........................   32
            4.1.2.11  FTP応答 .....................................   33
            4.1.2.12  接続 ........................................   34
            4.1.2.13  最小限の実装 ................................   34
         4.1.3  固有の課題 ........................................   35
            4.1.3.1  標準外のコマンド名 ...........................   35
            4.1.3.2  アイドルタイムアウト .........................   36
            4.1.3.3  データ転送と制御の同時並列性 .................   36
            4.1.3.4  FTPの再開の仕組み ............................   36
         4.1.4  FTP/ユーザー間のインターフェース ..................   39


Internet Engineering Task Force                                 [Page 2]


RFC1123                       INTRODUCTION                  October 1989


            4.1.4.1  パス名の指定 .................................   39
            4.1.4.2  "QUOTE"コマンド ..............................   40
            4.1.4.3  ユーザーへの応答表示 .........................   40
            4.1.4.4  同期の維持 ...................................   40
         4.1.5   FTPの要件の概要 ..................................   41
      4.2  TFTP(トリビアルファイルトランスファープロトコル) .......   44
         4.2.1  導入 ..............................................   44
         4.2.2  プロトコルのウォークスルー ........................   44
            4.2.2.1  転送モード ...................................   44
            4.2.2.2  UDPヘッダー ..................................   44
         4.2.3  固有の問題 ........................................   44
            4.2.3.1  SAS(Sorcerer's Apprentice Syndrome) ..........   44
            4.2.3.2  タイムアウトアルゴリズム .....................   46
            4.2.3.3  拡張 .........................................   46
            4.2.3.4  アクセス制御 .................................   46
            4.2.3.5  ブロードキャストリクエスト ...................   46
         4.2.4  TFTPの要件の概要 ..................................   47

   5.  電子メール -- SMTP及びRFC 822 ..............................   48
      5.1  導入 ...................................................   48
      5.2  プロトコルのウォークスルー .............................   48
         5.2.1  SMTPモデル ........................................   48
         5.2.2  正規化 ............................................   49
         5.2.3  VRFY、EXPNコマンド: RFC 821 セクション3.3 .........   50
         5.2.4  SEND、SOML、SAMLコマンド ..........................   50
         5.2.5  HELOコマンド ......................................   50
         5.2.6  メールの中継 ......................................   51
         5.2.7  RCPTコマンド ......................................   52
         5.2.8  DATAコマンド ......................................   53
         5.2.9  コマンド構文 ......................................   54
         5.2.10  SMTP応答 .........................................   54
         5.2.11  透過性 ...........................................   55
         5.2.12  MX処理におけるWKSの使用 ..........................   55
         5.2.13  RFC 822のメッセージ仕様 ..........................   55
         5.2.14  RFC 822の日付と時刻の仕様 ........................   55
         5.2.15  RFC 822の構文の変更 ..............................   56
         5.2.16  RFC 822のLocal-part ..............................   56
         5.2.17  ドメインリテラル .................................   57
         5.2.18  アドレスフォーマットの一般的なエラー .............   58
         5.2.19  明示的なソースルート .............................   58
      5.3  固有の課題 .............................................   59
         5.3.1  SMTPのキュー管理戦略 ..............................   59
            5.3.1.1  送信の戦略 ...................................   59
            5.3.1.2  受信の戦略 ...................................   61
         5.3.2  SMTPのタイムアウト ................................   61
         5.3.3  信頼性のあるメール受信 ............................   63
         5.3.4  信頼性のあるメール送信 ............................   63
         5.3.5  ドメイン名のサポート ..............................   65


Internet Engineering Task Force                                 [Page 3]


RFC1123                       INTRODUCTION                  October 1989


         5.3.6  メーリングリストとエイリアス ......................   65
         5.3.7  メールのゲートウェイ中継 ..........................   66
         5.3.8  最大メッセージサイズ ..............................   68
      5.4  SMTPの要件の概要 .......................................   69

   6. サポートサービス ............................................   72
      6.1 ドメイン名の変換 ........................................   72
         6.1.1 導入 ...............................................   72
         6.1.2  プロトコルのウォークスルー ........................   72
            6.1.2.1  TTLがゼロのリソースレコード ..................   73
            6.1.2.2  QCLASSの値 ...................................   73
            6.1.2.3  使用されないフィールド .......................   73
            6.1.2.4  圧縮 .........................................   73
            6.1.2.5  設定情報の誤用 ...............................   73
         6.1.3  固有の課題 ........................................   74
            6.1.3.1  リゾルバーの実装 .............................   74
            6.1.3.2  トランスポートプロトコル .....................   75
            6.1.3.3  効率的なリソースの使用 .......................   77
            6.1.3.4  マルチホームホスト ...........................   78
            6.1.3.5  拡張性 .......................................   79
            6.1.3.6  RRタイプの状態 ...............................   79
            6.1.3.7  ロバスト性 ...................................   80
            6.1.3.8  ローカルホストテーブル .......................   80
         6.1.4  DNS/ユーザー間のインターフェース ..................   81
            6.1.4.1  DNSの管理 ....................................   81
            6.1.4.2  DNSのユーザーインターフェース ................   81
            6.1.4.3 インターフェースにおける名前の省略機能 ........   82
         6.1.5  DNSの要件の概要 ...................................   84
      6.2  ホストの初期設定 .......................................   87
         6.2.1  導入 ..............................................   87
         6.2.2  要件 ..............................................   87
            6.2.2.1  動的設定 .....................................   87
            6.2.2.2  ロード段階 ...................................   89
      6.3  リモート管理 ...........................................   90
         6.3.1  導入 ..............................................   90
         6.3.2  プロトコルのウォークスルー ........................   90
         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92

   7.  REFERENCES .................................................   93


Internet Engineering Task Force                                 [Page 4]


RFC1123                       INTRODUCTION                  October 1989


1.  はじめに

   本文書は、インターネットプロトコルスイートのホストシステム実装の
   要件を定義し議論する対のRFCの一つである。本RFCは、アプリケーション
   レイヤー及びサポートプロトコルをカバーする。対のもう片方のRFC
   である"インターネットホストの要件: 通信レイヤー"[INTRO:1]は、下位の
   プロトコルレイヤー、具体的にリンクレイヤー、IPレイヤー、トランス
   ポートレイヤーをカバーする。

   これら一連の文書は、インターネット通信ソフトウェアのベンダー、
   実装者、利用者らに対して指針を提供することを意図している。これらは、
   インターネットの研究コミュニティやベンダーコミュニティのメンバーに
   よって寄与された多くの技術経験や知見の合意を表現するものである。

   本RFCは、インターネットに接続されるホストが使用しなければならない
   標準プロトコルを列挙する。また、参照により、これらのプロトコルの
   現行仕様を記述するRFCや他の文書も組み入れている。更に、参照される
   文書に含まれるエラーを修正し、実装者に向けて付加的な議論と指針を
   追加する。

   各プロトコルについて、本文書は要件、推奨、任意の選択肢等の明示的な
   項目を含む。読者は、本文書記載の要件一覧がそれ単独では不完全である
   ことを理解しなければならない。インターネットホストに関する要件の
   すべては、主として標準プロトコルの仕様書で定義されたものに、本RFCに
   含まれる修正、改正、補足が加わったものである。

   RFCを注意深く読み、インターネットの技術コミュニティとある程度の
   やりとりを経た後に作成された、通信ソフトウェアの良質な工学的実践に
   従う誠実なプロトコル実装は、本文書記載の要件と些細な点でしか違いが
   生じないはずである。言い換えると、多くの場合、本文書の"要件"は標準
   プロトコル文書において既に記載または暗示されているものであるから、
   それらをここに組み入れるのは、ある意味で冗長である。それでも
   それらを本文書に組み入れた理由は、一部の過去の実装が誤った選択を
   行い、相互運用性、パフォーマンス、ロバスト性のいずれかあるいは
   それらすべてに問題を生じさせたからである。

   本文書は、多くの要件と推奨に関する議論と解説を含んでいる。要件の
   単純な一覧を提供することは、以下の理由で危険だからである。

   ・   要求される幾つかの機能は他のものよりも重要であり、幾つかの
        機能は任意である。

   ・   限定されたコンテキスト向けに設計された特定のベンダー製品が、
        標準と異なる仕様を採用する場合があることには正当な理由が
        あるかもしれない。


Internet Engineering Task Force                                 [Page 5]


RFC1123                       INTRODUCTION                  October 1989


   しかし、インターネットシステムの多様性と複雑性を踏まえた上で任意の
   ホストが相互運用するという一般的なゴールを達成するためには、本文書
   記載の仕様が守られなければならない。現在の実装の大半がさまざまな形で、
   あるものは軽微にあるものは大幅に、これらの要件を満たすことに失敗して
   いるが、この仕様は我々がそこに向かわなければならない理想である。

   これらの要件は、現在のインターネットアーキテクチャーのレベルに
   基づいている。本文書は、付加的な明確化を提供したり、発展が続いている
   仕様に関してその領域における付加的な情報を取り込むために、必要に
   応じて更新されるだろう。

   この導入セクションは、ホストソフトウェアベンダーへの一般的な助言
   から始まり、次に本文書の残り部分を読むための幾つかの指針を与える。
   セクション2は、すべてのアプリケーションプロトコル及びサポート
   プロトコルに適用可能な一般的な要件を含む。セクション3、4、5は、
   主要な三つのアプリケーションであるTelnet、ファイル転送、電子メール
   に関する要件をそれぞれ含む。セクション6はサポートアプリケーション、
   具体的にドメイン名システム、システムの初期設定、管理をカバーする。
   最後に、すべての参考文献はセクション7で得られる。

   1.1  インターネットアーキテクチャー

      ホストの観点からのインターネットアーキテクチャーに関する簡単な
      導入については、[INTRO:1]のセクション1.1.を参照せよ。同セクション
      は、インターネットアーキテクチャーの一般的な背景に関する推奨参考
      文献も含んでいる。

   1.2  一般的な考慮点

      インターネットホストソフトウェアのベンダーが経験を通して学び
      取った、そして新たなベンダーが真剣に考慮すべき重要な知見が
      二つある。

      1.2.1  継続的なインターネットの発展

         インターネットが膨大な規模で成長したことで、データグラム
         ベースの大規模なパケット通信システムにおける管理とスケールの
         問題が露呈した。これらの問題は対処中であり、結果として本文書
         に記述される仕様も発展し続けるだろう。これらの変更は注意深く
         立案され制御されるだろう。変更の立案にはベンダーとネットワーク
         運用に責任を持つ組織が多数参加するからである。


Internet Engineering Task Force                                 [Page 6]


RFC1123                       INTRODUCTION                  October 1989


         開発、発展、改訂は、今日のコンピューターネットワークプロトコル
         の特徴であり、この状況は今後数年は持続する。ベンダーがインター
         ネットプロトコルスイート(あるいは他のどのようなプロトコル
         スイートであっても!)向けのコンピューターの通信ソフトウェアを
         開発しており、後に仕様変更に対応した保守、更新に失敗すると、
         不幸な顧客の行列を残すことになるだろう。インターネットは大規模
         な通信ネットワークであり、ユーザーは日常的にインターネットを
         通して連絡を取っている。経験によれば、ベンダーソフトウェアの
         欠陥に関する知識は、インターネット技術コミュニティを通して
         短時間で伝播することが分かっている。

      1.2.2  ロバストネス原則

         プロトコルの各レイヤーにおいて、それを適用することでロバスト性
         と相互運用性に莫大な便益をもたらし得る一般的なルールが存在する。
         それは以下のようなものである。

                "受信するものに対しては寛容であれ。
                 送信するものに対しては保守的であれ"

         ソフトウェアは、想定されるエラーそれぞれについて、どんなに
         あり得なさそうであってもそのエラーに対処できるように書かれる
         べきである。遅かれ早かれ特定のエラーや属性の組み合わせを抱えた
         パケットが到着するので、ソフトウェアが準備をしておかなければ
         混乱が生じる可能性がある。一般に、ネットワークは悪意ある
         エンティティに満ちており、彼らは考えられる最悪の効果を与える
         ように設計されたパケットを送信すると想定するのが最善である。
         この想定は適切な保護の設計をもたらすだろう。とは言え、インター
         ネットにおける深刻な問題の大半は、低い確率で発生するイベントが
         きっかけとなり、予期できない仕組みによって生じてきた。人間の
         悪意だけならば、大きく道を外れるような状況は決して生じない!

         変更への適応性は、インターネットホストのソフトウェアのあらゆる
         レベルで設計に組み込まれていなければならない。単純な例として、
         特定のヘッダーフィールドの値、例えばタイプフィールド、ポート
         番号、エラーコード等の列挙を含むプロトコル仕様を考える。その
         場合、この列挙は不完全だと想定されなければならない。従って、
         プロトコル仕様が起こり得るエラーコードを四つ定義している場合、
         ソフトウェアは五つめのエラーコードが現れた際に機能不全を起こしては
         ならない。未定義のコードのログを採ることは構わないが(後述）、
         未定義のコードによって障害を生じさせてはならない。

         原則の2文目も1文目と同じくらい重要である。他のホストのソフト
         ウェアには欠陥があり、プロトコル上正当ではあっても不明確な機能
         は活用できないかもしれない。悪影響がどこかに生じるのを避けよう
         として、明確でシンプルなものからかけ離れてしまうことは賢明では
         ない。


Internet Engineering Task Force                                 [Page 7]


RFC1123                       INTRODUCTION                  October 1989


         ここから引き出される結論は"作法を守らないホストに注意せよ"で
         ある。ホストソフトウェアは、他の作法を守らないホストによって
         生じる厄介な状況を切り抜けて存続するだけではなく、そのような
         ホストが共用の通信設備に引き起こすかもしれない混乱の規模を限定
         するべく協調するように準備をしておくべきである。

      1.2.3  エラーのロギング

         インターネットは非常に多様なホストとゲートウェイシステムを含む。
         各ホスト、 ゲートウェイは多数のプロトコルとプロトコルレイヤーを
         実装しており、そのうちの幾つかはインターネットプロトコルソフト
         ウェアにバグや仕様の欠陥を含んでいる。複雑性、多様性に加えて
         機能を分散させた結果として、ユーザーが引き起こす問題の診断は
         しばしば非常に困難である。

         ホスト実装が誤ったあるいは"おかしな"プロトコルイベントを
         ロギングするための注意深く設計された機能を保持していれば、
         問題の診断が支援されるだろう。エラーのログを採る際に、可能な
         限り多くの診断情報を含めることが重要である。特に、エラーを
         生じさせたパケットのヘッダーを記録しておくとしばしば有益である。
         しかし、エラーのロギングが極端な量のリソースを消耗させたり、
         ホストの運用に干渉したりといったことのないように注意が
         払われなければならない。

         異常だが無害なプロトコルイベントがエラーのログファイルをあふれ
         させる傾向がある。これは"循環"ログを使用するか、既知の障害を
         診断する間だけロギングを有効にすることで回避できる。重複する
         連続したメッセージをフィルターしてカウントすると有益かもしれない。
         うまく機能しそうに思える戦略の一つは次の通りである。(1)常に
         異常をカウントし、管理プロトコルを通してそのカウント数にアクセス
         できるようにする(セクション6.3参照)。(2)非常に多岐に渡るイベント
         のロギングを選択的に有効にできるようにする。例えば、"すべてを記録
         せよ"や"ホストXに関してすべてを記録せよ"等を選択できたら恐らく
         便利だろう。

         管理者が違えば、ホストで通常有効にしたいと考えるエラーロギング量
         に関するポリシーも異なるかもしれないことに注意せよ。プロトコルの
         異常に関して、ある者は"自分に被害がないのなら、それについては
         知りたくない"と言う一方で、別の者は異常を検知して除去することに
         対してより注意深く積極的な態度をとるだろう。

      1.2.4  環境設定

         インターネットプロトコルスイートのホスト実装が完全に自己設定
         できるならば、それが理想だろう。それが実現すれば、すべての
         プロトコルスイートをROMに実装したり、シリコンに収めたりできる
         ようになる。


Internet Engineering Task Force                                 [Page 8]


RFC1123                       INTRODUCTION                  October 1989


         結果としてディスクレスのワークステーションが簡素化され、
         悩めるLAN管理者に加えてシステムベンダーにも多大な恩恵を
         もたらすだろう。我々はまだその理想に到達していない。実際の
         ところ、近づいてすらいない。

         本文書の多くの場所で、パラメーターを設定可能なオプションにせよ
         という要件が見つかるだろう。そのような要件の背後には幾つかの
         異なる理由がある。少数の事例では、現時点で最善の値が不確かで
         合意に至っていないため、推奨値を将来更新する必要があるかもしれない
         ことがその理由となっている。別の事例の場合、パラメーター値が
         実際のところ外部要素、例えばホストのサイズや通信負荷の分布、
         近隣のネットワークの通信速度やトポロジーといったものに依存して
         おり、自己調整アルゴリズムが利用できないか、利用できても非効率
         であることがその理由である。幾つかの事例では、管理上の要件の
         ためにパラメーター設定機能が求められることもある。

         最後に、廃止された、あるいは不正確なプロトコル実装と通信する
         ために、幾つかの設定オプションが要求される。そのような実装は
         ソースコード無しで配付されており、不幸にしてインターネットの
         多くの場所で生き残っている。正しいシステムをこれらの欠陥のある
         システムと共存させるために、管理者はしばしば正しいシステムを
         "誤った設定"にしなければならない。欠陥のあるシステムが退役して
         いくため、この問題は何もしなくても徐々に解消されていくだろうが、
         ベンダーはこれを無視できない。

         本文書で、パラメーターが設定可能でなければならないと記述する
         場合、それは、その値をブート時に設定ファイルから明示的に読み
         込めるよう求めるという意図ではない。我々は、実装者が各パラメーター
         のデフォルト値を設定しておくことを推奨する。従って設定
         ファイルが必要になるのは、デフォルト値では不適切な特定の導入
         状況で、それらを上書きする場合だけである。つまり設定機能に
         関する要件は、たとえデフォルト値がバイナリーでしか保存されて
         いないか、ROMベースの書き換えできない機器の中にあるとしても、
         必要に応じて上書きが"可能である"ことの保証である。

         本文書は、幾つかの事例において、そのようなデフォルト値に対して
         特定の値を要求している。設定項目が既存の欠陥のあるシステムへの
         適応を制御している場合、デフォルト値の選択はセンシティブな問題
         になる。インターネットが完全な相互運用性に向けてうまく収束して
         いくのであれば、実装に組み込まれるデフォルト値は公式プロトコルを
         実装したものでなければならず、欠陥のある実装に適応するための
         "誤った設定"であってはならない。幾つかのベンダーは、マーケティング
         への配慮から誤った設定をデフォルトに選択してきたが、我々は標準
         に従うデフォルト値を選択するようベンダーに要請する。


Internet Engineering Task Force                                 [Page 9]


RFC1123                       INTRODUCTION                  October 1989


         最後に、ベンダーはすべての設定パラメーターについて、上限値や効果に
         関する適切な文書を提供する必要があることを注記しておく。


   1.3  本文書の読み方

      1.3.1  構成

         一般に、本文書の各主要セクションは、以下のサブセクションで構成
         される。

         (1)  導入

         (2)  プロトコルのウォークスルー
              プロトコルの仕様文書をセクションごとに検討し、エラーを修正
              し、不明確またはあいまいな可能性のある要件を提示し、より
              明確な記述または説明を提供する。

         (3)  固有の課題
              ウォークスルーには含まれなかったプロトコル設計と実装に
              関する課題を議論する。

         (4)  インターフェース
              一つ上のレイヤーへのサービスインターフェースを議論する。

         (5)  概要
              そのセクションの要件の概要を含む。

         本文書の多くの個々の話題の配下に、"【 議論 】"または"【 実装 】"
         とラベルされた説明的な資料が存在する。この資料は、その前に記述
         されている要件の本文の明確化と説明を与えることを目的としている。
         また、見込まれる将来の方向付けまたは開発について若干の提案も
         含んでいる。実装の資料は、実装者が検討したいと思うかもしれない
         推奨アプローチを含む。

         概要セクションは、本文の手引き及び目次となることを目的として
         いるが、やむを得ずあいまいで不完全なものになっている。概要は、
         このRFC全体から切り離した形では絶対に使用または参照されるべき
         ではない。

      1.3.2  要件

         本文書において、個々の固有の要件の重要性を定義するために使用
         される語句は大文字で注記される。それらの語句は以下の通り
         である。


Internet Engineering Task Force                                [Page 10]


RFC1123                       INTRODUCTION                  October 1989


         ・   "しなければならない(MUST)"

              この語句または形容詞の"要求される(REQUIRED)"は、その項目が
              仕様の絶対的な要件であることを意味する。

         ・   "すべきである(SHOULD)"

              この語句または形容詞の"推奨される(RECOMMENDED)"は、特定の
              状況ではその項目を無視する正当な理由が存在する場合もあるが、
              その意味するところはすべて理解されるべきであり、異なるやり方
              を選択する前に慎重に検討されるべきであることを意味する。

         ・   "してもよい(MAY)"

              この語句または形容詞の"任意の(OPTIONAL)"は、この項目が
              紛れもなく任意であることを意味する。例えば、あるベンダーは
              特定の市場がそれを要求していたり製品を強化するという理由で
              その項目を含めるかもしれないし、別のベンダーは同じ項目を
              除外するかもしれない。


         ある実装が、実装しようとするプロトコルの一つ以上の"MUST"要件を
         満たすことに失敗している場合、その実装はプロトコル準拠ではない。
         プロトコルのすべての"MUST"及び"SHOULD"の要件を満たす実装は、
         "無条件に準拠"であるという。一方、プロトコルの"MUST"要件はすべて
         満たしているが、"SHOULD"要件をすべて満たしていない実装は"条件付き
         準拠"であるという。

      1.3.3  用語

         本文書は、以下の技術用語を使用する。

         セグメント
              セグメントは、TCPプロトコルにおけるエンドツーエンドの転送
              単位である。セグメントは、TCPヘッダーとそれに続くアプリ
              ケーションデータで構成される。セグメントは、IPデータグラム
              内にカプセル化されて転送される。

         メッセージ
              この用語は、一部のアプリケーションレイヤープロトコル
              (特にSMTP)でアプリケーションのデータ単位を参照するために
              使用される。

         データグラム
              "UDP"データグラムは、UDPプロトコルにおけるエンドツーエンドの
              転送単位である。


Internet Engineering Task Force                                [Page 11]


RFC1123                       INTRODUCTION                  October 1989


         マルチホーム
              ホストが(複数の)接続ネットワークに対して複数のIPアドレス
              を持つ場合、そのホストはマルチホームであるという。


   1.4  Acknowledgments

      This document incorporates contributions and comments from a large
      group of Internet protocol experts, including representatives of
      university and research labs, vendors, and government agencies.
      It was assembled primarily by the Host Requirements Working Group
      of the Internet Engineering Task Force (IETF).

      The Editor would especially like to acknowledge the tireless
      dedication of the following people, who attended many long
      meetings and generated 3 million bytes of electronic mail over the
      past 18 months in pursuit of this document: Philip Almquist, Dave
      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).

      In addition, the following people made major contributions to the
      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
      Technology), and Mike StJohns (DCA).  The following also made
      significant contributions to particular areas: Eric Allman
      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
      (Toronto).

      We are grateful to all, including any contributors who may have
      been inadvertently omitted from this list.


Internet Engineering Task Force                                [Page 12]


RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989


2.  一般的なアプリケーションの要件

   本セクションは、すべてのアプリケーションレイヤープロトコルに適用可能と
   思われる一般的な要件を含む。

   2.1  ホスト名及び番号

      正当なインターネットホスト名の構文はRFC 952[DNS:4]で規定され、
      RFC 1034のセクション3.5[DNS:1]で繰り返し述べられている。
      ホスト名構文の一つの側面をここで変更する。先頭文字の制限が緩和
      され、英字または数字のいずれかであれば許容されるようになる。
      ホストソフトウェアは、より寛容なこの構文をサポートしなければ
      ならない(MUST)。(訳註: 本段落はErrata ID: 1354を反映している)

      ホストソフトウェアは、最大63文字のホスト名を扱えなければならず
      (MUST)、最大255文字のホスト名を扱えるべきである(SHOULD)。

      ユーザーがインターネットホストの識別情報を入力する場合、常に
      (1)ホストドメイン名か(2)ドット付き10進形式("#.#.#.#")のIPアドレス
      のどちらかを入力できるようにすべきである(SHOULD)。ホストは、
      入力された文字列をDNSで検索する前に、文字列がドット付き10進形式
      の番号の構文に従っているかを検査すべきである(SHOULD)。

      【 議論 】
           この最後の要件は、ドット付き10進形式のホスト番号入力で使用
           される完全な構文形式を指定しようとするものではない。それは
           ユーザーインターフェースの課題であると考えられている。
           例えばSMTPメールでは、ドット付き10進形式の番号は角括弧"[ ]"
           で囲まれなければならない(セクション5.2.17参照)。この表記法
           をホストシステム内で普遍的なものとし、ドット付き10進形式の
           番号の構文検査を簡素化することもできるかもしれない。

           そのような区切り文字無しでドット付き10進形式の番号が入力可能
           な場合、最大限の構文検査が行われなければならない。なぜなら、
           ホストドメイン名の一区切り(segment)は、今では数字で始まるもの
           が許容されるようになり、仕様の範囲内ですべてを数字にすることも
           可能になったからである(セクション6.1.2.4参照)。それでも有効
           なホスト名がドット付き10進形式#.#.#.#になることはあり得ない。
           少なくとも最上位の要素ラベルはアルファベットになるからである。

   2.2  ドメイン名サービスの使用

      ホストドメイン名は、セクション6.1で記述されているようにIPアドレス
      に変換されなければならない(MUST)。

      ドメイン名サービスを使用するアプリケーションは、ソフトエラー状態
      に対処できなければならない(MUST)。


Internet Engineering Task Force                                [Page 13]


RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989


      アプリケーションは、ソフトエラーに起因してくり返し生じるリトライの
      間で妥当な期間待機しなければならず(MUST)、またネットワーク障害の
      ためにサービスが数時間または数日であっても拒否される可能性も考慮
      しなければならない(MUST)。

      WKS RRタイプはインターネットサイトではあまり使用されていないので、
      アプリケーションは、特定のホストアドレスで提供される全サービスの
      正確な一覧を含むWKSレコードを検索する機能に依存すべきではない
      (SHOULD NOT)。サービスが存在することを確認するには、単にサービス
      使用を試みればよい。

   2.3  マルチホームホスト上のアプリケーション

      リモートホストがマルチホームの場合、名前からアドレスへの変換は
      候補となるIPアドレスの一覧を返す。セクション6.1.3.4で規定される
      ように、この一覧は、降順の優先順位で順序付けられるべきである。
      アプリケーションプロトコル実装は、成功が得られるまで一覧から
      複数のアドレスを試すよう準備されているべきである(SHOULD)。
      SMTPに関するより具体的な要件がセクション5.3.4で与えられる。

      ローカルホストがマルチホームの場合、UDPベースのリクエスト/応答
      アプリケーションは、UDPリクエストデータグラムの特定宛先アドレス
      と同じアドレスをIP送信元アドレスにして応答を返すべきである
      (SHOULD)。"特定宛先アドレス"は、対のもう片方のRFC[INTRO:1]の
      "アドレス体系"セクションで定義されている。

      同様に、同じクライアントに複数のTCP接続をオープンするサーバー
      アプリケーションは、そのすべての接続で同じローカルIPアドレスを使用
      すべきである(SHOULD)。

   2.4  タイプオブサービス

      アプリケーションは、トランスポートレイヤーのサービスを呼び出す際
      に適切なTOS値を選択しなければならず(MUST)、またこれらの値は設定
      可能でなければならない(MUST)。TOS値は5ビットを含むが、そのうちの
      上位3ビットだけしか現在定義されていないことに注意せよ。残りの
      2ビットはゼロでなければならない(MUST)。

      【 議論 】
           タイプオブサービスを実装するゲートウェイアルゴリズムが開発
           されると、さまざまなアプリケーションプロトコルの推奨値が変更
           されるかもしれない。更に、ユーザーとインターネットパス
           の特定の組み合わせでは、標準外のTOS値が望まれることもある
           だろう。これらの理由により、TOS値は設定可能でなければ
           ならない。

           主要なアプリケーションプロトコルの推奨TOS値については、
           "割り当て済み番号資源(Assigned Numbers)"RFC[INTRO:5]の
           最新版を参照せよ。


Internet Engineering Task Force                                [Page 14]


RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989


   2.5  一般的なアプリケーションの要件の概要

                                               |          | | | |S| |
                                               |          | | | |H| |
                                               |          | | | |O|M|
                                               |          | |S| |U|U|
                                               |          | |H| |L|S|
                                               |          |M|O| |D|T|脚
                                               |          |U|U|M| | |
                                               |          |S|L|A|N|N|
                                               |          |T|D|Y|O|O|注
機  能                                         |セクション| | | |T|T| 
-----------------------------------------------|----------|-|-|-|-|-|--
                                               |          | | | | | |
ユーザーインターフェース:                      |          | | | | | |
  数字で始まるホスト名を許容                   |2.1       |x| | | | |
  最大63文字のホスト名に対応                   |2.1       |x| | | | |
  最大255文字のホスト名に対応                  |2.1       | |x| | | |
  ドット付き10進形式のホスト番号をサポート     |2.1       | |x| | | |
  ドット付き10進形式の構文検査を初めに行う     |2.1       | |x| | | |
  (訳註: 本段落はErrata ID: 558を反映している)
                                               |          | | | | | |
セクション6.1に従いドメイン名をマップ          |2.2       |x| | | | |
ソフトDNSエラーへの対処                        |2.2       |x| | | | |
   リトライの間で妥当な期間待機                |2.2       |x| | | | |
   長期に渡るサービス停止を許容                |2.2       |x| | | | |
WKSレコードが利用可能であると期待              |2.2       | | | |x| |
                                               |          | | | | | |
ﾘﾓｰﾄのﾏﾙﾁﾎｰﾑﾎｽﾄに対して複数のｱﾄﾞﾚｽを試みる     |2.3       | |x| | | |
UDP応答の送信元ｱﾄﾞﾚｽはﾘｸｴｽﾄの特定宛先ｱﾄﾞﾚｽ     |2.3       | |x| | | |
関連するTCP接続では同じIPアドレスを使用        |2.3       | |x| | | |
適切なTOS値を設定                              |2.4       |x| | | | |
  TOS値は設定可能                              |2.4       |x| | | | |
  未使用のTOSビットはゼロにする                |2.4       |x| | | | |
                                               |          | | | | | |
                                               |          | | | | | |


Internet Engineering Task Force                                [Page 15]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


3.  リモートログイン -- Telnetプロトコル

   3.1  導入

      Telnetは、リモートログイン用の標準インターネットアプリケーション
      プロトコルである。このプロトコルは、クライアント("ユーザー")システム
      のユーザーのキーボード入力/表示とリモートサーバーシステムのコマンド
      インタープリターとを関連付けるエンコーディングルールを提供する。
      Telnetプロトコルのサブセットは、FTPやSMTP等の他のアプリケーション
      プロトコルにも組み込まれている。

      Telnetは単一のTCP接続を使用する。通常のデータストリーム("ネット
      ワーク仮想端末"または"NVT"モード)は、制御機能を組み込むための
      エスケープシーケンスに対応した7ビットASCIIである。またTelnetでは、
      多くのモード選択や機能のネゴシエーションも可能となっている。

      主要なTelnet仕様はRFC 854[TELNET:1]で得られる。オプションは他の
      多くのRFCで定義されている。それらについてはセクション7を参照せよ。

   3.2  プロトコルのウォークスルー

      3.2.1  オプションのネゴシエーション: RFC 854の2～3ページ

         あらゆるTelnet実装は、オプションに関するネゴシエーションと
         サブネゴシエーションの段階的手続き[TELNET:2]を含まなければ
         ならない(MUST)。

         ホストは、オプションのネゴシエーションのループを回避するため、
         RFC 854のルールに注意深く従わなければならない(MUST)。ホストは
         未サポートのオプションを拒否(DO/WILLに対しWONT/DONTを応答)
         しなければならない(MUST)。オプションのネゴシエーションは、
         Telnet接続が存続している間はずっと(たとえすべてのリクエストが
         拒否されても)機能が提供され続けるべきである(SHOULD)。

         全オプションのネゴシエーションが失敗した場合、Telnet実装は
         デフォルトのNVTに移行し、NVTをサポートしなければならない(MUST)。

         【 議論 】
              "端末"やサポートオプションのネゴシエーションは、今後より洗練
              された水準が求められるようになっていくだろうが、すべての実装は、
              あらゆるユーザー－サーバー間の通信用にNVTをサポートする準備が
              できていなければならない。

      3.2.2  TelnetのGo-Ahead機能: RFC 854の5ページ及びRFC 858

         TelnetコマンドGo Ahead(GA)を送信しないホストの場合、Server
         TelnetはSuppress Go Aheadオプションのネゴシエート("WILL 
         Suppress Go Ahead"送信)を試みなければならない(MUST)。


Internet Engineering Task Force                                [Page 16]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


         User TelnetまたはServer Telnetは、Suppress Go Aheadオプション
         のネゴシエーションを常に受け入れなければならない(MUST)。

         GAが意味を持たない全二重端末が操作されている場合、User Telnet
         実装はGAコマンドを無視してもよい(MAY)。

         【 議論 】
              Go-Aheadの仕組みは半二重の("キーボードがロックされる")
              ライン方式の端末向けに設計されたが、それらの端末は世界
              からほとんど姿を消してしまった。多くのオペレーティング
              システムにおいて、たとえそれが半二重端末を標準でサポート
              するシステムであってもGo-Ahead通知の送信を実装することは
              困難であることが判明している。困難である理由は、通常の
              場合、ユーザープロセスがTelnet接続からの入力待ちでブロック
              されているかどうかという情報にTelnetサーバーのコードが
              アクセスできない、言い換えると、TelnetサーバーはGAコマンド
              をいつ送信すべきか信頼性を持って判断できないからである。
              そのため、大半のServer TelnetホストはGAコマンドを送信
              しない。

              本セクションのルールの効果は、Telnet接続のどちらかの
              終端がGAコマンドの使用を拒否できるようにすることである。

              依然として商業上重要な半二重端末のクラスがある。フル
              スクリーン方式でやりとりする"データ入力端末"である。
              ただし、Telnetプロトコルを使用するデータ入力端末の
              サポートにあたり、Go Ahead通知は要求されない。
              セクション3.3.2を参照せよ。

      3.2.3  制御機能: RFC 854の7～8ページ

         Telnetコマンドの一覧は、コード239でEOR(End-of-Record)を含む
         ように拡張された[TELNET:9]。

         User TelnetとServer Telnetはどちらも制御機能EOR、EC、EL、Break
         をサポートしてもよく(MAY)、AO、AYT、DM、IP、NOP、SB、SEを
         サポートしなければならない(MUST)。

         ホストは、自身がサポートしていないあらゆるTelnet制御機能を受信
         して無視できなければならない(MUST)。

         【 議論 】
              Server Telnetは、たとえホストが同等のストリーム内機能
              (例えば多くのシステムにおけるControl-C)を持っていたと
              しても、Telnet IP(Interrupt Process: 割り込み処理)機能
              をサポートする必要があることに注意せよ。Telnet IP機能
              は、TCP緊急データのような接続チャネル外(out-of-band)の
              効果を持つため、ストリーム内の割り込みコマンドより強力
              な場合がある。


Internet Engineering Task Force                                [Page 17]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              EOR制御機能はストリームを区切るために使用される。重要な
              活用場所は、データ入力端末のサポートである(セクション3.3.2
              参照)。EORはRFC 854で定義されていなかったため、未知の
              Telnetコマンドを正しく無視する準備ができていないホストが
              EORを受信すると、クラッシュしてしまうかもしれないという
              懸念があった。そのようなホストを保護するためにEnd-of-Record
              オプション[TELNET:9]が導入されたが、適切に実装されたTelnet
              プログラムはこの保護を必要としない。

      3.2.4  Telnetの"Synch(同期)"通知: RFC 854の8～10ページ

         "緊急"のTCPデータを受信した場合、User TelnetまたはServer 
         Telnetは、DM(緊急データ終了)に到達するまでTelnetコマンドを
         除くすべてのデータを破棄しなければならない(MUST)。

         User TelnetがTelnet IP(Interrupt Process)を送信する場合、その後
         にTelnet "Synch"手順を続けるべきである(SHOULD)。言い換えると、
         TCP緊急データとして"IAC IP IAC DM"を順番に送信すべきである
         (SHOULD)。TCP緊急ポインターはDMオクテットを指し示す。

         Server TelnetがTelnet IPコマンドを受信した場合、出力ストリーム
         を廃棄させるためにTelnet "Synch"手順をユーザーに送り返しても
         よい(MAY)。この選択は、ローカルユーザーがプロセスを中断する際に
         サーバーオペレーティングシステムが反応するやり方と整合する
         はずである。

         Server TelnetがTelnet AO(Abort Output:出力アボート)を受信した
         場合、出力ストリームを廃棄させるためにTelnet "Synch"手順を
         ユーザーに送り返さなければならない(MUST)。

         User Telnetは、Telnet IPを送信する際に出力を廃棄する機能を持つ
         べきである(SHOULD)。セクション3.4.5も参照せよ。

         【 議論 】
              User Telnetがサーバー出力データのストリームを廃棄するに
              あたり、考えられる方法が三つある。

              (1)  IPの後にAOを送信する

                   これにより、サーバーホストがオペレーティングシステム
                   に"flush-buffered-output"シグナルを送信するようになる。
                   しかし、AOはローカルには効果を発揮しないかもしれない。
                   言い換えると、Server TelnetがAOを受信して処理し、
                   "Synch"を送り返すまでUser Telnet側終端の端末出力は
                   停止しないかもしれない。

              (2)  IPの後にDO TIMING-MARK[TELNET:7]を送信し、Server Telnet
                   からWILL/WONT TIMING-MARKを受信するまですべての出力を
                   ローカルに破棄する


Internet Engineering Task Force                                [Page 18]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


                   サーバーにおいて、DO TIMING-MARKはIPの後に処理される
                   ので、その応答は出力データストリームの適切な場所に
                   配置されるはずである。しかし、TIMING-MARKはサーバー
                   オペレーティングシステムに"flush-buffered-output"
                   シグナルを送信しない。これが必要かどうかはサーバー
                   システムによって異なる。

              (3)  両方行う

              最良の方法は完全には明確になっていない。さまざまな形でTelnet
              標準に準拠していない多数の既存サーバーに対応しなければ
              ならないからである。最も安全なアプローチは、恐らく(1)、
              (2)、(3)の選択をユーザーが指定できるオプションを提供する
              ことだろう。

      3.2.5  NVTプリンター及びNVTキーボード: RFC 854の11ページ

         NVTモードでは、Telnetは最上位ビットが1の文字を送信すべきでは
         なく(SHOULD NOT)、最上位ビットをパリティビットとして送信しては
         ならない(MUST NOT)。最上位ビットをアプリケーションに渡す実装は、
         バイナリーモードをネゴシエートすべきである(SHOULD)(セクション
         3.2.7参照)。


         【 議論 】
              RFC 854を厳密に読むと、クライアントまたはサーバーがNVT
              ASCIIを期待する場合、最上位ビットが設定された文字を無視
              しても許容されると実装者は認識すべきである。一般に、拡張
              文字集合(7ビットを越えるもの)をTelnetで転送する際には
              バイナリーモードを使用することが期待される。

              しかし、現在定義されていない8ビットのNVTモードを実際に
              必要とするアプリケーションが存在する。これらの既存
              アプリケーションは、Telnet接続が存続している間の一部
              またはすべてで最上位ビットを設定する。バイナリーモードは
              行末処理を行わないため、バイナリーモードと8ビットNVT
              モードは同じではないことに注意せよ。この理由により、
              最上位ビットの要件はMUSTではなくSHOULDと記述されている。

              RFC 854は、"ネットワーク仮想端末(network virtual terminal)"
              またはNVTの最小限の機能集合を定義している。これは実端末の
              追加機能を排除しようと意図するものではない。Telnet接続は、
              任意のASCII制御文字を含むすべての7ビットASCII文字に対して
              完全に透過的である。


Internet Engineering Task Force                                [Page 19]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              例えば、端末は、ASCIIのエスケープシーケンスとしてコード化
              されたフルスクリーンコマンドをサポートしているかも
              しれない。その場合、Telnet実装はそれらのエスケープ
              シーケンスを未解釈のデータとして渡すだろう。従って、
              NVTは制限の強いデバイスの端末タイプとして考えられるべき
              ではない。

      3.2.6  Telnetコマンドの構造: RFC 854の13ページ

         オプションはデータストリームのどの場所にも表れる可能性があるため、
         データとして送信されるTelnetエスケープ文字(IACとして知られる。
         値は255)は、同じ文字を二つ続けたものでなければならない(MUST)。

      3.2.7  TelnetのBinaryオプション: RFC 856

         Binaryオプションのネゴシエートが成功すると、任意の8ビット文字
         が許容されるようになる。しかし、データストリームは依然として
         IAC文字がないか検査されなければならず(MUST)、埋め込まれた
         Telnetコマンドには従わなければならない(MUST)。またIACと同じ
         データバイトは同じ値を2回続けたものにしなければならない(MUST)。
         他の文字処理(例えばCRをCR NULまたはCR LFで置き換える)が行われ
         てはならない(MUST NOT)。特に、バイナリーモードには行末に関する
         規定は存在しない(セクション3.3.1参照)。

         【 議論 】
              Binaryオプションは、通常両方向でネゴシエートされ、Telnet
              接続をNVTモードから"バイナリーモード"に変更する。

              IAC EORの並びは、バイナリーモード内でデータブロックを
              区切るために使用することができる。

      3.2.8  TelnetのTerminal-Typeオプション: RFC 1091

         特定の端末で端末タイプが利用可能な場合、Terminal-Typeオプション
         は、"割り当て済み番号資源" RFC[INTRO:5]内で公式に定義されている
         端末タイプ名を使用しなければならない(MUST)。ただし、Terminal-Type
         オプションの受信者は、どのような名前でも受け入れなければならない
         (MUST)。

         【 議論 】
              RFC 1091[TELNET:10]は、RFC 930で定義されたTerminal-Type
              オプションの古いバージョンを更新している。古いバージョン
              では、各物理端末が固有のタイプを持つという想定の下に、
              複数の端末タイプをサポート可能なサーバーホストは特定の
              クライアント端末のタイプを学習できるようになっていた。
              しかし、今日の"端末"は、大抵の場合、実際にはPC内で動作
              する端末エミュレータープログラムであり、恐らくは幅広い
              端末タイプをエミュレートする機能を持っている。


Internet Engineering Task Force                                [Page 20]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              そのため、RFC 1091は仕様を拡張し、User TelnetとServer 
              Telnetの間でより一般的な端末タイプのネゴシエーションが
              できるようした。

   3.3  固有の課題

      3.3.1  Telnetの行末に関する規定

         Telnetプロトコルでは、CR LFの並びは"行末"を意味すると定義
         している。端末入力の場合、これはコマンドの入力完了か、または
         ユーザー端末上で"行末"キーが押下されることに相当する。ASCII
         端末では、"行末"キーはCRキーだが、"Return"や"Enter"とラベル付け
         されていることもある。

         Server TelnetがTelnetの行末を意味するCR LFをリモート端末からの
         入力として受信した場合、その効果は、ユーザーがローカル端末で
         "行末"キーを押下した場合と同じでなければならない(MUST)。具体的
         に、ASCIIを使用するサーバーホストでは、TelnetでCR LFを受信した
         場合、ローカルユーザーがローカル端末でCRキーを押下した場合と
         同じ効果を生じさせなければならない。従って、Telnet接続上
         で入力として受信した場合、CR LFとCR NULはASCIIサーバーホスト
         で同じ効果を持たなければならない。

         User Telnetは、CR LF、CR NUL、LFのどの形式でも送信できなければ
         ならない(MUST)。ASCIIホスト上のUser Telnetは、ユーザーが"行末"
         キーを押下した際にCR LFまたはCR NULのどちらを送信するかをユーザー
         が指定可能なモードを持つべきであり(SHOULD)、CR LFをデフォルト
         とすべきである(SHOULD)。

         端末からコンピューターへの通信ではない場合(例えばServer Telnet
         が出力を送信する場合や、他のアプリケーションプロトコルに組み
         込まれたTelnetプロトコルなど)、Telnetデータを送信する際に、
         Telnetの行末を意味するものとしてCR LFが使用されなければ
         ならない(MUST)。

         【 議論 】
              任意のTelnetクライアント及びサーバー間での相互運用を
              可能にするため、Telnetプロトコルは、行を終端させるための
              標準的な表現方法を定義した。ASCII文字集合は明示的な行末
              文字を含まないので、システムはCR、LF、CR LFの並びといった
              多様な表現方法を選択してきた。Telnetプロトコルは、CR LFを
              ネットワーク転送用の標準として選択した。

              残念なことに、RFC 854[TELNET:1]のTelnetプロトコル仕様は、
              "行末"キーに関してクライアントからサーバーにどのような
              文字(群)が送信されるべきかについて若干あいまいであること
              が判明した。その結果、大規模で継続的な相互運用性の悩みが
              発生し、更にさまざまな形で誤ったUser TelnetとServer Telnet
              の両実装によって事態は更に悪化した。


Internet Engineering Task Force                                [Page 21]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              Telnetプロトコルは完全な対称モデルに基づいているが、
              リモートログインセッションでは、端末におけるユーザーの
              役割はサーバーホストの役割とは異なる。例えば、RFC 854は
              サーバーから出力されるCR、LF、CR LFの意味を定義している
              が、ユーザープロセスが"行末"キーを押下した際にUser Telnet
              が何を送信すべきかを規定していない。これが課題の核心で
              あることがわかっている。

              ユーザーが"行末"キーを押下した場合、(RFC 854の同じ文に
              対する異なった解釈のため)一部のUser Telnet実装はCR LFを
              送信し、そのほかの実装はCR NULを送信する。上記で議論された
              ように、正しく実装されたASCIIサーバーホスト上では、これら
              は等価となる。他のサーバーの場合、User Telnetにモード設定
              が必要となる。

              CRが押下された際にCR NULしか送信しないUser Telnetの存在
              は、非ASCIIホストにジレンマを生じさせる。なぜなら、CR NUL
              をCR LFと等価なものとして扱い"素の"CRが入力される可能性
              を排除するか、完全な相互運用を失うかのどちらか一つしか
              選べないからである。

              ホストA上のユーザーがTelnetを使用してサーバーホストBに
              ログインし、次にBのUser Telnetプログラムを使用してサーバー
              ホストCにログインしたとする。B上のServer/User Telnetの
              組み合わせは、可能な限り透過的であること、言い換えると、
              Aが直接Cに接続されたかのように見えることが望ましい。
              具体的に言うと、正しい実装は、CR LFがCR NULに変換されるか
              その逆変換がなされることを除けば、Telnetの行末に関して
              Bを透過的にする。

         【 実装 】
              Telnetの行末の課題を理解するために、少なくともTelnetと
              ローカルオペレーティングシステムの関係に関する一般的モデル
              が必要である。Server Telnetプロセスは、通常の場合、疑似
              端末としてオペレーティングシステムの端末ドライバーソフト
              ウェアと一体になる。Server Telnetに受信されたTelnetの
              行末は、ローカルに接続された実ターミナル上で行末キーが
              押下された場合と同じ効果を持たなければならない。

              対話型で文字単位の処理を行うアプリケーション(エディター
              等)をサポートするオペレーティングシステムの場合、端末の
              I/Oで使用される内部モードが一般に二つ存在する。一つめは
              フォーマット指定モードで、行末に関するローカルな処理や
              他のフォーマットに関するルールがデータストリームに適用
              される。もう一つは"未加工(raw)"モードで、アプリケーション
              は、すべての文字について入力された状態のままのものに直接
              アクセスする。


Internet Engineering Task Force                                [Page 22]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              Server Telnetは、これらのモードがローカル端末と同じ効果
              をリモートでも持つように実装されなければならない。例えば、
              CR LFまたはCR NULがASCIIホスト上のServer Telnetに受信
              されたとする。未加工モードであればCR文字はアプリケーション
              に渡され、フォーマット指定モードであればローカルシステム
              の行末の規定が使用される。

      3.3.2  データ入力端末

         【 議論 】
              Telnet設計時に対象とした行指向かつ文字指向のASCII端末に
              加えて、"データ入力端末"またはDETと呼ばれることもある
              ビデオディスプレイ端末のファミリーが幾つか存在する。
              IBM 3270ファミリーはよく知られた例である。

              汎用のDETをサポートするため、二つのインターネット
              プロトコルが設計された。SUPDUP[TELNET:16, TELNET:17]とDET
              オプション[TELNET:18, TELNET:19]である。DETオプションは、
              (サブ)ネゴシエーションを使用してTelnet接続上でデータ入力
              端末を操作する。SUPDUPは完全に独立した端末プロトコルで
              あり、ネゴシエーションによってTelnetからSUPDUPに入ること
              ができる。SUPDUPとDETオプションは共に特定の環境ではうまく
              利用されているが、どちらも一般的には受け入れられておらず、
              広範な実装も存在しない。

              Telnetを介してIBM3270ファミリーをサポートするために、
              異なるアプローチのDETの通信方式が開発されている。IBM3270
              ファミリーを対象としているが、同じアプローチはどのような
              DETに対しても適用可能である。アイディアは、"DET専用"
              モードに入り、そこでは専用のDET入力/出力ストリームが
              バイナリーデータとして配送されるというものである。この
              バイナリーストリーム内の論理レコード(例えば"スクリーン
              画面")を区切るために、Telnet EORコマンドが使用される。

         【 実装 】
              DET専用モードに入る場合及びDET専用モードから抜ける場合
              のルールは以下の通りである。

              ・   Server Telnetは、Terminal-Typeオプション[TELNET:10]
                   を使用してクライアントがDETであると認識する。

              ・   要求されてはいないが慣習として、両端の端末はEOR
                   オプション[TELNET:9]をネゴシエートする。

              ・   両端の端末は、DET専用モードに入るためにBinary
                   オプション[TELNET:3]をネゴシエートする。


Internet Engineering Task Force                                [Page 23]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              ・   どちらか片方の端末がバイナリーモードから抜け出すよう
                   ネゴシエートすると、もう片方もそのようにし、モードは
                   通常のNVTに復帰する。


      3.3.3  オプションの要件

         すべてのTelnet実装は、Binaryオプション[TELNET:3]とSuppress Go 
         Aheadオプション[TELNET:5]をサポートしなければならず(MUST)、
         Echo[TELNET:4]、Status[TELNET:6]、End-of-Record[TELNET:9]、
         Extended Options List[TELNET:8]各オプションをサポートすべき
         である(SHOULD)。

         ローカルオペレーティングシステムがその機能を提供する場合、User
         TelnetまたはServer Telnetは、Window Sizeオプション[TELNET:11]
         をサポートすべきである(SHOULD)。

         【 議論 】
              End-of-Recordオプションは、Telnetがクラッシュすることなく
              Telnet EORを受信可能だと通知するに過ぎないことに注意せよ。
              従って、すべてのTelnetはEnd-of-Recordオプションの
              ネゴシエーションを進んで受けいれるべきである。セクション
              3.2.3の議論も参照せよ。

      3.3.4  オプションのネゴシエーション

         Telnetプロトコルがクライアント/サーバー型の状況で使用される
         場合、サーバー側からサーバーの期待する端末間の動作モードに
         関するネゴシエーションを開始すべきである(SHOULD)。

         【 議論 】
              Telnetプロトコルは完全に対称的なものとして定義されたが、
              Telnetアプリケーションは一般に非対称である。リモート
              ログインは、デフォルト以外の端末モードが必要な場合に
              "どちらの側からも"ネゴシエーションを開始しないので失敗
              することが知られている。一般に、望ましいモードを決定
              するのはサーバーであるから、サーバーからネゴシエーション
              を開始する必要がある。ただし、ネゴシエーションは対称的
              なので、ユーザーからもネゴシエーションを開始できる。

         クライアント(User Telnet)は、オプションのネゴシエーション開始
         を有効または無効にする手段をユーザーに提供すべきである(SHOULD)。

         【 議論 】
              ユーザーは、制御ストリーム用にTelnetを使用するがTelnet
              オプションはサポートしないアプリケーションサービス(例えば
              FTPやSMTP)との接続が必要な場合がある。


Internet Engineering Task Force                                [Page 24]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              User Telnetのオプションのネゴシエーション開始が無効に
              なっていれば、そのような状況で使用できるだろう。

      3.3.5  TelnetのLinemodeオプション

         【 議論 】
              重要な新しいTelnetオプションのLINEMODE[TELNET:12]が提案
              されている。LINEMODEオプションは、User TelnetとServer 
              Telnetの両者の間で、端末の文字処理を実行するのはサーバー
              ではなくクライアントだと合意するための標準的な方法を提供
              する。クライアントがテキストの完全な行を1行準備すると、
              それを(通常)TCPパケット一つに収めてサーバーに送信する。
              このオプションはTelnetセッションのパケットコストを大幅に
              削減することに加えて、ふくそうしているかまたは遅延の大きい
              ネットワークにおいて、はるかに良好な応答性をユーザーに
              提供する。

              LINEMODEオプションにより、ローカルな文字処理とリモートの
              文字処理を動的に切り替えることができるようになる。例えば、
              Telnet接続は、フルスクリーンエディターが動作中は単一文字
              指向モードになり、エディターが終了すると行指向モードに
              復帰するように自動でネゴシエートする。

              本RFCがリリースされる頃には、ホストがこのオプションの
              クライアント側を実装しており、このオプションのサーバー
              側も実装しているかもしれないことを期待する。サーバー側
              を適切に実装するためには、サーバーからローカルシステム
              に対していかなる入力文字処理も行わず、現在の端末状態を
              記憶し、状態が変わった場合は常にServer Telnetプロセスに
              通知するよう指示できる必要がある。これにより、例えば
              パスワードのエコーやフルスクリーンエディターを適切に
              処理できるようになる。

   3.4  Telnet/ユーザー間のインターフェース

      3.4.1  文字集合の透過性

         User Telnet実装は、どのような7ビットASCII文字でも送信または
         受信できるべきである(SHOULD)。可能であれば、ユーザーホストの
         オペレーティングシステムによるあらゆる特殊文字の解釈は迂回
         されるべきである(SHOULD)。このようにすることで、これらの特殊
         文字を接続上でうまく送信、受信できるようになる。

         幾つかの文字値は、"コマンドモードへのエスケープ"として予約
         されなければならない(MUST)。慣習的に、この文字を2文字続ける
         ことで、その文字をデータとして入力することができる。
         エスケープに使用される固有の文字は、ユーザーが選択可能に
         すべきである(SHOULD)。


Internet Engineering Task Force                                [Page 25]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


         バイナリーモード接続において、ホストオペレーティングシステム
         が任意の8ビット文字をキーボードから直接入力できないようにして
         いる場合、User Telnetプログラムは、それらを入力するための
         エスケープの仕組みを提供してもよい(MAY)。

         【 実装 】
              サーバーに関しては、透過性の課題は差し迫ったものではない。
              しかし実装者は、NVT ASCIIのみを期待するプログラムに(旧式
              の、標準非準拠のクライアントによって送信された)パリティ
              ビットが到達する前にそれらをマスクする、あるいは8ビット
              データストリームをリクエストするプログラムを適切に処理
              するといった具合に、課題に対処するよう注意を払うべき
              である。

      3.4.2  Telnetコマンド

         User Telnetプログラムは、ユーザーに対してTelnet制御機能IP、AO、
         AYTをどれでも入力できる機能を提供しなければならず(MUST)、また
         EC、EL、Breakを入力する機能を提供すべきである(SHOULD)。

      3.4.3  TCP接続のエラー

         User Telnetプログラムは、トランスポートレイヤーから通知された
         あらゆるTCPエラーをユーザーに通知すべきである(SHOULD)([INTRO:1]
         の"TCP/アプリケーションレイヤー間のインターフェース"セクション
         を参照せよ)。

      3.4.4  デフォルト以外のTelnet接続ポート

         User Telnetプログラムは、Server Telnetホストの標準外の接続
         ポート番号をユーザーが任意で指定できるようにすべきである
         (SHOULD)。

      3.4.5  出力の廃棄

         User Telnetプログラムは、IPが送信された際に出力が廃棄される
         べきかどうかをユーザーが指定する機能を提供すべきである
         (SHOULD)。セクション3.2.4を参照せよ。

         Server TelnetからのTelnet通知を受信するまでUser Telnetが
         ローカルに出力を廃棄するという廃棄方式はすべて、Server Telnetが
         期待される通知の送信に失敗した場合に、ユーザーが手動で通常の
         出力に復旧できる方法を用意すべきである(SHOULD)。


Internet Engineering Task Force                                [Page 26]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


   3.5.  Telnetの要件の概要


                                                 |        | | | |S| |
                                                 |        | | | |H| |
                                                 |        | | | |O|M|
                                                 |        | |S| |U|U|
                                                 |        | |H| |L|S|
                                                 |        |M|O| |D|T|脚
                                                 |        |U|U|M| | |
                                                 |        |S|L|A|N|N|
                                                 |        |T|D|Y|O|O|注
機  能                                           | ｾｸｼｮﾝ  | | | |T|T| 
-------------------------------------------------|--------|-|-|-|-|-|--
                                                 |        | | | | | |
オプションのネゴシエーション                     |3.2.1   |x| | | | |
  ネゴシエーションのループ回避                   |3.2.1   |x| | | | |
  未サポートのオプションを拒否                   |3.2.1   |x| | | | |
  接続上でいつでもネゴシエーションできる         |3.2.1   | |x| | | |
  ﾈｺﾞｼｴｰｼｮﾝが失敗したらﾃﾞﾌｫﾙﾄのNVTに移行         |3.2.1   |x| | | | |
  Terminal-Typeｵﾌﾟｼｮﾝでは公式な端末ﾀｲﾌﾟ名を送信  |3.2.8   |x| | | | |
  Terminal-Typeｵﾌﾟｼｮﾝ受信者はあらゆる名前を受理  |3.2.8   |x| | | | |
  Binary、Suppress Go Aheadオプションを実装      |3.3.3   |x| | | | |
  Echo、Status、EOL、Extended Options Listｵﾌﾟｼｮﾝ |3.3.3   | |x| | | |
  適切な場合Window Sizeオプションを実装          |3.3.3   | |x| | | |
  サーバーからモードのネゴシエーションを開始     |3.3.4   | |x| | | |
  ﾕｰｻﾞｰがﾈｺﾞｼｴｰｼｮﾝ開始を有効/無効にできる        |3.3.4   | |x| | | |
                                                 |        | | | | | |
Go-Ahead機能                                     |        | | | | | |
  GAを送信しないｻｰﾊﾞｰがSUPPRESS-GAｵﾌﾟｼｮﾝをﾈｺﾞｼｴｰﾄ|3.2.2   |x| | | | |
  User/Server TelnetがSUPPRESS-GAｵﾌﾟｼｮﾝを受理    |3.2.2   |x| | | | |
  User TelnetがGAを無視                          |3.2.2   | | |x| | |
                                                 |        | | | | | |
制御機能                                         |        | | | | | |
  SE NOP DM IP AO AYT SBをサポート               |3.2.3   |x| | | | |
  EOR EC EL Breakをサポート                      |3.2.3   | | |x| | |
  未サポートの制御機能を無視                     |3.2.3   |x| | | | |
  緊急ﾃﾞｰﾀ受信時User/ServerはDMまでのﾃﾞｰﾀを破棄  |3.2.4   |x| | | | |
  User TelnetがIP、AO、AYTの後に"Synch"送信      |3.2.4   | |x| | | |
  Server TelnetがIPに対してSynchで応答           |3.2.4   | | |x| | |
  Server TelnetがAOに対してSynchで応答           |3.2.4   |x| | | | |
  User TelnetがIP送信時に出力を廃棄可能          |3.2.4   | |x| | | |
                                                 |        | | | | | |
エンコーディング                                 |        | | | | | |
  NVTモードで最上位ビットを設定して送信          |3.2.5   | | | |x| |
  最上位ビットをパリティビットとして送信         |3.2.5   | | | | |x|
  最上位ﾋﾞｯﾄをｱﾌﾟﾘｹｰｼｮﾝに渡すならBinaryをﾈｺﾞｼｴｰﾄ |3.2.5   | |x| | | |
  IACをﾃﾞｰﾀﾊﾞｲﾄとして送信する場合は常に二つ続ける|3.2.6   |x| | | | |


Internet Engineering Task Force                                [Page 27]


RFC1123                  REMOTE LOGIN -- TELNET             October 1989


  ﾊﾞｲﾅﾘｰﾓｰﾄﾞでIACﾃﾞｰﾀﾊﾞｲﾄを送信する時は二つ続ける|3.2.7   |x| | | | |
  バイナリーモードでもTelnetコマンドには従う     |3.2.7   |x| | | | |
  バイナリーモードで行末処理、CR NULへの置き換え |3.2.7   | | | | |x|
                                                 |        | | | | | |
行末に関する規定                                 |        | | | | | |
  Serverの行末はローカルの行末と同じ             |3.3.1   |x| | | | |
  ASCIIのServerが行末としてCR LFまたはCR NUL受理 |3.3.1   |x| | | | |
  User TelnetはCR LF、CR NUL、LFのどれでも送信可 |3.3.1   |x| | | | |
    ASCIIのユーザーがCR LF/CR NULを選択可能      |3.3.1   | |x| | | |
    User TelnetのデフォルトモードはCR LF         |3.3.1   | |x| | | |
  非対話型の利用では、行末としてCR LFを使用      |3.3.1   |x| | | | |
                                                 |        | | | | | |
User Telnetのインターフェース                    |        | | | | | |
  あらゆる7ビット文字を送信、受信                |3.4.1   | |x| | | |
  ﾛｰｶﾙなｵﾍﾟﾚｰﾃｨﾝｸﾞｼｽﾃﾑの解釈を迂回               |3.4.1   | |x| | | |
  エスケープ文字                                 |3.4.1   |x| | | | |
     エスケープ文字をユーザーが設定可能          |3.4.1   | |x| | | |
  8ビット値を入力するためのエスケープ            |3.4.1   | | |x| | |
  IP、AO、AYTを入力可能                          |3.4.2   |x| | | | |
  EC、EL、Breakを入力可能                        |3.4.2   | |x| | | |
  TCP接続のエラーをユーザーに通知                |3.4.3   | |x| | | |
  任意のデフォルト以外の接続ポート               |3.4.4   | |x| | | |
  IP送信時に出力が廃棄されるかを指定可能         |3.4.5   | |x| | | |
  出力モードを手動で復旧可能                     |3.4.5   | |x| | | |
                                                 |        | | | | | |


Internet Engineering Task Force                                [Page 28]


RFC1123                   FILE TRANSFER -- FTP              October 1989


4.  ファイル転送

   4.1  FTP(ファイルトランスファープロトコル)

      4.1.1  導入

         FTP(ファイルトランスファープロトコル)は、ファイル転送で使用
         される主要なインターネット標準である。現在の仕様はRFC 959
         [FTP:1]に含まれている。

         FTPは、制御用とデータ転送用で別々のTCP接続を同時に使用する。
         FTPプロトコルは多くの機能を含むが、その一部は一般に実装されて
         いない。とは言え、FTPの各機能について、少なくとも一つは実装が
         存在する。RFC 959で定義される最小限の実装は小さすぎたため、
         ここでは若干大きな最小限の実装を定義する。

         インターネットユーザーは、不完全なFTP実装によって何年も不要な
         負担を強いられてきた。プロトコル実装者は、FTPを実装するという
         ことは小規模でささいな作業だろうという誤った意見に苦しめられて
         きた。これは誤っている。なぜなら、FTPはユーザーインターフェース
         を持ち、発生する可能性のあるさまざまな通信エラーやオペレーティング
         システムのエラーすべてに(正しく)対処しなければならず、世界中に
         ある実ファイルシステムの膨大な多様性に対応しなければならない
         からである。

      4.1.2.  プロトコルのウォークスルー

         4.1.2.1  LOCALタイプ: RFC 959 セクション3.1.1.4

            FTPプログラムは、TYPE I("IMAGE"タイプまたはバイナリータイプ)
            と同様にTYPE L 8(論理バイトサイズが8の"LOCAL"タイプ)も
            サポートしなければならない(MUST)。メモリが(8の倍数では
            ない)mビットワードで構成された機器は、TYPE L mもサポート
            してよい(MAY)。

            【 議論 】
                 コマンド"TYPE L 8"は、メモリが(例えば)36ビットワード
                 構成の機器と8ビットバイト構成の機器の間でバイナリー
                 データを転送するためにしばしば必要とされる。8ビット
                 バイト構成の機器の場合、TYPE L 8はIMAGEと等価である。

                 2台のmビットワード構成の機器間で片側からもう片側に
                 ネイティブモードのバイナリーファイル転送が正しく
                 行われることを保証するため、それぞれの機器上のFTP
                 プログラムに対して"TYPE L m"が指定されることがある。
                 しかし、このコマンドはそれらの機器に対して"TYPE I"
                 と同じ効果を持つべきである。


Internet Engineering Task Force                                [Page 29]


RFC1123                   FILE TRANSFER -- FTP              October 1989


         4.1.2.2  Telnetのフォーマット制御: RFC 959 セクション3.1.1.5.2

            TYPE NとTYPE Tを区別しないホストは、TYPE Nと同一のTYPE Tを
            実装すべきである(SHOULD)。

            【 議論 】
                 この要件は、TYPE NとTYPE Tを区別するホストとの相互運用
                 を容易にするはずである。

                 多くのホストは、テキストファイルを内部的にASCII文字列
                 として表現し、ファイルが印刷される際には、埋め込み
                 ASCIIフォーマット制御文字(LF、BS、FF等)を使用して
                 フォーマットを制御する。そのようなホストの場合、"印刷"
                 可能なファイルと他のファイルの間に違いはない。しかし、
                 レコード単位で構造化されたファイルを使用するシステム
                 の場合、通常、印刷可能なファイル用の特殊なフォーマット
                 (例えばASAキャリッジ制御)を必要とする。後者のホストを
                 対象として、FTPはTYPE NかTYPE Tかの選択をできるように
                 している。

         4.1.2.3  ページ構造: RFC 959 セクション3.1.2.3及び付録Ⅰ

            一般に、ページ構造(page-structure)の実装は推奨されない(NOT
            RECOMMENDED)。しかし、ホストシステムが"ランダムアクセス"
            ファイル用または"データが疎ですき間のある(holey)"ファイル用
            にFTPを実装する必要がある場合、新しいプライベートFTP
            フォーマットを定義するのではなく、定義されているページ構造
            フォーマットを使用しなければならない(MUST)。

         4.1.2.4  データ構造の変換: RFC 959 セクション3.1.2

            FTPによるレコード構造(record-structure)とファイル構造(file-
            structure)の間の変換は、変換結果が対象ホスト上で有用になる
            範囲内で可逆性を持つべきである(SHOULD)。

            【 議論 】
                 RFC 959は、レコード構造とファイル構造の間で厳密な可逆性
                 を要求していたが、現実には効率性と有用性の観点からそれ
                 が除外されることもあった。そのため、この要件は緩和され
                 つつある。ファイルの転送には、二つの異なる目的がある。
                 一つは対象ホスト上でそのファイルを処理することで、もう
                 一つは単なる保存である。保存目的の場合には、厳密な可逆性
                 が重要である。処理が目的の場合、対象ホスト上に生成される
                 ファイルは、ホスト上のアプリケーションプログラムに期待
                 されるフォーマットであることが必要となる。

                 可逆性と競合する例として、各レコードが正確に80バイトの
                 データファイルを必要とするレコード指向オペレーティング
                 システムを考える。


Internet Engineering Task Force                                [Page 30]


RFC1123                   FILE TRANSFER -- FTP              October 1989


                 そのようなホスト上にファイルを処理目的で転送(STOR)する
                 際に、FTPサーバーは各行または各レコードを80バイトに
                 パディングできなければならないが、そのようなファイルを
                 後で取得したとしても厳密に可逆にはなり得ない。

         4.1.2.5  データ転送用接続の管理: RFC 959 セクション3.3

            ストリーム(stream)モードを使用するUser FTPは、各転送コマンド
            が発行される前に、PORTコマンドを送信してデフォルト以外の
            データポートを割り当てるべきである(SHOULD)。

            【 議論 】
                 この要件が必要な理由は、TCP接続がクローズされた後に両端
                 のソケットが再利用可能になるまで長い遅延があることを考慮
                 して、単一のFTPセッションの間に複数の転送をできるように
                 するためである。ストリーム以外の転送モードが使用されて
                 いる場合、転送と転送の間もデータ転送用接続をオープンの
                 ままにすることでPORTコマンドの送信を回避できる。

         4.1.2.6  PASVコマンド: RFC 959 セクション4.1.2

            Server FTPはPASVコマンドを実装しなければならない(MUST)。

            同じセッションの間に第三者を介した転送(third party 
            transfer)が複数回実行される場合、各転送コマンドの前に新しい
            PASVコマンドを発行して一意なポートの対を取得しなければ
            ならない(MUST)。

            【 実装 】
                 PASVコマンドに対する227応答のフォーマットは十分に標準化
                 されていない。具体的に、FTPクライアントは、RFC 959の
                 40ページに示されている括弧(訳注: "(h1,h2,h3,h4,p1,p2)")
                 が存在すると想定できない(実際、45ページの図3では省略
                 されている)。従って、PASV応答を解釈するUser FTP
                 プログラムは、応答を精査してホスト番号とポート番号の
                 一桁目を見つけなければならない。

                 ホスト番号h1、h2、h3、h4は応答を送信したサーバーホスト
                 のIPアドレスであり、p1、p2はPASVが割り当てたデフォルト
                 以外のデータ転送用ポートであることに注意せよ。

         4.1.2.7  LISTコマンド及びNLSTコマンド: RFC 959 セクション4.1.3

            NLSTコマンドに返されるデータは、正式なパス名の単純な一覧
            だけを含まなければならない(MUST)。そのようにすることで、
            サーバーは後に個々のファイルに対するデータ転送コマンドの
            引数としてそれらを直接使用できるようになる。

            LISTコマンドやNLSTコマンドに返されるデータは、暗黙にTYPE AN
            が使用されるべきである(SHOULD)。

Internet Engineering Task Force                                [Page 31]


RFC1123                   FILE TRANSFER -- FTP              October 1989


            ただし現行のタイプがEBCDICの場合は別で、その場合は暗黙に
            TYPE ENが使用されるべきである(SHOULD)。

            【 議論 】
                 多くのFTPクライアントは、NLSTを使用してパス名の一覧を
                 取得し、ワイルドカード指定にマッチするファイルを
                 ダウンロード(get)またはアップロード(put)するマクロ
                 コマンドをサポートしている。"複数ファイルアップロード"
                 の拡張はクライアントローカルなものだが、"複数ファイル
                 ダウンロード"はサーバーの協力が必要である。

                 LIST及びNLSTの暗黙のタイプは、既存のUser FTPとの
                 互換性、特に複数ファイル取得コマンドとの互換性を提供
                 するように設計されている。

         4.1.2.8  SITEコマンド: RFC 959 セクション4.1.3

            Server FTPは、標準外の機能に対して新しいプライベートコマンド
            を考案したり既存のコマンドを標準外のやり方で拡張するのでは
            なく、SITEコマンドを使用すべきである(SHOULD)。

         4.1.2.9  STOUコマンド: RFC 959 セクション4.1.3

            STOUコマンドは、一意に名前付けされたファイルにデータを保存
            する。Server FTPがSTOUコマンドを受信すると、転送の前に"125 
            Transfer Starting"メッセージか"150 Opening Data Connection"
            メッセージの中で実際のファイル名を返さなければならない(MUST)。
            (RFC 959に記述されている250応答コードは誤っている)。これら
            のメッセージの正確なフォーマットは、今後以下のように定義
            されるものとする。

                125 FILE: pppp
                150 FILE: pppp

            ppppは、書き込まれるファイルの一意なパス名を表現する。

         4.1.2.10  Telnetの行末コード: RFC 959の34ページ

            実装者は、制御用接続のREAD境界とTelnetの行末を意味する
            文字列の並び(CR LF)との間にどのような対応関係も想定
            してはならない(MUST NOT)。

            【 議論 】
                 従って、Server FTP(またはUser FTP)は、コマンド
                 (User FTPの場合は応答)を処理する前に、Telnetの行末
                 まで文字を読み込み続けなければならない。逆に、制御用
                 接続からREAD 1回で読み込んだものは、二つ以上のFTP
                 コマンドを含んでいるかもしれない。


Internet Engineering Task Force                                [Page 32]


RFC1123                   FILE TRANSFER -- FTP              October 1989


         4.1.2.11  FTP応答: RFC 959 セクション4.2の35ページ

            Server FTPは、制御用接続上で正しくフォーマット指定された
            応答だけを送信しなければならない(MUST)。RFC 959は(FTP仕様
            の以前のバージョンとは異なり)、"システムメッセージとして
            無作為に生成される(spontaneous)"応答メッセージに関する
            規定を含まないことに注意せよ。

            Server FTPは、RFC 959で定義される応答コードが適用可能である
            場合は必ず使用すべきである(SHOULD)。しかし、セクション4.2の
            一般的ルールに従う限り、Server FTPは必要に応じて異なる応答
            コードを使用してもよい(MAY)。応答コードを4xxにするか5xxに
            するかを実装者が選択できる場合、FTP障害が数時間後には解消
            するという何らかの妥当な見込みがあるならば、Server FTPは4xx
            (一時的障害)コードを送信すべきである(SHOULD)。

            User FTPは、手続き上の判断を行うにあたり、3桁の応答コードの
            うち最上位桁だけを使用すべきである(SHOULD)。そのようにする
            ことで、Server FTPが標準外の応答コードを使用する場合の困難さ
            が抑制される。

            User FTPは、複数行に渡る応答に対応できなければならない
            (MUST)。実装が行数に関する制限を課している状況で応答がその
            制限を超えた場合、User FTPは、例えば複数行の応答の終わりに
            達するまで超過した行を無視するなどして異常な状況を復旧させ
            なければならない(MUST)。

            User FTPは、応答コード421("サービス利用不可、制御用転送を
            クローズする")を特別に解釈すべきではない(SHOULD NOT)が、
            サーバーによる制御用接続のクローズを検知すべきである
            (SHOULD)。

            【 議論 】
                 応答ルールの厳密な準拠に失敗したサーバー実装は、FTP
                 ユーザープログラムをしばしばハングアップさせる。
                 RFC 959は、以前のFTP仕様に存在していた応答ルールの
                 あいまいさを解消しており、これに準拠しなければならない
                 ことに注意せよ。

                 一時的障害と永続的障害を区別して適切にFTP応答コードを
                 選択することは、ファイル転送クライアントデーモンをうまく
                 利用できるようにするためにも重要である。これらのプログラム
                 は、失敗した転送を再試行するか否かの判断の際に応答コード
                 に依存する。一時的エラーに対して永続的な障害コード(5xx)
                 を使用すると、これらのプログラムを不必要に断念させて
                 しまうことになる。


Internet Engineering Task Force                                [Page 33]


RFC1123                   FILE TRANSFER -- FTP              October 1989


                 応答の意味がRFC 959に示されるテキストと正確に一致する
                 場合、RFC 959のテキストをそのまま使用することで統一性
                 が向上する。しかし、Server FTPの実装者は、それが適切な
                 場合、固有のシステム依存情報を伝える応答テキストを選択
                 するよう推奨される。

         4.1.2.12  接続: RFC 959 セクション5.2

            RFC 959のこのセクションの第2段落に含まれる"and the port used"
            という表記は誤り(旧式)であり、無視されるべきである。(訳注: 
            対象の文は"The direction of the transfer and the port used 
            will be determined by the FTP service command.")。

            マルチホームなサーバーホストでは、デフォルトのデータ転送用
            接続ポート(L-1)は、対応するポートLへの制御用接続と同じローカル
            IPアドレスに関連付けられなければならない(MUST)。

            User FTPは、FTP制御用接続上でSYNCHとIP以外のいかなるTelnet
            制御も送信してはならない(MUST NOT)。特に、制御用接続上で
            Telnetオプションのネゴシエートを試みてはならない(MUST NOT)。
            しかし、Server FTPは、Telnetネゴシエーションを受理し拒否
            する(つまりDONT/WONTを送信する)機能を持たなければならない
            (MUST)。

            【 議論 】
                 RFCは、"Server-及びUser-のプロセスは[制御用接続上
                 で]Telnetプロトコルの規定に従うべきである"と述べている
                 が、これはTelnetオプションのネゴシエーションが使用
                 できることを意図するものではない。

         4.1.2.13  最小限の実装: RFC 959 セクション5.1

            以下に示すコマンドとオプションは、すべてのServer FTP及び
            User FTPにサポートされなければならない(MUST)。ただし、基盤
            となるファイルシステムまたはオペレーティングシステムが特定
            のコマンドを許可しないかサポートしない場合は例外とする。

                 タイプ: ASCII Non-print、IMAGE、LOCAL 8
                 モード: ストリーム
                 データ構造: ファイル、レコード(*)
                 コマンド:
                    USER、PASS、ACCT、
                    PORT、PASV、
                    TYPE、MODE、STRU、
                    RETR、STOR、APPE、
                    RNFR、RNTO、DELE、
                    CWD、 CDUP、RMD、 MKD、 PWD、


Internet Engineering Task Force                                [Page 34]


RFC1123                   FILE TRANSFER -- FTP              October 1989


                    LIST、NLST、
                    SYST、STAT、
                    HELP、NOOP、QUIT

            (*)レコード構造は、レコード構造をサポートするファイルシステム
            のホストに対してのみ要求される(REQUIRED)。

            【 議論 】
                 ベンダーは、プロトコルのより大きいサブセットを実装する
                 よう推奨される。例えば、プロトコルには重要なロバスト性
                 に関する機能(例えばRestart、ABOR、ブロックモード)が存在
                 し、実装されれば一部のインターネットユーザーへの助けと
                 なるのだが、広く実装されてはいない。

                 レコード構造を持たないファイルシステムのホストであっても、
                 STRU Rでファイルを受信してよい。その場合、バイトストリーム
                 が文字通り記憶(recording)される。

      4.1.3  固有の課題

         4.1.3.1  標準外のコマンド名

            FTPは"実験的"コマンドを許容しており、それらの名前は"X"で
            始まる。それらのコマンドが後に標準として採用されても、"X"
            形式を使用する実装が依然として存在し続ける場合がある。
            現在、以下に示すディレクトリに関連するコマンドがこれに
            当てはまっている。

                RFC 959    "実験的"

                  MKD        XMKD
                  RMD        XRMD
                  PWD        XPWD
                  CDUP       XCUP
                  CWD        XCWD

            すべてのFTP実装は、コマンド検索テーブル内に追加エントリーを
            設定し、両方のコマンドを単純に同等と見なすことにより、
            どちらの形式も認識すべきである(SHOULD)。

            【 実装 】
                 "X"形式しかサポートしないサーバーにUser FTPがアクセス
                 できるようにする方法として、モード切替を実装するか、
                 あるいは上記のRFC 959形式コマンドの一つが500または502
                 の応答コードで拒否された場合は実験的形式を試み、他の
                 応答はユーザーに渡すという手順を自動的に使用する等が
                 考えられる。


Internet Engineering Task Force                                [Page 35]


RFC1123                   FILE TRANSFER -- FTP              October 1989


         4.1.3.2  アイドルタイムアウト

            Server FTPはアイドルタイムアウトを持つべきである(SHOULD)。
            これは、サーバーが長時間活動していない(言い換えると進行中
            のコマンドのやりとりやデータ転送が存在しない)場合に、プロセス
            を停止して制御用接続をクローズするものである。アイドル
            タイムアウトの時間は設定可能であるべきで(SHOULD)、デフォルト
            は少なくとも5分とすべきである。

            クライアントFTPプロセス(RFC 959の"User-PI")は、プログラム
            から起動された場合にのみ応答のタイムアウトを必要とする。

            【 議論 】
                 タイムアウトが設定されない場合、対応するクライアント
                 が制御用接続をクローズせずにクラッシュすると、Server 
                 FTPプロセスは無期限に保留のままとなってしまうかも
                 しれない。

         4.1.3.3  データ転送と制御の同時並列性

            【 議論 】
                 FTPの設計者の意図は、データ転送が進行中の間、ユーザー
                 はいつでもSTATコマンドを送信でき、Server FTPは直ちに
                 状態(例えば転送済みバイト数)を返すようにすべきという
                 ことであった。同様に、データ転送中はいつでもABOR
                 コマンドが使えるべきである。

                 残念なことに、一部の小型機器のオペレーティングシステム
                 はそのような並列プログラミングを困難にしている。それ
                 とは別に、一部の実装者は最小限の解決策を模索している。
                 その結果、一部のFTP実装ではデータ転送用接続と制御用
                 接続を同時に使用できない。たとえそのような最小限の
                 サーバーであっても、データ転送中に到着するSTATまたは
                 ABORコマンドを受理し、その処理を保留する準備ができて
                 いなければならない。

         4.1.3.4  FTPの再開の仕組み

            RFC 959の40～41ページにある110応答の説明は誤っている。
            正しい記述は以下の通りである。制御用接続上で受信側FTP
            からUser FTPに向けて送信される再開応答メッセージは以下
            のフォーマットを持つ。

                110 MARK ssss = rrrr

            ここで、


Internet Engineering Task Force                                [Page 36]


RFC1123                   FILE TRANSFER -- FTP              October 1989


            ・   ssssは、データストリームにおいて再開マーカー(Restart 
                 Marker)内に現れるテキスト文字列で、送信側ファイル
                 システムの位置をエンコードしたものである。

            ・   rrrrは受信側ファイルシステムにおける対応する位置を
                 エンコードしたものである。

            エンコーディングは特定のファイルシステム及びネットワーク
            実装に固有のものであり、常に送信側か受信側のどちらかの
            システムによって生成され、また解釈もされる。

            再開を実装するFTPがデータストリームで再開マーカーを受信した
            場合、対応する位置rrrrをエンコードする前に、再開マーカーまでの
            データを強制的に不揮発性の記憶装置に書き込むべきである(SHOULD)。
            再開マーカーを送信するFTPは、110応答がデータストリーム転送と
            同期して返されるものと想定してはならない(MUST NOT)。言い
            換えると、110応答を待って追加のデータ送信を控えてはならない。

            転送再開時に発生するエラーに関して、ここで二つの新しい応答
            コードを定義する。

              554 Requested action not taken: invalid REST parameter.
                  (リクエストされた処理は実行不可: 無効なRESTパラメーター)

                 554応答は、RESTコマンドに続くFTPサービスコマンドに対して
                 返される場合があるものである。この応答は、Server FTP上の
                 既存ファイルをRESTで指定された通りに再配置できない
                 ことを示す。

              555 Requested action not taken: type or stru mismatch.
                  (リクエストされた処理は実行不可: タイプまたは構造が不整合)

                 555応答は、APPEコマンドまたはRESTコマンドに続くあらゆる
                 FTPサービスコマンドに対して返される場合があるものである。
                 この応答は、現在のパラメーター(タイプまたは構造)と既存の
                 ファイルの属性との間に何らかの不整合があることを示す。

            【 議論 】
                 FTPの再開の仕組みは、データストリーム内に再開マーカー
                 を組み込めるように、ブロック(Block)モードまたは圧縮
                 (Compressed)モードを使用したデータ転送を要求すること
                 に注意せよ。再開マーカーの頻度は低くできるだろう。

                 再開マーカーはデータストリーム内の場所をマークするが、
                 受信者は、データを不揮発性の記憶装置に保存する際に何らか
                 のデータの変換を実行しているかもしれない。一般に、受信者
                 のエンコーディングは、FTPデータストリームのどの場所から
                 でもこの変換を再開できるようにするために必要なあらゆる
                 状態情報を含まなければならない。


Internet Engineering Task Force                                [Page 37]


RFC1123                   FILE TRANSFER -- FTP              October 1989


                 例えばTYPE Aの転送の場合、一部の受信ホストはCR LFの並び
                 をディスク上では単一のLF文字に変換する。再開マーカー
                 が偶然CRとLFの間に挿入される場合、受信者は、"CRは認識
                 されたが破棄された"状態でデータ転送を再開する必要がある
                 ことを織り込んでrrrrをエンコードしなければならない。

                 再開マーカーは、データのタイプにかかわらず印字可能な
                 ASCII文字列としてエンコードされる必要があることに注意
                 せよ。

                 RFC 959は、再開情報は"ユーザーに"返されるものだと
                 述べている。これは文字通り受け取られるべきではない。
                 一般に、User FTPは再開情報(ssss,rrrr)を例えば再開制御
                 ファイルに追加するなどして不揮発性の記憶装置に保存
                 すべきである。再開制御ファイルは、転送が最初に開始
                 される際に空のものが生成され、転送が正常に終了した
                 段階で自動的に削除されるべきである。このファイルは、
                 転送中のファイル名とリモートホスト名から容易に導出
                 できる方法で作成された名前を持つことが推奨される。
                 これは、多くのテキストエディターが"バックアップ"
                 ファイルに名前を付ける際に使用される方法と似ている。

                 FTPの再開が使用される状況は以下の三つである。

                 (1)  User FTPからServer FTPへの転送

                      User FTPは、再開マーカー<ssss>をデータストリーム
                      内の都合の良い場所に配置する。Server FTPは、再開
                      マーカーを受信すると、再開マーカーの前にある
                      全データをディスクに書き込み、ファイルシステム
                      の位置とデータ変換状況をrrrrとしてエンコードし、
                      制御接続上で"110 MARK ssss = rrrr"応答を返す。
                      User FTPは、(ssss,rrrr)の対を再開制御ファイル
                      に追加する。

                      データ転送を再開する場合、User FTPは再開制御
                      ファイルから最後の(ssss,rrrr)の対を取得し、ssss
                      を使用して自身のローカルファイルシステムとデータ
                      変換状況を再配置し、"REST rrrr"コマンドをServer 
                      FTPに送信する。

                 (2)  Server FTPからUser FTPへの転送

                      Server FTPは、再開マーカー<ssss>をデータストリーム
                      内の都合の良い場所に配置する。User FTPは、再開
                      マーカーを受信すると、再開マーカーの前にある
                      全データをディスクに書き込み、ファイルシステムの
                      位置とデータ変換状況をrrrrとしてエンコードし、
                      (rrrr,ssss)の対を再開制御ファイルに追加する。


Internet Engineering Task Force                                [Page 38]


RFC1123                   FILE TRANSFER -- FTP              October 1989


                      データ転送を再開する場合、User FTPは再開制御
                      ファイルから最後の(rrrr,ssss)の対を取得し、rrrr
                      を使用して自身のローカルファイルシステムとデータ
                      変換状況を再配置し、"REST ssss"コマンドをServer 
                      FTPに送信する。

                 (3)  Server FTPからServer FTPへの転送
                      (第三者を介した転送)

                      送信側Server FTPは、再開マーカー<ssss>をデータ
                      ストリーム内の都合の良い場所に配置する。受信側
                      Server FTPは、再開マーカーを受信すると、再開
                      マーカーの前にある全データをディスクに書き込み、
                      ファイルシステムの位置とデータ変換状況をrrrr
                      としてエンコードし、User FTPへの制御接続上で
                      "110 MARK ssss = rrrr"応答を送信する。User FTP
                      は、(ssss,rrrr)の対を再開制御ファイルに追加
                      する。

                      データ転送を再開する場合、User FTPは再開制御
                      ファイルから最後の(ssss,rrrr)の対を取得し、送信
                      側Server FTPには"REST ssss"を送信し、受信側Server 
                      FTPには"REST rrrr"を送信する。


      4.1.4  FTP/ユーザー間のインターフェース

         本セクションは、User FTPプログラムのユーザーインターフェース
         について議論する。

         4.1.4.1  パス名の指定

            FTPは異機種が混在する環境での使用を想定しているため、User 
            FTP実装は、リモートのパス名として任意の文字列をサポート
            しなければならない(MUST)。これにより、リモートのパス名及び
            内容はローカルなオペレーティングシステムの規定に制約されなく
            なる。

            【 議論 】
                 特に、リモートのパス名は任意の長さにでき、すべての印字
                 可能ASCII文字と同様に空白(0x20)も許容されなければ
                 ならない。RFC 959は、パス名としてCRまたはLFを除く
                 あらゆる7ビットASCII文字を許容している。


Internet Engineering Task Force                                [Page 39]


RFC1123                   FILE TRANSFER -- FTP              October 1989


         4.1.4.2  "QUOTE"コマンド

            User FTPプログラムは、任意の文字列をサーバーに渡し、
            得られた応答メッセージすべてをユーザーに表示する"QUOTE"
            コマンドを実装しなければならない(MUST)。

            "QUOTE"コマンドを有用なものにするため、User FTPは、ユーザー
            が入力したコマンドをすべて保存しておきデータ転送が開始された
            時にだけそれを送信するのではなく、ユーザーがコマンドを入力
            した時点で制御コマンドをサーバーに送信すべきである(SHOULD)。

            【 議論 】
                 "QUOTE"コマンドは、システム固有のコマンド(例えばSITE
                 やALLO)を要求するサーバーにユーザーがアクセスしたり、
                 User FTPが実装していない新しいまたは任意の機能を起動
                 したりするために不可欠なものである。例えば、印刷ファイル
                 の明示的な区別を要求するホストに印刷ファイルを送信する
                 際に、たとえUser FTPがTYPEの違いを認識しなくても、
                 "QUOTE"を使用して"TYPE A T"と指定することができる。

         4.1.4.3  ユーザーへの応答表示

            User FTPは、受信したエラー応答メッセージすべてにおいて、受信
            した全文をユーザーに表示すべきである(SHOULD)。また、問題の
            診断のために、送信するコマンドすべてと受信した全文及び応答
            コードを表示する"詳細表示(verbose)"モードを持つべきである
            (SHOULD)。

         4.1.4.4  同期の維持

            User FTPの状態マシンは、応答メッセージの欠落や予期しない
            応答メッセージの到着を許容してでもサーバーとのコマンド同期
            を維持すべきである(SHOULD)。


Internet Engineering Task Force                                [Page 40]


RFC1123                   FILE TRANSFER -- FTP              October 1989


      4.1.5   FTPの要件の概要

                                           |               | | | |S| |
                                           |               | | | |H| |
                                           |               | | | |O|M|
                                           |               | |S| |U|U|
                                           |               | |H| |L|S|
                                           |               |M|O| |D|T|脚
                                           |               |U|U|M| | |
                                           |               |S|L|A|N|N|
                                           |               |T|D|Y|O|O|注
機  能                                     | セクション    | | | |T|T| 
-------------------------------------------|---------------|-|-|-|-|-|--
TYPE Nと同じならTYPE Tを実装               |4.1.2.2        | |x| | | |
可能ならファイル/レコード変換を可逆にする  |4.1.2.4        | |x| | | |
User FTPはｽﾄﾘｰﾑﾓｰﾄﾞでPORTｺﾏﾝﾄﾞを送信       |4.1.2.5        | |x| | | |
Server FTPはPASVを実装                     |4.1.2.6        |x| | | | |
  転送ごとにPASV発行                       |4.1.2.6        |x| | | | |
NLST応答をRETRコマンドで利用しやすくする   |4.1.2.7        |x| | | | |
LISTとNLSTで暗黙のTYPE AN使用              |4.1.2.7        | |x| | | |
標準外の機能に対してSITEコマンド使用       |4.1.2.8        | |x| | | |
STOUｺﾏﾝﾄﾞはｻｰﾊﾞｰが指定したﾊﾟｽ名を返す      |4.1.2.9        |x| | | | |
制御用接続でTCPのREAD境界を使用            |4.1.2.10       | | | | |x|
                                           |               | | | | | |
Server FTPは正しい応答ﾌｫｰﾏｯﾄだけを送信     |4.1.2.11       |x| | | | |
Server FTPは適用可能なら定義済応答ｺｰﾄﾞ使用 |4.1.2.11       | |x| | | |
  セクション4.2に従う新しい応答コード      |4.1.2.11       | | |x| | |
User FTPは応答の最上位桁だけを使用         |4.1.2.11       | |x| | | |
User FTPは複数行に渡る応答に対応           |4.1.2.11       |x| | | | |
User FTPは421応答を特別に扱う              |4.1.2.11       | | | |x| |
                                           |               | | | | | |
ﾃﾞﾌｫﾙﾄのﾃﾞｰﾀ転送ﾎﾟｰﾄは制御用と同じIPｱﾄﾞﾚｽ  |4.1.2.12       |x| | | | |
User FTPがSYNCH、IP以外のTelnetｺﾏﾝﾄﾞ送信   |4.1.2.12       | | | | |x|
User FTPがTelnetオプションをネゴシエート   |4.1.2.12       | | | | |x|
Server FTPはTelnetオプションに対応         |4.1.2.12       |x| | | | |
"実験的"ディレクトリ関連コマンドに対応     |4.1.3.1        | |x| | | |
Server FTPがアイドルタイムアウト機能を持つ |4.1.3.2        | |x| | | |
    アイドルタイムアウトの時間は設定可能   |4.1.3.2        | |x| | | |
受信側は再開ﾏｰｶｰをﾃﾞｰﾀ受信中断地点とする   |4.1.3.4        | |x| | | |
送信側は110応答とﾃﾞｰﾀが同期していると想定  |4.1.3.4        | | | | |x|
                                           |               | | | | | |
サポートするタイプ:                        |               | | | | | |
  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
  ASCII - Telnet (AT) -- ANと同じ場合      |4.1.2.2        | |x| | | |
  ASCII - キャリッジ制御 (AC)              |959 3.1.1.5.2  | | |x| | |
  EBCDIC - (あらゆる形式)                  |959 3.1.1.2    | | |x| | |
  IMAGE                                    |4.1.2.1        |x| | | | |
  LOCAL 8                                  |4.1.2.1        |x| | | | |


Internet Engineering Task Force                                [Page 41]


RFC1123                   FILE TRANSFER -- FTP              October 1989


  LOCAL m                                  |4.1.2.1        | | |x| | |2
                                           |               | | | | | |
サポートするモード:                        |               | | | | | |
  ストリーム                               |4.1.2.13       |x| | | | |
  ブロック                                 |959 3.4.2      | | |x| | |
                                           |               | | | | | |
サポートするデータ構造                     |               | | | | | |
  ファイル                                 |4.1.2.13       |x| | | | |
  レコード                                 |4.1.2.13       |x| | | | |3
  ページ                                   |4.1.2.3        | | | |x| |
                                           |               | | | | | |
サポートするコマンド:                      |               | | | | | |
  USER                                     |4.1.2.13       |x| | | | |
  PASS                                     |4.1.2.13       |x| | | | |
  ACCT                                     |4.1.2.13       |x| | | | |
  CWD                                      |4.1.2.13       |x| | | | |
  CDUP                                     |4.1.2.13       |x| | | | |
  SMNT                                     |959 5.3.1      | | |x| | |
  REIN                                     |959 5.3.1      | | |x| | |
  QUIT                                     |4.1.2.13       |x| | | | |
                                           |               | | | | | |
  PORT                                     |4.1.2.13       |x| | | | |
  PASV                                     |4.1.2.6        |x| | | | |
  TYPE                                     |4.1.2.13       |x| | | | |1
  STRU                                     |4.1.2.13       |x| | | | |1
  MODE                                     |4.1.2.13       |x| | | | |1
                                           |               | | | | | |
  RETR                                     |4.1.2.13       |x| | | | |
  STOR                                     |4.1.2.13       |x| | | | |
  STOU                                     |959 5.3.1      | | |x| | |
  APPE                                     |4.1.2.13       |x| | | | |
  ALLO                                     |959 5.3.1      | | |x| | |
  REST                                     |959 5.3.1      | | |x| | |
  RNFR                                     |4.1.2.13       |x| | | | |
  RNTO                                     |4.1.2.13       |x| | | | |
  ABOR                                     |959 5.3.1      | | |x| | |
  DELE                                     |4.1.2.13       |x| | | | |
  RMD                                      |4.1.2.13       |x| | | | |
  MKD                                      |4.1.2.13       |x| | | | |
  PWD                                      |4.1.2.13       |x| | | | |
  LIST                                     |4.1.2.13       |x| | | | |
  NLST                                     |4.1.2.13       |x| | | | |
  SITE                                     |4.1.2.8        | | |x| | |
  STAT                                     |4.1.2.13       |x| | | | |
  SYST                                     |4.1.2.13       |x| | | | |
  HELP                                     |4.1.2.13       |x| | | | |
  NOOP                                     |4.1.2.13       |x| | | | |
                                           |               | | | | | |


Internet Engineering Task Force                                [Page 42]


RFC1123                   FILE TRANSFER -- FTP              October 1989


ユーザーインターフェース:                  |               | | | | | |
  任意の文字列のパス名                     |4.1.4.1        |x| | | | |
  "QUOTE"コマンドの実装                    |4.1.4.2        |x| | | | |
  制御コマンドを直ちに転送                 |4.1.4.2        | |x| | | |
  エラーメッセージをユーザーに表示         |4.1.4.3        | |x| | | |
    詳細表示モードを持つ                   |4.1.4.3        | |x| | | |
  サーバーとの同期の維持                   |4.1.4.4        | |x| | | |

脚注:

(1)  本文書の前の部分で、この値に関して述べられた内容を含む

(2)  mはメモリワードのビット数

(3)  レコード構造のファイルシステムを持つホストに対する要求であり、
     他のホストの場合は任意


Internet Engineering Task Force                                [Page 43]


RFC1123                  FILE TRANSFER -- TFTP              October 1989


   4.2  TFTP(トリビアルファイルトランスファープロトコル)

      4.2.1  導入

         TFTP(トリビアルファイルトランスファープロトコル)はRFC 783
         [TFTP:1]で定義されている。

         TFTPは、stop-and-wait方式の単純な確認応答を使用することで、
         UDPをトランスポートプロトコルとして使用しながらも信頼性の
         ある配送を提供する。TFTPは単一の512オクテットセグメントの
         実効ウインドウしか持たないので、遅延×帯域の積が小さいパス上
         でしか良好なパフォーマンスを提供できない。TFTPファイル
         インターフェースは非常に簡単なもので、アクセス制御や
         セキュリティ機能は提供しない。

         TFTPはEPROM内に容易に実装されるほど十分単純で小さいので、その
         最も重要な適用例は、ローカルネットワーク上でホストをブート
         させることである[BOOT:1, BOOT:2]。ベンダーには、ブートにおける
         TFTPの使用をサポートするよう勧告する。

      4.2.2  プロトコルのウォークスルー

         TFTP仕様[TFTP:1]は議論の余地を残す形(open style)で書かれて
         おり、プロトコルの多くの部分を完全には規定していない。

         4.2.2.1  転送モード: RFC 783の3ページ

            転送モード"mail"はサポートされるべきではない(SHOULD NOT)。

         4.2.2.2  UDPヘッダー: RFC 783の17ページ

            UDPヘッダーのデータグラム長(Length)フィールドは誤って定義
            されている。データグラム長はUDPヘッダー長(8)を含む。(訳注: 
            該当箇所は"Number of bytes in packet after Datagram header")。

      4.2.3  固有の問題

         4.2.3.1  SAS(Sorcerer's Apprentice Syndrome)

            プロトコル仕様には、"SAS(Sorcerer's Apprentice Syndrome)"
            として知られる深刻なバグがある。このバグが転送の誤りを
            引き起こすことはないが(転送が完了したならファイルは常に
            正しく転送されている)、過度な再送を生じさせる可能性があり、
            それによって転送のタイムアウトが発生するかもしれない。

            実装は、この問題に対する修正を含まなければならない(MUST)。
            具体的に、送信者(DATAパケット生成側)は、重複ACKを受信した
            際に重複ACKが指定するDATAパケットを絶対に再送しては
            ならない。


Internet Engineering Task Force                                [Page 44]


RFC1123                  FILE TRANSFER -- TFTP              October 1989


            【 議論 】
                 このバグは、どちらか片方が古い重複データグラムを受信
                 した際に、重複データグラムが指定するデータグラムを
                 再送するというプロトコルルールによって引き起こされる。
                 ネットワーク内でパケットに遅延が生じ、どちらか片方が
                 タイムアウトしてパケットが再送された後に遅延した
                 パケットが正しく配送された場合、応答の重複したコピー
                 が生成される。対向側がこの重複した応答に重複したデータ
                 グラムで応答すると、転送の残り期間、(データグラムが
                 消失して繰り返しが中断しない限り)各データグラムは重複
                 して送信されるようになる。更に悪いことに、遅延は大抵
                 ふくそうによって引き起こされるので、この重複した転送は
                 更なるふくそうを生じさせ、より多くのパケットが遅延する
                 という結果につながる。

                 以下の例は、この問題を明確にする助けとなるだろう。

                     TFTP A                  TFTP B

                 (1)  ACK X-1 受信
                      DATA X 送信
                 (2)                          DATA X 受信
                                              ACK X 送信
                        (ACK Xがネットワーク内で遅延し、
                         Aがタイムアウトする)
                 (3)  DATA X 再送

                 (4)                          DATA X 再度受信
                                              ACK X 再度送信
                 (5)  (遅延した)ACK X受信
                      DATA X+1 送信
                 (6)                          DATA X+1 受信
                                              ACK X+1 送信
                 (7)  ACK X 再度受信
                      DATA X+1 再度送信
                 (8)                          DATA X+1 再度受信
                                              ACK X+1 再度送信
                 (9)  ACK X+1 受信
                      DATA X+2 送信
                 (10)                         DATA X+2 受信
                                              ACK X+2 送信
                 (11) ACK X+1 再度受信
                      DATA X+2 再度送信
                 (12)                         DATA X+2 再度受信
                                              ACK X+2 再度送信


Internet Engineering Task Force                                [Page 45]


RFC1123                  FILE TRANSFER -- TFTP              October 1989


                 遅延したACKが到着すると、プロトコルは、以後の全パケット
                 を重複して送信するように収束する((5)～(8)及び(9)～(12))
                 ことに注目せよ。この問題の原因は、どちらか片方がタイム
                 アウトすることではなく、両方の側が重複パケットを受信
                 した際に、重複パケットが指定するパケットを再送すること
                 にある。

                 修正策は、上記に示した再送ループを中断することである。
                 これはTCPの振る舞いに似ている。その場合、再送ACKは
                 いかなる動作も決して引き起こさなくなるので、受信側は
                 再送タイマーを取り除くことができる。TFTPがブート
                 プログラムの中で使用されているような場合、この簡略化
                 は有益である。受信側にタイマーを残しても構わない。
                 それを利用することで、ネットワーク内で本当に失われた
                 ACKを再送ACKが置き換えられれば有用だろう。もちろん、
                 送信側は依然として再送タイマーが必要である。

         4.2.3.2  タイムアウトアルゴリズム

            TFTP実装は、適応タイムアウトを使用しなければならない(MUST)。

            【 実装 】
                 TCPの再送アルゴリズムは、作業に役立つ基礎を提供する。
                 少なくとも、再送タイムアウトの指数的バックオフは必要
                 である。

         4.2.3.3  拡張

            付加的な転送モードや(パスワード付きの)安全な動作モード等を
            含むさまざまな標準外の拡張がTFTPに行われてきた。しかし、その
            どれもが標準化されていない。

         4.2.3.4  アクセス制御

            TFTPサーバー実装は、TFTP処理でどのようなパス名が許容されるか
            について、何らかの設定可能なアクセス制御を含むべきである
            (SHOULD)。

         4.2.3.5  ブロードキャストリクエスト

            ブロードキャストアドレスに宛てられたTFTPリクエストは、黙って
            無視されるべきである(SHOULD)。

            【 議論 】
                 TFTPのアクセス制御機能は脆弱なので、ランダムなネット
                 ワークに対するTFTPリクエストのブロードキャストは、重大
                 なセキュリティホールを生じさせる可能性がある。


Internet Engineering Task Force                                [Page 46]


RFC1123                  FILE TRANSFER -- TFTP              October 1989


      4.2.4  TFTPの要件の概要

                                                 |        | | | |S| |
                                                 |        | | | |H| |
                                                 |        | | | |O|M|
                                                 |        | |S| |U|U|
                                                 |        | |H| |L|S|
                                                 |        |M|O| |D|T|脚
                                                 |        |U|U|M| | |
                                                 |        |S|L|A|N|N|
                                                 |        |T|D|Y|O|O|注
機  能                                           | ｾｸｼｮﾝ  | | | |T|T| 
-------------------------------------------------|--------|-|-|-|-|-|--
SAS(Sorcerer's Apprentice Syndrome)の修正を含む  |4.2.3.1 |x| | | | |
転送モード:                                      |        | | | | | |
  netascii                                       |RFC 783 |x| | | | |
  octet                                          |RFC 783 |x| | | | |
  mail                                           |4.2.2.1 | | | |x| |
  拡張                                           |4.2.3.3 | | |x| | |
適応タイムアウトの使用                           |4.2.3.2 |x| | | | |
アクセス制御を設定可能                           |4.2.3.4 | |x| | | |
ブロードキャストリクエストを黙って無視           |4.2.3.5 | |x| | | |
-------------------------------------------------|--------|-|-|-|-|-|--
-------------------------------------------------|--------|-|-|-|-|-|--


Internet Engineering Task Force                                [Page 47]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


5.  電子メール -- SMTP及びRFC 822

   5.1  導入

      TCP/IPプロトコルスイートでは、RFC 822[SMTP:2]で規定された
      フォーマットの電子メールがRFC 821[SMTP:1]で定義されたSMTP
      (Simple Mail Transfer Protocol)を使用して送信される。

      SMTPは何年も変更されていないが、インターネットコミュニティはSMTP
      の使用方法に幾つかの変更を加えた。特に、DNS(Domain Name System)利用
      への転換により、アドレスフォーマットやメールルーティングに変更が
      生じた。本セクションは、読者がDNSの概念と用語に精通していること
      を前提とする。DNSの要件についてはセクション6.1で与えられる。

      RFC 822は、電子メールメッセージのインターネット標準フォーマット
      を規定している。RFC 822は古い標準のRFC 733に代わるものである。
      RFC 733は廃止されているが、一部の場所では依然として使用されて
      いる可能性がある。二つのフォーマットは、単純に番号("822"や"733")
      で参照されることもある。

      RFC 822は、SMTP以外のメール送信プロトコルを使用するインターネット
      以外のメール環境でも使用されている。また、SMTPも、インターネット
      以外の幾つかの環境にあわせて適合作業がなされてきている。
      本文書は、SMTPとRFC 822の使用に関するルールを提示するが、それは
      インターネット環境だけを対象としたものであることに注意せよ。
      これらのプロトコルを使用する他のメール環境は、それぞれ独自の
      ルールを持つ場合があることが予想される。

   5.2  プロトコルのウォークスルー

      本セクションは、RFC 821とRFC 822の両方をカバーする。

      RFC 821のSMTP仕様は明確であり、多数の例を含むため、実装者が理解
      しにくいと感じることはないはずである。本セクションは、現在の使用法
      に準拠するように単にRFC 821を更新し、その一部に注釈を加えるだけ
      である。

      RFC 822は長く密度の濃い文書で、表現力の高い構文を定義している。
      残念なことに、RFC 822の実装は不完全なものや欠陥のあるものをよく
      見かける。実際、RFC 822で規定される多数のフォーマットのほぼすべてが
      使用されているため、実装は一般にRFC 822構文のすべてを認識し、正しく
      解釈する必要がある。

      5.2.1  SMTPモデル: RFC 821 セクション2

         【 議論 】
              メールは、クライアントである"Sender-SMTP(送信側SMTP)"と、
              サーバーである"Receiver-SMTP(受信側SMTP)"の間でやりとり
              される一連のリクエスト/応答トランザクションによって送信
              される。

Internet Engineering Task Force                                [Page 48]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


              これらのトランザクションでは、(1)ヘッダーとボディで構成
              された適切なメッセージ、(2)"エンベロープ"と呼ばれるSMTPの
              送信元アドレス及び宛先アドレスが渡される。

              SMTPプログラムは、X.400のメッセージ送信エージェント(MTA)
              と似ている。いずれ、プロトコルソフトウェアにもう一つの階層
              が設定されるだろう。それはエンドユーザーにより近く、RFC 
              822メッセージヘッダーの生成や解析の責任を持つものである。
              この構成要素は、X.400では"ユーザーエージェント"として
              知られるもので、本文書でもこの用語を使用する。ユーザー
              エージェントとSMTP実装はプロトコルの異なる階層で動作する
              ため、これらの間には明確な論理的区別が存在する。しかし、
              この区別はインターネットメール実装の一般的な構造を正確に
              反映していないかもしれないことに注意せよ。多くの場合、
              "メーラー"として知られるプログラムが存在し、それがSMTPに
              加えてユーザーエージェント機能の一部を実装している。
              残りのユーザーエージェント機能は、メールの入力と閲覧で
              使用されるユーザーインターフェースに含まれる。

              SMTPエンベロープは、起点となるサイトにおいてメッセージが
              Sender-SMTPプログラムのキューに初めて入れられる際に、通常
              はユーザーエージェントによって構成される。エンベロープ
              アドレスは、メッセージヘッダーの情報や、ユーザーインター
              フェースから提供される情報(例えばbcc:リクエストを実装する
              ための情報)、ローカルな設定情報(例えばメーリングリストの
              展開)などから導出される。一般に、メッセージ配送の途中で
              ヘッダーから再度SMTPエンベロープを導出することはできない
              ため、エンベロープは、SMTPのMAIL、RCPTコマンドを使用して
              メッセージそれ自体とは別に送信される。

              RFC 821の本文は、ホストの個々のユーザーに対してメールが
              配送されると示唆している。ドメインシステムとMXリソース
              レコードを使用したメールルーティングの出現に伴い、実装者
              は、ドメインのユーザーにメールを配送しようと考えるように
              すべきである。ドメインは特定のホストであるかもしれないし、
              そうでないかもしれないが、これは、SMTPがホストツーホスト
              型のメール交換プログラムであるという事実を変更"しない"。

      5.2.2  正規化: RFC 821 セクション3.1

         Sender-SMTPがMAILコマンドやRCPTコマンドで送信するアドレスに
         含まれるドメイン名は、"正規化"されていなければならない(MUST)。
         言い換えると、Sender-SMTPが送信するものは、ドメイン名を
         含まないニックネームやドメインの省略形ではなく、完全修飾された
         プリンシパル名またはドメインリテラルでなければならない。正規化
         された名前は、ホストを直接識別するかMX名かのどちらかである。
         CNAMEにすることはできない。


Internet Engineering Task Force                                [Page 49]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


      5.2.3  VRFY、EXPNコマンド: RFC 821 セクション3.3

         Receiver-SMTPはVRFYを実装しなければならず(MUST)、EXPNを実装
         すべきである(SHOULD)(本要件はRFC 821を上書きする)。しかし、
         特定の導入状況においてはVRFYとEXPNを無効にする設定情報が
         あってもよい(MAY)。これにより、設定情報で選択されたリストに
         対してだけEXPNを無効にするといったことさえ可能かもしれない。

         VRFYコマンド用に新しい応答コードを定義する。

              252 Cannot VRFY user (e.g., info is not local), but will
                  take message for this user and attempt delivery.
                  (情報がローカルでない等の理由で)ユーザーをVRFYできない
                  が、このユーザー宛のメッセージは受け付け配送を試みる。

         【 議論 】
              SMTPユーザーと管理者は、メール配送の問題を診断するために
              これらのコマンドを日常的に使用する。メーリングリストを
              複数段階(2段階を越える場合もある)で展開する事例の増加に
              伴い、不注意によるメールループを診断するためにEXPNは
              ますます重要になってきている。一方で、EXPNは重大な
              プライバシーの露出(exposure)に留まらず、セキュリティの
              露出にすら相当すると感じる人々もいる。

      5.2.4  SEND、SOML、SAMLコマンド: RFC 821 セクション3.4

         SMTPは、ユーザーの端末にメッセージを送信するためのコマンド
         SEND、SOML、SAMLを実装してもよい(MAY)。

         【 議論 】
              MXレコードを介したメール中継の使用は、メッセージを直ちに
              ユーザーの端末に直接配送するSENDの意図と矛盾することが
              指摘されている。しかし、ユーザーの端末に直接書き込めない
              Receiver-SMTPは、SENDに続くRCPTに"251 User Not Local
              (ユーザーはローカルではない)"と応答することで、メッセージ
              生成者に配送遅延の可能性を通知することができる。

      5.2.5  HELOコマンド: RFC 821 セクション3.5

         Sender-SMTPは、HELOコマンドの<domain>パラメーターがクライアント
         ホストの有効なプリンシパルホストドメイン名であることを保証
         しなければならない(MUST)。これにより、Receiver-SMTPはHELO
         パラメーターの妥当性検証のため、その名前のMX解決を実行する
         必要がなくなる。

         HELO受信者は、HELOパラメーターが本当に送信者のIPアドレスに対応
         しているかを検証してもよい(MAY)。


Internet Engineering Task Force                                [Page 50]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         ただし受信者は、送信者のHELOコマンドの検証に失敗したとしても、
         メッセージ受理を拒否してはならない(MUST NOT)。

         【 議論 】
              HELOパラメーターの検証はドメイン名の検索を必要とするため、
              無視できない時間を取られる可能性がある。偽造メールの
              送信源を追跡するための代替ツールを後ほど提案する("DATA
              コマンド"を参照せよ)。

              また、HELOの引数はReceived:行に現れることから、有効な
              <domain>構文を持つ必要があることにも注意せよ。そうでない
              場合、501エラーが送信される。

         【 実装 】
              HELOパラメーターの妥当性検証に失敗した場合、推奨される
              手順は、メッセージヘッダーの中(例えば"Received:行"の中)
              に送信者の信頼性が不明である旨の注記を挿入すること
              である。

      5.2.6  メールの中継: RFC 821 セクション3.6

         メールの(一時蓄積及び)転送を以下のように三つのタイプに分類
         する。

         (1)  単純なフォワーダーまたは"メールエクスチェンジャー"は、
              受信者に関するプライベートな知識を使用してメッセージを
              転送する。RFC 821のセクション3.2を参照せよ。

         (2)  SMTPのメール"リレー"は、明示的なソースルートの結果として、
              (RFC 821のセクション3.6で定義される通りに)SMTPメール
              環境内でメッセージを転送する。SMTPの中継機能は、RFC 822
              に由来する"@...:"形式のソースルートを使用する(セクション
              5.2.19を参照せよ)。

         (3)  メール"ゲートウェイ"は、異なる環境間でメッセージの受け渡し
              を行う。メールゲートウェイのルールについては、後ほど
              セクション5.3.7で議論する。

         メッセージの転送は行うが、異なるメール環境へのゲートウェイには
         なっていない(つまり(1)または(2)に該当する)インターネットホスト
         は、セクション5.2.8で要求されるように適切なReceived:行を追加
         することはあっても、既存のどのヘッダーフィールドも書き換える
         べきではない(SHOULD NOT)。

         Sender-SMTPは、"@...:"アドレス形式を使用した明示的なソースルート
         を含むRCPT TO:コマンドを送信すべきではない(SHOULD NOT)。
         従って、RFC 821のセクション3.6で定義される中継機能は使用
         されるべきではない。


Internet Engineering Task Force                                [Page 51]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         【 議論 】
              この要件の意図は、すべてのソースルーティングを抑制し、
              インターネット環境内におけるメール配送の明示的ソース
              ルーティングを廃止することである。単純な宛先アドレス
              "user@domain"で常に十分なはずであり、ソースルーティング
              は不要である。これは、メールをソースルーティングする
              のではなく、宛先に普遍的な名前付けを使用するという明示的
              なアーキテクチャー上の決定の結果である。具体的に、SMTPは
              エンドツーエンドの接続性を提供し、DNSはグローバルに一意で
              場所に依存しない名前を提供する。MXレコードは、それが
              無ければソースルーティングが必要だったかもしれない主要な
              事例に対処する。

         Receiver-SMTPは、エンベロープ内の明示的なソースルート構文を
         受理しなければならない(MUST)が、RFC 821のセクション3.6で定義
         される中継機能は実装しなくてもよい(MAY)。中継機能を実装して
         いない場合、Receiver-SMTPは、一番右にある"@"記号の右側で指定
         されるホストに直接メッセージを配送しようと試みるべきである
         (SHOULD)。

         【 議論 】
              例として、中継機能を実装していないホストがSMTPコマンド
              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>"でメッセージを受信した
              場合を考える。ここで、ALPHA、BETA、GAMMAはドメイン名を
              表すものとする。ホストは、RFC 821の20ページで提案されて
              いるように550エラー応答で直ちにメッセージを拒否するのでは
              なく、"RCPT TO:<joe@GAMMA>"を使用してGAMMMAに直接メッセージ
              を転送しようと試みるべきである。このホストは中継をサポート
              していないため、reverse-pathを更新する必要はない。

              一部の人々は、障害を回避するように手動でメールをルーティング
              するため、ソースルーティングが時には必要になることもある
              と指摘している。しかし、この必要性が現実的で重要かは議論
              の余地がある。この目的のために明示的なSMTPメール中継を使用
              することは推奨されず、実際、多くのホストシステムがサポート
              していないので成功しないだろう。この目的のために"%ハック
              (%-hack)"(セクション5.2.16参照)を使用している人々も存在
              する。

      5.2.7  RCPTコマンド: RFC 821 セクション4.1.1

         Receiver-SMTPをサポートするホストは、予約済みのメールボックス
         "Postmaster"をサポートしなければならない(MUST)。

         Receiver-SMTPは、RCPTパラメーター到着時にそれを検証してもよい
         (MAY)。ただし妥当な時間を越えてRCPT応答を遅延させてはならない
         (MUST NOT)(セクション5.3.2参照)。


Internet Engineering Task Force                                [Page 52]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         従って、RCPTに対する"250 OK"応答は、必ずしも配送先アドレス
         が有効であることを意味しない。メッセージ受理後に見つかった
         エラーは、適切なアドレスに通知メッセージをメールすることによって
         報告される(セクション5.3.3参照)。

         【 議論 】
              RCPTパラメーターが直ちに妥当性検証可能だと判断する条件を
              どうするかは、工学的な設計上の選択である。宛先メール
              ボックスのエラーは、メールが送信される前にSender-SMTPに
              報告する方が時間とネットワーク帯域の節約の観点から
              望ましいのだが、RCPT検証が長くなるとこの利点は失われる。

              例えば、受信者は、ローカルに登録された単一のメール
              ボックス等のあらゆる単純なローカル参照であれば直ちに検証
              できる。一方で、"妥当な時間"という制限が暗に意味すること
              は、一般にメッセージが送信されて受理されるまでメーリング
              リストの検証は先送りされるということである。これは、
              大規模なメーリングリストを検証するには非常に長い時間を
              要する可能性があることによる。実装は、ローカルではない
              ためDNS検索を必要とするアドレスの妥当性検証の延期を選択
              するかもしれないし、しないかもしれない。DNS検索が実行
              されたがソフトドメインシステムエラー(例えばタイムアウト)
              が発生した場合、アドレスは妥当であると想定されなければ
              ならない。

      5.2.8  DATAコマンド: RFC 821 セクション4.1.1

         すべてのReceiver-SMTP("中継や最終的な配送のためにメッセージを
         受理するもの"[SMTP:1]だけに限定されない)は、メッセージの先頭
         に"Received:"行を挿入しなければならない(MUST)。RFC 821では
         "タイムスタンプ行"と呼ばれるこの行において、

         ・   FROMフィールドは、(1)HELOコマンドで提示された通りの
              送信元ホスト名と、(2)TCP接続から判定された送信元のIP
              アドレスを含むドメインリテラルの両方を含むべきである
              (SHOULD)。

         ・   IDフィールドは、RFC 822で提案されているように"@"を含んでも
              よい(MAY)が、これは必須ではない。

         ・   FORフィールドは、複数のRCPTコマンドが与えられた際に<path>
              エントリーの一覧を含んでもよい(MAY)。


         インターネットメールプログラムは、以前にメッセージヘッダーに
         追加されたReceived:行を変更してはならない(MUST NOT)。


Internet Engineering Task Force                                [Page 53]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         【 議論 】
              Received:行に送信元ホスト名と送信元IPアドレスの両方を含める
              ことで、不正なメール送信元の追跡に十分な情報を提供し、HELO
              パラメーターを明示的に検証する必要性をなくせるかもしれない。

              Received:行は、主に障害の診断のため、メールの配送ルートを
              追跡する人間を対象としたものである。セクション5.3.7の議論
              も参照せよ。

         Receiver-SMTPがメッセージの"最終的な配送"を行う際に、エラー
         通知メッセージを後で送信しなければならない場合に使用するため、
         メッセージのSMTPエンベロープから取得したMAIL FROM:アドレスを
         メッセージと共に渡さなければならない(MUST)(セクション5.3.3
         参照)。インターネットから異なるメール環境へのゲートウェイ中継
         を行う際にも同様の要件が存在する。セクション5.3.7を参照せよ。

         【 議論 】
              DATAコマンドへの最後の応答は、メッセージの配送と保存の成功
              にのみ依存することに注意せよ。宛先アドレスに関するあらゆる
              問題は、(1)RCPTコマンドへのSMTPエラー応答で報告されるか、
              (2)メッセージ生成者に後でメールされるエラーメッセージの中
              で報告されるかのどちらかでなければならない。

         【 実装 】
              MAIL FROM:情報は、パラメーターとして渡されてもよいし、
              メッセージ先頭に挿入されるReturn-Path:行の中で渡されても
              よい。

      5.2.9  コマンド構文: RFC 821 セクション4.1.2

         RFC 821で提示されているMAIL FROM:コマンドの構文は、パスが空の
         事例"MAIL FROM: <>"(RFC 821の15ページ参照)を省略している。
         空のreverse-pathはサポートされなければならない(MUST)。

      5.2.10  SMTP応答:  RFC 821 セクション4.2

         Receiver-SMTPは、RFC 821のセクション4.2.2または本文書に列挙
         されている応答コードだけを送信すべきである(SHOULD)。
         Receiver-SMTPは、RFC 821の例で示されているテキストの使用が
         適切である場合は、常にそれを使用すべきである(SHOULD)。

         Sender-SMTPは、(251応答と551応答を除き)テキストではなく、
         応答コードのみによって動作を決定しなければならない(MUST)。
         テキストが存在しない場合も含めて、あらゆるテキストを受理可能
         でなければならない。応答コードに続く空白(ホワイトスペース
         及びタブ)は、テキストの一部と見なされる。


Internet Engineering Task Force                                [Page 54]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         Sender-SMTPは、RFC 821の付録Eで規定されているように、応答コード
         の1桁目(最上位桁)だけの検査で十分な場合は、できる限りそこまで
         に留めるべきである(SHOULD)。

         【 議論 】
              RFC 821のセクション4.3には明示的に列挙されていないが、
              付録Eで説明されている応答コードの理論に照らして正当な
              応答コードを使用するSMTPシステム間で相互運用性の問題が
              発生している。

      5.2.11  透過性: RFC 821 セクション4.5.2

         実装者は、メッセージの透過性を保証するため、彼らの実装した
         メールシステムが常にピリオドを追加、削除することを保証
         しなければならない(MUST)。

      5.2.12  MX処理におけるWKSの使用: RFC 974の5ページ

         RFC 974[SMTP:3]では、提示されたメール送信先が本当にSMTPを
         サポートしているかを検証するため、ドメインシステムにWKS("Well-
         Known Service")レコードを問い合わせることを推奨していた。その後
         の経験により、WKSは広くサポートされていないことが分かったため、
         MX処理でWKSは使用されるべきではない(SHOULD NOT)。

      以下はRFC 822の注釈で、RFC 822のセクション番号に従った構成と
      なっている。

      5.2.13  RFC 822のメッセージ仕様: RFC 822 セクション4

         Return-Path行の構文は、エラー通知のループを防止するために
         ヌル(null)が指定される可能性を除外している(セクション5.3.3
         参照)。完全な構文は以下の通りである。

             return = "Return-path"  ":" route-addr
                    / "Return-path"  ":" "<" ">"

         任意のヘッダーフィールドの集合をここで拡張し、RFC 1049[SMTP:7]
         で定義されるContent-Typeフィールドを含めるものとする。この
         フィールドは、"メール読み出しシステムが構造化されたメッセージ
         ボディのタイプを自動的に特定し、適切な表示のための処理を可能
         とする"ものである[SMTP:7]。ユーザーエージェントは、この
         フィールドをサポートしてもよい(MAY)。

      5.2.14  RFC 822の日付と時刻の仕様: RFC 822 セクション5

         ここで、日付の構文を以下のように変更する。

            date = 1*2DIGIT month 2*4DIGIT


Internet Engineering Task Force                                [Page 55]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         すべてのメールソフトウェアは、次の世紀への移行を容易にするため、
         日付で4桁の年を使用すべきである(SHOULD)。

         数字のタイムゾーンインジケーターを使用する傾向が強くなっている
         ため、実装はタイムゾーン名の代わりに数字のタイムゾーンを使用
         すべきである(SHOULD)。ただし、すべての実装はどちらの表記も受理
         しなければならない(MUST)。タイムゾーン名が使用される場合、厳密
         にRFC 822で定義された通りでなければならない(MUST)。

         軍用タイムゾーンはRFC 822で誤って規定されている。具体的に、UT
         からの計算方法が誤っている(正負の符号が逆になっている)。結果
         として、RFC 822ヘッダーにおける軍用タイムゾーンは何も情報を
         配送しなくなっている。

         最後に、付録Dの構文概要の中で、"ゾーン"の定義にタイプ誤りが
         あることに注意せよ。正しい定義はRFC 822のセクション3にある。

      5.2.15  RFC 822の構文の変更: RFC 822 セクション6.1

         ここで、RFC 822の"mailbox"の構文定義を以下のように変更する。

            mailbox =  addr-spec            ; simple address
                    / [phrase] route-addr   ; name & addr-spec

         つまり、route-addrの前にあるphraseは今後任意(OPTIONAL)となる。
         この変更により、例えば以下のようなヘッダーフィールドは有効な
         ものとなる。

             From: <craig@nnsc.nsf.net>

      5.2.16  RFC 822のLocal-part: RFC 822 セクション6.2

         基本的なメールアドレス仕様は、"local-part@domain"形式である。
         ここで、"local-part"はアドレスの"左側"と呼ばれることもあり、
         ドメインに属するものである。

         右側の"domain"で暗示されるメッセージの宛先ではないホストがその
         メッセージを転送する場合、アドレスの"local-part"を解釈または
         変更してはならない(MUST NOT)。

         メールがインターネットメール環境から外部のメール環境にゲート
         ウェイ中継される場合(セクション5.3.7参照)、外部のメール環境で
         使用されるルーティング情報をアドレスの"local-part"に埋め込んでも
         よい(MAY)。その場合、ゲートウェイは、そのlocal-partを外部の
         メール環境にあわせて適切に解釈するだろう。


Internet Engineering Task Force                                [Page 56]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         【 議論 】
              ソースルートはインターネット内では推奨されないが
              (セクション5.2.6参照)、配送の仕組みをソースルートに
              頼っているインターネット以外のメール環境も存在する。
              インターネット以外の環境へのソースルートは、通常、
              インターネット内を横断する間は、アドレスの"local-part"
              部に埋め込むことができる(セクション5.2.16参照)。
              メールが適切なインターネットゲートウェイに到達すると、
              そのゲートウェイはlocal-partを解釈し、必要なアドレスを
              構築したり、対象メール環境に向けてルーティングを
              行なったりする。

              例えば、インターネットホストは"a!b!c!user@gateway-domain"
              にメールを送信するかもしれない。その場合、複雑なlocal-part
              の"a!b!c!user"はインターネットドメイン内では解釈されない
              が、指定されたメールゲートウェイによって構文解析され理解
              される。

              埋め込まれるソースルートは、"%"を右結合性を持つルーティング
              演算子として使用して"local-part"内にエンコードされること
              もある。例として以下のような場合を考える。

                 user%domain%relay3%relay2@relay1

              "%"の規定は、メールが"relay1"から"relay2"、"relay3"を
              経て、最後に"domain"の"user"へとルーティングされることを
              意味する。これは一般に、"%ハック"として知られている。
              "%"はlocal-partに隠された他のルーティング演算子(例えば"!")
              よりも優先順位を低くすることが提案されている。そのように
              することで、例えば"a!b%c"は"(a!b)%c"と解釈されるように
              なる。

              宛先ホスト(この場合は"relay1")だけがlocal-part
              "user%domain%relay3%relay2"の解析を許可される。

      5.2.17  ドメインリテラル: RFC 822 セクション6.2.3

         メーラーは、内容がドット付き10進のホストアドレスとなっている
         インターネットドメインリテラル("dtext"。RFC 822参照)を受理し、
         構文解析できなければならない(MUST)。これにより、セクション2.1
         に記述されているメールの場合の要件を満たす。

         SMTPは、自身が持つどのIPアドレスに対して設定されたドメイン
         リテラルであっても、受理し認識できなければならない(MUST)。


Internet Engineering Task Force                                [Page 57]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


      5.2.18  アドレスフォーマットの一般的なエラー: RFC 822 セクション6.1

         残念なことに、RFC 822のアドレスのフォーマット指定や構文解析の
         エラーをよく見かける。本セクションは、最も一般的なエラーに
         ついてのみ記述する。ユーザーエージェントは有効なRFC 822アドレス
         フォーマットをすべて受理しなければならず(MUST)、不正なアドレス
         構文を生成してはならない(MUST NOT)。

         ・   よくあるエラーは、グループ識別子の後にセミコロンを付けない
              ことである。

         ・   一部のシステムは、生成するメッセージにおいて、ドメイン名
              を完全修飾することに失敗する。ヘッダーアドレスフィールド
              の"@"記号の右側は、完全修飾ドメイン名でなければならない
              (MUST)。

              例えば、一部のシステムはFrom:アドレスを完全修飾すること
              に失敗する。これは、ユーザーインターフェースの"reply"
              コマンドが返信先アドレスを自動的に構築することを阻害
              する。

              【 議論 】
                   RFC 822は、ドメイン内部ではローカルにドメイン名の一部
                   を省略して使用することを許容しているが、インターネット
                   メールにRFC 822を適用する場合、これは許容されない。
                   この意味するところは、インターネットホストはSMTP
                   メッセージヘッダーのアドレスフィールドに省略した
                   ドメイン名を含めて送信してはならないということである。
                   これにより、セクション5.2.6で要求されるように、
                   インターネット全域でヘッダーのアドレスフィールドを
                   改変せずに受け渡すことが可能となる。

         ・   一部のシステムは、以下のような複数ホップの明示的なソース
              ルートを誤って構文解析する。

                  @relay1,@relay2,@relay3:user@domain


         ・   一部のシステムは、アドレスやMessage-IDに含まれる一部または
              すべてのドメイン名の末尾にドットを追加してドメイン名を過度に
              修飾する。これはRFC 822の構文に違反している。


      5.2.19  明示的なソースルート: RFC 822 セクション6.2.7

         インターネットホストソフトウェアは、明示的なソースルートを持つ
         アドレスを含むRFC 822ヘッダーを生成すべきではない(SHOULD NOT)。
         ただし、以前のシステムとの互換性のため、そのようなヘッダーも
         受理しなければならない(MUST)。


Internet Engineering Task Force                                [Page 58]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         【 議論 】
              RFC 822は、控えめに"明示的なソースルーティングは奨められ
              ない"と述べている。多くのホストはRFC 822のソースルートを
              誤って実装してきたため、実際問題として構文を使用できない
              ことは明らかである。多くのユーザーは構文を醜いと感じている。
              配送のための明示的なソースルートは、メールのエンベロープ
              では必要とされない。セクション5.2.6を参照せよ。これらすべて
              の理由により、RFC 822の表記法を使用する明示的なソース
              ルートは、インターネットメールヘッダーでは使用されない
              ものとする。

              セクション5.2.16で記述されるように、ソースルーティングを
              必要とする他のメール環境にメールをゲートウェイ中継できる
              ようにするため、例えば"%ハック"を使用するなどして明示的
              なソースルートをアドレスのlocal-partに埋め込めるように
              する必要がある。注意深い者は、宛先がインターネット内に
              ある場合であっても、ユーザーエージェントがそのような暗黙
              のソースルーティングを使用していることを検知して抑制する
              方法がないことに気づくだろう。我々にできることは、
              インターネット内におけるあらゆる種類のソースルーティング
              は不要で望ましくないので推奨しないことだけである。

   5.3  固有の課題

      5.3.1  SMTPのキュー管理戦略

         ホストSMTP実装の一般的な構造は、ユーザーのメールボックス、
         配送中のメッセージのキュー管理で使用される一つ以上の領域、
         メールの送信、受信を行う一つ以上のデーモンプロセスを含む。
         正確な構造は、ホスト上のユーザーの要望や、ホストにサポート
         されるメーリングリストの数と規模によって異なるものになる。
         高いトラフィックレベルをサポートするメーラーで特に役立つ
         ことが示されている幾つかの最適化について説明する。

         あらゆるキュー管理戦略は以下を含まなければならない(MUST)。

         ・   すべての動作に関するタイムアウト。セクション5.3.2を参照
              せよ。

         ・   エラーメッセージに応答してエラーメッセージを送信しない。


         5.3.1.1  送信の戦略

            Sender-SMTPの一般的なモデルは、送信メールを定期的に送信しよう
            と試みる一つ以上のプロセスである。典型的なシステムの場合、
            メッセージを構成するプログラムは、一編の新しい送信メールを
            直ちに配送するようリクエストする何らかの手法を持つ。


Internet Engineering Task Force                                [Page 59]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


            一方で、直ちに送信できないメールはキューに入れられ、送信者
            によって定期的にリトライされなければならない(MUST)。メール
            キューのエントリーは、メッセージそれ自身だけではなく
            エンベロープ情報も含む。

            送信者は、特定の宛先への試行が失敗した場合、次のリトライ
            を遅らせなければならない(MUST)。一般に、リトライ間隔は
            少なくとも30分とすべきである(SHOULD)。ただし、Sender-SMTP
            が配送失敗の理由を判定できる場合には、より洗練された柔軟
            な戦略の方が有益だろう。

            メッセージが送信されるか送信者が断念するまでリトライは継続
            する。断念するまでの期間は、一般的な場合で少なくとも4-5日と
            する必要がある。リトライアルゴリズムのパラメーターは設定
            可能でなければならない(MUST)。

            送信者は、キューに入れられたメールアイテムを単にリトライ
            するよりは、到達できないホスト及び対応するタイムアウト値
            の一覧を保持すべきである(SHOULD)。

            【 議論 】
                 経験によれば、障害は一般的に(対象システムがクラッシュ
                 したなど)一時的なものであることを示唆しているため、
                 メッセージをキューに入れた最初の1時間の間に2度接続を
                 試み、以後の試行は2時間または3時間に1度にバックオフ
                 するというポリシーが好ましい。

                 Sender-SMTPは、Receiver-SMTPと協調することでキュー内待機
                 による遅延を短縮することができる。具体的に、特定の
                 アドレスからメールが受信された場合、キューに入れられた
                 そのホスト宛てのあらゆるメールは直ちに送信できるという
                 良い証拠となる。

                 この戦略は、単一ホストが複数のアドレスを持つ(セクション
                 5.3.4参照)ことを受けて、配送時間とリソース使用のバランス
                 を最適化するために更に修正できるかもしれない。

                 Sender-SMTPは、利用できない宛先ホストに対する長大な
                 メッセージのキューを保持するかもしれない。その場合、
                 それらすべてのメッセージをリトライ周期ごとにリトライ
                 すると、過大なインターネットのオーバーヘッドを生じさせ、
                 デーモンも長時間に渡ってブロックされる。一般に、配送の
                 試みが失敗したとSMTPが判断できるのは、1分以上のタイム
                 アウトの後だけであることに注意せよ。接続ごとのタイム
                 アウトが1分であるとすると、キューに入れられた数十
                 または数百のメッセージに対してそれが繰り返されれば
                 非常に大きな遅延が生じることになる。


Internet Engineering Task Force                                [Page 60]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


            同じホスト上の複数ユーザーに同じメッセージを配送する場合、その
            メッセージのコピー一つだけを送信すべきである(SHOULD)。つまり、
            Sender-SMTPは、RCPT、DATA、RCPT、DATA、…、RCPT、DATAという
            コマンド手順の代わりに、RCPT、RCPT、…、RCPT、DATAというコマンド
            手順を使用すべきである。この効率化機能の実装を強く要請する。

            同様に、Sender-SMTPはタイムリーな配送を実現するため、送信メール
            トランザクションを複数並列に実行することをサポートしてもよい
            (MAY)。ただし、ホストがすべてのリソースをメールに注ぎ込むのを防止
            するため、幾つかの制限が課されるべきである(SHOULD)。

            マルチホームホストによる異なるアドレスの使用については後ほど
            議論する。

         5.3.1.2  受信の戦略

            Receiver-SMTPは、SMTPポート上で常に待機する状態を維持しよう
            とすべきである(SHOULD)。そのためには、SMTPへの複数のTCP接続
            をサポートする必要がある。そこに何らかの制限を課してもよい
            (MAY)。

            【 実装 】
                 Receiver-SMTPが特定のホストアドレスからメールを受信
                 した際に、Sender-SMTPに通知して、そのホストアドレス宛
                 の保留となっているあらゆるメールをリトライさせることが
                 できるかもしれない。

      5.3.2  SMTPのタイムアウト

         Sender-SMTPのタイムアウトに関して二つのアプローチが存在する。
         (a)各SMTPコマンドに対して独立に時間制限を課すか、または(b)
         単一メールのSMTPの対話処理全体に対して時間制限を課すかの
         どちらかである。Sender-SMTPは、選択肢(a)、つまりコマンドごと
         のタイムアウトを使用すべきである(SHOULD)。タイムアウトは容易
         に再設定できるようにすべきであり(SHOULD)、SMTPコードの
         再コンパイルが不要であることが望ましい。

         【 議論 】
              タイムアウトは、SMTP実装の必要不可欠な機能である。タイム
              アウトが長すぎる(または更に悪い、タイムアウトが存在しない)
              場合、Receiver-SMTPプログラムにおけるインターネット通信の
              障害やソフトウェアバグによって、SMTPプロセスが無期限に拘束
              される可能性がある。タイムアウトが短すぎる場合、メッセージ
              配送の途中で試行がタイムアウトすると、リソースが無駄になる。

              選択肢(b)が使用される場合、非常に大きなメーリングリストを
              展開する時間を許容するため、タイムアウトを非常に大きく、
              例えば1時間などにしなければならない。


Internet Engineering Task Force                                [Page 61]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


              また、非常に大きいメッセージを送信する時間を考慮して、
              メッセージのサイズに比例してタイムアウトを増加させる
              必要がある。タイムアウトを大きい固定値にすると二つの問題
              が生じる。依然として障害が非常に長時間送信者を拘束する
              可能性があること、また依然として非常に大きいメッセージが
              不当にタイムアウトする可能性があることである(これは無駄
              な障害だ!)。

              推奨される選択肢(a)を使用する場合、タイマーは、各SMTP
              コマンドと各データ転送のバッファー処理に対して設定される。
              後者は、全体のタイムアウトが本質的にメッセージのサイズに
              比例することを意味する。

         高負荷なメールリレーホストにおける豊富な経験に基づき、コマンド
         ごとの最小のタイムアウト値は以下のように設定されるべきである
         (SHOULD)。

         ・   冒頭の220メッセージ: 5分

              Sender-SMTPプロセスは、TCP接続の失敗と、冒頭の220
              グリーティングメッセージ受信の遅延を区別する必要がある。
              多くのReceiver-SMTPは、TCP接続は受理するが、システム負荷
              がより多くのメールを処理できる程度になるまで220メッセージ
              の配送を遅らせる。

         ・   MAILコマンド: 5分

         ・   RCPTコマンド: 5分

              メーリングリストとエイリアスの処理がメッセージの受理後
              まで保留されない場合、より長いタイムアウトが必要になる。

         ・   DATAの開始: 2分

              これは、DATAコマンドに対する"354 Start Input"応答を待つ
              時間である。

         ・   DATAのブロック転送: 3分

              これは、大量のデータを転送する各TCP SENDコールの終了を
              待つ時間である。

         ・   DATAの終了: 10分

              これは、"250 OK"応答を待つ時間である。メッセージデータを
              終了させる最後のピリオドを受信者が取得すると、通常は
              ユーザーのメールボックスにメッセージを配送する処理を実行
              する。メッセージは正しく配送されているため、この時点での
              不当なタイムアウトは極めて無駄である。


Internet Engineering Task Force                                [Page 62]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         Receiver-SMTPは、送信者からの次のコマンドを待つ間、少なくとも
         5分のタイムアウトを持つべきである(SHOULD)。

      5.3.3  信頼性のあるメール受信

         Receiver-SMTPは、(DATAに応答して"250 OK"を送信することで)メール
         を受理した段階で、そのメールを配送または中継する責任を引き受けて
         いる。この責任は真剣に受け止めなければならない。言い換えると、
         Receiver-SMTPは、後でホストがクラッシュしたとか予測できた
         リソース不足などの取るに足らない理由でメッセージを消失させては
         ならない(MUST NOT)。

         メッセージ受理の後に配送障害が発生した場合、Receiver-SMTPは、
         通知メッセージを作成してメール送信しなければならない(MUST)。
         この通知は、エンベロープでヌルのreverse-path("<>")を使用して
         送信されなければならない(MUST)。RFC 821のセクション3.6を参照
         せよ。この通知の受信アドレスは、エンベロープの返信先(または
         Return-Path:行)から取得したアドレスとすべきである(SHOULD)。
         ただし、この取得したアドレスがヌル("<>")の場合、Receiver-SMTP
         は通知を送信してはならない(MUST NOT)。アドレスが明示的なソース
         ルートの場合、最終ホップまでは取り除かれるべきである(SHOULD)。

         【 議論 】
              例えば、"MAIL FROM:<@a,@b:user@d>"で到着したメッセージ
              に対してエラー通知が送信されなければならないとする。
              その場合、通知メッセージは"RCPT TO:<user@d>"に送信される
              べきである。

              メッセージがSMTPに受理された後にメッセージ配送の失敗が
              生じることは避けられない。例えば、RCPTコマンドで提示された
              配送アドレスすべてをReceiver-SMTPが妥当性検証することは、
              ドメインシステムの"ソフト"エラーや対象アドレスがメーリング
              リストになっている等の理由で不可能かもしれない(RCPTに
              関する前の議論を参照せよ)。

         タイムアウトのためにメッセージを重複して受信してしまう状況を
         回避するため、Receiver-SMTPは、メッセージ送信を終了させる最後
         の"."への応答に要する時間を最小限にしようとしなければならない
         (MUST)。この問題に関する議論ついては、RFC 1047[SMTP:4]を参照
         せよ。

      5.3.4  信頼性のあるメール送信

         Sender-SMTPは、メッセージを送信するにあたり、エンベロープ内の
         宛先アドレスから対象ホストのIPアドレスを判定する。具体的に、
         "@"記号の右側の文字列をIPアドレスにマップする。


Internet Engineering Task Force                                [Page 63]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


         このマッピングや送信は、ソフトエラーで失敗する可能性がある。
         その場合、Sender-SMTPは、セクション5.3.1.1で要求されている
         ように、送信メールを後のリトライのために再度キューに入れる。

         マッピングが成功した場合、(a)MXレコードが複数ある、(2)マルチ
         ホーム接続されている、またはその両方といった理由で、単一の配送
         アドレスではなく複数のアドレス候補の一覧を得るという結果になる
         可能性がある。信頼性のあるメール送信を提供するため、Sender-SMTP
         は、配送の試みが成功するまでこの一覧に含まれるアドレスを順番に
         試行(リトライ)できなければならない(MUST)。ただし、試行を行える
         アドレス候補数には、設定可能な上限を設けてもよい(MAY)。いずれの
         場合においても、ホストは少なくとも二つのアドレスを試みるべき
         である(SHOULD)。

         ホストアドレスの順序を決定するにあたり、以下の情報が使用
         される。

         (1)  複数のMXレコード -- これらには、ソート時に使用されるべき
              優先度表示が含まれる。同じ優先度を持つ複数の宛先が存在し、
              そのうちのどれかを優先すべき明確な理由(例えばアドレスの
              優先度など)がない場合、Sender-SMTPは、特定の組織で使用
              される複数のメールエクスチェンジの負荷を分散させるため、
              ランダムに一つを選択すべきである(SHOULD)。これは[DNS:3]
              記載の手順を改良したものであることに注意せよ。

         (2)  マルチホームホスト -- (恐らくは優先度の高いMXレコード
              から取得された)宛先ホストはマルチホームかもしれない。
              その場合、ドメイン名リゾルバーはIPアドレス候補の一覧を
              返すだろう。この一覧を優先度降順で順序付けするのは
              ドメイン名リゾルバーインターフェースの責任であり
              (セクション6.1.3.4参照)、SMTPは提示された順序に従って
              試行していかなければならない(MUST)。

         【 議論 】
              複数のアドレス候補を試す機能が要求されているが、特定の
              導入状況では、アドレス候補への試行を制限または無効に
              したいこともある。マルチホームホストの異なるアドレスを
              使用したリトライを送信者が試みるべきかという問題は、
              ずっと議論の的になっている。複数のアドレスを使用する主な
              論拠は、それがタイムリーな配送の確率(実際には、あらゆる
              配送の確率となることもある)を最大化することである。
              これに対する反論は、不必要なリソースの使用をもたらす
              かもしれないことである。

              リソースの使用については、セクション5.3.1で議論される
              送信戦略も大きく考慮された決定がなされることに注意せよ。


Internet Engineering Task Force                                [Page 64]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


      5.3.5  ドメイン名のサポート

         SMTP実装は、ドメイン名とIPアドレスのマッピングを行うために
         セクション6.1で定義される仕組みを使用しなければならない(MUST)。
         これは、あらゆるインターネットSMTPはインターネットDNSの
         サポートを含まなければならない(MUST)ことを意味する。

         特に、Sender-SMTPは、MXレコードの仕組み[SMTP:3]をサポート
         しなければならない(MUST)。SMTPのドメイン名サポートに関する
         情報については、[DNS:2]のセクション7.4も参照せよ。

      5.3.6  メーリングリストとエイリアス

         SMTP機能を持つホストは、複数の配送先へのエイリアス形式及び
         リスト形式両方のアドレス展開をサポートすべきである(SHOULD)。
         展開されたリスト形式の各アドレスにメッセージを配送または転送
         する場合、エンベロープの返信先アドレス("MAIL FROM:")は、リスト
         管理者のアドレスに変更されなければならない(MUST)。ただし、
         メッセージのヘッダー、特に、メッセージの"From"フィールドに
         ついては、その影響を受けず変更されないままでなければならない
         (MUST)。

         【 議論 】
              重要なメールの機能として、疑似メールボックスアドレスから
              宛先メールボックスアドレス一覧への変換または"展開"により、
              単一のメッセージを複数の宛先に配送する仕組みが挙げられる。
              そのような疑似メールボックス("エクスプローダー"と呼ばれる
              こともある)にメッセージが送信されると、展開されたリストに
              含まれる各メールボックスにメッセージのコピーが転送または
              再配布される。展開ルールに応じて、このような疑似メール
              ボックスを"エイリアス"または"リスト"に分類する。

              (a)  エイリアス

                   エイリアスを展開するにあたり、受信メーラーは、
                   エンベロープに含まれる疑似メールボックスアドレスを
                   展開されたアドレス一覧に置き換えるだけである。
                   エンベロープの残りの部分及びメッセージボディーは
                   変更されないまま残される。その後、メッセージは展開
                   された各アドレスに配送または転送される。

              (b)  リスト

                   メーリングリストは、"転送"ではなく"再配布"によって
                   動作すると言えるだろう。リストを展開するにあたり、
                   受信メーラーは、エンベロープに含まれる疑似メール
                   ボックスを展開されたアドレス一覧に置き換える。


Internet Engineering Task Force                                [Page 65]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


                   エンベロープ内の返信先アドレスは、最終的な配送で生成
                   される全エラーメッセージがメッセージ生成者ではなく
                   リスト管理者に返されるように変更される。メッセージ
                   生成者は一般にリストの中身に関して管理権限を持たない
                   ため、大抵の場合エラーメッセージをわずらわしく思う
                   だけだろう。


      5.3.7  メールのゲートウェイ中継

         異なるメール環境間、言い換えると異なるメールフォーマットと
         プロトコルを持つ環境間でメールをゲートウェイ中継する処理は複雑
         であり、標準化は容易ではない。例えば、[SMTP:5a]、[SMTP:5b]を
         参照せよ。しかしながら、インターネットと別のメール環境間の
         ゲートウェイ中継に関して、幾つかの一般的な要件は与えられる
         かもしれない。

         (A)  ヘッダーフィールドは、メッセージがメール環境の境界を越えて
              ゲートウェイ中継される際に、必要に応じて書き換えられても
              よい(MAY)。

              【 議論 】
                   セクション5.2.16で示唆されるように、この要件は宛先
                   アドレスのlocal-partの解釈に影響する場合がある。

                   インターネットにゲートウェイ接続される別のメール
                   システムは、一般にRFC 822ヘッダーのサブセットを使用
                   するが、一部のシステムはSMTPエンベロープと等価なもの
                   を持たない。従って、メッセージがインターネット
                   環境から出ていく際に、SMTPエンベロープ情報をメッセージ
                   ヘッダーの中に収める必要があるかもしれない。考えられる
                   解決策は、エンベロープ情報を運ぶために新しいヘッダー
                   フィールド(例えば"X-SMTP-MAIL:"や"X-SMTP-RCPT:"等)
                   を作ることだが、これはインターネットの外にある環境
                   のメールプログラム変更を必要とする。

         (B)  メッセージをインターネット環境に転送する場合、あるいは
              メッセージをインターネット環境の外へと転送する場合、ゲート
              ウェイはReceived:行を先頭に付加しなければならない(MUST)が、
              ヘッダー内に既に存在するReceived:行はどのような形であれ
              変更してはならない(MUST NOT)。

              【 議論 】
                   この要件はセクション5.2.8で示した一般的な"Received:"
                   行の要件のサブセットだが、強調のためにここで再度示す
                   ものである。

                   他の環境で生成されたメッセージのReceived:フィールド
                   は、RFC 822に厳密に準拠していないかもしれない。


Internet Engineering Task Force                                [Page 66]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


                   しかし、Received:行の最も重要な用途は、メール障害の
                   デバッグである。このデバッグは、Received:行を"修正"
                   しようとする善意のゲートウェイのためにひどく妨げられて
                   しまう可能性がある。

                   ゲートウェイは、自身が追加する(複数の)Received
                   フィールドの"via"項の中で、環境とプロトコルを提示
                   することを強く推奨される。

         (C)  ゲートウェイは、インターネット側から到着するSMTPコマンド
              とRFC 822ヘッダーにおけるすべての有効なアドレスフォーマット
              及びすべての有効なRFC 822メッセージを受理すべきである
              (SHOULD)。ゲートウェイは、RFC 822ヘッダーまたはエンベロープ
              のどちらかの中にあるRFC 822の明示的なソースルート"("@...:"
              フォーマット)を受理しなければならないが、ソースルートに
              従った動作はしてもよい(MAY)し、しなくてもよい。セクション
              5.2.6及び5.2.19を参照せよ。

              【 議論 】
                   リモート環境のアドレスへの変換を単純化するため、
                   メールゲートウェイで受理されるアドレスの範囲を制限
                   する誘惑にかられることもあるだろう。この実践は、
                   メーラーがメールゲートウェイに送信するアドレスを
                   メールユーザーが制御できるという想定に基づいている。
                   しかし実際のところ、ユーザーは最終的に送信される
                   アドレスをほとんど制御できない。彼らの使用する
                   メーラーは、アドレスを公式RFC 822フォーマットの
                   いずれかに勝手に変更してしまう。

         (D)  ゲートウェイは、インターネットに転送するメッセージの
              全ヘッダーフィールドがインターネットメールの要件を満たす
              ことを保証しなければならない(MUST)。特に、"From:"、"To:"、
              "Cc:"等のフィールドはすべて、RFC 822の構文を満たすように
              (必要に応じて)変換されなければならず、変換されたフィールド
              は返信を送信する際に実効的で有用なものでなければならない。

         (E)  インターネットプロトコルから他の環境のプロトコルにメール
              を変換する際に使用される変換アルゴリズムは、外部メール
              環境からのエラーメッセージがRFC 822メッセージの"From:"
              フィールドに列挙される送信者ではなく、SMTPエンベロープの
              返信先に配送されることを保証しようと試みるべきである
              (SHOULD)。

              【 議論 】
                   インターネットのメーリングリストは、通常メーリング
                   リスト管理者のアドレスをエンベロープに設定するが、
                   オリジナルのメッセージヘッダーは(オリジナルの送信者
                   を含む"From:"フィールドを含めて)変更せずに残される。


Internet Engineering Task Force                                [Page 67]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


                   これにより、平均的な受信者が期待する振る舞いが得られる。
                   つまり、ヘッダーへの応答はメーリングリスト管理者では
                   なくオリジナルの送信者に送られるが、エラーは(恐らく
                   は問題を解決できない)送信者ではなく(問題を解決できる)
                   管理者に送られるようになる。

         (F)  同様に、別の環境からインターネットにメッセージを転送する
              場合、エラーメッセージの返信先アドレスがどのようなもの
              であれ外部の環境から提供されているならば、ゲートウエイは
              それに応じてエンベロープの返信先を設定すべきである(SHOULD)。


      5.3.8  最大メッセージサイズ

         メーラーソフトウェアは、(ヘッダーを含めて)少なくとも64Kバイトの
         長さを持つメッセージを送受信できなければならない(MUST)が、最大
         サイズはそれよりもはるかに大きい事が極めて望ましい。

         【 議論 】
              SMTPはメッセージの最大サイズを定義していないが、多くの
              システムは実装上の制限を課している。

              現時点で、インターネットにおける最小値のデファクトは
              64Kバイトである。しかし、電子メールは、さまざまな目的で使用
              されており、はるかに大きいメッセージが生成される場合も
              ある。例えば、メールはFTPの代わりにASCIIファイルを転送
              するために、特に文書全体を転送するために使用されること
              がある。その結果、メッセージは1メガバイトかそれ以上に
              なる可能性さえある。本文書と低位レイヤーを扱う対の文書
              をあわせると、0.5メガバイトになることを注記しておく。


Internet Engineering Task Force                                [Page 68]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


   5.4  SMTPの要件の概要

                                               |          | | | |S| |
                                               |          | | | |H| |
                                               |          | | | |O|M|
                                               |          | |S| |U|U|
                                               |          | |H| |L|S|
                                               |          |M|O| |D|T|脚
                                               |          |U|U|M| | |
                                               |          |S|L|A|N|N|
                                               |          |T|D|Y|O|O|注
機  能                                         |セクション| | | |T|T| 
-----------------------------------------------|----------|-|-|-|-|-|--
                                               |          | | | | | |
Receiver-SMTP:                                 |          | | | | | |
  VRFYを実装                                   |5.2.3     |x| | | | |
  EXPNを実装                                   |5.2.3     | |x| | | |
    EXPN、VRFYを無効にする設定が可能           |5.2.3     | | |x| | |
  SEND、SOML、SAMLを実装                       |5.2.4     | | |x| | |
  HELOパラメーターの妥当性を検証               |5.2.5     | | |x| | |
    不正なHELOを介したメッセージを拒否         |5.2.5     | | | | |x|
  ｴﾝﾍﾞﾛｰﾌﾟにおける明示的なｿｰｽﾙｰﾄ構文を受理     |5.2.6     |x| | | | |
  "postmaster"をサポート                       |5.2.7     |x| | | | |
  (リストの場合を除き)RCPTを受信時に処理       |5.2.7     | | |x| | |
      RCPT応答を大幅に遅延                     |5.2.7     | | | | |x|
                                               |          | | | | | |
  Received:行を追加                            |5.2.8     |x| | | | |
      Received:行はドメインリテラルを含む      |5.2.8     | |x| | | |
  以前に追加されたReceived:行を変更            |5.2.8     | | | | |x|
  返信先情報を渡す(最終的な配送/ｹﾞｰﾄｳｪｲ中継時) |5.2.8     |x| | | | |
  空のreverse-pathをサポート                   |5.2.9     |x| | | | |
  公式な応答コードだけを送信                   |5.2.10    | |x| | | |
  適切な場合RFC 821で示されているテキストを送信|5.2.10    | |x| | | |
  透過性を保証するため"."を削除                |5.2.11    |x| | | | |
  自身のｱﾄﾞﾚｽに設定されたﾄﾞﾒｲﾝﾘﾃﾗﾙを理解し受理 |5.2.17    |x| | | | |
                                               |          | | | | | |
  ｴﾗｰﾒｯｾｰｼﾞに対してｴﾗｰﾒｯｾｰｼﾞを送信             |5.3.1     | | | | |x|
  SMTPポート上で待機する状態を維持             |5.3.1.2   | |x| | | |
  複数の同時TCP接続受信数を制限                |5.3.1.2   | | |x| | |
  送信者からの次のコマンドまで最低でも5分待つ  |5.3.2     | |x| | | |
  "250 OK"後に回避できた障害でメッセージ消失   |5.3.3     | | | | |x|
  ﾒｯｾｰｼﾞ受理後の障害発生時ｴﾗｰ通知送信          |5.3.3     |x| | | | |
    ヌルのreverse-pathを使用して送信           |5.3.3     |x| | | | |
    エンベロープの返信先に送信                 |5.3.3     | |x| | | |
    返信先がヌルの場合に送信                   |5.3.3     | | | | |x|
    明示的ソースルートを取り除く               |5.3.3     | |x| | | |
  ﾒｯｾｰｼﾞ受理を示す応答の遅延を最小化(RFC 1047) |5.3.3     |x| | | | |
-----------------------------------------------|----------|-|-|-|-|-|--


Internet Engineering Task Force                                [Page 69]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


                                               |          | | | | | |
Sender-SMTP:                                   |          | | | | | |
  MAIL、RCPTで正規化されたドメイン名を送信     |5.2.2     |x| | | | |
  SEND、SOML、SAMLを実装                       |5.2.4     | | |x| | |
  HELOで有効なプリンシパルホスト名を送信       |5.2.5     |x| | | | |
  RCPT TO:で明示的ソースルートを送信           |5.2.6     | | | |x| |
  応答コードだけを使用して動作を決定           |5.2.10    |x| | | | |
  可能なら応答コードの最上位桁だけを使用       |5.2.10    | |x| | | |
  透過性のため"."を追加                        |5.2.11    |x| | | | |
                                               |          | | | | | |
  ソフト障害発生後メッセージをリトライ         |5.3.1.1   |x| | | | |
    次のリトライを遅らせる                     |5.3.1.1   |x| | | | |
    リトライのパラメーターは設定可能           |5.3.1.1   |x| | | | |
    ｷｭｰに入れられた宛先ﾎｽﾄごとに1回ずつﾘﾄﾗｲ    |5.3.1.1   | |x| | | |
  同じデータに対して複数のRCPTを使用           |5.3.1.1   | |x| | | |
  送信トランザクションの複数並列実行をサポート |5.3.1.1   | | |x| | |
    並列実行数を制限                           |5.3.1.1   | |x| | | |
                                               |          | | | | | |
  すべての動作に関するタイムアウト             |5.3.1     |x| | | | |
    コマンドごとにタイムアウトを使用           |5.3.2     | |x| | | |
    タイムアウトは容易に再設定可能             |5.3.2     | |x| | | |
    コマンド別の推奨タイムアウトを使用         |5.3.2     | |x| | | |
  配送先アドレス候補を順番に試行               |5.3.4     |x| | | | |
    試行するアドレス候補数の上限を設定可能     |5.3.4     | | |x| | |
    少なくとも二つのアドレスを試行             |5.3.4     | |x| | | |
  等価なMX候補間で負荷を分散                   |5.3.4     | |x| | | |
  ドメイン名システムを使用                     |5.3.5     |x| | | | |
    MXレコードをサポート                       |5.3.5     |x| | | | |
    MX処理でWKSレコードを使用                  |5.2.12    | | | |x| |
-----------------------------------------------|----------|-|-|-|-|-|--
                                               |          | | | | | |
メールの転送:                                  |          | | | | | |
  既存のヘッダーフィールド(群)を書き換え       |5.2.6     | | | |x| |
  RFC 821セクション3.6定義の中継機能を実装     |5.2.6     | | |x| | |
    実装しない場合、"@"右側のドメインに配送    |5.2.6     | |x| | | |
  アドレスの"local-part"を解釈                 |5.2.16    | | | | |x|
                                               |          | | | | | |
メーリングリストとエイリアス                   |          | | | | | |
  両方をサポート                               |5.3.6     | |x| | | |
  ﾒｰﾘﾝｸﾞﾘｽﾄのｴﾗｰをﾘｽﾄ管理者に通知              |5.3.6     |x| | | | |
                                               |          | | | | | |
メールのゲートウェイ中継:                      |          | | | | | |
  外部ﾒｰﾙ環境のﾙｰﾃｨﾝｸﾞをlocal-partに埋め込み   |5.2.16    | | |x| | |
  ヘッダーフィールドを必要に応じて書き換え     |5.3.7     | | |x| | |
  Received:行を先頭に付加                      |5.3.7     |x| | | | |
  ヘッダー内に既に存在するReceived:行の変更    |5.3.7     | | | | |x|
  ｲﾝﾀｰﾈｯﾄ側では有効な全RFC 822ﾒｯｾｰｼﾞを受理     |5.3.7     | |x| | | |
  RFC 822の明示的ソースルートに従って動作      |5.3.7     | | |x| | |


Internet Engineering Task Force                                [Page 70]


RFC1123                  MAIL -- SMTP & RFC-822             October 1989


  ｲﾝﾀｰﾈｯﾄ側では有効なRFC 822ﾒｯｾｰｼﾞだけを送信   |5.3.7     |x| | | | |
  エラーメッセージをエンベロープの返信先に配送 |5.3.7     | |x| | | |
  ｴﾗｰ返信先ｱﾄﾞﾚｽに応じてｴﾝﾍﾞﾛｰﾌﾟの返信先を設定 |5.3.7     | |x| | | |
                                               |          | | | | | |
ユーザーエージェント -- RFC 822                |          | | | | | |
  ユーザーがソースルートを含むアドレスを入力   |5.2.6     | | | |x| |
  RFC 1049のContent-Typeフィールドをサポート   |5.2.13    | | |x| | |
  4桁の年を使用                                |5.2.14    | |x| | | |
  数字のタイムゾーンを生成                     |5.2.14    | |x| | | |
  ﾀｲﾑｿﾞｰﾝ名も数字のﾀｲﾑｿﾞｰﾝもすべて受理         |5.2.14    |x| | | | |
  数字以外のﾀｲﾑｿﾞｰﾝの場合はRFC 822の定義を使用 |5.2.14    |x| | | | |
  route-addrの前のphraseを省略                 |5.2.15    | | |x| | |
  ﾄﾞｯﾄ付き10進のﾄﾞﾒｲﾝﾘﾃﾗﾙを受理して構文解析    |5.2.17    |x| | | | |
  すべてのRFC 822アドレスフォーマットを受理    |5.2.18    |x| | | | |
  不正なRFC 822アドレスフォーマットを生成      |5.2.18    | | | | |x|
  ヘッダーに含まれるドメイン名は完全修飾       |5.2.18    |x| | | | |
  ヘッダーで明示的なソースルートを生成         |5.2.19    | | | |x| |
  明示的なソースルートを含むヘッダーを受理     |5.2.19    |x| | | | |
                                               |          | | | | | |
少なくとも64Kバイトのメッセージを送信/受信     |5.3.8     |x| | | | |


Internet Engineering Task Force                                [Page 71]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


6. サポートサービス

   6.1 ドメイン名の変換

      6.1.1 導入

         すべてのホストは、ドメイン名システム(DNS)のリゾルバーを実装
         しなければならない(MUST)。また、このDNSリゾルバーを使用して
         ホスト名からIPアドレスへの変換またはその逆の変換を行う仕組み
         を実装しなければならない(MUST)[DNS:1、DNS:2]。

         ホストは、ホスト名を変換するにあたり、DNSに加えてローカルな
         インターネットホストテーブルを検索する仕組みも実装してよい
         (MAY)。この選択肢の詳細についてはセクション6.1.3.8を参照せよ。

         【 議論 】
              当初、インターネットホスト名の変換は、全ホストのテーブル
              のローカルなコピーを検索することで実行されていた。この
              テーブルはタイムリーに更新して配布するには大きくなりすぎ、
              また大きすぎて多くのホストに適合しなくなったため、DNSが
              考案された。

              DNSは、主にホスト名とホストアドレスの間の変換で使用される
              分散データベースを作成する。DNSソフトウェアの実装が必要
              である。DNSは、論理的に異なる二つの部分で構成される。一つは
              ネームサーバーで、もう一つはリゾルバーである(ただし、効率化
              の観点から、実装ではこれら二つの論理的要素が組み合わされる
              こともある)[DNS:2]。

              DNSネームサーバーは、データベースの特定の区域に関する権威を持つ
              データを保持し、そのデータに関する問い合わせに回答する。
              ドメインリゾルバーは、ユーザープロセスに代わってDNSネーム
              サーバーにデータを問い合わせる。従って、すべてのホストは
              DNSリゾルバーを必要とする。一部のホスト機器は、DNSネームサーバー
              も稼働させる必要がある。完全な情報を持つネームサーバーは
              存在しないので、一般に、問い合わせを解決するには二つ以上の
              ネームサーバーから情報を取得する必要がある。

      6.1.2  プロトコルのウォークスルー

         実装者は、参考文献[DNS:1]と[DNS:2]を慎重に調査しなければ
         ならない。これらの文書は、ドメイン名システムの理論、
         プロトコル、実装の詳細な記述を提供し、数年の経験が反映された
         ものになっている。


Internet Engineering Task Force                                [Page 72]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


         6.1.2.1  TTLがゼロのリソースレコード: RFC 1035 セクション3.2.1

            すべてのDNSネームサーバーとリゾルバーは、TTLがゼロのRRを適切
            に扱う、つまりクライアントにRRは返すがキャッシュしないという
            振る舞いをしなければならない(MUST)。

            【 議論 】
                 TTL値ゼロは、そのRRは進行中のトランザクションに対して
                 だけ使用可能であり、キャッシュされるべきではないという
                 意味だと解釈される。この仕組みは変化の極めて速いデータ
                 に有用である。

         6.1.2.2  QCLASSの値: RFC 1035 セクション3.2.5

            リクエスト発行者が二つ以上のクラスのデータを検索していない
            限り、"QCLASS=*"を指定した問い合わせは使用されるべきではない
            (SHOULD NOT)。特に、リクエスト発行者がInternetデータタイプ
            にのみ関心がある場合、QCLASS=INが使用されなければならない
            (MUST)。

         6.1.2.3  使用されないフィールド: RFC 1035 セクション4.1.1

            問い合わせメッセージまたは応答メッセージにおいて、使用されない
            フィールドはゼロでなければならない(MUST)。

         6.1.2.4  圧縮: RFC 1035 セクション4.1.4

            ネームサーバーは、応答で圧縮を使用しなければならない(MUST)。

            【 議論 】
                 圧縮は、UDPデータグラムのオーバーフローを避けるために
                 不可欠である。セクション6.1.3.2を参照せよ。

         6.1.2.5  設定情報の誤用: RFC 1035 セクション6.1.2

            再帰ネームサーバーとフルサービスリゾルバーは、一般に、ルート
            ネームサーバーまたはローカルネームサーバーの所在に関する
            ヒントを含む設定情報を保持する。実装は、これらのヒントの
            どれであっても応答に含めてはならない(MUST NOT)。

            【 議論 】
                 多くの実装者は、これらのヒントをキャッシュされたデータ
                 であるかのように保存すると便利であることに気付いたが、
                 一部の実装者は、この"キャッシュされたデータ"が応答に
                 含まれないことを保証するのを無視していた。それにより、
                 ヒントが古くなったり誤っていたりした場合に、インター
                 ネットに深刻な問題を引き起こしてきた。


Internet Engineering Task Force                                [Page 73]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


      6.1.3  固有の課題

         6.1.3.1  リゾルバーの実装

            ホストが並列プロセスをサポートしているならば、名前のリゾルバー
            は複数の並列リクエストを多重化できるべきである(SHOULD)。

            DNSリゾルバーの実装にあたり、二つの異なるモデル、フルサービス
            リゾルバーまたはスタブリゾルバーのうちの一つを任意で選択して
            よい(MAY)。


            (A)  フルサービスリゾルバー

                 フルサービスリゾルバーは、リゾルバーサービスの完全な
                 実装であり、通信障害、個々のネームサーバーの障害、
                 与えられた名前に対する適切なネームサーバーの所在特定
                 などを処理することができる。フルサービスリゾルバーは
                 以下の要件を満たさなければならない。

                 ・   リゾルバーは、複数の同一リクエストのためにリモート
                      アクセスが繰り返されるのを回避するため、ローカル
                      なキャッシュ機能を実装しなければならず(MUST)、
                      またキャッシュ内の情報をタイムアウトさせなければ
                      ならない(MUST)。

                 ・   リゾルバーは、複数のルートネームサーバーと複数の
                      ローカルドメインのネームサーバーを指し示す起動情報
                      によって動作を設定できるようにすべきである(SHOULD)。
                      このようにすることで、リゾルバーは、通常の場合は
                      名前空間全体にアクセスでき、ローカルネットワークが
                      インターネットから切り離された場合にもローカルな
                      ドメイン情報にはアクセスできることが保証される。


            (B)  スタブリゾルバー

                 "スタブリゾルバー"は、接続ネットワーク上または"近隣の"
                 ネットワーク上にある再帰ネームサーバーのサービスに
                 依存する。この仕組みは、ホストが別のホスト上のネーム
                 サーバーにリゾルバー機能の負担を転嫁できるようにする。
                 このモデルは、PCのような能力の低いホストにはしばしば
                 不可欠であり、ホストがローカルネットワーク上のワーク
                 ステーションの一つである場合にも推奨される。その理由は、
                 すべてのワークステーションが再帰ネームサーバーの
                 キャッシュを共有できるようになるので、ローカルネット
                 ワークから送出されるドメインリクエスト数が削減される
                 からである。


Internet Engineering Task Force                                [Page 74]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


                 少なくとも、スタブリゾルバーは、複数の冗長な再帰ネーム
                 サーバーにリクエストを振り分けられなければならない
                 (MUST)。再帰ネームサーバーは引き受けるリクエストの
                 送信元を制限することが許されているので、ホスト管理者は
                 サービスが提供されるかを確認しなければならないことに
                 注意せよ。スタブリゾルバーはキャッシュの使用を選択して
                 実装してもよい(MAY)が、その場合、キャッシュされた情報
                 をタイムアウトさせなければならない(MUST)。


         6.1.3.2  トランスポートプロトコル

            DNSリゾルバーと再帰サーバーは、(ゾーン転送以外の)問い合わせ
            を送信するためにUDPをサポートしなければならず(MUST)、TCPも
            サポートすべきである(SHOULD)。具体的に、ゾーン転送以外の
            問い合わせを送信するDNSリゾルバーまたはサーバーは、初めにUDP
            で問い合わせを送信しなければならない(MUST)。応答の回答部
            (Answer section)が切り詰められており、かつリクエスト発行者
            がTCPをサポートしている場合、TCPを使用して再度問い合わせを
            試みるべきである(SHOULD)。

            DNSサーバーはUDPの問い合わせに対してサービスを提供できなければ
            ならず(MUST)、TCPの問い合わせに対してもサービスを提供できる
            ようにすべきである(SHOULD)。ネームサーバーは、TCPの問い合わせ
            に割り当てるリソースを制限してもよい(MAY)が、UDPを使用しても
            成功していたはずだというだけの理由でTCPの問い合わせに対する
            サービスを拒否すべきではない(SHOULD)。

            切り詰められた応答は、保存(キャッシュ)されたり、切り詰め
            られたという事実が失われる形で後に使用されたりしては
            ならない(MUST NOT)。

            【 議論 】
                 UDPの問い合わせはパケット数と接続状態の維持の両方でオーバー
                 ヘッドが極めて低いため、問い合わせに関してはUDPがTCPより
                 も優先される。負荷の高いサーバー、特にルートサーバーに
                 とって、UDPの使用は必須である。また、リゾルバーは、単一
                 のTCPの問い合わせコストで複数の異なるサーバーに対してUDP
                 の問い合わせを試みられるので、UDPは付加的なロバスト性を
                 提供する。

                 現時点のインターネットDNSでは非常にまれだとはいえ、DNS
                 応答は切り詰められる可能性がある。切り詰めが生じるかは
                 データ次第なので、事実上予測は不可能である。要因となる
                 ものには、応答に含まれるRRの数、各RRのサイズ、名前圧縮
                 アルゴリズムによって実現される容量の節約の度合いなどが
                 含まれる。経験則として、応答に含まれるRR数が15個以下の
                 場合、NSやMXの一覧の切り詰めは発生しないはずである。


Internet Engineering Task Force                                [Page 75]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


                 切り詰められた応答が使用できるかどうかは、アプリケーション
                 依存である。メーラーは、メールループを引き起こす可能性
                 があるため、切り詰められたMX応答を使用してはならない。

                 確かな判断に基づく実践により、大部分の場合はUDPで十分
                 になるだろう。ネームサーバーは、応答で圧縮を使用
                 しなければならない。リゾルバーは、応答の付加情報部
                 (Additional section)の切り詰め(追加の情報が消失する
                 だけ)と、回答部の切り詰め(MXレコードの場合、メーラー
                 が応答を使用できなくなる)を区別しなければならない。
                 データベース管理者は、ネームサーバーやMX候補などの一覧
                 に含まれる基本名(primary name)のうち、妥当な数だけを
                 列挙すべきである。

                 また一方で、将来定義される幾つかの新しいDNSレコード
                 タイプは512バイトの制限を越える情報を含むであろうから、
                 TCPが必要になることも明らかである。従って、
                 リゾルバーとネームサーバーは、将来TCPサービスが必要に
                 なるという認識に基づき、今日のUDPのバックアップとして
                 TCPサービスを実装すべきである。

            ネームサーバーとリゾルバーは、個別の合意により、両者間の
            すべてのトラフィックでTCPを使用するように調整してもよい(MAY)。
            ゾーン転送ではTCPが使用されなければならない(MUST)。

            DNSサーバーは、オープンなTCP接続上で応答を待っている間、
            またはゾーン転送実行を実行している間[DNS:2]にもUDPの問い合わせ
            処理を継続できるように、十分な内部並列性を持たなければ
            ならない(MUST)。

            サーバーは、IPブロードキャストアドレスまたはマルチキャスト
            アドレスを使用して配送されたUDPの問い合わせをサポートしても
            よい(MAY)。ただし、マルチキャストされる問い合わせには、再帰
            要求(RD)ビットが設定されてはならない(MUST NOT)。ブロード
            キャストアドレスまたはマルチキャストアドレスを介してRDビット
            が設定された問い合わせを受信したネームサーバーは、その問い合わせ
            を無視しなければならない(MUST)。ブロードキャストまたはマルチ
            キャストでDNSの問い合わせを送信するホストは、時折り実行される
            探索としてのみその問い合わせを送信すべきである(SHOULD)。
            ここで、探索とは(複数の)応答から取得したサーバーのIPアドレス
            をキャッシュしておくことで、通常はユニキャストで問い合わせを
            送信できるようにする仕組みである。

            【 議論 】
                 ブロードキャストや(特に)IPマルチキャストは、近隣のネーム
                 サーバーのIPアドレスを前もって知らなくても、その所在を
                 特定する方法を提供できる。しかし、一般的な再帰問い合わせを
                 ブロードキャストすると、ネットワークとサーバーの両方に
                 過度で不必要な負荷を課す結果となる可能性がある。


Internet Engineering Task Force                                [Page 76]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


         6.1.3.3  効率的なリソースの使用

            サーバーとリゾルバーに関する以下の要件は、特にDNSサービス
            がメーラーをはじめとする上位レベルの自動サーバーによって
            繰り返し呼び出される場合、インターネット全体の健全性の
            ために非常に重要である。

            (1)  リゾルバーは、通信帯域を無駄にしないことを保証するため
                 に再送制御を実装しなければならず(MUST)、また単一の
                 リクエストに応答するために消費されるリソースに関して
                 有限な上限を設定しなければならない(MUST)。固有の推奨
                 については、[DNS:2]の43～44ページを参照せよ。

            (2)  応答がないまま問い合わせが複数回繰り返された場合、実装は
                 あきらめてアプリケーションにソフトエラーを返さなければ
                 ならない(MUST)。

            (3)  すべてのDNSネームサーバーとリゾルバーは、分のオーダーの
                 タイムアウト期間で一時的な障害をキャッシュすべきである
                 (SHOULD)。

                 【 議論 】
                      これにより、アプリケーションが(本文書のセクション
                      2.2に違反して)ソフト障害に直ちにリトライすることで
                      過剰なDNSトラフィックが生成されるのを防止する。

            (4)  すべてのDNSネームサーバーとリゾルバーは、[DNS:2]に記述
                 されている通り、指定された名前または指定されたタイプ
                 のデータが存在しないことを示すネガティブ応答をキャッシュ
                 すべきである(SHOULD)。

            (5)  DNSサーバーまたはリゾルバーがUDPの問い合わせをリトライ
                 する場合、リトライ間隔は指数的バックオフアルゴリズム
                 によって制限されるべきであり(SHOULD)、またリトライ間隔
                 には上限と下限が設定されるべきである(SHOULD)。

                 【 実装 】
                      再送間隔の初期値計算にあたり、測定されたRTTと(利用
                      可能であれば)分散が使用されるべきである。この情報
                      が利用できない場合、5秒以上のデフォルト値が使用
                      されるべきである。実装は再送間隔の上限を設定しても
                      よいが、この上限は、インターネットの最大セグメント
                      生存時間を2倍してネームサーバー上のサービス遅延
                      時間を加えた値よりも大きくなければならない。

            (6)  リゾルバーまたはサーバーが問い合わせを発行後、それに対する
                 送信元抑制を受信した場合、しばらくの間はそのサーバーに
                 問い合わせる頻度を減らす手順を踏むべきである(SHOULD)。


Internet Engineering Task Force                                [Page 77]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


                 サーバーは、応答データグラムを送信した結果送信元抑制を
                 受信した場合、それを無視してもよい(MAY)。

                 【 実装 】
                      問い合わせ頻度を下げるための推奨動作の一つは、使用
                      可能な代替サーバーがある場合、次の問い合わせの試み
                      をそのサーバーに送信することである。もう一つは、
                      同じサーバーに対するリトライ間隔をバックオフする
                      ことである。


         6.1.3.4  マルチホームホスト

            ホスト名からアドレスへの変換機能が複数アドレスを持つホスト
            に遭遇した場合、直接接続された(複数の)ネットワークのネット
            ワーク番号や、他に利用可能なパフォーマンス情報や履歴情報と
            いった知識を使用して、複数アドレスを順位付けまたはソート
            すべきである(SHOULD)。

            【 議論 】
                 マルチホームホストの異なるアドレスは、一般に、複数の
                 異なるインターネットパスがあり、パフォーマンス、信頼性、
                 管理上の制約などにおいて、あるパスは他のパスよりも
                 望ましい可能性があることを意味する。ドメインシステム
                 が最良のパスを決定する一般的な方法は存在しない。推奨
                 されるアプローチは、この決定にあたり、システム管理者
                 に設定されたローカルな設定情報に基づくことである。

            【 実装 】
                 以下に示す仕組みは、これまでうまく使用されてきている。

                 (a)  ホストの設定データに、ネットワークを単純に優先度順
                      に並べたネットワーク優先順位表(Network-Preference 
                      List)を組み込む。優先度が存在しない場合、この順位表
                      は空であってもよい。

                 (b)  ホスト名がIPアドレスの一覧にマップされる場合、
                      それらのアドレスは、ネットワーク番号に基づき、
                      ネットワーク優先順位表の対応ネットワークと同じ
                      順序に並べ替えられるべきである。IPアドレスのネット
                      ワーク番号がネットワーク優先順表内に存在しない場合、
                      そのIPアドレスは優先順位的に最下位に配置されるべき
                      である。


Internet Engineering Task Force                                [Page 78]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


         6.1.3.5  拡張性

            DNSソフトウェアは、ウェルノウンでクラス非依存なフォーマット
            [DNS:2]をすべてサポートしなければならず(MUST)、ウェルノウン
            タイプの新規導入や標準外のタイプの局所的な実験に伴う労苦を
            最小限に留めるように書かれるべきである(SHOULD)。

            【 議論 】
                 DNSに使用されるデータタイプとクラスは拡張可能である
                 ため、新しいタイプが追加されたり、古いタイプが削除
                 または再定義されたりするだろう。新しいデータタイプの
                 導入に影響するものは、DNSメッセージ内のドメイン名圧縮
                 ルールと、リソースレコード(RR)の印字可能な(つまり
                 マスターファイルの)フォーマットと内部フォーマットの間
                 の変換ルールだけのはずである。

                 圧縮は、特定のRR内部のデータフォーマットに関する知識を
                 必要とする。従って、ウェルノウンでクラス非依存なRR
                 の内容に対してのみ圧縮が使用されなければならず、クラス
                 固有のRRやウェルノウンでないRRタイプに対しては絶対に
                 使用されてはならない。RRの所有者名は、常に圧縮の対象と
                 なる。

                 ネームサーバーは、印字可能なフォーマットへの変換方法
                 がわからないRRをゾーン転送で取得するかもしれない。
                 リゾルバーも問い合わせの結果同様の情報を受信する可能性
                 がある。適切な処理を行うには、この取得したデータが
                 そのまま保持されなければならない。これはつまり、DNS
                 ソフトウェアが内部で情報を保持するにあたり、(印字可能
                 な)テキストフォーマットは使用できないことを意味する。

                 DNSは、ドメイン名の構文を非常に大まかに定義している。
                 すなわち、それぞれ63個以下の8ビットオクテットを含む
                 ラベルをひと続きに並べたもので、ラベル間はドットで
                 区切られ、全合計が最大255オクテットとなるものである。
                 DNSの特定アプリケーションでは、使用するドメイン名の構文
                 を更に制限することが許可されているが、DNSの普及に伴い、
                 より一般的な名前を許容する幾つかのアプリケーションも
                 出現している。特に、本文書のセクション2.1は、RFC 952
                 [DNS:4]で定義された正当なインターネットホスト名の構文
                 を少し緩和している。

         6.1.3.6  RRタイプの状態

            ネームサーバーは、設定ファイルからMDとMFを除く全RRタイプを
            ロードできなければならない(MUST)。MDタイプとMFタイプは廃止
            されており、実装されてはならない(MUST NOT)。特に、ネーム
            サーバーは、これらのタイプを設定ファイルからロードしては
            ならない(MUST NOT)。


Internet Engineering Task Force                                [Page 79]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


            【 議論 】
                 RRタイプMB、MG、MR、NULL、MINFO、RPは実験的なものと
                 みなされており、DNSを使用するアプリケーションは、これら
                 のRRタイプが大半のドメインでサポートされることを期待
                 できない。更に、これらのタイプは再定義される可能性
                 もある。

                 TXT RRとWKS RRは、インターネットサイトで広く使用されて
                 こなかった。その結果、アプリケーションは、大半のドメイン
                 でTXT RRまたはWKS RRの存在をあてにできない。

         6.1.3.7  ロバスト性

            DNSソフトウェアは、ネットワーク接続性や他の問題のために
            ルートサーバーや他のサーバーが利用できない環境でも動作が
            求められる場合がある。そのような状況において、DNSネーム
            サーバーとリゾルバーは、名前空間の到達できない範囲に関して
            一時的な障害を返すことはあっても、到達可能な範囲に関しては
            サービスを提供し続けなければならない(MUST)。

            【 議論 】
                 DNSは、主としてインターネットに接続された状況での使用
                 が意図されているが、インターネットに接続されていない
                 ネットワークでも使用できるべきである。従って、
                 実装は、ローカルな名前に関するサービスを提供する前に
                 ルートサーバーへのアクセスに依存してはならない。

         6.1.3.8  ローカルホストテーブル

            【 議論 】
                 ホストは、DNSのバックアップまたは補足としてローカル
                 ホストテーブルを使用してもよい。これは、DNSとホスト
                 テーブルのどちらが優先されるのかという問題を提起する。
                 最も柔軟なアプローチは、これを設定オプションにする
                 ことだろう。

                 典型的な場合、このような補足的なホストテーブルの内容
                 は、サイトによってローカルに決定される。ただし、公開
                 されているインターネットホストのテーブルは、[DNS:4]で
                 文書化されたフォーマットに従い、DDNネットワーク
                 インフォメーションセンター(DDN NIC)によって保守されて
                 いる。このテーブルは、[DNS:5]に記述されるプロトコルを
                 使用して、DDN NICから取得することができる。このテーブル
                 は、全インターネットホストのごく一部しか含まないこと
                 が留意されなければならない。このプロトコルを使用して
                 DDN NICホストテーブルを取得するホストは、ALLコマンド
                 でテーブル全体をリクエストする前に、VERSIONコマンドを
                 使用してテーブルが変更されたかを検査すべきである。


Internet Engineering Task Force                                [Page 80]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


                 VERSION識別子は任意の文字列として扱われ、等価性のみが
                 テストされるべきである。ひと続きの数字の並びだとは想定
                 されない場合もある。

                 DDN NICホストテーブルは、ホストの運用には必要なく、
                 従って現在DNSデータベースには含まれていない管理
                 情報を含んでいる。そのような管理情報の例として、ネット
                 ワークエントリーとゲートウェイエントリーが挙げられる。
                 とは言え、この付加的な情報の多くは将来DNSに追加される
                 ことになるだろう。逆に、DNSはDDN NICホストテーブル
                 からは利用できない不可欠なサービス(特にMXレコード)
                 を提供する。

      6.1.4  DNS/ユーザー間のインターフェース

         6.1.4.1  DNSの管理

            本文書は、ホストソフトウェアの設計と実装の課題に関係するもの
            であり、管理上の課題や運用上の課題は扱わない。とは言え、
            管理上の課題はDNSで特に重要である。なぜなら、この大規模分散
            データベースでは、特定のセグメントのエラーが多くのサイト
            でパフォーマンスを低下させたり誤動作を引き起こしたりする
            可能性があるからである。これらの課題については[DNS:6]と
            [DNS:7]で議論されている。

         6.1.4.2  DNSのユーザーインターフェース

            ホストは、ホスト上で稼働しているアプリケーションプログラム
            すべてに対してDNSへのインターフェースを提供しなければならない
            (MUST)。このインターフェースは、通常、リゾルバー機能
            [DNS:1, 6.1:2]を実行するため、システムプロセスにリクエスト
            を渡す。

            最低限、基本インターフェースは、特定の名前に関連する特定の
            タイプとクラスの情報すべてに関するリクエストをサポートしなければ
            ならず(MUST)、リクエストされた情報すべてを返すか、ハードエラー
            コードまたはソフトエラー通知を返すかのどちらかでなければ
            ならない(MUST)。エラーがない場合、基本インターフェースは、
            修正、削除、順序変更などを行わずに応答全体を返すので、新しい
            データタイプに適応させるために基本インターフェースを変更する
            必要はない。

            【 議論 】
                 DNSから特定の情報に常にアクセスできるとは限らないため、
                 ソフトエラー通知はインターフェースの不可欠な要素である。
                 セクション6.1.3.3を参照せよ。


Internet Engineering Task Force                                [Page 81]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


            ホストは、素のドメインデータを特定の機能により適した
            フォーマットに変換するなど、特定の機能にあわせた他のDNS
            インターフェースを提供してもよい(MAY)。特に、ホストは、
            ホストアドレスとホスト名との間の変換を容易にするDNS
            インターフェースを提供しなければならない(MUST)。

         6.1.4.3 インターフェースにおける名前の省略機能

            ユーザーインターフェースは、一般的に使用される名前の省略形
            を入力する方法をユーザーに提供してもよい(MAY)。そのような
            方法の定義はDNS仕様の対象範囲外だが、これらの方法でDNS名前
            空間全体にアクセスできること、及びこれらの方法がインター
            ネットリソースを過度に使用しないことを保証するため、幾つか
            のルールが必要である。

            省略法が提供される場合、

            (a)  ある名前は既に完全なもので、省略法の適用は禁止されて
                 いることを示す表記の規則が存在しなければならない
                 (MUST)。末尾のドットは通常の方法である。

            (b)  省略形の展開はただ一度だけしか行われてはならず(MUST)、
                 省略された名前が入力されたコンテキストの中で、その
                 展開が実行されなければならない(MUST)。


            【 議論 】
                 例えば、メールプログラムの宛先に省略形が使用される場合、
                 その省略形は完全修飾ドメイン名に展開され、その名前は
                 既に完全であるという指示とともにキューに入れられる
                 メッセージに保存されるべきである。さもないと、ユーザー
                 の探索リストではなく、メールシステムの探索リストを使用
                 して省略形が展開されるかもしれない。あるいは、ワイルド
                 カードのやりとりを伴う正規化の試みが繰り返されることで
                 名前が肥大化するかもしれない。

            最も一般的な二つの省略法は以下の通りである。

            (1)  インターフェースレベルの別名

                 インターフェースレベルの別名は、概念的に別名/ドメイン名
                 の対の一覧として実装される。この一覧はユーザーごと
                 またはホストごとに設定することができ、機能別に異なる
                 一覧を関連付けることもできる。例えばホスト名からアドレス
                 への変換用にある一覧を関連付け、メールドメイン用に別の
                 一覧を関連付けるといったこともできる。ユーザーが名前を
                 入力すると、インターフェースは、その名前が一覧の
                 エントリーの別名部分と一致するかを調査する。一致する
                 エントリーが見つかった場合、その名前は対の対応する
                 ドメイン名に置き換えられる。

Internet Engineering Task Force                                [Page 82]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


                 インターフェースレベルの別名とCNAMEは完全に別個の仕組み
                 であることに注意せよ。インターフェースレベルの別名は
                 ローカルな問題だが、CNAMEはインターネット規模で別名を
                 提供する仕組みであり、あらゆるDNS実装で必須の要素と
                 なっている。

            (2)  探索リスト

                 探索リストは、概念的に、ドメイン名を順序付けて一覧に
                 並べたものとして実装される。ユーザーが名前を入力する
                 と、探索リストに含まれるドメイン名は入力された名前の
                 サフィックスとして一つずつ使用されていき、所望する
                 関連付けられたデータが見つかるか探索リストが使い
                 尽くされるまでそれが繰り返される。探索リストには、
                 大抵ローカルホストの親ドメインや他の先祖ドメインが
                 含まれる。大抵の場合、探索リストはユーザーごとまたは
                 プロセスごとに設定される。

                 管理者は、DNSの探索リスト機能を無効にできるべきである
                 (SHOULD)。DNSの濫用を防止するため、管理上機能を拒否
                 することが容認される場合もある。

                 ユーザーの入力にドメイン名が完全であることを示す末尾
                 のピリオドがない場合、そのドメイン名が完全なドメイン名
                 であるかを調査する際に、探索リストの仕組みがルート
                 サーバーに過剰な問い合わせを生成するという危険がある。
                 これを防止するため、探索リストの仕組みは、以下の二つの
                 条項のうち一つを満たさなければならず(MUST)、両方を
                 満たすべきである(SHOULD)。

                 (a)  ローカルリゾルバー/ローカルネームサーバーは、
                      ネガティブ応答(セクション6.1.3.3参照)の
                      キャッシュを実装してもよい。

                 (b)  探索リストを使用した名前拡張処理は、生成された
                      名前を使用してルートなどのローカルでないドメイン
                      サーバーに問い合わせを試みる前に、生成された名前の
                      中に二つ以上のドットが存在することを要求してもよい。

                 【 議論 】
                      この要件の意図は、探索リストの検査時にユーザーに
                      過剰な遅延が生じるのを回避すること、また更に重要
                      なことには、ルートサーバーや他の上位サーバーに過剰
                      なトラフィックが生じるのを防止することである。
                      例えば、ユーザーが名前"X"を提供し、探索リストが
                      ルートを要素として含んでいる場合、探索リストの次の
                      選択肢を試みる前に、ルートサーバーへの問い合わせが
                      実行されなければならない。


Internet Engineering Task Force                                [Page 83]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


                      その結果、ルートサーバー及びルートサーバー近傍
                      のゲートウェイで観測される負荷は、インターネット上
                      のホスト数倍になるだろう。

                      ネガティブキャッシングを選択しない場合、ある名前が
                      初めて使用された場合の効果が制限される。また、内部
                      にドットが一つあるかで判断するルールは、実装は容易
                      だが幾つかのトップレベル名が簡単に利用できなくなる
                      可能性がある。


      6.1.5  DNSの要件の概要

                                               |           | | | |S| |
                                               |           | | | |H| |
                                               |           | | | |O|M|
                                               |           | |S| |U|U|
                                               |           | |H| |L|S|
                                               |           |M|O| |D|T|脚
                                               |           |U|U|M| | |
                                               |           |S|L|A|N|N|
                                               |           |T|D|Y|O|O|注
機  能                                         |セクション | | | |T|T| 
-----------------------------------------------|-----------|-|-|-|-|-|--
一般的な課題:                                  |           | | | | | |
                                               |           | | | | | |
名前からアドレスに変換するDNSの実装            |6.1.1      |x| | | | |
アドレスから名前に変換するDNSの実装            |6.1.1      |x| | | | |
ホストテーブルを使用した変換のサポート         |6.1.1      | | |x| | |
TTLがゼロのRRを適切に扱う                      |6.1.2.1    |x| | | | |
不必要にQCLASS=*を使用しない                   |6.1.2.2    | |x| | | |
  Internetクラスに対してQCLASS=INを使用        |6.1.2.2    |x| | | | |
使用されないフィールドはゼロにする             |6.1.2.3    |x| | | | |
応答で圧縮を使用                               |6.1.2.4    |x| | | | |
                                               |           | | | | | |
設定情報を応答に含める                         |6.1.2.5    | | | | |x|
ｳｴﾙﾉｳﾝでｸﾗｽ非依存なﾀｲﾌﾟはすべてｻﾎﾟｰﾄ           |6.1.3.5    |x| | | | |
タイプの一覧を容易に拡張できるようにする       |6.1.3.5    | |x| | | |
(MDとMFを除き)すべてのRRタイプをロード         |6.1.3.6    |x| | | | |
MDタイプまたはMFタイプをロード                 |6.1.3.6    | | | | |x|
ルートサーバー等が利用できない環境でも動作     |6.1.3.7    |x| | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
リゾルバーの課題:                              |           | | | | | |
                                               |           | | | | | |
リゾルバーが複数の同時リクエストをサポート     |6.1.3.1    | |x| | | |
フルサービスリゾルバーを実装                   |6.1.3.1    | | |x| | |
  ローカルなキャッシュ機能                     |6.1.3.1    |x| | | | |


Internet Engineering Task Force                                [Page 84]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


  ﾛｰｶﾙｷｬｯｼｭ内の情報をﾀｲﾑｱｳﾄさせる              |6.1.3.1    |x| | | | |
  起動情報で動作を設定できるようにする         |6.1.3.1    | |x| | | |
スタブリゾルバーを実装                         |6.1.3.1    | | |x| | |
  冗長な再帰ネームサーバーを使用               |6.1.3.1    |x| | | | |
  ローカルなキャッシュ機能                     |6.1.3.1    | | |x| | |
  ﾛｰｶﾙｷｬｯｼｭ内の情報をﾀｲﾑｱｳﾄさせる              |6.1.3.1    |x| | | | |
リモートのマルチホームホストをサポート:        |           | | | | | |
  複数アドレスを優先順にソートする             |6.1.3.4    | |x| | | |
                                               |           | | | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
トランスポートプロトコル:                      |           | | | | | |
                                               |           | | | | | |
UDPの問い合わせをサポート                      |6.1.3.2    |x| | | | |
TCPの問い合わせをサポート                      |6.1.3.2    | |x| | | |
  UDPを使用した問い合わせを初めに送信          |6.1.3.2    |x| | | | |1
  UDPの回答が切り詰められていた場合TCPを試みる |6.1.3.2    | |x| | | |
ﾈｰﾑｻｰﾊﾞｰがTCPの問い合わせに割り当てるﾘｿｰｽを制限|6.1.3.2    | | |x| | |
  本来不要だったTCP問い合わせを不当に扱う      |6.1.3.2    | | | |x| |
切り詰められたﾃﾞｰﾀをそうでなかったように扱う   |6.1.3.2    | | | | |x|
TCPしか使用しないように個別に合意する          |6.1.3.2    | | |x| | |
ゾーン転送でTCPを使用                          |6.1.3.2    |x| | | | |
UDPの問い合わせをブロックしないようにTCPを使用 |6.1.3.2    |x| | | | |
ﾌﾞﾛｰﾄﾞｷｬｽﾄまたはﾏﾙﾁｷｬｽﾄの問い合わせをｻﾎﾟｰﾄ     |6.1.3.2    | | |x| | |
  問い合わせでRDビットを設定                   |6.1.3.2    | | | | |x|
  RDビットが設定されている場合ｻｰﾊﾞｰは無視      |6.1.3.2    |x| | | | |
  時折り実行される死活確認としてのみ送信       |6.1.3.2    | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
リソースの使用:                                |           | | | | | |
                                               |           | | | | | |
[DNS:2]に従い伝送制御を行う                    |6.1.3.3    |x| | | | |
  ﾘｸｴｽﾄごとに消費ﾘｿｰｽの有限な上限を設定        |6.1.3.3    |x| | | | |
複数回のリトライ失敗の後ソフトエラーを返す     |6.1.3.3    |x| | | | |
一時的な障害をキャッシュ                       |6.1.3.3    | |x| | | |
ネガティブ応答をキャッシュ                     |6.1.3.3    | |x| | | |
リトライ時指数的バックオフを使用               |6.1.3.3    | |x| | | |
  リトライ間隔に上限と下限を設定               |6.1.3.3    | |x| | | |
クライアントは送信元抑制に対処                 |6.1.3.3    | |x| | | |
サーバーは送信元抑制を無視                     |6.1.3.3    | | |x| | |
-----------------------------------------------|-----------|-|-|-|-|-|--
ユーザーインターフェース:                      |           | | | | | |
                                               |           | | | | | |
すべてのﾌﾟﾛｸﾞﾗﾑがDNSｲﾝﾀｰﾌｪｰｽへのｱｸｾｽを持つ     |6.1.4.2    |x| | | | |
与えられた名前に関する全情報をリクエスト可能   |6.1.4.2    |x| | | | |
完全な情報かエラーのどちらかを返す             |6.1.4.2    |x| | | | |
特別なインターフェースの提供                   |6.1.4.2    | | |x| | |
  名前とアドレスの間の変換                     |6.1.4.2    |x| | | | |
                                               |           | | | | | |
名前を省略できる機能の提供                     |6.1.4.3    | | |x| | |


Internet Engineering Task Force                                [Page 85]


RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989


  名前が完全であることを示す表記の規則         |6.1.4.3    |x| | | | |
  省略形の展開はただ一度だけ                   |6.1.4.3    |x| | | | |
  適切なコンテキストの中で展開を行う           |6.1.4.3    |x| | | | |
  探索リスト:                                  |6.1.4.3    | | |x| | |
    管理者が機能を無効にできる                 |6.1.4.3    | |x| | | |
    ルートサーバーへの過剰な問い合わせを防止   |6.1.4.3    |x| | | | |
      二つの方法をどちらも採用                 |6.1.4.3    | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
-----------------------------------------------|-----------|-|-|-|-|-|--

1.   特定のリゾルバーと特定のサーバーの間で個別の合意がない場合に限る


Internet Engineering Task Force                                [Page 86]


RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989


   6.2  ホストの初期設定

      6.2.1  導入

         本セクションでは、接続ネットワークを介した、あるいはより一般的
         にインターネットパスを介したホストソフトウェアの初期設定に
         ついて議論する。これはディスクレスなホストには必要なもので
         あり、ディスクドライブを持つホストに対しても任意で使用する
         ことができる。ディスクレスなホストの場合、初期設定手順は"ネット
         ワークブート"と呼ばれ、ブートROMの中に位置する起動プログラム
         によって制御される。

         ディスクレスなホストをネットワークを介して初期設定するにあたり、
         以下に示す二つの異なる段階が存在する。

         (1)  IPレイヤーの設定

              ディスクレスな機器は、大抵の場合ネットワーク設定情報を保持
              する固定記憶装置を持たないので、この後に続くロード段階の
              サポートに十分な設定情報を動的に取得しなければならない。
              この設定情報には、少なくともホストとブートサーバーのIP
              アドレスが含まれていなければならない。また、ゲートウェイ
              越しのブートをサポートするため、アドレスマスクとデフォルト
              ゲートウェイの一覧も必要とされる。

         (2)  ホストのシステムコードのロード

              このロード段階の間に、適切なファイル転送プロトコルが使用
              され、ネットワークを介してブートサーバーからシステムコード
              がコピーされる。

         ディスクを持つホストが第1段階、つまりIPレイヤーの動的設定を
         実行してもよい。これはマイクロコンピューターにとって重要である。
         マイクロコンピューターはフロッピーディスクを持つため、ネット
         ワーク設定情報を誤って2台以上のホストに複製できてしまうから
         である。また、新しいホストが中央サーバーから設定情報を自動で
         取得してくれれば導入が非常に簡単になり、管理者の時間を節約
         するとともに間違いの可能性を減らすだろう。

      6.2.2  要件

         6.2.2.1  動的設定

            動的設定のために、多数のプロトコル規定が作られている。

            ・   ICMP情報リクエスト/リプライメッセージ


Internet Engineering Task Force                                [Page 87]


RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989


                 廃止されたこのメッセージの対は、ホストが自分の属する
                 ネットワークのネットワーク番号を発見できるようにする
                 ために設計された。残念なことに、この仕組みは、ホスト
                 がIPアドレスのホスト番号部を既に知っている場合にしか
                 有用ではなく、動的設定で必要とされるそのような情報を
                 ホストが保持していることはまれであった。

            ・   RARP(Reverse Address Resolution Protocol)[BOOT:4]

                 RARPは、ブロードキャストメディアで使用されるリンク
                 レイヤープロトコルで、ホストが自分のリンクレイヤー
                 アドレスをもとに自分のIPアドレスを発見できるように
                 するものである。残念ながら、RARPはIPゲートウェイを
                 越えては機能しないので、各ネットワークでRARPサーバー
                 を必要とする。更に、RARPは他のどのような設定情報
                 も提供しない。

            ・   ICMPアドレスマスクリクエスト/リプライメッセージ

                 これらのICMPメッセージにより、ホストは特定のネット
                 ワークインターフェースで使用されるアドレスマスクを
                 学習できるようになる。

            ・   BOOTPプロトコル[BOOT:2]

                 このプロトコルにより、ホストは、ローカルホストとブート
                 サーバーのIPアドレス、適切なブートファイル名、また任意
                 でアドレスマスクとデフォルトゲートウェイの一覧を決定
                 できるようになる。BOOTPサーバーの所在を特定するため、
                 ホストはUDPを使用してBOOTPリクエストをブロードキャスト
                 する。ゲートウェイを越えてBOOTPブロードキャストを転送
                 するため、場当たり的なゲートウェイ拡張が使用されて
                 きている。将来は、IPマルチキャスト機能がこの目的の
                 ための標準的仕組みを提供するだろう。


            動的設定のための推奨アプローチは、RFC 1084"BOOTPベンダー
            情報拡張(BOOTP Vendor Information Extensions)"[BOOT:3]で
            定義された拡張機能を持つBOOTPプロトコルを使用すること
            である。RFC 1084は、幾つかの重要な一般的(ベンダー固有では
            ない)拡張を定義している。具体的に、これらの拡張により、
            アドレスマスクがBOOTPで提供できるようになる。この方法で
            アドレスマスクを提供することが推奨される(RECOMMENDED)。

            【 議論 】
                 歴史的に、サブネット化はIPのだいぶ後に定義されたため、
                 ホストにアドレスマスクを提供するための独立した仕組み
                 (ICMPアドレスマスクメッセージ)が設計された。


Internet Engineering Task Force                                [Page 88]


RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989


                 しかし、IPアドレスマスクと対応するIPアドレスは概念的に
                 対をなすので、運用を簡便にするため、これらの情報は、
                 設定ファイル経由であれBOOTPのような動的な仕組み経由で
                 あれ、同じ時に同じ仕組みによって定義されるべきである。

                 BOOTPは、マルチホームホストの全インターフェースの設定を
                 指定するほど十分に汎用的ではないことに注意せよ。マルチ
                 ホームホストは、インターフェースごとにBOOTPを使用するか、
                 BOOTPを使用して一つのインターフェースを設定してロードを
                 実行し、その後ファイルから完全な初期設定を実行するかの
                 どちらかでなければならない。

                 アプリケーションレイヤーの設定情報は、システムコード
                 のロード後にファイルから取得されることになると思われる。

         6.2.2.2  ロード段階

            ロード段階の推奨アプローチは、BOOTPによって設定されたブート
            サーバーのIPアドレスとローカルホストのIPアドレス間でTFTP
            [BOOT:1]を使用することである。

            セクション4.2.3.4で説明される理由により、ブロードキャスト
            アドレスへのTFTPは使用されるべきではない(SHOULD NOT)。


Internet Engineering Task Force                                [Page 89]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


   6.3  リモート管理

      6.3.1  導入

         近年、インターネットコミュニティはネットワーク管理プロトコル
         の開発に多大な労力をつぎ込んできた。その成果は、二つのアプローチ
         に分かれた[MGT:1、MGT:6]。一つはSNMP(Simple Network Management 
         Protocol)[MGT:4]で、もう一つはCMOT(Common Management Information
         Protocol over TCP)[MGT:5]である。

         SNMPまたはCMOTを使用した管理下に入るにあたり、ホストは適切な
         管理エージェントを実装する必要がある。インターネットホストは、
         SNMPかCMOTのどちらかのエージェントを含むべきである(SHOULD)。

         SNMP、CMOTのどちらも収集対象の管理値を定義するMIB(Management
         Information Base)を使用して動作する。これらの値を読み取ったり
         設定したりすることで、リモートアプリケーションは管理対象
         システムの状態を問い合わせたり変更したりできるようになる。

         標準MIB[MGT:3]は、[MGT:2]で定義されたSMI(Structure of 
         Management Information)で規定されているデータタイプを使用する
         ことで、どちらの管理プロトコルでも使用できるように定義されて
         いる。追加のMIB変数は、MIB名前空間[MGT:2]の"enterprises"
         及び"experimental"下位のサブツリーに導入することができる。

         ホストの各プロトコルモジュールは、関連するMIB変数を実装すべき
         である(SHOULD)。ホストは、最も新しい標準MIBで定義されている
         MIB変数を実装すべきであり(SHOULD)、標準外のMIB変数もそれが
         適切で有用であれば実装してもよい(MAY)。

      6.3.2  プロトコルのウォークスルー

         MIBは、ホストとゲートウェイの両方をカバーすることが意図されて
         いるが、MIBアプリケーションは、両者の間に細かい点で違いがある。
         本セクションは、ホストに関するMIBの適切な解釈を含む。今後
         現れるバージョンのMIBには、ホスト管理のためのエントリーが
         より多く含まれるかもしれない。

         管理対象ホストは、system, interface, at(address translation), 
         ip, icmp, tcp, udpといったMIBオブジェクトを定義するグループ
         を実装しなければならない。

         以下に示す固有の解釈をホストに適用する。

         ・   ipInHdrErrors

              "転送中TTL超過"のエラーは、ホストがソースルート指定された
              データグラムを転送する場合にしか発生し得ないことに注意せよ。


Internet Engineering Task Force                                [Page 90]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


         ・   ipOutNoRoutes

              このオブジェクトは、宛先までのルートを見つけられなかった
              ために破棄されたデータグラム数を計測する。ホストにおいて、
              設定内にあるすべてのデフォルトゲートウェイがダウンすると、
              そのような状況が発生する可能性がある。

         ・   ipFragOKs, ipFragFails, ipFragCreates

              意図的なフラグメンテーションを実装していないホスト([INTRO:1]
              の"フラグメンテーション"セクションを参照せよ)は、これら
              三つのオブジェクトに対して値ゼロを返さなければならない(MUST)。

         ・   icmpOutRedirects

              ホストの場合、リダイレクトを送信しないので、このオブジェクト
              は常にゼロでなければならない(MUST)。

         ・   icmpOutAddrMaskReps

              ホストの場合、そのホストがアドレスマスクの権威を持つ
              情報源でない限り、このオブジェクトは常にゼロでなければ
              ならない(MUST)。

         ・   ipAddrTable

              ホストの場合、この"IPアドレステーブル"オブジェクトは、
              実質的に論理インターフェースのテーブルである。

         ・   ipRoutingTable

              ホストの場合、この"IPルーティングテーブル"オブジェクトは、
              実質的にホストのルートキャッシュと[INTRO:1]の"送信データ
              グラムのルーティング"セクション記載の静的ルーティング
              テーブルを組み合わせたものである。

              各ipRouteEntry配下のipRouteMetric1～ipRouteMetric4は、
              ホストの場合通常意味を持たないので常に-1とすべきである
              (SHOULD)。またipRouteTypeは通常の場合、値"remote"を持つ
              ことになる。

              接続ネットワーク上にある宛先がルートキャッシュ内にない場合
              ([INTRO:1]の"送信データグラムのルーティング"セクションを
              参照せよ)、値"direct"を持つipRouteTypeエントリーは存在
              しない。


Internet Engineering Task Force                                [Page 91]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


         【 議論 】
              現在のMIBはipRouteEntry配下にタイプオブサービスを含まない
              が、将来の改訂でその追加がなされることが期待される。

              また、アプリケーションのリモート管理(例えば、メールシステム
              を部分的に再設定する機能)を可能にするためにMIBが拡張される
              ことも期待される。従って、メールシステムのようなネット
              ワークサービスアプリケーションは、リモート管理で使用される
              "フック"も含めて書かれるべきである。

      6.3.3  リモート管理の要件の概要

                                               |           | | | |S| |
                                               |           | | | |H| |
                                               |           | | | |O|M|
                                               |           | |S| |U|U|
                                               |           | |H| |L|S|
                                               |           |M|O| |D|T|脚
                                               |           |U|U|M| | |
                                               |           |S|L|A|N|N|
                                               |           |T|D|Y|O|O|注
機  能                                         |セクション | | | |T|T| 
-----------------------------------------------|-----------|-|-|-|-|-|--
SNMPかCMOTのエージェントをサポート             |6.3.1      | |x| | | |
標準MIBで規定されたオブジェクトを実装          |6.3.1      | |x| | | |


Internet Engineering Task Force                                [Page 92]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


7.  REFERENCES

   This section lists the primary references with which every
   implementer must be thoroughly familiar.  It also lists some
   secondary references that are suggested additional reading.

   INTRODUCTORY REFERENCES:


   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
        October 1989.

   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
        (three volumes), SRI International, December 1985.

   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
        RFC-1011, May 1987.

        This document is republished periodically with new RFC numbers;
        the latest version must be used.

   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
        Postel, RFC-980, March 1986.

   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
        May 1987.

        This document is republished periodically with new RFC numbers;
        the latest version must be used.


   TELNET REFERENCES:


   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
        Reynolds, RFC-854, May 1983.

   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
        RFC-855, May 1983.

   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
        RFC-856, May 1983.

   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
        May 1983.

   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.


Internet Engineering Task Force                                [Page 93]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


        Reynolds, RFC-858, May 1983.

   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
        859, May 1983.

   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
        RFC-860, May 1983.

   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
        Reynolds, RFC-861, May 1983.

   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-885,
        December 1983. (訳注: 本段落はErrata ID: 584を反映している)

   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
        February 1989.

        This document supercedes RFC-930.

   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
        October 1988.

   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
        1989.

   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
        December 1988.

   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
        1080, November 1988.


   SECONDARY TELNET REFERENCES:


   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
        Defense, May 1984.

        This document is intended to describe the same protocol as RFC-
        854.  In case of conflict, RFC-854 takes precedence, and the
        present document takes precedence over both.

   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.

   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
        1977.

   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.


Internet Engineering Task Force                                [Page 94]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
        1988.


   FTP REFERENCES:


   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
        959, October 1985.

   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
        December 1974.

   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
        Defense, May 1984.

        This document is based on an earlier version of the FTP
        specification (RFC-765) and is obsolete.


   TFTP REFERENCES:


   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
        1981.


   MAIL REFERENCES:


   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
        1982.

   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
        D. Crocker, RFC-822, August 1982.

        This document obsoleted an earlier specification, RFC-733.

   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
        974, January 1986.

        This RFC describes the use of MX records, a mandatory extension
        to the mail delivery process.

   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
        February 1988.


Internet Engineering Task Force                                [Page 95]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
        June 1986.

   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.

        The two preceding RFC's define a proposed standard for
        gatewaying mail between the Internet and the X.400 environments.

   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
        Department of Defense, May 1984.

        This specification is intended to describe the same protocol as
        does RFC-821.  However, MIL-STD-1781 is incomplete; in
        particular, it does not include MX records [SMTP:3].

   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
        RFC-1049, March 1988.


   DOMAIN NAME SYSTEM REFERENCES:


   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
        RFC-1034, November 1987.

        This document and the following one obsolete RFC-882, RFC-883,
        and RFC-973.

   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
        P. Mockapetris, November 1987.


   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
        January 1986.


   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
        RFC-952, M. Stahl, E. Feinler, October 1985.

        SECONDARY DNS REFERENCES:


   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
        RFC-953, October 1985.

   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
        1987.


Internet Engineering Task Force                                [Page 96]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
        1033, November 1987.

   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
        Protocol Handbook, NIC 50007, SRI Network Information Center,
        August 1989.


   SYSTEM INITIALIZATION REFERENCES:


   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
        1984.

   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
        951, September 1985.

   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
        1084, December 1988.

        Note: this RFC revised and obsoleted RFC-1048.

   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.


   MANAGEMENT REFERENCES:


   [MGT:1]  "IAB Recommendations for the Development of Internet Network
        Management Standards," V. Cerf, RFC-1052, April 1988.

   [MGT:2]  "Structure and Identification of Management Information for
        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
        August 1988.

   [MGT:3]  "Management Information Base for Network Management of
        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
        August 1988.

   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
        M. Schoffstall, and C. Davin, RFC-1098, April 1989.

   [MGT:5]  "The Common Management Information Services and Protocol
        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.

   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
        Group," V. Cerf, RFC-1109, August 1989.


Internet Engineering Task Force                                [Page 97]


RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989


セキュリティに関する考慮点

   ホストソフトウェアのアプリケーションプログラム及びサポートプログラム
   には多くのセキュリティに関する課題が存在するが、抜けのない完全な議論は
   本RFCの対象範囲を越えている。セキュリティに関する課題は、TFTPに関連
   するセクション(セクション4.2.1、4.2.3.4、4.2.3.5)、SMTPのVRFYコマンド
   及びEXPNコマンドに関連するセクション(セクション5.2.3)、SMTP HELO
   コマンドに関連するセクション(セクション5.2.5)、SMTP DATAコマンドに関連
   するセクション(セクション5.2.8)でそれぞれ述べられている。

Author's Address

   Robert Braden
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   Phone: (213) 822 1511

   EMail: Braden@ISI.EDU


Internet Engineering Task Force                                [Page 98]