RFC2223-ja-NJT.TXT 本文書は RFC2223 Instructions to RFC Authors RFCの著者への手引 の日本語訳である。 第1.2版（レビュー待ちバージョン） ※「 20. 付録 − RFC用nroffマクロ」を除いて翻訳完了しました。 ※みなさまのレビューをお願いします。 著作権表示 Copyright (C) The Internet Society (1997). All Rights Reserved. 日本語訳についての二次的著作権は： Derivative copyright about Japanese translation: Copyright (C) NAKAZATO Takeshi (1998). All Rights Reserved. 配布条件 日本語訳の配布条件は英語の原文の配布条件に従う。（無制限） ただし、無保証であることに注意すること。 翻訳にあたっての方針 逐語訳ではなく、日本語の文章として自然であるように訳した。したがっ て、受動態を能動態として訳したところもある。規格書として文意が変わ らないよう心がけたが、英文が公式であることに注意されたい。 一般的に雑誌などで訳されずに、テクニカル・タームとしてカタカナ書き で使われているものはそれに従った。また、固有名詞あるいはそれに類す るもの、日本語訳の定着していないものについては、英文綴りのままとし、 必要に応じて初出の際にカッコ書きで日本語訳を付した。 例： Internet Protocol → ○ インターネット・プロトコル × 網際手順 Carrige return & line feed → 復帰改行（キャリッジ・リターンおよびライン・フィード） Obsolete → Obsolete(廃止) 文体は技術文書としての性格から常体（「だ、である」体）とした。 3a.の第10段落によると相互参照にページ番号を用いるべきではないとい うことであり、翻訳にあたってページが保存される必要がないとも解され るが、これは原稿提出にあたっての注意であって、RFCの原本はASCIIテキ スト版のみであるとも解される。本RFCの翻訳にあたっては暫定的に元の ページ区切りのままとした。 原文の段落は保存した。原文の文は保存するように心がけたが、自然な日 本語とする都合上、変えたところもある。 表記について カタカナ語の末尾の音引きについては原則として、（末尾の音引きを含ま ずに）３文字以上（拗音を示す小さい文字は１文字として数えない）の場 合には省略する、こととした。 例： ヘッダ、コンピュータ、メーラ、バッファ、ディザー 但し、慣用の表記があるものはそれに従った 例： バークレー カタカナ語の表記については慣用にしたがった。 例： ○ メール × メイル ASCII文字（「半角」）が２バイト文字(JIS X0208)（「全角」）の半分の 幅となる等幅フォントで読まれることを仮定した。 １行は「半角」70文字とし、禁則処理のため句読点を行末にぶら下げる必 要のある場合には１文字分に限って許容した。（本文3aから類推） 検索の便を考え、英数字はASCIIを原則とし、JIS X0208の英数字（全角英 数字）は使わない。ただしASCIIに含まれないものは除く。 完全な著作権表示 （訳者註：以下、法律効果を持つ文章なので、翻訳は参考にとどめ、必ず原文 を用いること。） Copyright (C) The Internet Society (1997). All Rights Reserved. 日本語訳についての二次的著作権は： Derivative copyright about Japanese translation: Copyright (C) NAKAZATO Takeshi (1998). All Rights Reserved. 上記の著作権表示および本項がすべての写しおよび二次的著作物に含まれる ことを条件として、本文書とその翻訳の複製および他者への提供、および、 二次的著作物、すなわち本文書へのコメント他の表現による解説、実装の支 援、の全部または一部の作成、複製、公開、配布をいかなる制限なしに許諾 する。但し、本文書そのものはいかなる方法、すなわちthe Internet Societyその他のインターネット機関への言及および著作権表示の削除によ る等の改変も禁ずるが、但し、インターネット標準を定める目的でインター ネット標準化過程に定める著作権手続に従うために必要な場合、あるいは英 語以外の言語に翻訳するために必要な場合を除く。 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 implmentation 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 Internet Societyまたは その承継人あるいは被譲渡人が撤回することはない(WILL NOT)。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 本文書と本文書に含まれる情報は「ありのまま(AS IS)」として提供される ものであり、「the Internet Societyおよびthe Internet Engineering Task Forceは、明示、黙示の別をとわず、ここに含まれる情報の利用がい かなる権利も侵害しない保証、あるいは商業的あるいは特定目的への適合 性のいかなる黙示の保証を含み、これらに限られないいかなる保証も否認 する。」 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." 日本語訳に関する二次的著作権については、上記の許諾・否認声明におけ る原著作権者（the Internet Society）を訳者（中里武志）と読み替えて これを準用する。 About derivative copyright on Japanese translated version, above permission and disclaimer statement shall be applied with replacing original copyright with derivative copyright. 本日本語訳については、原文の問い合わせ先に質問することは遠慮してほ しい。訳者は質問に対応するよう努力するが、保証はしない。 連絡先（訳者） 中里 武志 〔所属組織・住所等省略〕 電子メール： njt@nn.iij4u.or.jp -- Network Working Group J. Postel Request for Comments: 2223 J. Reynolds 廃止(Obsoletes): 1543, 1111, 825 ISI 分類(Category): 情報提供(Informational) 1997年10月 Network Working Group J. Postel Request for Comments: 2223 J. Reynolds Obsoletes: 1543, 1111, 825 ISI Category: Informational October 1997 RFCの著者への手引 Instructions to RFC Authors このメモの位置づけ Status of this Memo このメモはインターネット社会への情報提供である。このメモはいかなるイン ターネット標準も定めない。このメモの配布は無制限である。 This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 著作権表示 Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. Copyright (C) The Internet Society (1997). All Rights Reserved. 目次 Table of Contents 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 編集方針 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3 3. フォーマット規則 . . . . . . . . . . . . . . . . . . . . . . 4 3. Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4 3a. ASCIIフォーマットの規則 . . . . . . . . . . . . . . . . . . 5 3a. ASCII Format Rules . . . . . . . . . . . . . . . . . . . . 5 3b. ポストスクリプトフォーマットの規則 . . . . . . . . . . . . 6 3b. PostScript Format Rules . . . . . . . . . . . . . . . . . . 6 4. ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4a. 先頭ページの見出し . . . . . . . . . . . . . . . . . . . . 7 4a. First Page Heading . . . . . . . . . . . . . . . . . . . . 7 4b. ページヘッダ . . . . . . . . . . . . . . . . . . . . . . . 8 4b. Running Header . . . . . . . . . . . . . . . . . . . . . . 8 4c. ページフッタ . . . . . . . . . . . . . . . . . . . . . . . 8 4c. Running Footer . . . . . . . . . . . . . . . . . . . . . . 8 5. 位置づけの節 . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Status Section . . . . . . . . . . . . . . . . . . . . . . . 8 6. 著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 9 7. はじめにの節 . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Introduction Section . . . . . . . . . . . . . . . . . . . . 9 8. 参考文献の節 . . . . . . . . . . . . . . . . . . . . . . . 11 8. References Section . . . . . . . . . . . . . . . . . . . . 11 9. セキュリティに関する考察の節 . . . . . . . . . . . . . . . 11 9. Security Considerations Section . . . . . . . . . . . . . 11 10. 著者の住所の節 . . . . . . . . . . . . . . . . . . . . . . 11 10. Author's Address Section . . . . . . . . . . . . . . . . . 11 11. 著作権の節 . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Copyright Section . . . . . . . . . . . . . . . . . . . . 11 12. 他のRFCとの関係 . . . . . . . . . . . . . . . . . . . . . 12 12. Relation to other RFCs . . . . . . . . . . . . . . . . . . 12 13. プロトコル標準化過程 . . . . . . . . . . . . . . . . . . . 13 13. Protocol Standards Process . . . . . . . . . . . . . . . . 13 14. 連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. 配布リスト . . . . . . . . . . . . . . . . . . . . . . . . 14 15. Distribution Lists . . . . . . . . . . . . . . . . . . . . 14 16. RFCインデックス . . . . . . . . . . . . . . . . . . . . . 14 16. RFC Index . . . . . . . . . . . . . . . . . . . . . . . . 14 17. セキュリティに関する考察 . . . . . . . . . . . . . . . . . 14 17. Security Considerations . . . . . . . . . . . . . . . . . 14 18. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 14 18. References . . . . . . . . . . . . . . . . . . . . . . . . 14 19. 著者の住所 . . . . . . . . . . . . . . . . . . . . . . . . 15 19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 20. 付録 − RFC用nroffマクロ . . . . . . . . . . . . . . . . . 16 20. Appendix - RFC "nroff macros" . . . . . . . . . . . . . . 16 21. 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . 20 21. Full Copyright Statement . . . . . . . . . . . . . . . . . 20 ポステル & レイノルズ 情報提供 [1ページ] Postel & Reynolds Informational [Page 1] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 1. はじめに 1. Introduction このRFCではRFC作成と、RFC発行に関する方針についての情報を提供する。 This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. RFCシリーズの文書は広い関心領域をカバーしている。中心的な主題はインタ ーネット(the Internet)とTCP/IPプロトコル群である。しかし、コンピュータ 通信に関わるどんな話題でもRFC編集者の裁量で扱うことができる。 The RFC series of notes covers a broad range of interests. The core topics are the Internet and the TCP/IP protocol suite. However, any topic related to computer communication may be acceptable at the discretion of the RFC Editor. 誰でもRFCとして提案するメモを提出することができる。RFCになるメモの内、 かなりの部分をしめるのはInternet Engineering Task Force (IETF)からの ものである。IETF working group (WG)は作業メモ（Internet Draft（イン ターネット標準原案）あるいはI-Dとして知られている）を、公開に適する と判断するまで改訂する。その後これらのメモはInternet Engineering Steering Group (IESG)が査読し、承認されたものはIESGからRFC編集者へ送 付される。 Memos proposed to be RFCs may be submitted by anyone. One large source of memos that become RFCs is the Internet Engineering Task Force (IETF). The IETF working groups (WGs) evolve their working memos (known as Internet Drafts or I-Ds) until they feel they are ready for publication, then the memos are reviewed by the Internet Engineering Steering Group (IESG), and if approved sent by the IESG to the RFC Editor. 独立の出所からRFC編集者に提出されたメモのほとんどは、IETF Working Groupの作業との関連があるかどうかＩＥＳＧにより査読される。 Most of the memos submitted to the RFC Editor from independent sources will be reviewed by the IESG for possible relationship to work in progress in the IETF Working Groups. RFCは公開でアクセスできるファイルとして保管され、当該メモが利用可 能になったことを伝える短いメッセージが配布リストに送られることに より、電子的に配布される。 RFCs are distributed online by being stored as public access files, and a short message is sent to the distribution list indicating the availability of the memo. 電子ファイルは関心を持つ人々のサイトの装置上で、コピーされ、印刷さ れ、また表示される。すなわち、電子ファイルのフォーマットは極めて 多岐に亘る印刷・表示装置の制限に合致しなければならない(MUST)。 （また、RFCは電子メールの問い合わせに対して電子メールで送り返され ることもあり、またGopher、Wais、ワールドワイドウェブ(WWW)のような 情報・データベース検索手段を用いて利用されることもある。） （訳者註：原文のカッコの対応が謎？？） The online files are copied by the interested people and printed or displayed at their site on their equipment. This means that the format of the online files must meet the constraints of a wide variety of printing and display equipment. (RFCs may also be returned via e-mail in response to an e-mail query, or RFCs may be found using information and database searching tools such as Gopher, Wais, or the World Wide Web (WWW). RFCは伝統的にASCIIテキストとして公開されており、今後もその形で公開 され続ける。 RFCs have been traditionally published and continue to be published in ASCII text. RFC正本はつねにASCIIテキストファイルであるが、二次的、ないし、代替 的バージョンのRFCがポストスクリプト(PostScript)として提供されるこ とがある(MAY)。この決定は、図表等をRFCに含めるという動機からである。 ポストスクリプトの文書（現在のところ紙のみ）は視覚的訴求力があり、 読みやすい。 While the primary RFCs is always an ASCII text file, secondary or alternative versions of RFC may be provided in PostScript. This decision is motivated by the desire to include diagrams, drawings, and such in RFCs. PostScript documents (on paper only, so far) are visually more appealing and have better readability. RFC発行のためのグラフィカルな方式としてポストスクリプトが他の方式 （例：impress, interpress, oda）をさしのけて選ばれたのは、ポスト スクリプト対応のプリンタが広く利用可能であるとの判断からである。 PostScript was chosen for the fancy form of RFC publication over other possible systems (e.g., impress, interpress, oda) because of the perceived wide spread availability of PostScript capable printers. ポステル & レイノルズ 情報提供 [2ページ] Postel & Reynolds Informational [Page 2] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 しかし、RFC利用者の多くが文書を電子的に読み、種々のテキスト用ツール （例：Emacs, grep）で検索を行う。ＲＦＣからの短い抜粋が電子メールに 含められることも多い。こういった方法はポストスクリプトファイルでは 現実的ではない。 However, many RFC users read the documents online and use various text oriented tools (e.g., emacs, grep) to search them. Often, brief excerpts from RFCs are included in e-mail. These practices are not yet practical with PostScript files. ポストスクリプト生成システムは望ましいレベルにまで標準化されては おらず、ポストスクリプトを生成すると称する文書生成システムの中に は実際には非標準的な結果を生成するものがいくつもある。 PostScript producing systems are less standard than is desirable and that several of the document production systems that claim to produce PostScript actually produce nonstandard results. 将来的には、生成する出力ファイルの合理性を基準として、ポストスク リプト版のRFCを生成するために利用可能な文書生成システムを認定する 必要があろう(MAY)。 In the future, it may be necessary to identify a set of document production systems authorized for use in production of PostScript RFCs, based on the reasonableness of the output files they generate. 2. 編集方針 2. Editorial Policy RFCとして提案された文書は、RFC編集者とその選んだ査読者（がいれば） によって査読される。 Documents proposed to be RFCs are reviewed by the RFC Editor and possibly by other reviewers he selects. 査読の結果、発行前に文書の改善を著者に提案することがある。 The result of the review may be to suggest to the author some improvements to the document before publication. 場合により、提案されたRFCの主題が明らかにIETF Working Groupの作業対 象でもあり、両者の都合のよいように著者がWorking Groupと協調すること がある。このような場合、通常、改訂版のメモがWorking GroupのInternet Draftとして作成され、やがてIETFの手続を通してIESGからのRFC編集者へ の勧告となる。 Occasionally, it may be apparent that the topic of a proposed RFC is also the subject of an IETF Working Group, and that the author could coordinate with the working group to the advantage of both. The usual result of this is that a revised memo is produced as a working group Internet Draft and eventually emerges from the IETF process as a recommendation from the IESG to the RFC Editor. 提出された文書がRFCとしての発行に適さないものであると判断されることも ある。 In some cases it may be determined that the submitted document is not appropriate material to be published as an RFC. 文書の内容についての査読にもとづく記述を文書に含める必要のある場合が ある。文書が妥当な問題提起をしているが、不適当ないし安全でない内容を 含んでいる等の状況の場合にありうる。 In some cases it may be necessary to include in the document a statement based on the reviews about the ideas in the document. This may be done in the case that the document suggests relevant but inappropriate or unsafe ideas, and other situations. RFC編集者は文書に重要でない変更、特に文書のスタイルやフォーマットの分 野においての変更をすることがある。しかし、ある場合にはテキスト自体に ついても変更することがある。ときには、特にフォーマット規則（下記）に 従っていない場合には、RFC編集者はさらに大きな変更を引き受けることがあ る。しかし、それよりも追加作業のためにメモを著者に差し戻すことがずっ と多い。 The RFC Editor may make minor changes to the document, especially in the areas of style and format, but on some occasions also to the text. Sometimes the RFC Editor will undertake to make more significant changes, especially when the format rules (see below) are not followed. However, more often the memo will be returned to the author for the additional work. 標準化過程にあるプロトコルを定めるRFCとなる文書はRFC編集者に送付され る前にIESGの承認を得なければならない(MUST)。確立された手続では、標準 化過程のRFCとなる文書についての作業をIESGが完了させた時点でIESG事務 局長(Secretary)からRFC編集者に連絡がとられる。一般的には、この議論に あてはまる文書はInternet Draftである。連絡では通常、対象のインターネ ットドラフトが的確に（ファイル名により）引用される。RFC編集者はその ファイルのみがRFCとなる手続を通ったとうけとらなければならない。著者 がテキストに小さな変更を加えた場合には、この変更はRFC編集者へ別に （あるいはdiffとして）送付しなければならない。著者は新しい版そのもの を送ってはならない(SHOULD NOT)。 Documents intended to become RFCs specifying standards track protocols must be approved by the IESG before being sent to the RFC Editor. The established procedure is that when the IESG completes work on a document that is to become a standards track RFC the communication will be from the Secretary of the IESG to the RFC ポステル & レイノルズ 情報提供 [3ページ] Postel & Reynolds Informational [Page 3] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 Editor. Generally, the documents in question are Internet Drafts. The communication usually cites the exact Internet Draft in question (by file name). The RFC Editor must assume that only that file is to be processed to become the RFC. If the authors have small corrections to the text, they should be sent to the RFC Editor separately (or as a "diff"), authors should not send a new version of the document. 場合により、ポストスクリプトを用いたグラフィカルにフォーマットされた RFCを二次的な代替バージョンとして著者が用意する場合がある。ASCIIテキ スト版が正本であるので、ポストスクリプト版はテキスト版に一致しなけれ ばならない(MUST)。RFC編集者はポストスクリプト版を公開できるか決定す る前に、ポストスクリプト版がASCII版と「同一である」かどうか判断しな ければならない(MUST)。 In some cases, authors prepare alternate secondary versions of RFCs in fancy format using PostScript. Since the ASCII text version of the RFC is the primary version, the PostScript version must match the text version. The RFC Editor must decide if the PostScript version is "the same as" the ASCII version before the PostScript version can be published. 上記の結果、RFC編集者はまずASCII版のメモをRFCとしての公開のために処 理する。著者がASCII版に一致する（そしてRFC編集者がその通りだと認め る）ポストスクリプト版をその時点で提出しようと希望する場合には、ポ ストスクリプト版がRFCレポジトリ（データベース）に収納され、インター ネット社会に広報される。 The effect of this is that the RFC Editor first processes the ASCII version of the memo through to publication as an RFC. If the author wishes to submit a PostScript version at that point that matches the ASCII version (and the RFC Editor agrees that it does), then the PostScript version will be installed in the RFC repositories and announced to the community. RFC編集スタッフに対するさまざまな時間的な圧迫により、提出から公開ま でに費やされる時間は大きく変わり得る。この期間中にRFC編集者に対して RFCの状態を問い合わせる（pingをかける）ことは（１週間に１度を超えな い範囲で）常に認められる。IETF meeting（会議）に先立つ２週間は通常 非常に多忙であるので、IETF meetingの直前に提出されたRFCは多くの場合 meetingの後に発行される。 Due to various time pressures on the RFC Editorial staff, the time elapsed between submission and publication can vary greatly. It is always acceptable to query (ping) the RFC Editor about the status of an RFC during this time (but not more than once a week). The two weeks preceding an IETF meeting are generally very busy, so RFCs submitted shortly before an IETF meeting are most likely to be published after the meeting. 3. フォーマット規則 3. Format Rules 配布上の制限に合わせるため、下記の規則が２種類のフォーマット、すな わちASCIIフォーマットとポストスクリプトフォーマットのそれぞれに対 して定められた。 To meet the distribution constraints, the following rules are established for the two allowed formats for RFCs: ASCII and PostScript. RFC編集者はRFCのスタイルの一貫性を保とうとする。そのため、RFC編集者 は提出されたRFCを再フォーマットすることがある。提出物が最近のRFCの スタイルに従っていれば、これは容易である。最近のいくつかのRFCを見て、 自分のものを同様のスタイルに合わせてほしい。 The RFC Editor attempts to ensure a consistent RFC style. To do this the RFC Editor may choose to reformat the RFC submitted. It is much easier to do this if the submission matches the style of the most recent RFCs. Please do look at some recent RFCs and prepare yours in the same style. RFC編集者には、編集可能な電子文書を提出しなければならない。RFC編集者 はフォーマットないしスタイル上の重要でない変更をし、また変更を求める ことができ、また実際のRFC番号を挿入する。 You must submit an editable online document to the RFC Editor. The RFC Editor may require or make minor changes in format or style and will insert the actual RFC number. ポステル & レイノルズ 情報提供 [4ページ] Postel & Reynolds Informational [Page 4] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 ほとんどのRFCはRFC編集者によってユニックスのnroffプログラムで"ms"マ クロパッケージのうち非常に単純な書式コマンド(または"request")のみを 用いて処理されている。（付録参照）著者がRFCとして提出するメモをnroff を用いて準備した場合には、提出時にその旨をRFC編集者に知らせていただ けると助かる。 Most of the RFCs are processed by the RFC Editor with the unix "nroff" program using a very simple set of the formatting commands (or "requests") from the "ms" macro package (see the Appendix). If a memo submitted to be an RFC has been prepared by the author using nroff, it is very helpful to let the RFC Editor know that when it is submitted. 3a. ASCIIフォーマットの規則 3a. ASCII Format Rules 文字コードはASCIIである。 The character codes are ASCII. ｘ 各ページは５８行に制限され、フォームフィード文字のみの行で終わる。 Each page must be limited to 58 lines followed by a form feed on a line by itself. ｘ 各行は７２文字に制限され、復帰改行（キャリッジ・リターンとライン・ フィード）で終わる。 Each line must be limited to 72 characters followed by carriage return and line feed. 重ね打ち（および下線）は許されない。 No overstriking (or underlining) is allowed. 上記の「高さ」と「幅」の制限には、すべてのヘッダ、フッタ、ページ番 号、左端の字下げを含む。 These "height" and "width" constraints include any headers, footers, page numbers, or left side indenting. 右揃えを行うために余分な空白を入れてはならない。 Do not fill the text with extra spaces to provide a straight right margin. 右余白でハイフネーションを行ってはならない。 Do not do hyphenation of words at the right margin. 脚注を用いてはならない。注が必要であれば、節の末尾、または文書の 末尾に置くこと。 Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document. 段落内ではシングルスペースで文章を打ち、段落間には１行分の空行を 入れること。（訳者註：文の間は２文字分のスペースになっている） Use single spaced text within a paragraph, and one blank line between paragraphs. 文書の全ページ数や各節の記載されたページは再フォーマットにより変 わりうることに留意せよ。したがって相互参照はページ番号によるより も節番号によったほうが一貫性を保つことが容易である。 Note that the number of pages in a document and the page numbers on which various sections fall will likely change with reformatting. Thus cross references in the text by section number usually are easier to keep consistent than cross references by page number. ASCIIフォーマットのRFCはRFC編集者に電子メールで（または電子ファイ ルとして）整形されたフォーマットまたはnroffのフォーマットで提出さ れる。nroffファイルとして文書を提出しようと計画しているのであれば、 まずRFC編集者に連絡をとってほしい。 RFCs in ASCII Format may be submitted to the RFC Editor in e-mail messages (or as online files) in either the finished publication format or in nroff. If you plan to submit a document in nroff please consult the RFC Editor first. ポステル & レイノルズ 情報提供 [5ページ] Postel & Reynolds Informational [Page 5] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 3b. ポストスクリプトフォーマットの規則 3b. PostScript Format Rules 標準ページサイズは8インチ半×11インチである。 Standard page size is 8 1/2 by 11 inches. 各辺（天、地、左、右）1インチの余白。 Margin of 1 inch on all sides (top, bottom, left, and right). 本文サイズは10ポイント以上、行間隔は12ポイント以上。 Main text should have a point size of no less than 10 points with a line spacing of 12 points. 脚注とグラフの説明は8ポイント以上で行間隔9.6ポイント以上。 Footnotes and graph notations no smaller than 8 points with a line spacing of 9.6 points. 以下の３フォントを用いてよい：ヘルヴェティカ(Helvetica), タイムズ ローマン(Times Roman), クーリエ(Courier)。および、上記の太字（ボー ルド体）ないし斜体（イタリック体）。上記３種の標準フォントはほとん どのポストスクリプトプリンタにある。 Three fonts are acceptable: Helvetica, Times Roman, and Courier. Plus their bold-face and italic versions. These are the three standard fonts on most PostScript printers. 最低限の一般的な縮小ポストスクリプト命令セットで図表を作成せよ。 一般的なポストスクリプトプリンタの機能とメモリへの要求条件を考慮 せよ。 Prepare diagrams and images based on lowest common denominator PostScript. Consider common PostScript printer functionality and memory requirements. 以下のポストスクリプトオペレータは使ってはならない(should not)。 initgraphics, erasepage, copypage, grestoreall, initmatrix, initclip, banddevice, framedevice, nulldevice および renderbands. The following PostScript commands should not be used: initgraphics, erasepage, copypage, grestoreall, initmatrix, initclip, banddevice, framedevice, nulldevice and renderbands. 文書の全ページ数や各節の記載されたページはASCII版とポストスクリ プト版で相違しうることに留意せよ。したがって相互参照はページ番号 によるよりも節番号によったほうが一貫性を保つことが容易である。 Note that the number of pages in a document and the page numbers on which various sections fall will likely differ in the ASCII and the PostScript versions. Thus cross references in the text by section number usually are easier to keep consistent than cross references by page number. 以上のポストスクリプトについての規則は経験が得られるに伴って変更 され、追加されてゆくべきものである。 These PostScript rules are likely to changed and expanded as experience is gained. ポストスクリプトフォーマットのRFCはRFC編集者に電子メールで（また は電子ファイルとして）提出される。ポストスクリプトで文書を提出し ようと計画しているのであれば、まずRFC編集者に連絡をとってほしい。 RFCs in PostScript Format may be submitted to the RFC Editor in e-mail messages (or as online files). If you plan to submit a document in PostScript please consult the RFC Editor first. ASCIIテキスト版のRFCが正本であることに留意せよ。ポストスクリプ ト版はASCII版に一致しなければならない。（訳者註：その逆ではな い）RFC編集者はポストスクリプト版が「ポストスクリプト版が発行さ れる前にASCII版と同一である」ことを判定しなければならない(MUST)。 Note that since the ASCII text version of the RFC is the primary version, the PostScript version must match the text version. The RFC Editor must decide if the PostScript version is "the same as" the ASCII version before the PostScript version can be published. ポステル & レイノルズ 情報提供 [6ページ] Postel & Reynolds Informational [Page 6] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 4. ヘッダとフッタ 4. Headers and Footers 最初のページの見出し、ヘッダ、フッタがある。 There is the first page heading, the running headers, and the running footers. 4a. 最初のページ 4a. First Page 表紙ページの例として、このメモの表紙ページを見よ。最初のページには ページヘッダはない。最初のページの上部には以下の項目が来る。 Please see the front page of this memo for an example of the front page heading. On the first page there is no running header. The top of the first page has the following items: Network Working Group Network Working Group 一連のRFCを確立したグループの伝統的な見出しである。見出しの１行 目の左端に記述する。 The traditional heading for the group that founded the RFC series. This appears on the first line on the left hand side of the heading. Request for Comments: 番号 Request for Comments: nnnn RFCであることを記述し、番号を定める。２行目の左端に記述する。実 際の番号は発行直前にRFC編集者が埋める。 Identifies this as a request for comments and specifies the number. Indicated on the second line on the left side. The actual number is filled in at the last moment before publication by the RFC Editor. 著者 Author 著者名（名前の頭文字と名字のみ）。見出しの１行目の右端に記述する。 The author's name (first initial and last name only) indicated on the first line on the right side of the heading. 組織 Organization 著者の属する組織。２行目の右端に記述する。 The author's organization, indicated on the second line on the right side. 日付 Date RFCの発行月と発行年である。３行目の右端に記述する。 This is the Month and Year of the RFC Publication. Indicated on the third line on the right side. Updates（更新）またはObsoletes（廃止） Updates or Obsoletes 本RFCが他のRFCをUpdate（更新）またはObsolete（廃止）する場合、見 出しの３行目の左端に記述する。 If this RFC Updates or Obsoletes another RFC, this is indicated as third line on the left side of the heading. ポステル & レイノルズ 情報提供 [7ページ] Postel & Reynolds Informational [Page 7] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 Category（分類） Category 本RFCの分類であり、以下のいずれか：Standards Track（標準化過 程）、Best Current Practice（現行の最良の運用）、Informational （情報提供）、Experimental（実験的）。３行目（Updatesないし Obsoletesの記述がない場合）ないし４行目の左端に記述する。 The category of this RFC, one of: Standards Track, Best Current Practice, Informational, or Experimental. This is indicated on the third (if there is no Updates or Obsoletes indication) or fourth line of the left side. 他の番号 Other Numbers FYI (For Your Information, 参考情報)[4]、BCP (Best Current Practice, 現行の最良の運用)[5], STD (Standard, インターネッ ト標準) [6]を含むRFC内の別の番号体系である。左端に記述する。 Other numbers in the RFC series of notes include the subseries of FYI (For Your Information) [4], BCP (Best Current Practice) [5], and STD (Standard) [6]. These are placed on the left side. 標題 Title 標題は他の見出しの下にセンタリングされて表示される。ピリオドま たは「ドット」は標題の中に現れてはならない。 The title appears, centered, below the rest of the heading. Periods or "dots" in the titles are not allowed. 複数の著者がおり、その複数の著者が複数の組織に属する場合には、右 側の見出しには所属組織を正しく明記するのに必要なだけの行を追加し てよい。 If there are multiple authors and if the multiple authors are from multiple organizations the right side heading may have additional lines to accommodate them and to associate the authors with the organizations properly. 4b. ページヘッダ 4b. Running Headers ページヘッダ（第２ページ以降のページに現れる）は、左端にRFC番号 (RFC NNNN)、中央に（必要なら短縮された形式の）標題、右端に日付 （月 年）を１行で記述したものである。 The running header in one line (on page 2 and all subsequent pages) has the RFC number on the left (RFC NNNN), the (possibly nshortened form) title centered, and the date (Month Year) on the right. 4c. ページフッタ 4c. Running Footers ページフッタ（すべてのページに現れる）は、左端に著者の姓、中央に Category（分類）、右端にページ番号([Page N])を１行で記述したもの である。 The running footer in one line (on all pages) has the author's last name on the left, category centered, and the page number on the right ([Page N]). 5. 位置づけの節 5. Status Section 各RFCの最初のページは「このメモの位置づけ(Status of this Memo)」 の節がなければならない。この節は以下の２つの要素からなる。(1) R FCの種別を示す段落、と (2) 配布条件。 Each RFC must include on its first page the "Status of this Memo" section which contains two elements: (1) a paragraph describing the type of the RFC, and (2) the distribution statement. この節の内容は以下の４種の宣言のいずれかでなければならない。 The content of this section will be one of the four following statements. ポステル & レイノルズ 情報提供 [8ページ] Postel & Reynolds Informational [Page 8] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 Standards Track（標準化過程） Standards Track 「この文書はインターネット社会のためのインターネット標準過程のプロ トコルを定める。改善のための議論と提案を求める。標準化への状態およ びこのプロトコルの位置づけについては『Internet Official Protocol Standards（インターネット公式プロトコル標準）』(STD 1)の現行版を参 照のこと。このメモの配布は無制限である。」 "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." Best Current Practice（現行の最良の方法） Best Current Practice 「この文書はインターネット社会のための『Internet Best Current Practices（インターネットでの現行の最良の方法）』を定める。改善の ための議論と提案を求める。このメモの配布は無制限である。」 "This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited." Experimental（実験的） Experimental 「このメモはインターネット社会のためのExperimental Protocol（実験 的なプロトコル）を定義する。このメモはいかなるインターネット標準 も定めない。改善のための議論と提案を求める。このメモの配布は無制 限である。」 "This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited." Informational（情報提供） Informational 「このメモはインターネット社会への情報提供である。このメモはいか なるインターネット標準も定めない。このメモの配布は無制限である。」 "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited." 6. 著作権表示 6. Copyright Notice 位置づけの節の直後に以下の宣言を置く。「Copyright (C) The Internet Society (日付). All Rights Reserved.」。また、文書の末尾に置かれる べき完全な著作権表示については11節を参照。 Immediately following the Status section the statement, "Copyright (C) The Internet Society (date). All Rights Reserved." is placed. Also, see Section 11 for the full statement that must appear at the end of the document. 7. はじめにの節 7. Introduction Section 各RFCには、（他の記述に加え）そのRFCの動機を説明し、（適切であれば） 記述されているプロトコルの適用範囲を説明した「はじめに」の節がなけ ればならない(SHOULD)。 Each RFC should have an Introduction section that (among other things) explains the motivation for the RFC and (if appropriate) describes the applicability of the protocol described. 通常、これはインターネットドラフトの「摘要（アブストラクト）」 節である。当該RFCがI-D由来でない場合、他の可能性としては： Normally, this will be the "abstract" section from the Internet Draft. If the RFC is not based on an I-D, other possibilities are: ポステル & レイノルズ 情報提供 [9ページ] Postel & Reynolds Informational [Page 9] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 プロトコル(Protocol) Protocol 本プロトコルはほにゃららサービスのために、ホスト計算機上の サーバとクライアントとの間で用いられることを意図している。 典型的にはワークステーションホスト上のクライアントとメイン フレームホスト上のサーバである。 This protocol is intended to provide the bla-bla service, and be used between clients and servers on host computers. Typically the clients are on workstation hosts and the servers on mainframe hosts. または or 本プロトコルはほにゃららサービスのために、ターミナルサーバ やルータのような特定目的の装置と監視ホストの間で用いられる ことを意図している。 This protocol is intended to provide the bla-bla service, and be used between special purpose units such as terminal servers or routers and a monitoring host. 考察(Discussion) Discussion 本RFCの目的はインターネットの特定の問題と可能な解決方法につ いて議論することである。本文書の解決策のいずれもインターネッ ト標準として意図されているものではない。むしろ、問題に対する 適切な解決策に関して広く合意が生まれ、いずれ標準の採択に向か うことを期待する。 The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. 関心(Interest) Interest 本RFCは提案への反応を求めるためにインターネットコミュニテ ィのメンバへ配布されている。議論されている問題点は直ちにイ ンターネットの研究上の問題点と関連があるとは限らないが、あ る研究者や実装者にとっては興味深いであろう。 This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. 状況報告(Status Report) Status Report インターネットコミュニティの種々のプロジェクトの進捗と状況に 関する現在の情報の整備に対する要求に応え、本RFCはコミュニテ ィのメンバの利益のために発行される。本文書に含まれる情報は 発行日現在において正確であるが、変更があり得る。後続のRFCは そのような変更を反映する。 In response to the need for maintenance of current information about the status and progress of various projects in the Internet community, this RFC is issued for the benefit of community members. The information contained in this document is accurate as of the date of publication, but is subject to change. Subsequent RFCs will reflect such changes. これらの段落に逐語的に従う必要はないが、そのRFCの概要的な目的 は明確にされなくてはならない(MUST)。 These paragraphs need not be followed word for word, but the general intent of the RFC must be made clear. ポステル & レイノルズ 情報提供 [10ページ] Postel & Reynolds Informational [Page 10] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 8. 参考文献の節 8. References Section ほぼすべてのRFCには他の文書の引用が含まれ、そのRFCの末尾近くの参考文 献の節に列挙されている。参考文献には多くのスタイルがあるが、RFCは独 自のスタイルがある。最新のRFCの参考文献スタイルに従ってほしい。この RFCの参考文献の節を例として参照せよ。STD番号の与えられているプロトコ ルについてはSTD番号を参考文献に含めなければならない(MUST)ことに留意 せよ。 Nearly all RFCs contain citations to other documents, and these are listed in a References section near the end of the RFC. There are many styles for references, and the RFCs have one of their own. Please follow the reference style used in recent RFCs. See the reference section of this RFC for an example. Please note that for protocols that have been assigned STD numbers, the STD number must be included in the reference. 標準化過程の文書の多くにおいて、当該仕様の要求条件を示すのに用いられ る用語がいくつかある。これらの用語はキャピタライズされることが多い。 BCP 14, RFC 2119 [3]においてこれらの用語がIETFの文書でどのように解釈 されるべき(SHOULD)であるかを定義している。 In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. BCP 14, RFC 2119 [3], defines these words as they should be interpreted in IETF documents. 9. セキュリティに関する考察の節 9. Security Considerations Section すべてのRFCには、文書の末尾近くに、そのRFCの主題のプロトコルないし 手続についてのセキュリティに関しての考察について議論した節がなけれ ばならない。 All RFCs must contain a section near the end of the document that discusses the security considerations of the protocol or procedures that are the main topic of the RFC. 10. 著者の住所の節 10. Author's Address Section すべてのRFCには、末尾に著者の住所、すなわち、氏名、郵便物の住所、 電話番号（任意：FAX番号）、インターネット電子メールアドレス、を 示す節がなくてはならない。 Each RFC must have at the very end a section giving the author's address, including the name and postal address, the telephone number, (optional: a FAX number) and the Internet email address. 11. 著作権の節 11. Copyright Section BCP 9, RFC 2026 [2]によれば「以下の著作権表示と否認声明がすべてのISOC の標準関連文書に含まれなければならない(SHALL BE)。」下記の宣言がRFCの 最終ページに「完全な著作権表示」として含まれるべきである(SHOULD)。 Per BCP 9, RFC 2026 [2], "The following copyright notice and disclaimer shall be included in all ISOC standards-related documentation." The following statement should be placed on the last page of the RFC, as the "Full Copyright Statement". （訳者註：以下、法律効果を持つ文章なので、翻訳は参考にとどめ、必ず原文を 用いること。） "Copyright (C) The Internet Society (日付). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved. 上記の著作権表示および本項がすべての写しおよび二次的著作物に含まれ ることを条件として、本文書とその翻訳の複製および他者への提供、およ び、二次的著作物、すなわち本文書へのコメント他の表現による解説、実 装の支援、の全部または一部の作成、複製、公開、配布をいかなる制限な しに許諾する。但し、本文書そのものはいかなる方法、すなわちthe Internet Societyその他のインターネット機関への言及および著作権表示 の削除による等の改変も禁ずるが、但し、インターネット標準を定める目 的でインターネット標準化過程に定める著作権手続に従うために必要な場 合、あるいは英語以外の言語に翻訳するために必要な場合を除く。 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 implmentation 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 ポステル & レイノルズ 情報提供 [11ページ] Postel & Reynolds Informational [Page 11] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 languages other than English. 上記の条件付き許諾は永久的なものであり、the Internet Societyまたは その承継人あるいは被譲渡人が撤回することはない(WILL NOT)。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 本文書と本文書に含まれる情報は「ありのまま(AS IS)」として提供される ものであり、「the Internet Societyおよびthe Internet Engineering Task Forceは、明示、黙示の別をとわず、ここに含まれる情報の利用がい かなる権利も侵害しない保証、あるいは商業的あるいは特定目的への適合 性のいかなる黙示の保証を含み、これらに限られないいかなる保証も否認 する。」 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. 12. 他のＲＦＣとの関係 12. Relation to other RFCs 過去のRFCで扱われている内容に情報を付け加えたり、過去のRFCに完全に 置き換わるRFCがある。これらは順に「Update（更新）」と「Obsolete （廃止）」という用語で呼ばれる。過去の文書を廃止する文書は単独で意 味をなす。過去の文書を更新するに過ぎない文書は単独では意味をなさな い。すなわち、既存の文書に付け加え、挿入されるのであって、単独では 限られた意味しか持たない。「Supercedes（上書き）」と「Replace（置 換）」という用語はもはや用いられていない。 Sometimes an RFC adds information on a topic discussed in a previous RFC or completely replaces an earlier RFC. There are two terms used for these cases respectively, Updates and Obsoletes. A document that obsoletes an earlier document can stand on its own. A document that merely updates an earlier document cannot stand on its own; it is something that must be added to or inserted into the previously existing document, and has limited usefulness independently. The terms Supercedes and Replaces are no longer used. 更新(Updates) Updates 単独で用いることのできない新規項目（すなわち以前の文書を補足する もの）から以前の文書への参照として用いられる。新規の文書は既存の 文書に補足ないし追加された部分、例えば、補遺、または別個の、元の 文書に追加される追加情報である。 To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. 廃止(Obsoletes) Obsoletes その文書で置き換えられる先行する文書を参照するのに用いられる。こ の文書は改訂された情報あるいは同一の情報に加えて新規の情報を含む が、この新規の情報は広範であるか簡潔であるかにかかわらない。すな わち、この文書は以前の文書を参照することなく単独で用いることがで きる。 To be used to refer to an earlier document that is replaced by this document. This document contains either revised information, or else all of the same information plus some new information, however extensive or brief that new information is; i.e., this document can be used alone, without reference to the older document. ポステル & レイノルズ 情報提供 [12ページ] Postel & Reynolds Informational [Page 12] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 例： For example: 割当て番号(Assigned Numbers)のRFCにおいてはObsoletes（廃止）の 語が用いられるべきである。なぜなら新しい文書は既存の情報の記述 に（どれだけ簡潔であるとしても）新規の情報を実際に組み入れ、ま た古い文書に比べ、より最新の情報であるので、古い文書を置換え Obsolete（廃止）にする。 On the Assigned Numbers RFCs the term Obsoletes should be used since the new document actually incorporate new information (however brief) into the text of existing information and is more up-to-date than the older document, and hence, replaces it and makes it Obsoletes. RFCのリスト、またはRFCインデックスにおいて（但し、RFCそのものにおい てではない）は新しい文書を参照するために、古い文書とともに以下の表 記が用いられる。 In lists of RFCs or the RFC-Index (but not on the RFCs themselves) the following may be used with early documents to point to later documents. Obsoleted-by（〜により廃止された） Obsoleted-by 古い文書を置き換える新しい文書を参照するのに用いられる。 To be used to refer to the newer document(s) that replaces the older document. Updated-by（〜により更新された） Updated-by 既存の（有効な）文書に追加された新しい節を参照するのに用いられる。 To be used to refer to the newer section(s) which are to be added to the existing, still used, document. 13. プロトコル標準化過程 13. Protocol Standards Process プロトコル標準とその公開についての信頼のおける記述として、現行の 「Internet Official Protocol Standards（インターネット公式プロトコル 標準）」(STD 1)[1]を見よ。 See the current "Internet Official Protocol Standards" (STD 1) memo for the definitive statement on protocol standards and their publication [1]. 確立された手続では、標準化過程のRFCとなる文書についての作業をIESGが 完了させた時点でIESG事務局長(Secretary)からRFC編集者に連絡がとられる。 一般的には、この議論にあてはまる文書はInternet Draftである。連絡では 通常、対象のインターネットドラフトが的確に（ファイル名により）引用さ れる。RFC編集者はそのファイルのみがRFCとなる手続を通ったとうけとらな ければならない。著者がテキストに小さな変更を加えた場合には、この変更 はRFC編集者へ別に（あるいはdiffとして）送付しなければならない。著者 は新しい版そのものを送ってはならない(SHOULD NOT)。 The established procedure is that when the IESG completes work on a document that is to become a standards track RFC the communication will be from the Secretary of the IESG to the RFC Editor. Generally, the documents in question are Internet Drafts. The communication usually cites the exact Internet Draft (by file name) in question. The RFC Editor must assume that only that file is to be processed to become the RFC. If the authors have small corrections to the text, they should be sent to the RFC Editor separately (or as a "diff"), do not send a new version of the document. 14. 連絡先 14. Contact RFC編集者に連絡を取るには、電子メールを以下の宛先に送れ： To contact the RFC Editor send an email message to: "rfc-editor@isi.edu". "rfc-editor@isi.edu". ポステル & レイノルズ 情報提供 [13ページ] Postel & Reynolds Informational [Page 13] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 15. 配布リスト 15. Distribution Lists RFCの周知は２つのメーリングリスト、"IETF-Announce"メーリングリストと "RFC-DIST"メーリングリストを通じて行われる。両方のメーリングリストに 参加する必要はない。 The RFC announcements are distributed via two mailing lists: the "IETF-Announce" list, and the "RFC-DIST" list. You don't want to be on both lists. IETF-Announceメーリングリストに参加（脱退）するにはietf-request@ietf.org に電子メールを送る。 To join (or quit) the IETF-Announce list send a message to ietf- request@ietf.org. RFC-DISTメーリングリストに参加（脱退）するにはrfc-dist-request@isi.edu に電子メールを送る。 To join (or quit) the RFC-DIST list send a message to rfc-dist- request@isi.edu. 16. RFCインデックス 16. RFC Index いくつかの機関が通常rfc-index.txtというファイルネームでRFCインデッ クスファイルを保守している。あるサイトからコピーされたそのようなフ ァイルは、別のサイトからコピーされたものとおそらく同一ではない。 Several organizations maintain RFC Index files, generally using the file name "rfc-index.txt". The contents of such a file copied from one site may not be identical to that copied from another site. 17. セキュリティに関する考察 17. Security Considerations このRFCはセキュリティに関する問題を取り扱っていない（但し、９節参照） This RFC raises no security issues (however, see Section 9). 18. 参考文献 18. References [1] Postel, J., Editor, "Internet Official Protocol Standards"（イ ンターネット公式プロトコル標準）, STD 1, RFC 2200, 1997年7月. [1] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 2200, June 1997. [2] Bradner, S., "The Internet Standards Process -- Revision 3"（イ ンターネット標準過程第三版）, BCP 9, RFC 2026, 1996年10月. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels"（ＲＦＣにおいて要求水準を示すために用いるキーワード）, BCP 14, RFC 2119, 1997年3月. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I Introduction to the F.Y.I. Notes"（FYIについてのFYI FYIシリーズ入門）, FYI 1, RFC 1150, 1990年3月. [4] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I Introduction to the F.Y.I. Notes", FYI 1, RFC 1150, March 1990. [5] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", （現行で最良の方法）, BCP 1, RFC 1818, 1995年8月. [5] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", BCP 1, RFC 1818, August 1995. [6] Postel, J., Editor, "Introduction to the STD Notes"（STDシリー ズ入門, RFC 1311, March 1992. [6] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311, March 1992. ポステル & レイノルズ 情報提供 [14ページ] Postel & Reynolds Informational [Page 14] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 19. 著者の住所 19. Authors' Addresses Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 電話： +1 310-822-1511 FAX： +1 310-823-6714 電子メール： Postel@ISI.EDU Phone: +1 310-822-1511 Fax: +1 310-823-6714 EMail: Postel@ISI.EDU Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 電話： +1 310-822-1511 FAX： +1 310-823-6714 電子メール： Postel@ISI.EDU Phone: +1 310-822-1511 Fax: +1 310-823-6714 EMail: jkrey@isi.edu ポステル & レイノルズ 情報提供 [15ページ] Postel & Reynolds Informational [Page 15] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 20. 付録 − RFC用nroffマクロ 20. Appendix - RFC "nroff macros" [訳者註：翻訳未完了。また日本語化groffでの動作も未確認] Generally, we use the very simplest nroff features. We use the "ms" macros. So, "nroff -ms input-file > output-file". However, we could not get nroff to do the right thing about putting a form feed after the last visible line on a page and no extra line feeds before the first visible line of the next page. We want: last visible line on page i ^L first visible line on page i+1 So, we invented a hack to fix this. We use a perl script called "fix.pl". So the command to process the file becomes: nroff -ms input-file | fix.pl > output-file The actual perl script is: #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #! /local/bin/perl # fix.pl 17-Nov-93 Craig Milo Rogers at USC/ISI # # The style guide for RFCs calls for pages to be delimited by the # sequence . # Unfortunately, NROFF is reluctant to produce output that conforms to # this convention. This script fixes RFC-style documents by searching # for the token "FORMFEED[Page", replacing "FORMFEED" with spaces, # appending a formfeed line, and deleting white space up to the next # non-white space character. # # There is one difference between this script's output and that of # the "fix.sh" and "pg" programs it replaces: this script includes a # newline after the formfeed after the last page in a file, whereas the # earlier programs left a bare formfeed as the last character in the # file. To obtain bare formfeeds, uncomment the second substitution # command below. To strip the final formfeed, uncomment the third # substitution command below. # # This script is intended to run as a filter, as in: # # nroff -ms input-file | fix.pl > output-file # # When porting this script, please observe the following points: # # 1) ISI keeps perl in "/local/bin/perl"; your system may keep it ポステル & レイノルズ 情報提供 [16ページ] Postel & Reynolds Informational [Page 16] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 # elsewhere. # 2) On systems with a CRLF end-of-line convention, the "\n"s below # may have to be replaced with "\r\n"s. $* = 1; # Enable multiline patterns. undef $/; # Read whole files in a single # gulp. while (<>) { # Read the entire input file. s/FORMFEED(\[Page\s+\d+\])\s+/ \1\n\f\n/g; # Rewrite the end-of-pages. # s/\f\n$/\f/; # Want bare formfeed at end? # s/\f\n$//; # Want no formfeed at end? print; # Print the resultant file. } #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc- editor/fix.pl Now as to the nroff features we actually use, following is a sample memo, prepared in RFC style. ポステル & レイノルズ 情報提供 [17ページ] Postel & Reynolds Informational [Page 17] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Waitzman .ds RF PUTFFHERE[Page %] .ds CF .ds LH RFC 1149 .ds RH 1 April 1990 .ds CH IP Datagrams on Avian Carriers .hy 0 .ad l .in 0 Network Working Group D. Waitzman Request for Comments: 1149 BBN STC 1 April 1990 .ce A Standard for the Transmission of IP Datagrams on Avian Carriers .ti 0 このメモの位置づけ .ti 0 Status of this Memo .fi .in 3 This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. Distribution of this memo is unlimited. .ti 0 Overview and Rational Avian carriers can provide high delay, low throughput, and low altitude service. The connection topology is limited to a single point-to-point path for each carrier, used with standard carriers, but many carriers can be used without significant interference with each other, outside of early spring. This is because of the 3D ether space available to the carriers, in contrast to the 1D ether used by IEEE802.3. The carriers have an intrinsic collision avoidance system, which increases availability. Unlike some network technologies, such as packet radio, communication is not limited to line-of-sight distance. Connection oriented service is available in some cities, usually based upon a central hub topology. ポステル & レイノルズ 情報提供 [18ページ] Postel & Reynolds Informational [Page 18] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 .ti 0 フレームフォーマット .ti 0 Frame Format The IP datagram is printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram's edges. The bandwidth is limited to the leg length. The MTU is variable, and paradoxically, generally increases with increased carrier age. A typical MTU is 256 milligrams. Some datagram padding may be needed. Upon receipt, the duct tape is removed and the paper copy of the datagram is optically scanned into a electronically transmittable form. .ti 0 Discussion Multiple types of service can be provided with a prioritized pecking order. An additional property is built-in worm detection and eradication. Because IP only guarantees best effort delivery, loss of a carrier can be tolerated. With time, the carriers are self-regenerating. While broadcasting is not specified, storms can cause data loss. There is persistent delivery retry, until the carrier drops. Audit trails are automatically generated, and can often be found on logs and cable trays. .ti 0 セキュリティに関する考察 .ti 0 Security Considerations .in 3 Security is not generally a problem in normal operation, but special measures must be taken (such as data encryption) when avian carriers are used in a tactical environment. .ti 0 著者の住所 .ti 0 Author's Address .nf David Waitzman BBN Systems and Technologies Corporation BBN Labs Division 10 Moulton Street Cambridge, MA 02238 Phone: (617) 873-4323 EMail: dwaitzman@BBN.COM ポステル & レイノルズ 情報提供 [19ページ] Postel & Reynolds Informational [Page 19] RFC 2223 RFCの著者への手引 1997年10月 RFC 2223 Instructions to RFC Authors October 1997 21. 完全な著作権表示 21. Full Copyright Statement （訳者註：以下、法律効果を持つ文章なので、翻訳は参考にとどめ、必ず原文を 用いること。） Copyright (C) The Internet Society (1997). All Rights Reserved. Copyright (C) The Internet Society (1997). All Rights Reserved. 上記の著作権表示および本項がすべての写しおよび二次的著作物に含まれる ことを条件として、本文書とその翻訳の複製および他者への提供、および、 二次的著作物、すなわち本文書へのコメント他の表現による解説、実装の支 援、の全部または一部の作成、複製、公開、配布をいかなる制限なしに許諾 する。但し、本文書そのものはいかなる方法、すなわちthe Internet Societyその他のインターネット機関への言及および著作権表示の削除によ る等の改変も禁ずるが、但し、インターネット標準を定める目的でインター ネット標準化過程に定める著作権手続に従うために必要な場合、あるいは英 語以外の言語に翻訳するために必要な場合を除く。 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 implmentation 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 Internet Societyまたは その承継人あるいは被譲渡人が撤回することはない(WILL NOT)。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 本文書と本文書に含まれる情報は「ありのまま(AS IS)」として提供される ものであり、「the Internet Societyおよびthe Internet Engineering Task Forceは、明示、黙示の別をとわず、ここに含まれる情報の利用がい かなる権利も侵害しない保証、あるいは商業的あるいは特定目的への適合 性のいかなる黙示の保証を含み、これらに限られないいかなる保証も否認 する。」 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." ポステル & レイノルズ 情報提供 [20ページ] Postel & Reynolds Informational [Page 20]