RFC2223 日本語訳
2223 Instructions to RFC Authors. J. Postel, J. Reynolds. October 1997. (Format: TXT=37948 bytes) (Obsoletes RFC1543, RFC1111, RFC0825) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Postel Request for Comments: 2223 J. Reynolds Obsoletes: 1543, 1111, 825 ISI Category: Informational October 1997
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 2223 J.レイノルズは以下を時代遅れにします。 1543、1111、825ISIカテゴリ: 情報の1997年10月
Instructions to RFC Authors
RFC作者への指示
Status of this Memo
この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)インターネット協会(1997)。 All rights reserved。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 編集方針. . . . . . . . . . . . . . . . . . . . . . 3 3。 形式は.4 3にaを統治します。 ASCII形式は.5 3にbを統治します。 ポストスクリプトは規則. . . . . . . . . . . . . . . . . . 6 4をフォーマットします。 ヘッダー. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4a。 最初に、ページ見出し. . . . . . . . . . . . . . . . . . . . 7 4b。 ヘッダー. . . . . . . . . . . . . . . . . . . . . . 8 4cを走らせます。 フッター. . . . . . . . . . . . . . . . . . . . . . 8 5を車で送ります。 状態部. . . . . . . . . . . . . . . . . . . . . . . 8 6。 版権情報. . . . . . . . . . . . . . . . . . . . . . 9 7。 序論部. . . . . . . . . . . . . . . . . . . . 9 8。 参照部. . . . . . . . . . . . . . . . . . . . 11 9 セキュリティ問題部. . . . . . . . . . . . . 11 10 作者のアドレス部. . . . . . . . . . . . . . . . . 11 11。 Copyright部. . . . . . . . . . . . . . . . . . . . 11 12。 他のRFCs. . . . . . . . . . . . . . . . . . 12 13との関係。 標準化過程. . . . . . . . . . . . . . . . 13 14を議定書の中で述べてください。 .13 15に連絡してください。 発送先リスト. . . . . . . . . . . . . . . . . . . . 14 16。 RFCは.14 17に索引をつけます。 セキュリティ問題. . . . . . . . . . . . . . . . . 14 18。 参照. . . . . . . . . . . . . . . . . . . . . . . . 14 19。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 15 20。 付録--RFC「nroffマクロ」.16 21。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 20
Postel & Reynolds Informational [Page 1] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[1ページ]のRFC2223Instructions
1. Introduction
1. 序論
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs.
Comments(RFC)のためのこのRequestはRFCsの準備、およびRFCsの公表に関連するある方針の情報を提供します。
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 Editorの裁量で許容できるかもしれません。
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.
メモは、RFCsがだれによっても提出されるかもしれないということであるよう提案しました。 RFCsになるメモの1つの大きい源がインターネット・エンジニアリング・タスク・フォース(IETF)です。 彼らが、公表の準備ができています、次に、メモがインターネットEngineering Steering Groupが再検討されるということであると感じて(IESG)、IESGによってRFC Editorに送られて、承認されるなら、IETFワーキンググループ(WGs)は彼らの作業メモ(インターネットDraftsかI-Dsとして、知られている)を発展します。
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 Editorに提出されたメモの大部分は、可能な関係がIETF Working Groupsで進行中で働くように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.
パブリックアクセスがファイルされるとき、格納されることによって、オンラインでRFCsを分配します、そして、メモの有用性を示す発送先リストに短いメッセージを送ります。
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).
彼らの設備に関する彼らのサイトにオンライン・ファイルを関心がある人々がコピーして、印刷するか、または表示します。 これは、オンライン・ファイルの形式がさまざまな印刷と表示設備の規制を満たさなければならないことを意味します。 (また、メール質問に対応したメールでRFCsを返すか、または情報とゴーファー、Wais、またはWorld Wide Web(WWW)などのデータベース検索ツールを使用しているのをRFCsを見つけるかもしれません。
RFCs have been traditionally published and continue to be published in ASCII text.
RFCsは、伝統的に発行されて、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.
いつも第一のRFCsがASCIIテキスト・ファイルである間、RFCの二次の、または、代替のバージョンをポストスクリプトに提供するかもしれません。 この決定はRFCsにダイヤグラム、図面、およびそのようなものを含む願望によって動機づけられています。 ポストスクリプトが記録する、(紙上、あまりにだけ遠くに)、目視によりさらに上告していて、読み易さを改善させます。
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.
ポストスクリプトはポストスクリプトのできるプリンタの知覚された広い普及の有用性のために他の可能なシステム(例えば、押印、interpress、oda)の上の高級フォームのRFC公表に選ばれました。
Postel & Reynolds Informational [Page 2] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[2ページ]のRFC2223Instructions
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)を使用します。 しばしば、RFCsからの簡潔な抜粋はメールに含まれています。 これらの習慣はポストスクリプトファイルでまだ実用的ではありません。
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.
ポストスクリプト生産システムは望ましいより少ない規格です、そして、ポストスクリプトを生産すると主張する文書作成システムの数個が実際に標準的でない結果を生みます。
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.
将来、ポストスクリプトRFCsの生産における使用のために認可された1セットの文書作成システムを特定するのが必要であるかもしれません、それらが発生させる出力ファイルの順正に基づいて。
2. Editorial Policy
2. 編集方針
Documents proposed to be RFCs are reviewed by the RFC Editor and possibly by other reviewers he selects.
ドキュメントは、RFCsがRFC Editorとことによると彼が選ぶ他の評論家によって見直されるということであるよう提案しました。
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作業部会の対象であり、作者がワーキンググループと共に両方の利点に調整できたのは、明らかであるかもしれません。 この普通の結果は改訂されたメモがワーキンググループインターネットDraftとして製作されて、結局IESGからRFC Editorまでの推薦としてIETFの過程から出て来るということです。
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 Editorは特にスタイルと形式の領域でマイナーチェンジをドキュメントにしますが、テキストにもいくつかの時にするかもしれません。 時々、RFC Editorは、より重要な変更を行うのを引き受けるでしょう、特に形式規則(以下を見る)が従われていないとき。 しかしながら、よりしばしば、追加仕事のためにメモを作者に返すでしょう。
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
RFC Editorに送る前にIESGは標準化過程プロトコルを指定するRFCsになることを意図するドキュメントを承認しなければなりません。 決められた手順はIESGが標準化過程RFCになることになっているドキュメントへの作業を終了するとき、IESGの長官からRFCまでコミュニケーションがあるということです。
Postel & Reynolds Informational [Page 3] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[3ページ]のRFC2223Instructions
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.
エディタ。 一般に、問題のドキュメントはインターネットDraftsです。 通常、コミュニケーションは問題の正確なインターネットDraft(ファイル名による)を引用します。 RFC Editorは、その唯一のファイルがRFCになるように処理されることであると仮定しなければなりません。 作者は、作者が小さい修正をテキストに持っているなら、別々に(または「デフ」として)それらをRFC Editorに送るべきであり、ドキュメントの新しいバージョンは送るべきではありません。
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.
いくつかの場合、作者は、高級形式でポストスクリプトを使用することでRFCsの交互の二次バージョンを準備します。 RFCのASCIIテキストバージョンが正式バージョンであるので、ポストスクリプトバージョンはテキストバージョンに合わなければなりません。 RFC Editorが決めなければならない、ポストスクリプトバージョンであるなら、ポストスクリプトバージョンを発行できる前に「同じ」は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 Editorが最初にRFCとして公表に終えたメモについてASCII版を処理するということです。 作者がASCII版に合っているそのポイントでポストスクリプトバージョンを提出したいなら(RFC Editorは、そうするのに同意します)、ポストスクリプトバージョンは、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 Editorialスタッフへの様々な時間プレッシャーのため、提出と発行の間の経過時間は大いに異なることができます。 この間に(一度1週間だけ)RFCの状態に関してRFC Editorについて質問するのは(確認します)いつも許容できます。 IETFミーティングに先行する2週間が一般に非常に忙しいので、IETFミーティングのすぐ前に提出された中でRFCsはミーティングの後に最も発行されそうです。
3. Format Rules
3. 形式規則
To meet the distribution constraints, the following rules are established for the two allowed formats for RFCs: ASCII and PostScript.
分配規制を満たすために、以下の規則はRFCsのための2つの許容形式のために確立されます: ASCIIとポストスクリプト。
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 Editorは、一貫したRFCスタイルを確実にするのを試みます。 これをするために、RFC EditorはRFCが提出した再フォーマットに選ぶかもしれません。 服従が最新のRFCsのスタイルに合っているなら、これをするのははるかに簡単です。 いくつかの最近のRFCsを見て、同じスタイルであなたのものを用意してください。
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 Editorに提出しなければなりません。 RFC Editorは形式かスタイルにおけるマイナーチェンジを必要である、または作るかもしれません、そして、実際のRFC番号を挿入するでしょう。
Postel & Reynolds Informational [Page 4] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[4ページ]のRFC2223Instructions
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.
unix"nroff"プログラムが"ms"マクロ・パッケージから書式付けコマンド(または、「要求」)の非常に簡単なセットを使用している状態で、RFCsの大部分はRFC Editorによって処理されます(Appendixを見てください)。 それを提出するとき、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の線に制限しなければなりません。
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.
終わっている公表形式かnroffのメールメッセージ(またはオンライン・ファイルとして)のRFC EditorにASCII FormatのRFCsを提出するかもしれません。 nroffのドキュメントを提出するのを計画しているなら、最初に、RFC Editorに相談してください。
Postel & Reynolds Informational [Page 5] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[5ページ]のRFC2223Instructions
3b. PostScript Format Rules
3b。 ポストスクリプト形式規則
Standard page size is 8 1/2 by 11 inches.
標準のページ・サイズは8 1/2×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.
9.6ポイントの線スペースがある8ポイントほど小さくない脚注と図表注釈。
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.
3つの字体が許容しています: Helvetica、タイムズのローマン、および急使。 それらの太字とイタリック体のバージョン。 これらはほとんどのポストスクリプトプリンタの3つの標準の字体です。
Prepare diagrams and images based on lowest common denominator
PostScript. Consider common PostScript printer functionality and
memory requirements.
最小公分母ポストスクリプトに基づくダイヤグラムとイメージを用意してください。 一般的なポストスクリプトがプリンタの機能性とメモリ要件であると考えてください。
The following PostScript commands should not be used:
initgraphics, erasepage, copypage, grestoreall, initmatrix,
initclip, banddevice, framedevice, nulldevice and renderbands.
以下のポストスクリプトコマンドを使用するべきではありません: 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とポストスクリプトバージョンにおいておそらく異なることに注意してください。 したがって、通常、セクション番号に従ったテキストにおける相互参照はページ番号による参照に交差しているより一貫していた状態で保ちやすいです。
These PostScript rules are likely to changed and expanded as
experience is gained.
経験するのに応じて、規則がありそうであるこれらのポストスクリプトは、変化して、広がりました。
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.
メールメッセージ(またはオンライン・ファイルとして)のRFC EditorにポストスクリプトFormatのRFCsを提出するかもしれません。 ポストスクリプトでドキュメントを提出するのを計画しているなら、最初に、RFC Editorに相談してください。
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テキストバージョンが正式バージョンであるのでテキストバージョンに合わなければならないことに注意してください。 RFC Editorが決めなければならない、ポストスクリプトバージョンであるなら、ポストスクリプトバージョンを発行できる前に「同じ」はASCII版ですか?
Postel & Reynolds Informational [Page 6] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[6ページ]のRFC2223Instructions
4. Headers and Footers
4. ヘッダーとフッター
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.
コメントを求めてこれが要求であると認識して、数を指定します。 左側のセカンドラインの上に示されます。 実数は公表の前に土壇場で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.
作者の名前(先頭の頭文字と姓専用)は、1日に見出しの右側に立ち並ぶように示しました。
Organization
組織
The author's organization, indicated on the second line on the
right side.
右側のセカンドラインの上に示された作者の組織。
Date
日付
This is the Month and Year of the RFC Publication. Indicated on
the third line on the right side.
これは、RFC PublicationのMonthとYearです。 右側の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 UpdatesかObsoletesであるなら、別のRFCであり、これは見出しの左側の3番目の線として示されます。
Postel & Reynolds Informational [Page 7] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[7ページ]のRFC2223Instructions
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、1のカテゴリ、: 標準化過程、情報的、または、実験的な最も良い現在の習慣。 これは左側の3(どんなUpdatesもObsoletes指示もなければ)番目か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(Your情報のための)[4]、BCP(最も良いCurrent Practice)[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 NNNN)、中心に置かれた(ことによるとnshortenedされたフォーム)タイトル、および(月のYear)日付に右にRFC番号を持っています。
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ページ])に左、中心に置かれたカテゴリ、およびページ番号に作者の姓を持っています。
5. Status Section
5. 状態部
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は、最初のページ「このMemoの状態」部にどれが2つの要素を含むかを含まなければなりません: (1) (2) RFCのタイプ、および分配声明について説明するパラグラフ。
The content of this section will be one of the four following statements.
このセクションの内容は4つの次の声明の1つになるでしょう。
Postel & Reynolds Informational [Page 8] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[8ページ]のRFC2223Instructions
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."
「このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。」 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 「このメモの分配は無制限です。」
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."
「このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。」 「このメモの分配は無制限です。」
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."
「このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。」 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 「このメモの分配は無制限です。」
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. Copyright Notice
6. 版権情報
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.
すぐに、声明、「Copyright(C)インターネット協会(日付)」というStatus部に続きます。 「All rights reserved」 置かれます。 また、ドキュメントの端に現れなければならない明細書に関してセクション11を見てください。
7. Introduction Section
7. 序論部
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に関する動機について(特に)説明して、説明されたプロトコルの適用性について説明する(適切であるなら)Introduction部があるはずです。
Normally, this will be the "abstract" section from the Internet
Draft. If the RFC is not based on an I-D, other possibilities
are:
通常、これはインターネットDraftから「抽象的な」セクションになるでしょう。 RFCがI-Dに基づいていないなら、他の可能性は以下の通りです。
Postel & Reynolds Informational [Page 9] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[9ページ]のRFC2223Instructions
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は、それに含まれた提案への彼らの反応に請求するためにインターネットコミュニティのメンバーに分配されています。 議論した問題が直接インターネットの研究課題に関連していないかもしれない間、それらは多くの研究者とimplementersにおもしろいかもしれません。
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は共同体のメンバーの利益のために発行されます。 本書では含まれた情報は、公表の日付現在、正確ですが、変化を被りやすいです。 その後のRFCsはそのような変化を反映するでしょう。
These paragraphs need not be followed word for word, but the
general intent of the RFC must be made clear.
これらのパラグラフは一語一語従われる必要はありませんが、RFCの総合的目的を明らかにしなければなりません。
Postel & Reynolds Informational [Page 10] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[10ページ]のRFC2223Instructions
8. References Section
8. 参照部
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.
ほとんどすべてのRFCsが他のドキュメントに引用を含んでいます、そして、これらはRFCの端頃のReferences部で記載されています。 参照のための多くのスタイルがあります、そして、RFCsには、それら自身のの1つがあります。 最近のRFCsで使用される参照スタイルに続いてください。 例に関してこの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.
多くの標準化過程ドキュメントでは、いくつかの単語が、仕様による要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 BCP14(RFC2119[3])はそれらがIETFドキュメントで解釈されるべきであるとこれらの単語を定義します。
9. Security Considerations Section
9. セキュリティ問題部
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.
すべてのRFCsがドキュメントの端頃のRFCの主な話題であるプロトコルか手順のセキュリティ問題について論ずるセクションを含まなければなりません。
10. Author's Address Section
10. 作者のアドレス部
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番号) そして、インターネットEメールアドレス。
11. Copyright Section
11. Copyright部
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".
BCP9、RFC2026[2]あたり「以下の版権情報と注意書きはすべてのISOCの規格関連のドキュメンテーションに含まれているものとします」。 以下の声明はRFCの終面に関して「完全な著作権宣言文」として課されるべきです。
"Copyright (C) The Internet Society (date). All Rights Reserved.
「Copyright(C)インターネット協会(日付)。」 All rights reserved。
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを翻訳するために必要に応じてインターネットStandardsの過程で定義された著作権のための手順にどのケースに従わなければならないかにインターネット標準を開発する目的に必要であるのを除いて
Postel & Reynolds Informational [Page 11] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[11ページ]のRFC2223Instructions
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
12. Relation to other RFCs
12. 他のRFCsとの関係
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.
以前のドキュメントを参照するのに使用されるために、それをこのドキュメントに取り替えます。 このドキュメントは同じ情報と何らかの新情報の改訂された情報かすべてのどちらかを含んでいます、その新情報がどんなに大規模であるか、または簡潔であっても。 より古いドキュメントの参照なしですなわち、このドキュメントを単独で使用できます。
Postel & Reynolds Informational [Page 12] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[12ページ]のRFC2223Instructions
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.
したがって、そして、Assigned民数記RFCsでは、Obsoletesという用語が新しいドキュメントが実際に、新情報(しかしながら、簡潔な)を既存情報のテキストに組み入れるので使用されるべきであり、より古いドキュメントより最新である、それを取り替えて、それを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.
RFCsのリストかRFC-インデックス(しかし、いずれのRFCs自身でも、そうしない)では、以下は、後のドキュメントを示すのに早めのドキュメントと共に使用されるかもしれません。
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.
言及するのにおいて使用されているために、既存の、そして、それでも、中古のドキュメントに追加されることになっているセクションは、より新しいです。
13. Protocol Standards Process
13. プロトコル標準化過程
See the current "Internet Official Protocol Standards" (STD 1) memo for the definitive statement on protocol standards and their publication [1].
プロトコル標準に関する決定的な声明とそれらの公表[1]のための現在の「インターネット公式プロトコル標準」(STD1)というメモを見てください。
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.
決められた手順はIESGが標準化過程RFCになることになっているドキュメントへの作業を終了するとき、IESGの長官からRFC Editorまでコミュニケーションがあるということです。 一般に、問題のドキュメントはインターネットDraftsです。 通常、コミュニケーションは問題の正確なインターネットDraft(ファイル名による)を引用します。 RFC Editorは、その唯一のファイルがRFCになるように処理されることであると仮定しなければなりません。 作者が小さい修正をテキストに持っているなら、別々に(または「デフ」として)それらをRFC Editorに送るべきであり、ドキュメントの新しいバージョンは送らないでください。
14. Contact
14. 接触
To contact the RFC Editor send an email message to:
RFC Editorに連絡するために、メールメッセージを以下に送ってください。
"rfc-editor@isi.edu".
" rfc-editor@isi.edu "。
Postel & Reynolds Informational [Page 13] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[13ページ]のRFC2223Instructions
15. Distribution Lists
15. 発送先リスト
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発表は2つのメーリングリストで広げられます: 「IETF発表している」リスト、および"RFC-DIST"リスト。 あなたは両方のリストにいたがっていません。
To join (or quit) the IETF-Announce list send a message to ietf- request@ietf.org.
IETF発表しているリストを接合する(やめる)には、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 にメッセージを送ってください。
16. RFC Index
16. 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.
一般に、"rfc-index.txt"というファイル名を使用して、いくつかの組織がRFC Indexファイルを保守します。 1つのサイトからコピーされたそのようなファイルのコンテンツは別のサイトからコピーされたそれと同じでないかもしれません。
17. Security Considerations
17. セキュリティ問題
This RFC raises no security issues (however, see Section 9).
このRFCは安全保障問題を全く提起しません(しかしながら、セクション9を見てください)。
18. References
18. 参照
[1] Postel, J., Editor, "Internet Official Protocol Standards", STD
1, RFC 2200, June 1997.
[1] ポステル、J.、エディタ、「インターネット公式プロトコル標準」、STD1、RFC2200、1997年6月。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] マルキン、G.、およびJ.レイノルズ、「F.Y.I.注意へのF.Y.I序論でのF.Y.I.」、FYI1、RFC1150は1990を行進させます。
[5] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices",
BCP 1, RFC 1818, August 1995.
[5] ポステルとJ.と李、T.とY.Rekhter、「最も良い現在の実務」、BCP1、RFC1818、1995年8月。
[6] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
March 1992.
[6] ポステル、J.、エディタ、「STD注意への序論」、RFC1311、1992年3月。
Postel & Reynolds Informational [Page 14] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[14ページ]のRFC2223Instructions
19. Authors' Addresses
19. 作者のアドレス
Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: +1 310-822-1511 Fax: +1 310-823-6714 EMail: Postel@ISI.EDU
以下に電話をしてください。 +1 310-822-1511Fax: +1 310-823-6714 メールしてください: Postel@ISI.EDU
Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ジョイスK.レイノルズUSC/情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: +1 310-822-1511 Fax: +1 310-823-6714 EMail: jkrey@isi.edu
以下に電話をしてください。 +1 310-822-1511Fax: +1 310-823-6714 メールしてください: jkrey@isi.edu
Postel & Reynolds Informational [Page 15] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[15ページ]のRFC2223Instructions
20. Appendix - RFC "nroff macros"
20. 付録--RFC「nroffマクロ」
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は>出力ファイルを入力してファイルします」。 しかしながら、私たちはnroffに1ページの最後の可視行にもかかわらず、次のページの最初の可視行の前でどんな余分な改行の後にも改ページを置かないことに関して正しいことをさせることができませんでした。 私たちは、以下が欲しいと思います。
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"と呼ばれるパールスクリプトを使用します。 それで、ファイルを処理するコマンドはなります:
nroff -ms input-file | fix.pl > output-file
nroff -ms入力ファイル| fix.pl>出力ファイル
The actual perl script is:
実際のパールスクリプトは以下の通りです。
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #! /local/bin/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
# ページが最後に#系列<によって区切られるようにRFCsのためのスタイルガイドが呼ぶUSC/ISI##のfix.pl1993年11月17日のクレイグ・ミロ・ロジャース、-、非、-><><formfeed線の1番目を空白に裏打ちしてください、-、非、->を空白に裏打ちしてください。 # 残念ながら、NROFFはこのコンベンションを#、に従わせる出力を起こすのに気が重いです。 このスクリプトは象徴"FORMFEEDPage"のための#、を捜すことによって、RFC-スタイルドキュメントを修理します、"FORMFEED"を空間に取り替えて、#次の#非余白キャラクタまでformfeed線を追加して、余白を削除して。##それが置き換える#"fix.sh"と"pg"プログラムのこのスクリプトの出力とものの間には、1つの違いがあります: このスクリプトは終面の後のformfeedの後にファイルに#ニューラインを含んでいます;
Postel & Reynolds Informational [Page 16] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[16ページ]のRFC2223Instructions
# 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「#、が取り替えられなければならないかもしれないs下」\r円のn「s」。
$* = 1; # Enable multiline patterns.
undef $/; # Read whole files in a single
# gulp.
$* = 1; # マルチラインパターンundef$/を可能にしてください。 # ただ一つの#ぐい飲みで全体のファイルを読んでください。
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.
}
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(<>)をゆったり過ごしてください。{ # . 1s/FORMFEED(\[ページ\s+\d+\])\s+/円の\を全体の入力ファイルにn円fの\n/g読み込んでください。 # ページの端を書き直してください。 # s/\f\nドル/\f/。 # むき出しで、終わりにformfeedされて、欲しいですか? # s/\f\n$、//。 # 終わり?印刷でformfeedしないで欲しいです。 # 結果のファイルを印刷してください。 } #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc- editor/fix.pl
また、以下からこのスクリプトをコピーできます。 ftp://ftp.isi.edu/in-notes/rfc- エディタ/fix.pl
Now as to the nroff features we actually use, following is a sample memo, prepared in RFC style.
現在、私たちが実際に使用するnroffの特徴に関して、以下に、RFCスタイルで準備されたサンプルメモがあります。
Postel & Reynolds Informational [Page 17] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[17ページ]のRFC2223Instructions
.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
CommentsのためのAvian Carriers .hy0.ad l.in0Network作業部会D.Waitzman Requestの上の.pl 10.0i .po0.ll 7.2i .lt 7.2i.nr LL 7.2i .nr LT 7.2i .ds LF Waitzman .ds RF PUTFFHERE[ページ%].ds CF .ds LH RFC1149.ds RH1990年4月1日の.ds CH IPデータグラム: 1149 BBN STC1990年4月1日
.ce A Standard for the Transmission of IP Datagrams on Avian Carriers
.ceは鳥のキャリヤーにおけるIPデータグラムの送信の規格です。
.ti 0 Status of this Memo
このMemoの.ti0Status
.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 .in3ThisメモはIPデータグラムのカプセル化のために鳥のキャリヤーで実験的方法を説明します。 この仕様はMetropolitan Area Networksで主として役に立ちます。 これがそうである、実験的である、お勧めの規格でない。 このメモの分配は無制限です。
.ti 0 Overview and Rational
.ti0概観的で合理的です。
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.
鳥のキャリヤーは高い遅れ、少ないスループット、および低い高度サービスを提供できます。 接続形態は標準のキャリヤーと共に使用される各キャリヤーのためにただ一つの二地点間経路に制限されますが、互い(早春の外部)の重要な干渉なしで多くのキャリヤーを使用できます。 キャリヤーに、利用可能な3Dエーテルスペースのためにこれはそうです、IEEE802.3によって使用された1Dエーテルと対照して。 キャリヤーには、本質的な衝突回避システムがあります。(それは、有用性を増加させます)。 パケットラジオなどのいくつかのネットワーク技術と異なって、コミュニケーションは見通し距離に制限されません。 コネクション型サービスは、いくつかの都市で利用可能であって、通常、中央のハブトポロジーに基づいています。
Postel & Reynolds Informational [Page 18] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[18ページ]のRFC2223Instructions
.ti 0 Frame Format
.ti0フレーム形式
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進で、各八重奏がwhitestuffとblackstuffによって切り離されている状態で。 紙の巻き物は鳥のキャリヤーの1本の脚に巻きつけられます。 ダクトテープのバンドは、データグラムの優勢を保証するのに使用されます。 帯域幅は脚の長さに制限されます。 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
.ti0議論
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
.ti0セキュリティ問題
.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.
.in3Securityは通常の操作では一般に問題ではありませんが、鳥のキャリヤーが戦術の環境で使用されるとき、特別な対策は実施されなければなりません(データ暗号化としてのそのようなもの)。
.ti 0 Author's Address
.ti0作者のアドレス
.nf David Waitzman BBN Systems and Technologies Corporation BBN Labs Division 10 Moulton Street Cambridge, MA 02238
事業部10モールトン・通りケンブリッジ、技術社のBBN研究室MA .nfデヴィッドWaitzman BBN Systemsと02238
Phone: (617) 873-4323
以下に電話をしてください。 (617) 873-4323
EMail: dwaitzman@BBN.COM
メール: dwaitzman@BBN.COM
Postel & Reynolds Informational [Page 19] RFC 2223 Instructions to RFC Authors October 1997
RFC作者1997年10月へのポステルとレイノルズ情報[19ページ]のRFC2223Instructions
21. Full Copyright Statement
21. 完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配されたimplmentationを助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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."
「このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。」
Postel & Reynolds Informational [Page 20]
ポステルとレイノルズInformationalです。[20ページ]
一覧
スポンサーリンク
