Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Network Working Group P. Hethmon Request for Comments: 2389 Hethmon Brothers See Also: 959 R. Elz Category: Standards Track University of Melbourne August 1998 Feature negotiation mechanism for the File Transfer Protocol ファイル転送プロトコルのための機能取り決めメカニズム （本当にこんな訳でいいのん？：訳注） 訳者より この文書はRFC2389を自分のために翻訳したものです。 原文で述べられていることには、訳者（私）の英文読解能力、 コンピュータに関する知識を越えた部分があり、したがってこの文書 には誤解、誤訳が含まれている可能性があります。そのことを御承知 の上でこの文書を利用するようにしてください。 私が付けたコメントは MyComment = "（" "：訳注）" ; BNFにて:-) で書かれています。コメントには、私がその部分を訳しきれなかった ことを示すものもあります。そのような箇所（もちろんそうじゃない 部分も）の修正案を歓迎します。 また、文脈の上で特に強調する必要があると判断した語句については MyEmphasis = "＊" "＊" で強調しています。 日本語訳の配布条件は原文のそれに従いますが、上記のことに充分 注意してください。結局、ここにあるのは原文とは異なる物です。 山田 哲央 ivy@ma.kcom.ne.jp Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書はインターネットコミュニティのためのインターネットの 標準過程の取り決めを定め、改善のための議論と提案を要求する。 標準化状況とこの取り決めの状態を知るためには、"Internet Official Protocol Standards" (STD 1)の現行版を参照すること。このメモの 配布は無制限である。 Abstract The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms. This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. 時にファイル転送プロトコルは、新しいコマンドや設備で拡張される。 FTPプロトコルを実装するプログラムが、全ての新しく定義された メカニズムをすぐにすっかり装備するとは考えにくい。この文書は、 FTPプロトコルのクライアントがどの新しい長所が特定のFTPサーバで サポートされているかを判別することができるメカニズムを提供する。 Hethmon & Elz Standards Track [Page 1]  RFC 2389 Feature negotiation mechanism August 1998 Table of Contents Abstract ................................................ 1 1 Introduction ............................................ 2 2 Document Conventions .................................... 2 2.1 Basic Tokens ............................................ 3 2.2 Server Replies .......................................... 3 3 Knowledge of Extra Capabilities - the FEAT Command ...... 3 3.1 Feature (FEAT) Command Syntax ........................... 4 3.2 FEAT Command Responses .................................. 4 3.3 Rationale for FEAT ...................................... 6 4 The OPTS Command ........................................ 6 5 Security Considerations ................................. 7 6 References .............................................. 8 Acknowledgements ........................................ 8 Editors' Addresses ...................................... 8 Full Copyright Statement ................................ 9 1. Introduction This document amends the File Transfer Protocol (FTP) [1]. Two new commands are added: "FEAT" and "OPTS". この文書はファイル転送プロトコル（FTP）[1]を改正する。"FEAT"と "OPTS"の２つの新しいコマンドを追加する。 These commands allow a client to discover which optional commands a server supports, and how they are supported, and to select among various options that any FTP command may support. これらのコマンドは、クライアントがサーバがどのオプションコマンドを どのようにサポートしているかを判別し、そして何らかのFTPコマンドが サポートしているかもしれない様々なオプションを選択することを、 可能にする。 2. Document Conventions This document makes use of the document conventions defined in BCP14 [2]. That provides the interpretation of some capitalized words like MUST, SHOULD, etc. この文書はBCP14 [2]で定義されている文書のしきたりを利用する。 これは、MUST、SHOULDのような、いくつかの大文字で書かれた 単語の解釈を与えてくれるものである。 Terms defined in [1] will be used here as defined there. These include ASCII, reply, server-FTP process, user-FTP process, server- PI, user-PI, and user. [1] で定義されている言葉はここでも、そこで定義されているのと 同じ意味で使われる。それらの言葉は、ASCII、返答、サーバ側FTP プロセス、ユーザ側FTPプロセス、サーバ側PI、ユーザ側PIやユーザ を含む。（この文書ではreplyを返答、responseを応答と訳して います：訳注） Syntax required is defined using the Augmented BNF defined in [3]. Some general ABNF definitions are required throughout the document, those will be defined here. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section. 必要とされる構文は、[3] で定義されている拡張BNFを使って定義される。 いくつかの一般的なABNFの定義は文書全般で必要とされ、それらは ここで定義される。最初に読むのなら（？At first reading：訳注）、 これらの定義はここにあることを思い起こし、この次の章に戻って 来るのが賢いやり方だろう。 Hethmon & Elz Standards Track [Page 2]  RFC 2389 Feature negotiation mechanism August 1998 2.1. Basic Tokens This document imports the definitions given in Appendix A of [3]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, VCHAR, SP, etc. To that, the following terms are added for use in this document. この文書は [3] の付録Aにある定義を持ち込む。そこでは、ALPHA、 DIGIT、VCHAR、SPなどの基本的なABNFの要素が定義されている。 （？To that：訳注）以下の語句をこの文書での使用のために追加する。 TCHAR = VCHAR / SP / HTAB ; visible plus white space The TCHAR type, and VCHAR from [3], give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses. TCHARタイプと [3] のVCHARは、ASCII文字集合のさまざまな部分集合 から基本的な文字タイプを与え、これらはいろいろな命令と応答で使用 することができる。 error-response = error-code SP *TCHAR CRLF error-code = ("4" / "5") 2DIGIT Note that in ABNF, strings literals are case insensitive. That convention is preserved in this document. However note that ALPHA, in particular, is case sensitive, as are VCHAR and TCHAR. ABNFでは、文字変数はケースインセンシティブであることに注意 しなければならない。このしきたりはこの文書でも維持される。 しかしながら、特にALPHAは、VCHARやTCHARのようにケース センシティブであることに注意しなければならない。 （ケースセンシティブとは、大文字と小文字を区別すること。 インセンシティブはその逆：訳注） 2.2. Server Replies Section 4.2 of [1] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change. Implementors should note that the ABNF syntax (which was not used in [1]) in this document, and other FTP related documents, sometimes shows replies using the one line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may be of the multiline format described in [1]. [1] の4.2章は、サーバ側PIによる、ユーザ側PIからのFTPコマンドへの 応答の書式と意味の定義である。この応答のしきたりはここでも変更 なく使われる。この文書と他のFTP関連の文書でのABNFの構文（これは [1] では使われていない）が、１行の書式を使って応答を表現している時 があることに実装者は注意すべきである。はっきりと述べられていない 限り、これは複数行に渡る応答を禁止することを意味しているわけでは ない。それとは逆に、述べられていなければ、（QUITを含む）いかなる FTPコマンドの応答も、 [1] で述べられている複数行書式でかまわない ことに注意するべきである。 Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 Reply" means a reply from the server-PI using the three digit code "500". この文書全般で、返答はその最初の要素である３つの１０進数コード によって識別される。"500 Reply"のような言葉は、サーバ側PIから の"500"という３つの１０進数コードを使った応答を意味する。 3. Knowledge of Extra Capabilities - the FEAT Command It is not to be expected that all servers will necessarily support all of the new commands defined in all future amendments to the FTP protocol. In order to permit clients to determine which new commands are supported by a particular server, without trying each possible command, one new command is added to the FTP command repertoire. This command requests the server to list all extension commands, or extended mechanisms, that it supports. That is, all defined and specified commands and features not defined in [1], or this document, must be included in the FEAT command output in the form specified in Hethmon & Elz Standards Track [Page 3]  RFC 2389 Feature negotiation mechanism August 1998 the document that defines the extension. 全てのサーバが必ず、FTPプロトコルの全ての未来の修正案で定義 された、全ての新しいコマンドをサポートすると期待するべきでは ない。クライアントが可能なコマンドそれぞれを試すことなく、 特定のサーバでサポートされている新しいコマンドがどれかを決定 することを可能にするために、新しいコマンドを１つFTPコマンドの レパートリーに加える。このコマンドは、サーバにそれがサポート している全ての拡張コマンド、あるいは拡張メカニズムをリストする ことを要求する。つまり、 [1] やこの文書で定義されていない全ての、 定義され指定されたコマンドと長所が、拡張を定義する文書で指定 された形式で、FEATコマンドの出力に含まれなければならない。 User-FTP PIs must expect to see, in FEAT command responses, unknown features listed. This is not an error, and simply indicates that the server-FTP implementor has seen, and implemented, the specification of a new feature that is unknown to the user-FTP. ユーザ側FTP PI（プロトコルインタープリタ：訳注）は、FEATコマンドの 応答で、未知の特徴がリストされることになることを予期しなければ ならない。これはエラーではなく、単にサーバ側FTPの実装者が ユーザ側FTPに知られていない新しい特徴の仕様に出会い、そしてそれを 装備したことを示しているに過ぎない。 3.1. Feature (FEAT) Command Syntax feat = "Feat" CRLF The FEAT command consists solely of the word "FEAT". It has no parameters or arguments. FEATコマンドは"FEAT"という単語それ１つで成り立っている。 パラメータや引数は持たない。 3.2. FEAT Command Responses Where a server-FTP process does not support the FEAT command, it will respond to the FEAT command with a 500 or 502 reply. This is simply the normal "unrecognized command" reply that any unknown command would elicit. Errors in the command syntax, such as giving parameters, will result in a 501 reply. サーバ側FTPプロセスがFEATコマンドをサポートしていないサイトでは、 サーバはFEATコマンドに対して500か502返答を応答するだろう。 これは、あらゆる未知のコマンドが引き出す、普通の「コマンドが理解 できない」という意味の応答である。パラメータを与えたなどコマンドの 構文上でのエラーがあった場合、501返答の結果になる。 Server-FTP processes that recognize the FEAT command, but implement no extended features, and therefore have nothing to report, SHOULD respond with the "no-features" 211 reply. However, as this case is practically indistinguishable from a server-FTP that does not recognize the FEAT command, a 500 or 502 reply MAY also be used. The "no-features" reply MUST NOT use the multi-line response format, exactly one response line is required and permitted. FEATコマンドを認知できるが拡張された機能を実装しておらず、したがって 報告すべき機能を持たないサーバ側FTPプロセスは、211の「拡張機能なし」 返答で応答する＊べき＊である。しかしながら、この場合、実質的にFEAT コマンドを認知できないサーバ側FTPと区別することが出来ないが、 500 または502返答が使われても＊かまわない＊。「拡張機能無し」の返答は 複数行の応答書式を使っては＊ならない＊。正確に１行である応答が要求され、 そして許される。 Replies to the FEAT command MUST comply with the following syntax. Text on the first line of the reply is free form, and not interpreted, and has no practical use, as this text is not expected to be revealed to end users. The syntax of other reply lines is precisely defined, and if present, MUST be exactly as specified. FEATコマンドに対する返答は、以下の構文に従わなければ＊ならない＊。 返答の最初の行の文の形式は自由で、解釈されず、実際の有用性を 持たない。なぜなら、この文をエンドユーザに示すことは、期待され ていないからである。返答の他の行の構文は正確に定義されていて、 そしてもし存在するなら、指定された物にきっちりと一致しなければ ＊ならない＊。 feat-response = error-response / no-features / feature-listing no-features = "211" SP *TCHAR CRLF feature-listing = "211-" *TCHAR CRLF 1*( SP feature CRLF ) "211 End" CRLF feature = feature-label [ SP feature-parms ] feature-label = 1*VCHAR feature-parms = 1*TCHAR Note that each feature line in the feature-listing begins with a single space. That space is not optional, nor does it indicate general white space. This space guarantees that the feature line can Hethmon & Elz Standards Track [Page 4]  RFC 2389 Feature negotiation mechanism August 1998 never be misinterpreted as the end of the feature-listing, but is required even where there is no possibility of ambiguity. 拡張機能リストの各機能の行が１つのスペースで始まることに注意して ほしい。このスペースはオプションでも、普通の空白を示すものでも ない。このスペースは、機能の行（機能について書いてある行：訳注） がリストの終了と勘違いされることが決してないことを保証する。 これは、勘違いされる可能性がまったくないと思われる状況ですら必要 とされる。 Each extension supported must be listed on a separate line to facilitate the possible inclusion of parameters supported by each extension command. The feature-label to be used in the response to the FEAT command will be specified as each new feature is added to the FTP command set. Often it will be the name of a new command added, however this is not required. In fact it is not required that a new feature actually add a new command. Any parameters included are to be specified with the definition of the command concerned. That specification shall also specify how any parameters present are to be interpreted. サポートされる拡張それぞれは、各拡張コマンドでサポートされる パラメータを含めることを容易にするために、別々の行に リストされなければならない。FEATコマンドの応答で使われる機能の ラベル（feature-label：訳注）は、新しい機能それぞれがFTPコマンド の集合に追加される時に、指し示されるだろう。必ずそうしなければ ならないわけではないが、これは追加される新しいコマンドの名前に なることが多いだろう。事実、新しい機能のために本当に新しい コマンドを追加することは、求められていない（新しい機能のために 新しいコマンドを動的に生成しなくてもよい：訳注）。含まれる パラメータは、それがどんなものであれ、コマンドに関連した記述で 指定されなければならない。この指定は、何かここにあるパラメータが どのように解釈されるかも、指し示さなければ＊ならない＊。 The feature-label and feature-parms are nominally case sensitive, however the definitions of specific labels and parameters specify the precise interpretation, and it is to be expected that those definitions will usually specify the label and parameters in a case independent manner. Where this is done, implementations are recommended to use upper case letters when transmitting the feature response. 普通、ラベルとパラメータ（feature-parms：訳注）は大文字と 小文字を区別するが、具体的なラベルやパラメータの定義は正確な 解釈を指し示すし、さらに通常はこれらの定義は大文字と小文字 を区別するかどうかとは無関係の方法でラベルとパラメータを 指定することが予想される。これが成される場合、機能の応答を 伝達するときにプログラム（implementations：訳注）は大文字を 使うことが推奨される。 The FEAT command itself is not included in the list of features supported, support for the FEAT command is indicated by return of a reply other than a 500 or 502 reply. FEATコマンド自体は、サポートされる拡張機能のリストには含めず、 FEATコマンドのサポートは、500や502以外の返答の返却によって 示される。 A typical example reply to the FEAT command might be a multiline reply of the form: FEATコマンドの典型的な返答は、この形式の複数行返答のように なるだろう： C> feat S> 211-Extensions supported: S> MLST size*;create;modify*;perm;media-type S> SIZE S> COMPRESSION S> MDTM S> 211 END The particular extensions shown here are simply examples of what may be defined in other places, no particular meaning should be attributed to them. Recall also, that the feature names returned are not command names, as such, but simply indications that the server possesses some attribute or other. ここに示された具体的な拡張は、どこかで定義されているかもしれない 単なる例であり、これから何らかの意味を見い出すべきではない。 このように、返って来た拡張機能の名前はコマンド名ではなく、単に サーバが何らかの属性等を持っていることの示唆であることも思い出して ほしい。 The order in which the features are returned is of no importance, server-FTP processes are not required to implement any particular order, or even to consistently return the same order when the command is repeated. 拡張機能が返却される順番は重要ではなく、サーバ側FTPプロセス は何か特定の順番を装備したり、コマンドが繰り返されたときに 同じ順番を一貫して返す必要すらない。 Hethmon & Elz Standards Track [Page 5]  RFC 2389 Feature negotiation mechanism August 1998 FTP implementations which support FEAT MUST include in the response to the FEAT command all properly documented FTP extensions beyond those commands and mechanisms described in RFC959 [1], including any which existed before the existence of FEAT. That is, when a client receives a FEAT response from an FTP server, it can assume that the only extensions the server supports are those that are listed in the FEAT response. FEATをサポートするFTPプログラムは、FEATが登場する前から存在した 物も含めて、RFC959 [1] で述べられている物を越えるコマンドとメカニズム について、すべてのFTP拡張を適切に文書化してFEATコマンドの応答に 含めなけらば＊ならない＊。 User-FTP processes should, however, be aware that there have been several FTP extensions developed, and in widespread use, prior to the adoption of this document and the FEAT command. The effect of this is that an error response to the FEAT command does not necessarily imply that those extensions are not supported by the server-FTP process. User-PIs should test for such extensions individually if an error response has been received to the FEAT command. しかしながらユーザFTPプロセスは、開発され、広く普及していて、 この文書やFEATコマンドを採用するよりも優先するようなたくさんの FTP拡張があることを知っているべきである。その結果として、 FEATコマンドに対するエラー応答が、必ずしもそのような拡張が サーバ側FTPプロセスでサポートされていないことを示している というわけではない。ユーザ側PIは、FEATコマンドに対してエラー 応答を受け取った場合、これらの拡張を個別にテストしてみるべき である。 3.3. Rationale for FEAT While not absolutely necessary, a standard mechanism for the server- PI to inform the user-PI of any features and extensions supported will help reduce unnecessary traffic between the user-PI and server- PI as more extensions may be introduced in the future. If no mechanism existed for this, a user-FTP process would have to try each extension in turn resulting in a series of exchanges between the user-PI and server-PI. Apart from being possibly wasteful, this procedure may not always be possible, as issuing of a command just to determine if it is supported or not may have some effect that is not desired. 絶対に必要というわけではないが、サーバ側PIがユーザ側PIにサポート されている機能や拡張を報告するための標準的なメカニズムは、将来、 より多くの拡張が導入されたとき、ユーザ側PIとサーバ側PIの間の 不必要なトラフィックを減らす手助けになるだろう。もしこのための メカニズムがなかったら、ユーザ側FTPプロセスは次々と各拡張を 試さなければならず、結果としてユーザ側PIとサーバ側PIの間でやり 取りが繰り返されることになるだろう。 （ここからわからない：訳注） 浪費的になり得る状態から離れ、 この手続きはいつでも可能であるわけではない。 ただそれがサポートされているかどうかを判別するためのコマンドを 導入することが、何らかの望まれない効果を出すかもしれない 4. The OPTS Command The OPTS (options) command allows a user-PI to specify the desired behavior of a server-FTP process when another FTP command (the target command) is later issued. The exact behavior, and syntax, will vary with the target command indicated, and will be specified with the definition of that command. Where no OPTS behavior is defined for a particular command there are no options available for that command. OPTS（option）コマンドは、もう１つのFTPコマンド（ターゲットコマンド） が後で発行された時に、ユーザ側PIがサーバ側FTPプロセスの望ましい動作を 指定することを可能にする。正確な動作と構文は、指定されたターゲット コマンドによって異なり、そのコマンドの記述で指定されることになる。 特定のコマンドに対してOPTSの動作が定義されていなければ、そのコマンド には使用可能なオプションはない。 Request Syntax: opts = opts-cmd SP command-name [ SP command-options ] CRLF opts-cmd = "opts" command-name = command-options = Hethmon & Elz Standards Track [Page 6]  RFC 2389 Feature negotiation mechanism August 1998 Response Syntax: opts-response = opts-good / opts-bad opts-good = "200" SP response-message CRLF opts-bad = "451" SP response-message CRLF / "501" SP response-message CRLF response-message = *TCHAR An "opts-good" response (200 reply) MUST be sent when the command- name specified in the OPTS command is recognized, and the command- options, if any, are recognized, and appropriate. An "opts-bad" response is sent in other cases. A 501 reply is appropriate for any permanent error. That is, for any case where simply repeating the command at some later time, without other changes of state, will also be an error. A 451 reply should be sent where some temporary condition at the server, not related to the state of communications between user and server, prevents the command being accepted when issued, but where if repeated at some later time, a changed environment for the server-FTP process may permit the command to succeed. If the OPTS command itself is not recognized, a 500 or 502 reply will, of course, result. OPTSコマンドで指定されたコマンド名が認知され、コマンドオプション （command-options：訳注）があった場合にはそれが認知され、さらに それが適切であった時、「opts-good」応答（200返答）が送られなければ ＊ならない＊。「opts-bad」応答は、それ以外の場合に送られる。 501返答は、任意の恒久的エラーの場合に適切である。つまり、 状態を変えることなく後で単にコマンドを繰り返してもエラーになる ような任意の場合である。451返答は、コマンドが発行された時に、 ユーザとサーバの間のやり取りの状況とは関係なく、サーバ側の何らかの 一時的な状況がそれの受け入れを妨げたが、もし後になってコマンドが 繰り返されたなら、サーバ側FTPプロセスの変化した環境がコマンドの 成功を許すかもしれないような場面で送られるべきである。もしOPTS コマンド自体が認知されなければ、もちろん、500あるいは502返答が 結果として起こるだろう。 The OPTS command MUST be implemented whenever the FEAT command is implemented. Because of that, there is no indication in the list of features returned by FEAT to indicate that the OPTS command itself is supported. Neither the FEAT command, nor the OPTS command, have any optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS" commands. OPTSコマンドは、FEATコマンドが実装されているなら、いつでも実装されて いなければ＊ならない＊。なぜなら、FEATで返却される機能のリストには、 OPTSコマンドそれ自体がサポートされていることを示すための印がないからである。 FEATコマンドもOPTSコマンドも何らかのオプション機能を持たないので、 「OPTS FEAT」や「OPTS OPTS」のようなコマンドは存在しない。 5. Security Considerations No significant new security issues, not already present in the FTP protocol, are believed to have been created by this extension. However, this extension does provide a mechanism by which users can determine the capabilities of an FTP server, and from which additional information may be able to be deduced. While the same basic information could be obtained by probing the server for the various commands, if the FEAT command were not provided, that method may reveal an attacker by logging the attempts to access various extension commands. This possibility is not considered a serious enough threat to be worthy of any remedial action. FTPプロトコルですでにあるものではないもので、 この拡張によって産み出された意味深い新しいセキュリティの発行は ないと考えられる（？この文わかりません：訳注） しかしこの拡張は、ユーザがあるFTPサーバの能力を判別することが できるメカニズムを提供（ここ重要：訳注）していて、これから 付加的な情報も推測できるかもしれない。様々なコマンドを用いて サーバを調査することで同様の基本情報を得ることができるが、FEAT コマンドが提供されていなければ、この方法は様々な拡張コマンドに 接近する試みのログを取ることで攻撃者を暴くかもしれない。この 可能性は、何らかの対処に値するほど深刻な脅威であるとは考えられない。 The security of any additional features that might be reported by the FEAT command, and manipulated by the OPTS command, should be addressed where those features are defined. FEATコマンドで報告されたりOPTSコマンドで操作されるであろう 何らかの付加的機能のセキュリティは、それらの機能が定義されて いる所で言及されるべきである。 Hethmon & Elz Standards Track [Page 7]  RFC 2389 Feature negotiation mechanism August 1998 6. References [1] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Acknowledgements This protocol extension was developed in the FTPEXT Working Group of the IETF, and the members of that group are all acknowledged as its creators. このプロトコル拡張はIETFのFTPEXT Working Groupで開発された、 また、このグループのメンバーはすべてその作者として認知されている。 Editors' Addresses Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville, TN 37923 USA Phone: +1 423 690 8990 Email: phethmon@hethmon.com Robert Elz University of Melbourne Department of Computer Science Parkville, Vic 3052 Australia Email: kre@munnari.OZ.AU Hethmon & Elz Standards Track [Page 8]  RFC 2389 Feature negotiation mechanism August 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hethmon & Elz Standards Track [Page 9]