[要約] RFC 2223は、RFCの著者に対する指示を提供するドキュメントです。その目的は、RFCの作成プロセスを明確化し、一貫性を確保することです。
Network Working Group J. Postel
Request for Comments: 2223 J. Reynolds
Obsoletes: 1543, 1111, 825 ISI
Category: Informational October 1997
Instructions to RFC Authors
RFC作成者への指示
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）。全著作権所有。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3
3. Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4
3a. ASCII Format Rules . . . . . . . . . . . . . . . . . . . . 5
3b. PostScript Format Rules . . . . . . . . . . . . . . . . . . 6
4. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4a. First Page Heading . . . . . . . . . . . . . . . . . . . . 7
4b. Running Header . . . . . . . . . . . . . . . . . . . . . . 8
4c. Running Footer . . . . . . . . . . . . . . . . . . . . . . 8
5. Status Section . . . . . . . . . . . . . . . . . . . . . . . 8
6. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 9
7. Introduction Section . . . . . . . . . . . . . . . . . . . . 9
8. References Section . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations Section . . . . . . . . . . . . . 11
10. Author's Address Section . . . . . . . . . . . . . . . . . 11
11. Copyright Section . . . . . . . . . . . . . . . . . . . . 11
12. Relation to other RFCs . . . . . . . . . . . . . . . . . . 12
13. Protocol Standards Process . . . . . . . . . . . . . . . . 13
14. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Distribution Lists . . . . . . . . . . . . . . . . . . . . 14
16. RFC Index . . . . . . . . . . . . . . . . . . . . . . . . 14
17. Security Considerations . . . . . . . . . . . . . . . . . 14
18. References . . . . . . . . . . . . . . . . . . . . . . . . 14
19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
20. Appendix - RFC "nroff macros" . . . . . . . . . . . . . . 16
21. Full Copyright Statement . . . . . . . . . . . . . . . . . 20
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs.
このRequest for Comments（RFC）は、RFCの準備、および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の一連のノートは、幅広い関心をカバーしています。中心となるトピックは、インターネットとTCP / IPプロトコルスイートです。ただし、コンピュータ通信に関連するトピックは、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として提案されたメモは誰でも提出できます。 RFCになるメモの1つの大きな情報源は、インターネット技術特別調査委員会（IETF）です。 IETFワーキンググループ（WG）は、ワーキングメモ（インターネットドラフトまたはI-Dと呼ばれる）を公開の準備ができると感じるまで進化させ、その後、インターネットエンジニアリングステアリンググループ（IESG）によってレビューされ、承認された場合は、 IESGからRFCエディターへ。
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エディターに送信されたメモのほとんどは、IETFワーキンググループで進行中の関係についてIESGによって検討されます。
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.
RFCはパブリックアクセスファイルとして保存されることによりオンラインで配布され、メモの可用性を示す短いメッセージが配布リストに送信されます。
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は、電子メールクエリへの応答として電子メールで返される場合もあります。または、RFCは、Gopher、Wais、またはWorld Wide Web（WWW）などの情報およびデータベース検索ツールを使用して見つけることができます。
RFCs have been traditionally published and continue to be published in ASCII text.
RFCは伝統的に公開されており、引き続きASCIIテキストで公開されています。
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は常にASCIIテキストファイルですが、RFCのセカンダリまたは代替バージョンがPostScriptで提供される場合があります。この決定は、RFCに図や図面などを含めたいという欲求に基づいています。 PostScriptドキュメント（これまでのところ紙面のみ）は、視覚的に魅力的で読みやすくなっています。
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.
PostScript対応プリンターは広く普及していると認識されているため、PostScriptは他の可能なシステム（impress、interpress、odaなど）よりも優れた形式のRFC公開用に選択されました。
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.
ただし、多くのRFCユーザーはオンラインでドキュメントを読み、さまざまなテキスト指向のツール（emacs、grepなど）を使用して検索します。多くの場合、RFCからの短い抜粋が電子メールに含まれています。これらのプラクティスは、PostScriptファイルではまだ実用的ではありません。
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.
PostScript生成システムは望ましいものよりも標準的ではなく、PostScriptを生成すると主張するいくつかのドキュメント生成システムは実際には非標準的な結果を生成します。
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.
将来的には、PostScript RFCの生成での使用が許可された一連のドキュメント生成システムを、それらが生成する出力ファイルの妥当性に基づいて識別する必要が生じる可能性があります。
Documents proposed to be RFCs are reviewed by the RFC Editor and possibly by other reviewers he selects.
RFCであると提案されたドキュメントは、RFCエディターによって、そしておそらく彼が選択した他のレビューアーによってレビューされます。
The result of the review may be to suggest to the author some improvements to the document before publication.
レビューの結果は、出版前に文書にいくつかの改善を提案することになるかもしれません。
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のトピックがIETFワーキンググループの主題でもあり、著者がワーキンググループと協力して両方の利点を享受できることは明らかです。これの通常の結果は、改訂されたメモがワーキンググループのインターネットドラフトとして作成され、最終的にIESGプロセスからIESGからRFCエディターへの勧告として現れることです。
In some cases it may be determined that the submitted document is not appropriate material to be published as an RFC.
場合によっては、提出されたドキュメントが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.
場合によっては、ドキュメント内のアイデアに関するレビューに基づくステートメントをドキュメントに含める必要がある場合があります。これは、文書が関連しているが不適切または安全でないアイデアやその他の状況を示唆している場合に行われます。
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エディターは、特にフォーマットルール（下記参照）が守られていない場合に、より重要な変更を行うことを約束する場合があります。ただし、多くの場合、メモは追加の作業のために作成者に返されます。
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 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になることを目的としたドキュメントは、RFCエディタに送信する前にIESGによって承認される必要があります。確立された手順は、標準化されたRFCになるドキュメントでIESGが作業を完了するとき、通信はIESGの書記からRFC編集者への通信になるというものです。通常、問題の文書はインターネットドラフトです。通信では通常、問題の正確なインターネットドラフトが（ファイル名で）引用されます。 RFCエディタは、そのファイルだけが処理されてRFCになることを前提とする必要があります。作成者がテキストに小さな修正を加えた場合、それらは個別に（または「diff」として）RFCエディタに送信する必要があります。作成者はドキュメントの新しいバージョンを送信しないでください。
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.
場合によっては、著者はPostScriptを使用して、RFCの代替セカンダリバージョンを空想的な形式で準備します。 RFCのASCIIテキストバージョンがプライマリバージョンであるため、PostScriptバージョンはテキストバージョンと一致する必要があります。 RFCエディタは、PostScriptバージョンを公開する前に、PostScriptバージョンがASCIIバージョンと「同じ」かどうかを判断する必要があります。
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エディターが最初にメモのASCIIバージョンを処理してRFCとして公開することです。作成者がその時点でASCIIバージョンと一致するPostScriptバージョンを送信することを希望している（そしてRFCエディタが同意する）場合、PostScriptバージョンがRFCリポジトリにインストールされ、コミュニティに通知されます。
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.
RFC編集スタッフへのさまざまな時間的プレッシャーにより、提出から公開までの経過時間は大きく異なります。この間（ただし、週に1回以下）、RFCのステータスについてRFC Editorにクエリ（ping）することは常に許容されます。 IETF会議の前の2週間は一般的に非常に忙しいため、IETF会議の直前に送信されたRFCは、会議後に公開される可能性が最も高くなります。
To meet the distribution constraints, the following rules are established for the two allowed formats for RFCs: ASCII and PostScript.
配布の制約を満たすために、RFCで許可されている2つの形式（ASCIIとPostScript）に対して次の規則が確立されています。
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エディターは、送信された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.
RFCエディタに編集可能なオンラインドキュメントを提出する必要があります。 RFCエディタでは、形式やスタイルを変更する必要がある場合や、若干の変更が必要な場合があり、実際の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.
ほとんどのRFCは、「ms」マクロパッケージ（付録を参照）からの非常に単純なフォーマットコマンド（または「要求」）のセットを使用して、UNIXの「nroff」プログラムを使用してRFC Editorによって処理されます。 RFCとして提出されたメモが作者によってnroffを使用して作成されている場合、いつ提出されたかをRFC Editorに知らせることは非常に役立ちます。
3a. ASCII Format Rules
3a。 ASCII形式の規則
The character codes are ASCII.
文字コードはASCIIです。
Each page must be limited to 58 lines followed by a form feed on a line by itself.
各ページは58行に制限する必要があり、その後に1行だけのフォームフィードが続きます。
Each line must be limited to 72 characters followed by carriage return and line feed.
各行は72文字に制限され、その後に改行と改行が続きます。
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.
段落内ではスペースを空けたテキストを使用し、段落の間には空白行を1つ入れます。
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.
文書のページ数と、さまざまなセクションが配置されるページ番号は、再フォーマットによって変わる可能性があることに注意してください。したがって、セクション番号によるテキスト内の相互参照は、通常、ページ番号による相互参照よりも一貫性を保つ方が簡単です。
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.
ASCII形式のRFCは、完成した発行形式またはnroffのいずれかで、電子メールメッセージ（またはオンラインファイル）でRFCエディターに送信できます。 nroffでドキュメントを送信する場合は、最初にRFCエディタを参照してください。
3b. PostScript Format Rules
3b。 PostScriptフォーマットルール
Standard page size is 8 1/2 by 11 inches.
標準のページサイズは8 1/2 x 11インチです。
Margin of 1 inch on all sides (top, bottom, left, and right).
すべての側面（上、下、左、および右）の1インチのマージン。
Main text should have a point size of no less than 10 points with a line spacing of 12 points.
メインテキストのポイントサイズは10ポイント以上で、行間は12ポイントです。
Footnotes and graph notations no smaller than 8 points with a line spacing of 9.6 points.
脚注とグラフ表記は、8ポイント以上、行間隔は9.6ポイントです。
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.
使用できるフォントは、Helvetica、Times Roman、Courierの3つです。さらに、太字とイタリックのバージョン。これらは、ほとんどのPostScriptプリンターの3つの標準フォントです。
Prepare diagrams and images based on lowest common denominator PostScript. Consider common PostScript printer functionality and memory requirements.
最も一般的な分母のPostScriptに基づいて図と画像を準備します。一般的なPostScriptプリンターの機能とメモリ要件を考慮してください。
The following PostScript commands should not be used: initgraphics, erasepage, copypage, grestoreall, initmatrix, initclip, banddevice, framedevice, nulldevice and renderbands.
次のPostScriptコマンドは使用しないでください：initgraphics、erasepage、copypage、grestoreall、initmatrix、initclip、banddevice、framedevice、nulldevice、およびrenderbands。
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.
ドキュメントのページ数と、さまざまなセクションが配置されるページ番号は、ASCIIバージョンとPostScriptバージョンで異なる可能性があることに注意してください。したがって、セクション番号によるテキスト内の相互参照は、通常、ページ番号による相互参照よりも一貫性を保つ方が簡単です。
These PostScript rules are likely to changed and expanded as experience is gained.
これらのPostScriptルールは、経験に応じて変更および拡張される可能性があります。
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.
PostScript形式のRFCは、電子メールメッセージで（またはオンラインファイルとして）RFCエディターに送信できます。 PostScriptでドキュメントを送信する場合は、最初にRFCエディターに相談してください。
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.
RFCのASCIIテキストバージョンがプライマリバージョンであるため、PostScriptバージョンはテキストバージョンと一致する必要があることに注意してください。 RFCエディタは、PostScriptバージョンを公開する前に、PostScriptバージョンがASCIIバージョンと「同じ」かどうかを判断する必要があります。
There is the first page heading, the running headers, and the running footers.
最初のページの見出し、実行中のヘッダー、および実行中のフッターがあります。
4a. First Page
4a。一ページ目
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
ネットワークワーキンググループ
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.
RFCシリーズを設立したグループの伝統的な見出し。これは、見出しの左側の最初の行に表示されます。
Request for Comments: nnnn
コメントのリクエスト：nnnn
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.
これをコメントの要求として識別し、番号を指定します。左側の2行目に示されています。実際の番号は、RFCエディタによって公開される前の最後の瞬間に入力されます。
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.
右側の2行目に示されている著者の組織。
Date
日付
This is the Month and Year of the RFC Publication. Indicated on the third line on the right side.
これは、RFC発行の月と年です。右側の3行目に示されています。
Updates or Obsoletes
更新または廃止
If this RFC Updates or Obsoletes another RFC, this is indicated as third line on the left side of the heading.
このRFCが別のRFCを更新または廃止した場合、これは見出しの左側の3行目として示されます。
Category
カテゴリー
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.
このRFCのカテゴリ。標準トラック、現在のベストプラクティス、情報提供、実験のいずれか。これは、左側の3行目（更新または廃止の指示がない場合）または4行目に示されます。
Other Numbers
その他の番号
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.
RFCシリーズのその他の番号には、FYI（参考情報）[4]、BCP（ベストカレントプラクティス）[5]、およびSTD（標準）[6]のサブシリーズが含まれます。これらは左側に配置されます。
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. Running Headers
4b。ヘッダーの実行
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.
1行の実行ヘッダー（2ページ目以降のすべてのページ）の左側にはRFC番号（RFC NNNN）、中央には（短縮形の可能性がある）タイトル、中央には日付（月年）があります。
4c. Running Footers
4c。ランニングフッター
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]).
（すべてのページの）1行で実行されているフッターには、左側に著者の姓、カテゴリが中央に配置され、右側にページ番号（[ページN]）があります。
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.
各RFCの最初のページには、「このメモのステータス」セクションを含める必要があります。このセクションには、（1）RFCのタイプを説明する段落と、（2）配布ステートメントの2つの要素が含まれています。
The content of this section will be one of the four following statements.
このセクションの内容は、次の4つのステートメントのいずれかになります。
Standards Track
規格トラック
"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."
「このドキュメントは、インターネットコミュニティ用のインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化の状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。」
Best Current Practice
現在のベストプラクティス
"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
実験的
"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
情報提供
"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."
「このメモはインターネットコミュニティのための情報を提供します。このメモはいかなる種類のインターネット標準も指定しません。このメモの配布は無制限です。」
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.
ステータスセクションの直後に、「著作権（C）インターネット協会（日付）。すべての権利は留保されています。」配置されます。また、ドキュメントの最後に記載する必要がある完全なステートメントについては、セクション11を参照してください。
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には、（特に）RFCの動機を説明し、（該当する場合）記載されているプロトコルの適用性を説明する序文セクションが必要です。
Normally, this will be the "abstract" section from the Internet Draft. If the RFC is not based on an I-D, other possibilities are:
通常、これはインターネットドラフトの「抽象」セクションになります。 RFCがI-Dに基づいていない場合、他の可能性は次のとおりです。
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.
このプロトコルは、bla-blaサービスを提供することを目的としており、ホストコンピュータ上のクライアントとサーバー間で使用されます。通常、クライアントはワークステーションホスト上にあり、サーバーはメインフレームホスト上にあります。
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.
このプロトコルは、bla-blaサービスを提供することを目的としており、ターミナルサーバーやルーターなどの特別な目的のユニットと監視ホストの間で使用されます。
Discussion
討論
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.
このRFCの目的は、インターネットの特定の問題と考えられる解決方法に焦点を当てることです。このドキュメントで提案されているソリューションは、インターネットの標準として意図されたものではありません。むしろ、そのような問題の適切な解決策について一般的なコンセンサスが生まれ、最終的に標準の採用につながることが期待されます。
Interest
興味
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.
このRFCは、インターネットコミュニティに含まれる提案への反応を求めるために、インターネットコミュニティのメンバーに配布されています。議論された問題は、インターネットの研究問題に直接関連していないかもしれませんが、多くの研究者や実装者にとって興味深いかもしれません。
Status Report
ステータスレポート
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はコミュニティメンバーの利益のために発行されます。このドキュメントに記載されている情報は、発行日現在の情報ですが、変更される可能性があります。後続のRFCはそのような変更を反映します。
These paragraphs need not be followed word for word, but the general intent of the RFC must be made clear.
これらのパラグラフは一言一句従う必要はありませんが、RFCの一般的な意図を明確にする必要があります。
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.
ほとんどすべてのRFCには他のドキュメントへの引用が含まれており、これらはRFCの終わり近くの「参照」セクションにリストされています。参照には多くのスタイルがあり、RFCには独自のスタイルがあります。最近のRFCで使用されている参照スタイルに従ってください。例については、このRFCの参照セクションを参照してください。 STD番号が割り当てられているプロトコルの場合、STD番号をリファレンスに含める必要があることに注意してください。
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.
多くの標準トラック文書では、仕様の要件を示すためにいくつかの単語が使用されています。これらの単語は、多くの場合大文字です。 BCP 14、RFC 2119 [3]は、IETF文書で解釈される必要があるため、これらの単語を定義しています。
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.
すべてのRFCには、RFCのメイントピックであるプロトコルまたは手順のセキュリティに関する考慮事項を説明するドキュメントの終わり近くにセクションが含まれている必要があります。
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.
各RFCの最後には、名前と住所、電話番号（オプション：FAX番号）、インターネット電子メールアドレスなど、著者のアドレスを示すセクションが必要です。
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".
BCP 9、RFC 2026 [2]に従って、「次の著作権表示と免責事項はすべてのISOC標準関連ドキュメントに含まれるものとします。」次のステートメントは、「完全な著作権ステートメント」としてRFCの最後のページに配置する必要があります。
"Copyright (C) The Internet Society (date). All Rights Reserved.
「著作権（C）インターネット協会（日付）。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
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.
RFCは、以前のRFCで議論されたトピックに関する情報を追加したり、以前のRFCを完全に置き換えたりすることがあります。これらの場合にそれぞれ使用される2つの用語、UpdatesとObsoletesがあります。以前のドキュメントを廃止するドキュメントは、それ自体で独立できます。以前のドキュメントを更新するだけのドキュメントは、それ自体では成り立ちません。これは、既存のドキュメントに追加または挿入する必要があるものであり、独立して有用性が制限されています。 SupercedesおよびReplacesという用語は使用されなくなりました。
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
時代遅れ
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.
このドキュメントで置き換えられる以前のドキュメントを参照するために使用されます。このドキュメントには、改訂された情報、または同じ情報のすべてといくつかの新しい情報のいずれかが含まれていますが、新しい情報は広範囲または簡単です。つまり、このドキュメントは、古いドキュメントを参照することなく、単独で使用できます。
For example:
例えば：
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では、新しいドキュメントは実際に既存の情報のテキストに新しい情報（ただし簡単ではあります）を組み込んでおり、古いドキュメントよりも最新であるため、Obsoletesという用語を使用する必要があります。廃止。
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.
RFCまたはRFC-Index（RFC自体ではない）のリストでは、初期のドキュメントで以下を使用して、後のドキュメントを示すことができます。
Obsoleted-by
廃止
To be used to refer to the newer document(s) that replaces the older document.
古いドキュメントを置き換える新しいドキュメントを参照するために使用されます。
Updated-by
更新者
To be used to refer to the newer section(s) which are to be added to the existing, still used, document.
既存の、まだ使用されているドキュメントに追加される新しいセクションを参照するために使用されます。
See the current "Internet Official Protocol Standards" (STD 1) memo for the definitive statement on protocol standards and their publication [1].
プロトコル標準とその公開に関する決定的な声明については、現在の「インターネット公式プロトコル標準」（STD 1）のメモを参照してください[1]。
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.
確立された手順は、標準化されたRFCになるドキュメントでIESGが作業を完了するとき、通信はIESGの書記からRFC編集者への通信になるというものです。通常、問題の文書はインターネットドラフトです。通信では通常、問題の正確なインターネットドラフト（ファイル名別）が引用されます。 RFCエディタは、そのファイルだけが処理されてRFCになることを前提とする必要があります。作成者がテキストに小さな修正を加えている場合、それらは個別に（または「diff」として）RFCエディタに送信する必要があります。ドキュメントの新しいバージョンを送信しないでください。
To contact the RFC Editor send an email message to:
RFCエディタに連絡するには、次の宛先に電子メールメッセージを送信してください。
"rfc-editor@isi.edu".
”ｒｆｃーえぢとｒ＠いし。えづ”。
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.
RFCアナウンスは、「IETF-Announce」リストと「RFC-DIST」リストの2つのメーリングリストで配布されます。あなたは両方のリストに載ることを望まない。
To join (or quit) the IETF-Announce list send a message to ietf-request@ietf.org.
IETF-Announceリストに参加（または終了）するには、ietf-request @ ietf.orgにメッセージを送信してください。
To join (or quit) the RFC-DIST list send a message to rfc-dist-request@isi.edu.
RFC-DISTリストに参加（または終了）するには、メッセージをrfc-dist-request@isi.eduに送信します。
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.
複数の組織がRFCインデックスファイルを管理しており、通常はファイル名「rfc-index.txt」を使用しています。あるサイトからコピーされたそのようなファイルの内容は、別のサイトからコピーされたものと同一ではない場合があります。
This RFC raises no security issues (however, see Section 9).
このRFCではセキュリティの問題は発生しません（ただし、セクション9を参照）。
[1] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 2200, June 1997.
[1] Postel、J。、編集者、「インターネット公式プロトコル標準」、STD 1、RFC 2200、1997年6月。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner、S.、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年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.
[4] Malkin、G。、および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, August 1995.
[5] Postel、J.、Li、T。、およびY. Rekhter、「Best Current Practices」、BCP 1、RFC 1818、1995年8月。
[6] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311, March 1992.
[6] Postel、J。、編集者、「STDノートの紹介」、RFC 1311、1992年3月。
Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ジョンポステルUSC /情報科学研究所4676アドミラルティウェイマリナデルレイ、カリフォルニア90292
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マリーナデルレイ、カリフォルニア90292
Phone: +1 310-822-1511
Fax: +1 310-823-6714
EMail: jkrey@isi.edu
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:
通常、非常に単純なnroff機能を使用します。 「ms」マクロを使用します。したがって、「nroff -ms input-file> output-file」となります。しかし、nroffがページの最後の表示行の後にフォームフィードを配置することについて正しいことを実行できず、次のページの最初の表示行の前に余分なラインフィードがありませんでした。私たちは欲しい：
last visible line on page i ^L first visible line on page i+1
iページの最後の表示行^ L 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:
そこで、これを修正するためのハックを発明しました。 「fix.pl」と呼ばれるperlスクリプトを使用します。したがって、ファイルを処理するコマンドは次のようになります。
nroff -ms input-file | fix.pl > output-file
nroff -ms入力ファイル| fix.pl>出力ファイル
The actual perl script is:
実際のperlスクリプトは次のとおりです。
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /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 <last-non-blank-line><formfeed-line><first-non-blank-line>.
# 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
# elsewhere. # 2) On systems with a CRLF end-of-line convention, the "\n"s below # may have to be replaced with "\r\n"s.
＃他の場所。 ＃2）CRLFの行末規則があるシステムでは、以下の「\ n」を「\ r \ n」に置き換える必要がある場合があります。
$* = 1; # Enable multiline patterns. undef $/; # Read whole files in a single # gulp.
$ * = 1; ＃複数行パターンを有効にします。 undef $ /; ＃ファイル全体を1つの＃一括で読み取ります。
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.
次に、実際に使用するnroff機能について、RFCスタイルで作成されたサンプルのメモを示します。
.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
.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 4月1990 .ds CHの鳥類通信事業者のIPデータグラム.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
.ce鳥のキャリアでのIPデータグラムの送信に関する標準
.ti 0 Status of this Memo
.ti 0このメモのステータス
.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.
.fi .in 3このメモは、鳥のキャリアにおけるIPデータグラムのカプセル化の実験的方法を説明しています。この仕様は、主にメトロポリタンエリアネットワークで役立ちます。これは実験的なものであり、推奨される標準ではありません。このメモの配布は無制限です。
.ti 0 Overview and Rational
.ti 0概要と合理性
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.
鳥キャリアは、高遅延、低スループット、低高度サービスを提供できます。接続トポロジは、標準的なキャリアで使用される各キャリアの単一のポイントツーポイントパスに制限されていますが、春の初めを除いて、多くのキャリアを相互に大きな干渉なしに使用できます。これは、IEEE802.3で使用される1Dエーテルとは対照的に、キャリアが使用できる3Dエーテルスペースのためです。キャリアには固有の衝突回避システムがあり、可用性が向上します。パケット無線などの一部のネットワーク技術とは異なり、通信は見通し距離に限定されません。一部の都市では、通常は中央ハブトポロジに基づいて、接続指向のサービスを利用できます。
.ti 0 Frame Format
.ti 0フレーム形式
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.
IPデータグラムは、小さな紙の巻物に16進数で印刷され、各オクテットは白と黒で区切られています。鳥の運送業者の片方の脚に巻物の巻物が巻かれています。ダクトテープのバンドを使用して、データグラムの端を固定します。帯域幅はレッグの長さに制限されます。 MTUは変動しやすく、逆説的には、一般的にキャリア年齢の増加に伴い増加します。一般的なMTUは256ミリグラムです。いくつかのデータグラムのパディングが必要になる場合があります。
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
.ti 0ディスカッション
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.
複数のタイプのサービスを優先度の高い順序で提供できます。追加のプロパティは、組み込みのワーム検出と根絶です。 IPはベストエフォートの配信のみを保証するため、キャリアの損失は許容できます。時間とともに、キャリアは自己再生します。ブロードキャストは指定されていませんが、ストームはデータの損失を引き起こす可能性があります。キャリアがドロップするまで、永続的な配信の再試行があります。監査証跡は自動的に生成され、ログやケーブルトレイで確認できます。
.ti 0 Security Considerations
.ti 0セキュリティに関する考慮事項
.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.
.in 3通常の運用ではセキュリティは問題になりませんが、鳥類の保因者が戦術環境で使用される場合は、特別な対策（データの暗号化など）を行う必要があります。
.ti 0 Author's Address
.ti 0作成者のアドレス
.nf David Waitzman BBN Systems and Technologies Corporation BBN Labs Division 10 Moulton Street Cambridge, MA 02238
.nf David Waitzman BBN Systems and Technologies Corporation BBN Labs Division 10 Moulton Street Cambridge、MA 02238
Phone: (617) 873-4323
電話：（617）873-4323
EMail: dwaitzman@BBN.COM
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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 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."
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性の権利または黙示の保証を侵害するものではありません。」