RFC2360 日本語訳
2360 Guide for Internet Standards Writers. G. Scott. June 1998. (Format: TXT=47280 bytes) (Also BCP0022) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Scott, Editor Request for Comments: 2360 Defense Information Systems Agency BCP: 22 June 1998 Category: Best Current Practice
ワーキンググループのG.スコット、コメントを求めるエディタ要求をネットワークでつないでください: 2360防衛情報システム庁BCP: 1998年6月22日のカテゴリ: 最も良い現在の習慣
Guide for Internet Standards Writers
インターネット規格には、作家を誘導してください。
Status of this Memo
このMemoの状態
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を改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. In addition, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors".
このドキュメントはインターネット標準作家のためのガイドです。 それは一貫性を持っていて、明白で、解釈するのが規格が簡単であるそれらの特性を、定義します。 さらに、それは過去に非共同利用できる解釈をもたらして、不明瞭な仕様に通じたと信じられている用法を選び抜きます。 これらのガイドラインはRFC2223、「RFC作者への指示」と共に使用されることです。
Table of Contents
目次
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2 General Guidelines . . . . . . . . . . . . . . . . . . . . . 2 2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . 3 2.2 Protocol Description . . . . . . . . . . . . . . . . . . . 4 2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . 5 2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . 6 2.7 Decision History . . . . . . . . . . . . . . . . . . . . . 6 2.8 Response to Out of Specification Behavior . . . . . . . . . 6 2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . 7 2.10 Handling of Protocol Options . . . . . . . . . . . . . . . 8 2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . 9 2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . 9 2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . 10 2.14 Network Management Considerations . . . . . . . . . . . . 10 2.15 Scalability Considerations . . . . . . . . . . . . . . . . 10 2.16 Network Stability . . . . . . . . . . . . . . . . . . . . 11 2.17 Internationalization . . . . . . . . . . . . . . . . . . . 11
セキュリティ. . . . . . . . . . . . . . . . . . . 3 2.2プロトコル記述. . . . . . . . . . . . . . . . . . . 4 2.3対象者. . . . . . . . . . . . . . . . . . . . . . 5 2.4の.22.1議論が平らにする詳細.52.5のチェンジログ. . . . . . . . . . . . . . . . . . . . . . . . 6 2.6に関する1つの序論. . . . . . . . . . . . . . . . . . . . . . . 2 2の一般的ガイドラインはバージョンについて議定書の中で述べます…; .62.7 仕様の振舞い. . . . . . . . . 6 2.9からのプロトコルオプション. . . . . . . . . . . . . . . 8 2.11の要件レベル. . . . . . . . . . . . . . . 9 2.12 記号法のコンベンション. . . . . . . . . . . . . . . . . . . 9 2.13IANA問題. . . . . . . . . . . . . . . . . . . 10 2.14ネットワークマネージメントConsideratを示す寛容であるか保守的な規則. . . . . . . . . . . . . . . 7 2.10取り扱いへの決定歴史.62.8応答イオン. . . . . . . . . . . . 10 2.15Scalability Considerations. . . . . . . . . . . . . . . . 10 2.16Network Stability. . . . . . . . . . . . . . . . . . . . 11 2.17Internationalization. . . . . . . . . . . . . . . . . . . 11
Scott Best Current Practice [Page 1] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[1ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
2.18 Glossary . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Specific Guidelines . . . . . . . . . . . . . . . . . . . 12 3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . 12 3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . 13 3.3 State Machine Descriptions . . . . . . . . . . . . . . . . 13 4 Document Checklist . . . . . . . . . . . . . . . . . . . . 15 5 Security Considerations . . . . . . . . . . . . . . . . . 16 6 References . . . . . . . . . . . . . . . . . . . . . . . . 16 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18 8 Editor's Address . . . . . . . . . . . . . . . . . . . . . 18 9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . 19 10 Full Copyright Statement . . . . . . . . . . . . . . . . . 20
概要テーブル. . . . . . . . . . . . . . . . . . . . . 13 3.3が述べる2.18用語集. . . . . . . . . . . . . . . . . . . . . . . . 11 3特別な基準. . . . . . . . . . . . . . . . . . . 12 3.1パケットダイヤグラム. . . . . . . . . . . . . . . . . . . . . 12 3.2は記述. . . . . . . . . . . . . . . . 13 4ドキュメントチェックリストを機械加工します…; 15 5つのセキュリティ問題. . . . . . . . . . . . . . . . . 16 6参照. . . . . . . . . . . . . . . . . . . . . . . . 16 7承認. . . . . . . . . . . . . . . . . . . . . 18 8エディタのアドレス. . . . . . . . . . . . . . . . . . . . . 18 9付録. . . . . . . . . . . . . . . . . . . . . . . . . 19 10の完全な著作権宣言文. . . . . . . . . . . . . . . . . 20
1 Introduction
1つの序論
This document is a guide for Internet standard writers. It offers guidelines on how to write a standards-track document with clarity, precision, and completeness. These guidelines are based on both prior successful and unsuccessful IETF specification experiences. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors", or its update. Note that some guidelines may not apply in certain situations.
このドキュメントはインターネット標準作家のためのガイドです。 それは明快、精度、および完全性でどう標準化過程文書を書くかに関するガイドラインを提供します。 これらのガイドラインは両方の先のうまくいっていて失敗のIETF仕様経験に基づいています。 これらのガイドラインはRFC2223、「RFC作者への指示」、またはそのアップデートと共に使用されることです。 いくつかのガイドラインが、ある状況で適用されないかもしれないことに注意してください。
The goal is to increase the possibility that multiple implementations of a protocol will interoperate. Writing specifications to these guidelines will not guarantee interoperability. However, a recognized barrier to the creation of interoperable protocol implementations is unclear specifications.
目標はプロトコルの複数の実現が共同利用する可能性を増加させることです。 これらのガイドラインに仕様を書くのは相互運用性を保証しないでしょう。 しかしながら、共同利用できるプロトコル実現の創造への認識されたバリアは不明瞭な仕様です。
Many will benefit from having well-written protocol specifications. Implementers will have a better chance to conform to the protocol specification. Protocol testers can use the specification to derive unambiguous testable statements. Purchasers and users of the protocol will have a better understanding of its capabilities.
多くが上手に書いているプロトコル仕様の利益を得るでしょう。 Implementersには、プロトコル仕様に従うより良い見込みがあるでしょう。 プロトコルテスターは、明白な試験できる声明を引き出すのに仕様を使用できます。 プロトコルの購入者とユーザには、能力の、より良い理解があるでしょう。
For further information on the process for standardizing protocols and procedures please refer to BCP 9/RFC 2026, "The Internet Standards Process -- Revision 3". In addition, some considerations for protocol design are given in RFC 1958, "Architectural Principles of the Internet".
プロトコルと手順を標準化するための過程に関する詳細について、BCPを参照してください。9/RFC2026、「インターネット規格は処理されます--改正3インチ。」 さらに、RFC1958、「インターネットの建築プリンシプルズ」でプロトコルデザインのためのいくつかの問題を与えます。
2 General Guidelines
2 一般ガイドライン
It is important that multiple readers and implementers of a standard have the same understanding of a document. To this end, information should be orderly and detailed. The following are general guidelines intended to help in the production of such a document. The IESG may require that all or some of the following sections appear in a
規格の複数の読者とimplementersにはドキュメントの同じ理解があるのは、重要です。 このために、情報は、規則的であって、詳細であるべきです。 ↓これはそのようなドキュメントの生産で助けることを意図する一般的ガイドラインです。 IESGは、すべてか以下の数人のセクションがaに現れるのを必要とするかもしれません。
Scott Best Current Practice [Page 2] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[2ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
standards track document.
規格はドキュメントを追跡します。
2.1 Discussion of Security
2.1 セキュリティの議論
If the Internet is to achieve its full potential in commercial, governmental, and personal affairs, it must assure users that their information transfers are free from tampering or compromise. Well- written security sections in standards-track documents can help promote the confidence level required. Above all, new protocols and practices must not worsen overall Internet security.
インターネットが商業的、そして、政府的、そして、個人的な事で最大限の可能性を達成することであるなら、それは、彼らの情報転送にはいじるか妥協がないことをユーザに知らせなければなりません。 標準化過程文書の上手に書かれたセキュリティ部は、レベルが必要とした信用を促進するのを助けることができます。 何よりも、新しいプロトコルと習慣は総合的なインターネットセキュリティを悪化させてはいけません。
A significant threat to the Internet comes from those individuals who are motivated and capable of exploiting circumstances, events, or vulnerabilities of the system to cause harm. In addition, deliberate or inadvertent user behavior may expose the system to attack or exploitation. The harm could range from disrupting or denying network service, to damaging user systems. Additionally, information disclosure could provide the means to attack another system, or reveal patterns of behavior that could be used to harm an individual, organization, or network. This is a particular concern with standards that define a portion of the Management Information Base (MIB).
インターネットへの多大なる脅威は動機づけられて害を引き起こすのにシステムの事情、出来事、または脆弱性を利用できるそれらの個人から来ます。 さらに、慎重であるか不注意なユーザの振舞いは攻撃か開発にシステムを露出するかもしれません。 害はネットワーク・サービスを中断するか、または否定するので、及ぶかもしれません、ユーザシステムを破損するのに。情報公開は、個人、組織、またはネットワークに危害を加えるためにさらに、別のシステムを攻撃する手段を提供するか、または使用できた振舞いのパターンを明らかにするかもしれません。 Management Information基地(MIB)の一部を定義する規格に従って、これは特別の関心です。
Standards authors must accept that the protocol they specify will be subject to attack. They are responsible for determining what attacks are possible, and for detailing the nature of the attacks in the document. Otherwise, they must convincingly argue that attack is not realistic in a specific environment, and restrict the use of the protocol to that environment.
規格作者は、彼らが指定するプロトコルが攻撃するためになることがあると受け入れなければなりません。 彼らはどんな攻撃が可能であるかを決定して、ドキュメントにおける攻撃の本質を詳しく述べるのに原因となります。 さもなければ、彼らは、攻撃が特定の環境で現実的でないともっともらしく主張して、プロトコルの使用をその環境に制限しなければなりません。
After the document has exhaustively identified the security risks the protocol is exposed to, the authors must formulate and detail a defense against those attacks. They must discuss the applicable countermeasures employed, or the risk the user is accepting by using the protocol. The countermeasures may be provided by a protocol mechanism or by reliance on external mechanisms. Authors should be knowledgeable of existing security mechanisms, and reuse them if practical. When a cryptographic algorithm is used, the protocol should be written to permit its substitution with another algorithm in the future. Finally, the authors should discuss implementation hints or guidelines, e.g., how to deal with untrustworthy data or peer systems.
ドキュメントがプロトコルが露出されるセキュリティ危険を徹底的に特定した後に、作者は、それらの攻撃に対してディフェンスを定式化して、詳しく述べなければなりません。 彼らはユーザがプロトコルを使用することによって受け入れている使われた、適切な対策、または危険について議論しなければなりません。 実用的であるなら、対策は、プロトコルメカニズムか外部のメカニズムへの信用で. 作者が既存のセキュリティー対策で博識であるべきであるかどうかということであり、それらを再利用するかもしれません。 暗号アルゴリズムが使用されているとき、プロトコルは、将来別のアルゴリズムで代替を可能にするために書かれるべきです。 最終的に、作者は実現ヒントかガイドライン、例えば、どう信頼できないデータか同輩システムに対処するかについて議論するべきです。
Security measures will have an impact within the environment that they are used. Perhaps users will now be constrained on what they can do in the Internet, or will experience degradation in the speed of service. The effects the security measures have on the protocol's use and performance should be discussed.
それらが環境の中の衝撃ですが、使用されて、測定にはあるセキュリティ。 恐らく、ユーザは、現在彼らがインターネットでできることが抑制されるか、またはサービスの速度で退行を経験するでしょう。 安全策がプロトコルの使用と性能のときに持っている効果は検討されるべきです。
Scott Best Current Practice [Page 3] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[3ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
The discussion of security can be concentrated in the Security Considerations section of the document, or throughout the document where it is relevant to particular parts of the specification. An advantage of the second approach is that it ensures security is an integral part of the protocol's development, rather than something that is a follow-on or secondary effort. If security is discussed throughout the document, the Security Considerations section must summarize and refer to the appropriate specification sections. This will insure that the protocol's security measures are emphasized to implementer and user both.
ドキュメントのSecurity Considerations部、または、それが仕様の特定の部分に関連しているドキュメント中にセキュリティの議論を集結できます。 2番目のアプローチの利点はセキュリティがフォローオンか二次努力である何かよりむしろプロトコルの開発の不可欠の部分であることを確実にするということです。 ドキュメント中でセキュリティについて議論するなら、Security Considerations部は、適切な仕様部をまとめて、言及しなければなりません。 これは、プロトコルの安全策がimplementerとユーザの両方に強調されるのを保障するでしょう。
Within the Security Considerations section, a discussion of the path not taken may be appropriate. There may be several security mechanisms that were not selected for a variety of reasons: cost or difficulty of implementation, or ineffectiveness for a given network environment. By listing the mechanisms they did not use and the reasons, editors can demonstrate that the protocol's WG gave security the necessary thought. In addition, this gives the protocol's users the information they need to consider whether one of the non-selected mechanisms would be better suited to their particular requirements.
Security Considerations部の中では、取られなかった経路の議論は適切であるかもしれません。 さまざまな理由で選択されなかった数個のセキュリティー対策があるかもしれません: 費用か実現の困難、または与えられたネットワーク環境のための無効果。 それらが使用しなかったメカニズムと理由をリストアップすることによって、エディタは、プロトコルのWGが必要な考えをセキュリティに与えたのを示すことができます。 さらに、これは彼らが非選択されたメカニズムの1つがそれらの特定の要件に合うほうがよいかどうか考えるために必要とする情報をプロトコルのユーザに教えます。
A document giving further guidance on security topics is in development. Authors should obtain a copy of the completed RFC to help them prepare the security portion of the standard.
セキュリティ話題に関してさらなる指導を与えるドキュメントは開発中です。 作者は、彼らが規格のセキュリティ部分を準備するのを助けるために完成したRFCのコピーを入手するべきです。
Finally, it is no longer acceptable that Security Considerations sections consist solely of statements to the effect that security was not considered in preparing the standard.
最終的に、Security Considerations部が唯一セキュリティが規格を準備する際に考えられなかったという効果への声明から成るのは、もう許容できません。
Some examples of Security Considerations sections are found in STD 33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939. RFC 2316, "Report of the IAB Security Architecture Workshop", provides additional information in this topic area.
Security Considerations部に関するいくつかの例がSTD33/RFC1350、STD51/RFC1662、およびSTD53/RFC1939で見つけられます。 「IABセキュリティー体系ワークショップのレポート」というRFC2316はこの話題領域に追加情報を提供します。
2.2 Protocol Description
2.2 プロトコル記述
Standards track documents must include a description of the protocol. This description must address the protocol's purpose, intended functions, services it provides, and, the arena, circumstances, or any special considerations of the protocol's use.
標準化過程ドキュメントはプロトコルの記述を含まなければなりません。 そして、この記述は、プロトコルの目的を記述しなければならなくて、機能、それが提供するサービスを意図しました。アリーナ、事情、またはプロトコルの使用のどんな特別な問題。
The authors of a protocol specification will have a great deal of knowledge as to the reason for the protocol. However, the reader is more likely to have general networking knowledge and experience, rather than expertise in a particular protocol. An explanation of it's purpose and use will give the reader a reference point for
プロトコル仕様の作者には、プロトコルの理由に関して多くの知識があるでしょう。 しかしながら、読者は特定のプロトコルの一般的なネットワーク知識と専門的技術よりむしろ経験をさらに持っていそうです。 目的と使用が基準点を読者に与えるそれのものに関する説明
Scott Best Current Practice [Page 4] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[4ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
understanding the protocol, and where it fits in the Internet. The STD 54/RFC 2328 was recommended to the STDGUIDE working group as providing a good example of this in its "Protocol Overview" section.
プロトコルとそれがどこにインターネットをうまくはめ込むかを理解しています。 STD54/RFC2328は「プロトコル概観」セクションのこの好例を提供するとしてSTDGUIDEワーキンググループに推薦されました。
The protocol's general description must also provide information on the relationship between the different parties to the protocol. This can be done by showing typical packet sequences.
また、プロトコルの概説は異なったパーティーの間の関係の情報をプロトコルに提供しなければなりません。 典型的なパケット系列を示していることによって、これができます。
This also applies to the algorithms used by a protocol. A detailed description of the algorithms or citation of readily available references that give such a description is necessary.
また、これはプロトコルによって使用されるアルゴリズムに適用されます。 そのような記述を与える容易に利用可能な参照のアルゴリズムか引用の詳述が必要です。
2.3 Target Audience
2.3 目標聴衆
RFCs have been written with many different purposes, ranging from the technical to the administrative. Those written as standards should clearly identify the intended audience, for example, designers, implementers, testers, help desk personnel, educators, end users, or others. If there are multiple audiences being addressed in the document, the section for each audience needs to be identified. The goal is to help the reader discover and focus on what they have turned to the document for, and avoid what they may find confusing, diverting, or extraneous.
技術的から管理まで及んで、RFCsは多くの異なる役割で書かれています。 規格として書かれたものは明確に例えば対象とする訪問者、デザイナー、implementers、テスター、ヘルプデスク人員、教育者、エンドユーザ、または他のものを特定するはずです。 ドキュメントで宛てられる複数の聴衆がいれば、各聴衆のためのセクションは、特定される必要があります。 目標は、読者が彼らがドキュメントにターンしたことに発見して、焦点を合わせるのを助けて、彼らが紛らわしいか、楽しいか、または異質であることがわかるかもしれないものを避けることです。
2.4 Level of Detail
2.4 詳細のレベル
The author should consider what level of descriptive detail best conveys the protocol's intent. Concise text has several advantages. It makes the document easier to read. Such text reduces the chance for conflict between different portions of the specification. The reader can readily identify the required protocol mechanisms in the standard. In addition, it makes it easier to identify the requirements for protocol implementation. A disadvantage of concise descriptions is that a reader may not fully comprehend the reasoning behind the protocol, and thus make assumptions that will lead to implementation errors.
作者は、どんなレベルの描写的である詳細がプロトコルの意図を最もよく伝えるかを考えるべきです。 簡潔なテキストには、いくつかの利点があります。 それは、ドキュメントを読むのをより簡単にします。 そのようなテキストは闘争のために仕様の異なった部分の間で可能性を小さくします。 読者は規格で容易に必要なプロトコルメカニズムを特定できます。 さらに、それで、プロトコル実現のための要件を特定するのは、より簡単になります。 簡潔な説明の不都合は読者がプロトコルの後ろで推理を完全に理解して、その結果、実現誤りにつながる仮定をしないかもしれないということです。
Longer descriptions may be necessary to explain purpose, background, rationale, implementation experience, or to provide tutorial information. This helps the reader understand the protocol. Yet, several dangers exist with lengthy text. Finding the protocol requirements in the text is difficult or confusing. The same mechanism may have multiple descriptions, which leads to misinterpretation or conflict. Finally, it is more difficult to comprehend, a consideration as English is not the native language of the many worldwide readers of IETF standards.
より長い記述が、目的、バックグラウンド、原理、実現経験について説明するか、または家庭教師の情報を提供するのに必要であるかもしれません。 これは、読者がプロトコルを理解しているのを助けます。 しかし、いくつかの危険が長いテキストで存在しています。 テキストのプロトコル要件を見つけるのは、難しいか、または紛らわしいです。 同じメカニズムには、複数の記述、どれが誤解に通じるか、そして、または闘争があるかもしれません。 最終的に、理解するのが、より難しい、英語としての考慮はIETF規格の多くの世界的な読者の母国語ではありません。
Scott Best Current Practice [Page 5] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[5ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
One approach is to divide the standard into sections: one describing the protocol concisely, while another section consists of explanatory text. The STD 3/RFC 1122/RFC 1123 and STD 54/RFC 2328 provides examples of this method.
1つのアプローチは規格をセクションに分割することです: 1つがプロトコルについて簡潔に説明して、セクションは別のものである間、説明しているテキストから成ります。 54/RFC2328がこの方法に関する例を供給するSTD3/RFC1122/RFC1123とSTD。
2.5 Change Logs
2.5 変化ログ
As a document moves along the standards track, from Proposed to Draft or Draft to Full, or cycles in level, it will undergo changes due to better understanding of the protocol or implementation experience. To help implementers track the changes being made a log showing what has changed from the previous version of the specification is required (see Appendix).
ProposedからDraftまでDraftからドキュメントが標準化過程に沿って動くか、Fullか、レベルのサイクルまで、それはプロトコルか実現経験の、より良い理解のため移り変わるでしょう。 implementersが行われる変更を追うのを助けるために、仕様の旧バージョンから変化したものを示しているログが必要です(Appendixを見てください)。
2.6 Protocol Versions
2.6 プロトコルバージョン
Often the standard is specifying a new version of an existing protocol. In such a case, the authors should detail the differences between the previous version and the new version. This should include the rationale for the changes, for example, implementation experience, changes in technology, responding to user demand, etc.
しばしば、規格は既存のプロトコルの新しいバージョンを指定しています。 このような場合には、作者は前のバージョンと新しいバージョンの違いを詳しく述べるべきです。 これは変化、例えば、実現経験、技術における変化、ユーザ要求に応じるのなどための原理を含むべきです。
2.7 Decision History
2.7 決定歴史
In standards development, reaching consensus requires making difficult choices. These choices are made through working group discussions or from implementation experience. By including the basis for a contentious decision, the author can prevent future revisiting of these disagreements when the original parties have moved on. In addition, the knowledge of the "why" is as useful to an implementer as the description of "how". For example, the alternative not taken may have been simpler to implement, so including the reasons behind the choice may prevent future implementers from taking nonstandard shortcuts.
規格開発では、全員の意見が一致しているのは、難しい選択をするのを必要とします。 ワーキンググループ議論か実装経験からこれらの選択をします。 オリジナルのパーティーが移動したとき、議論好きな決定の基礎を含んでいることによって、作者はこれらの不一致の今後の再訪を防ぐことができます。 さらに、「なぜ」に関する知識はimplementerに「どのように」に関する記述と同じくらい役に立つか。 例えば、取られなかった代替手段は実装するのが、より簡単であったかもしれないので、選択の後ろに理由を含んでいるのは、将来のimplementersが標準的でない近道を取るのを防ぐかもしれません。
2.8 Response to Out of Specification Behavior
2.8 仕様の振舞いへの応答
A detail description of the actions taken in case of behavior that is deviant from or exceeds the specification is useful. This is an area where implementers often differ in opinion as to the appropriate response. By specifying a common response, the standard author can reduce the risk that different implementations will come in to conflict.
動作の記述がそれが異常である振舞いの場合に取るか、または仕様を超えているという詳細は役に立ちます。 これはimplementersが適切な応答に関して意見においてしばしば異なる領域です。 一般的な応答を指定することによって、標準の作者は異なった実装が闘争するために入る危険を減少させることができます。
The standard should describe responses to behavior explicitly forbidden or out of the boundaries defined by the specification. Two possible approaches to such cases are discarding, or invoking error- handling mechanisms. If discarding is chosen, detailing the
規格は明らかに禁じられた振舞い、または、仕様で定義された境界の外へから応答について説明するべきです。 2つの可能であるかそのようなケースへのアプローチが捨てられているのを呼び出し誤り取り扱いメカニズム捨てることが選ばれているなら細部
Scott Best Current Practice [Page 6] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[6ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
disposition may be necessary. For instance, treat dropped frames as if they were never received, or reset an existing connection or adjacency state.
気質が必要であるかもしれません。 例えば、まるでそれらを決して受け取らないかのように下げられたフレームを扱うか、または既存の接続か隣接番組状態をリセットしてください。
The specification should describe actions taken when a critical resource or a performance-scaling limit is exceeded. This is necessary for cases where a risk of network degradation or operational failure exists. In such cases, a consistent behavior between implementations is necessary.
仕様は重要な資源か性能をスケーリングする限界が超えられているとき取られた行動について説明するべきです。 これがネットワーク退行か操作上の失敗のリスクが存在するケースに必要です。 そのような場合、実装の間の一貫した振舞いが必要です。
2.9 The Liberal/Conservative Rule
2.9 寛容であるか保守的な規則
A rule, first stated in STD 5/RFC 791, recognized as having benefits in implementation robustness and interoperability is:
実装丈夫さと相互運用性における利益を持っていると認識された最初にSTD5/RFC791に述べられた規則は以下の通りです。
"Be liberal in what you accept, and
conservative in what you send".
「あなたが受け入れるもので寛容であって、あなたが送るもので保守的であってください。」
Or establish restrictions on what a protocol transmits, but be able to deal with every conceivable error received. Caution is urged in applying this approach in standards track protocols. It has in the past lead to conflicts between vendors when interoperability fails. The sender accuses the receiver of failing to be liberal enough, and the receiver accuses the sender of not being conservative enough. Therefore, the author is obligated to provide extensive detail on send and receive behavior.
または、プロトコルが伝えるものに関する制限を確立しなさい、ただし、受けられた想像できるあらゆる誤りに対処できてください。 警告は標準化過程プロトコルにおけるこのアプローチを適用する際に促されます。 相互運用性が失敗するとき、それはベンダーの間の闘争への過去のリードでそうしました。 送付者は十分寛容でないので、受信機を起訴します、そして、送付者が十分保守的でないので、受信機は起訴します。 したがって、作者が大規模な詳細を明らかにするのが義務付けられる、振舞いを送って、受けてください。
To avoid any confusion between the two, recommend that standard authors specify send and receive behavior separately. The description of reception will require the most detailing. For implementations are expected to continue operating regardless of error received. Therefore, the actions taken to achieve that result, need to be laid out in the protocol specification. Standard authors should concern themselves on achieving a level of cooperation that limits network disruption, not just how to survive on the network. The appearance of undefined information or conditions must not cause a network or host failure. This requires specification on how to attempt acceptance of most of the packets. Two approaches are available, either using as much of the packet's content as possible, or invoking error procedures. The author should specify a dividing line on when to take which approach.
2つの間のどんな混乱も避けるには、作者が指定する規格が別々に振舞いを送って、受けることを勧めてください。 レセプションの記述は、最も詳しく述べるのを必要とするでしょう。 実装が、受けられた誤りにかかわらず作動し続けていると予想されて。 したがって、その結果、プロトコル仕様で広げられるべき必要性を達成するために取られた行動。 いったいネットワークでどう生き残らないかというネットワーク分裂を制限する協力のレベルを達成するとき、一流作家はタッチするべきです。 未定義の情報か状態の外観はネットワークかホスト障害を引き起こしてはいけません。 これはどうパケットの大部分の承認を試みるかに関する仕様を必要とします。 パケットのできるだけ多くの内容を使用するか、または誤り処理手続きを呼び出して、2つのアプローチが利用可能です。 作者はいつどのアプローチを取ったらよいかの分け目を指定するべきです。
A case for consideration is that of a routing protocol, where acceptance of flawed information can cause network failure. For protocols such as this, the specification should identify packets that could have different interpretations and mandate that they be rejected completely or the nature of the attempt to recover some information from them. For example, routing updates that contain
考慮のためのケースは失敗する情報の承認がネットワーク失敗を引き起こす場合があるところのルーティング・プロトコルのものです。 これなどのプロトコルのために、仕様は異なった解釈を持って、それらが完全に拒絶されるのを強制できたパケットか何らかの情報をそれらから取り戻す試みの本質を特定するべきです。 例えばそれが含むルーティングアップデート
Scott Best Current Practice [Page 7] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[7ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
more data than the tuple count shows. The protocol authors should consider whether some trailing data can be accepted as additional routes, or to reject the entire packet as suspect because it is non- conformant.
tupleより多くのデータがショーを数えます。 プロトコル作者は、それが非conformantであるので全体のパケットが疑わしいと追加ルートとしていくつかの引きずっているデータを認めることができるか、廃棄物と考えるべきです。
2.10 Handling of Protocol Options
2.10 プロトコルオプションの取り扱い
Specifications with many optional features increase the complexity of the implementation and the chance of non-interoperable implementations. The danger is that different implementations may specify some combination of options that are unable to interoperate with each other.
多くのオプション機能がある仕様は実装の複雑さと非共同利用できる実装の可能性を増強します。 危険は異なった実装が互いと共に共同利用できないオプションの何らかの組み合わせを指定するかもしれないということです。
As the document moves along the standard track, implementation experience shall determine the need for each option. Implementation shall show whether the option should be a mandatory part of the protocol or remain an option. If an option is not implemented as the document advances, it must be removed from the protocol before it reaches draft standard status.
ドキュメントが標準の道に沿って移行するとき、実装経験はそれぞれのオプションの必要性を決定するものとします。 実装は、オプションがプロトコルの義務的な部分であるべきであるか否かに関係なく、目立つものとするか、またはオプションのままで残っているものとします。 ドキュメントが進むときオプションを実装しないなら、ドラフトの標準の状態に達する前にプロトコルからそれを取り除かなければなりません。
Therefore, options shall only be present in a protocol to address a real requirement. For example, options can support future extensibility of the protocol, a particular market, e.g., the financial industry, or a specific network environment, e.g., a network constrained by limited bandwidth. They shall not be included as a means to "buy-off" a minority opinion. Omission of the optional item shall have no interoperability consequences for the implementation that does so.
したがって、オプションは本当の要件を扱うプロトコルだけで存在するでしょう。 例えば、オプションはプロトコル、特定の市場、例えば、金融業界の将来の伸展性、または特定のネットワーク環境(例えば限られた帯域幅によって抑制されたネットワーク)をサポートすることができます。 aが「下に、買うこと」に少数意見を意味するとき、それらを含んでいないものとします。 任意の項目の省略には、そうする実装のための相互運用性結果が全くないものとします。
One possible approach is to document protocol options in a separate specification. This keeps the main protocol specification clean and makes it clear that the options are not required to implement the protocol. Regardless of whether they appear within the specification or in a separate document, the text shall discuss the full implications of either using the option or not, and the case for choosing either course. As part of this, the author needs to consider and describe how the options are used alongside other protocols. The text must also specify the default conditions of all options. For security checking options the default condition is on or enabled.
ドキュメントプロトコルオプションには1つの可能なアプローチが別々の仕様にあります。 これは、主なプロトコル仕様を清潔に守って、オプションはプロトコルを実装するのに必要でないと断言します。 彼らが仕様以内か別々のドキュメントに現れるかどうかにかかわらず、テキストはオプションを使用する完全な含意、およびどちらのコースも選ぶためのケースについて議論するものとします。 この一部として、作者は、オプションが他のプロトコルと並んでどう使用されるかを考えて、説明する必要があります。 また、テキストはすべてのオプションのデフォルト条件を指定しなければなりません。 セキュリティー検査オプションにおいて、デフォルト条件は、オンであるか可能にされます。
There are occasions when mutually exclusive options appear within the protocol. That is, the implementation of an optional feature precludes the implementation of the other optional feature. For clarity, the author needs to state when to implement one or the other, what the effect of choosing one over the other is, and what
互いに排他的なオプションがプロトコルの中に現れる時があります。 すなわち、オプション機能の実装はもう片方のオプション機能の実装を排除します。 そして、明快に、作者が、1かもう片方に関して1つを選ぶという効果が他、ものであるといつ実装するかを述べる必要がある、何
Scott Best Current Practice [Page 8] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[8ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
problems the implementer or user may face. The choice of one or the other options shall have no interoperability consequences between multiple implementations.
implementerかユーザが直面するかもしれない問題。 1つの選択か別の選択肢には、複数の実装の間の相互運用性結果が全くないものとします。
2.11 Indicating Requirement Levels
2.11 要件レベルを示すこと。
The BCP 14/RFC 2119, "Key words for use in RFCs to Indicate Requirement Level", defines several words that are necessary for writing a standards track document. Editors of standards track documents must not deviate from the definitions provided as they are intended to identify interoperability requirements or limit potentially harmful behavior. The capitalization of these words is the accepted norm, and can help in identifying an unintentional or unreasonable requirement. These words have been used in several RFCs the first instances being STD 3/RFC 1122/RFC 1123.
「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」というBCP14/RFC2119は標準化過程ドキュメントを書くのに必要ないくつかの単語を定義します。 標準化過程ドキュメントのエディターズは彼らが相互運用性要件を特定するか、または潜在的に有害な振舞いを制限することを意図するので提供された定義から逸れてはいけません。 これらの単語の資源化は、受け入れられた標準であり、意図的でないか無理な要件を特定するのを手伝うことができます。 これらの単語は数個のRFCs最初のインスタンス存在STD3/RFC1122/RFCで1123に使用されました。
2.12 Notational Conventions
2.12 記号法のコンベンション
Formal syntax notations can be used to define complicated protocol concepts or data types, and to specify values of these data types. This permits the protocol to be written without concern on how the implementation is constructed, or how the data type is represented during transfer. The specification is simplified because it can be presented as "axioms" that will be proven by implementation.
複雑なプロトコル概念かデータ型を定義して、これらのデータ型の値を指定するのに正式な構文記法を使用できます。 これは、実装がどのように構成されるか、そして、またはデータ型が転送の間どのように表されるかに関してプロトコルが関心なしで書かれていることを許可します。 仕様は、実装によって立証される「原理」としてそれを提示できるので、簡易型です。
The formal specification of the syntax used should be referenced in the text of the standard. Any extensions, subsets, alterations, or exceptions to that formal syntax should be defined within the standard.
使用される構文に関する形式仕様は規格のテキストで参照をつけられるべきです。 どんな拡大でありも、部分集合、変更、またはその正式な構文への例外が規格の中で定義されるべきです。
The STD 11/RFC 822 provides an example of this. In RFC 822 (Section 2 and Appendix D) the Backus-Naur Form (BNF) meta-language was extended to make its representation smaller and easier to understand. Another example is STD 16/RFC 1155 (Section 3.2) where a subset of the Abstract Syntax Notation One (ASN.1) is defined.
STD11/RFC822はこの例を提供します。 RFC822(セクション2とAppendix D)では、BN記法(BNF)メタ言語は、表現を理解しているのをより小さくより簡単にするように広げられました。 別の例は抽象的なSyntax Notation One(ASN.1)の部分集合が定義されるSTD16/RFC1155です(セクション3.2)。
The author of a standards track protocol needs to consider several things before they use a formal syntax notation. Is the formal specification language being used parseable by an existing machine? If no parser exists, is there enough information provided in the specification to permit the building of a parser? If not, it is likely the reader will not have enough information to decide what the notation means. In addition, the author should remember machine parseable syntax is often unreadable by humans, and can make the specification excessive in length. Therefore, syntax notations cannot take the place of a clearly written protocol description.
標準化過程プロトコルの作者は、正式な構文記法を使用する前に数個のものを考える必要があります。 使用される形式仕様言語は既存のマシンによる分析可能ですか? パーサが全く存在していないなら、パーサのビルを可能にするために仕様に提供された情報が十分ありますか? そうでなければ、読者には記法が意味することについて決めることができるくらいの情報がないのは、ありそうです。 さらに、作者は、マシン分析可能構文で人間がしばしば読みにくく、仕様が長さで過度になる場合があるのを覚えているべきです。 したがって、構文記法は明確に書かれたプロトコル記述の代理をすることができません。
Scott Best Current Practice [Page 9] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[9ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
2.13 IANA Considerations
2.13 IANA問題
The common use of the Internet standard track protocols by the Internet community requires that unique values be assigned to parameter fields. An IETF WG does not have the authority to assign these values for the protocol it developed. The Internet Assigned Numbers Authority (IANA) is the central authority for the assignment of unique parameter values for Internet protocols. The authors of a developing protocol need to coordinate with the IANA the rules and procedures to manage the number space. This coordination needs to be completed prior to submitting the Internet Draft to the standards track.
インターネットコミュニティによるインターネット標準道のプロトコルの一般の使用は、ユニークな値がパラメタ分野に割り当てられるのを必要とします。 IETF WGには、それが開発したプロトコルのためにこれらの値を割り当てる権威がありません。 インターネットAssigned民数記Authority(IANA)はインターネットプロトコルのためのユニークなパラメタ値の課題のための主要な権威です。 展開しているプロトコルの作者は、数のスペースを管理するためにIANAと共に規則と手順を調整する必要があります。 このコーディネートは、インターネットDraftを標準化過程に提出する前に完成される必要があります。
A document is in preparation that discusses issues related to identifier assignment policy and guidelines on specific text to task IANA with its administration. Standard authors should obtain a copy of it when it is finalized as an RFC.
ドキュメントは準備では、それが管理と共にIANAに仕事を課すために特定のテキストに関する識別子課題方針に関連する問題とガイドラインについて議論するということです。 それがRFCとして成立させられるとき、一流作家はそれのコピーを入手するべきです。
For further information on parameter assignment and current assignments, authors can reference STD 2, RFC 1700, "Assigned Numbers" (http://www.iana.org).
パラメタ課題と現在の課題の詳細に関しては、作者はSTD2(RFC1700)が「数を割り当てた」という参照( http://www.iana.org )をそうすることができます。
2.14 Network Management Considerations
2.14 ネットワークマネージメント問題
When relevant, each standard needs to discuss how to manage the protocol being specified. This management process should be compatible with the current IETF Standard management protocol. In addition, a MIB must be defined within the standard or in a companion document. The MIB must be compatible with current Structure of Management Information (SMI) and parseable using a tool such as SMICng. Where management or a MIB is not necessary this section of the standard should explain the reason it is not relevant to the protocol.
関連しているとき、各規格は、指定されていて、プロトコルを管理する方法について議論する必要があります。 この管理過程は現在のIETF Standard管理プロトコルと互換性があるべきです。 さらに、規格以内か仲間ドキュメントでMIBを定義しなければなりません。 MIBは、SMICngなどのツールを使用することでManagement情報(SMI)の現在のStructureと互換性があって、分析可能しなければなりません。 管理かMIBは必要でないところでは、規格のこのセクションがそれがプロトコルに関連していない理由について説明するべきです。
2.15 Scalability Considerations
2.15 スケーラビリティ問題
The standard should establish the limitations on the scale of use, e.g., tens of millions of sessions, gigabits per second, etc., and establish limits on the resources used, e.g., round trip time, computing resources, etc. This is important because it establishes the ability of the network to accommodate the number of users and the complexity of their relations. The STD 53/RFC 1939 has an example of such a section. If this is not applicable to the protocol, an explanation of why not should be included.
規格は、使用のスケール、例えば、何千万ものセッション、1秒あたりのギガビットなどで制限を確立して、運用資金で限界を確立するべきです、例えば、周遊旅行時間、リソースなどを計算して ネットワークがユーザの数と彼らの関係の複雑さを収容する能力を確立するので、これは重要です。 STD53/RFC1939には、そのようなセクションに関する例があります。 これがプロトコル、説明に適切でない、なぜ含まないべきですか?
Scott Best Current Practice [Page 10] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[10ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
2.16 Network Stability
2.16 ネットワークの安定性
A standard should discuss the relationship between network topology and convergence behavior. As part of this, any topology that would be troublesome for the protocol should be identified. Additionally, the specification should address any possible destabilizing events, and means by which the protocol resists or recovers from them. The purpose is to insure that the network will stabilize, in a timely fashion, after a change, and that a combination of errors or events will not plunge the network into chaos. The STD 34/RFC 1058, as an example, has sections which discuss how that protocol handles the affects of changing topology.
規格はネットワーク形態と集合の振舞いとの関係を定めるべきです。 この一部として、どんなプロトコルに、厄介なトポロジーも特定されるべきです。 さらに、仕様はどんな可能な動揺させているイベント、およびプロトコルがそれらから抵抗するか、または回復する手段も扱うべきです。 目的はネットワークが変化の後のタイムリーなファッションで安定して、誤りかイベントの組み合わせがネットワークをカオスに突入させないのを保障することです。 STD34/RFC1058には、例として、そのプロトコルがどうトポロジーを変える感情を扱うかを論ずるセクションがあります。
The obvious case this would apply to is a routing protocol. However, an application protocol could also have dynamic behavior that would affect the network. For example, a messaging protocol could suddenly dump a large number of messages onto the network. Therefore, editors of an application protocol will have to consider possible impacts to network stability and convergence behavior.
これが申し込む明白なケースはルーティング・プロトコルです。 しかしながら、アプリケーション・プロトコルには、また、ネットワークに影響する動的挙動があるかもしれません。 例えば、メッセージング・プロトコルは突然多くのメッセージをネットワークにどさっと落とすかもしれません。 したがって、アプリケーション・プロトコルのエディタは、可能な影響が安定性と集合の振舞いをネットワークでつなぐと考えなければならないでしょう。
2.17 Internationalization
2.17 国際化
At one time the Internet had a geographic boundary and was English only. The Internet now extends internationally. Therefore, data is interchanged in a variety of languages and character sets. In order to meet the requirements of an international Internet, a standard must conform to the policies stated in BCP 18/RFC 2277, "IETF Policy on Character Sets and Languages".
ひところ、インターネットは、地理的な境界を持って、英語専用でした。 インターネットは今、国際的に広がります。 したがって、データはさまざまな言語と文字集合で交換されます。 国際的なインターネットに関する必要条件を満たすために、規格はBCP18/RFC2277に述べられた方針、「文字コードと言語に関するIETF方針」に従わなければなりません。
2.18 Glossary
2.18 用語集
Every standards track RFC should have a glossary, as words can have many meanings. By defining any new words introduced, the author can avoid confusing or misleading the implementers. The definition should appear on the word's first appearance within the text of the protocol specification, and in a separate glossary section.
あらゆる標準化過程RFCには、単語が多くの意味を持つことができるように用語集があるはずです。 新しい単語が導入したいずれも定義することによって、作者は、implementersを混乱するか、またはミスリードするのを避けることができます。 定義はプロトコル仕様のテキスト以内と別々の用語集部に単語の初登場に載るべきです。
It is likely that definition of the protocol will rely on many words frequently used in IETF documents. All authors must be knowledgeable of the common accepted definitions of these frequently used words. FYI 18/RFC 1983, "Internet Users' Glossary", provides definitions that are specific to the Internet. Any deviation from these definitions by authors is strongly discouraged. If circumstances require deviation, an author should state that he is altering the commonly accepted definition, and provide rationale as to the necessity of doing so. The altered definition must be included in the Glossary section.
プロトコルの定義はIETFドキュメントで頻繁に使用される多くの単語を当てにしそうでしょう。 すべての作者がこれらの頻繁に使用された単語の一般的な受け入れられた定義で博識であるに違いありません。 「インターネットユーザの用語集」というFYI18/RFC1983はインターネットに特定の定義を提供します。 作者によるこれらの定義からのどんな逸脱も強くがっかりしています。 事情が逸脱を必要とするなら、作者は、彼が一般的に受け入れられた定義を変更していると述べて、そうするという必要性に関して原理を前提とするべきです。 Glossary部に変えられた定義を含まなければなりません。
Scott Best Current Practice [Page 11] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[11ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
If the author uses the word as commonly defined, she does not have to include the definition in the glossary. As a minimum, FYI 18/RFC 1983 should be referenced as a source.
作者が一般的に定義されているとして単語を使用するなら、彼女は用語集との定義を入れる必要はありません。 最小限として、FYI18/RFC1983はソースとして参照をつけられるべきです。
3 Specific Guidelines
3 特定のガイドライン
The following are guidelines on how to present specific technical information in standards.
↓これはどう規格における特定の技術資料を提示するかに関するガイドラインです。
3.1 Packet Diagrams
3.1 パケットダイヤグラム
Most link, network, and transport layer protocols have packet descriptions. Packet diagrams included in the standard are very helpful to the reader. The preferred form for packet diagrams is a sequence of long words in network byte order, with each word horizontal on the page and bit numbering at the top:
ほとんどのリンク、ネットワーク、およびトランスポート層プロトコルには、パケット記述があります。 読者にとって、規格に含まれていたパケットダイヤグラムは非常に役立っています。 パケットダイヤグラムのための好まれた形はネットワークバイトオーダーで、ロング・ワードの系列です、それぞれの単語水平面がページにあって、噛み付いている付番が先端にある状態で:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| Prio。 | 流れラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In cases where a packet is strongly byte-aligned rather than word- aligned (e.g., when byte-boundary variable-length fields are used), display packet diagrams in a byte-wide format. The author can use different height boxes for short and long words, and broken boxes for variable-length fields:
パケットがバイトによって強く並べられた(例えば、バイト境界の可変長の分野はいつ使用されていますか)単語よりむしろ並べられる場合では、幅バイトの形式でパケットダイヤグラムを表示してください。 作者は可変長の分野に略して異なった高さの箱、ロング・ワード、および壊れている箱を使用できます:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | 長さN| +-+-+-+-+-+-+-+-+ | | + アドレス+… + (Nバイト)+| | +-+-+-+-+-+-+-+-+ | | + 2バイトの分野+| | +-+-+-+-+-+-+-+-+
Scott Best Current Practice [Page 12] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[12ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
3.2 Summary Tables
3.2 概要テーブル
The specifications of some protocols are particularly lengthy, sometimes covering a hundred pages or more. In such cases, the inclusion of a summary table can reduce the risk of conformance failure by an implementation through oversight. A summary table itemizes what in a protocol is mandatory, optional, or prohibited. Summary tables do not guarantee conformance, but serve to assist an implementer in checking that they have addressed all protocol features.
時々100ページ以上覆っていて、いくつかのプロトコルの仕様は特に長いです。 そのような場合、概要テーブルの包含は見落としを通して実現で順応失敗の危険を減少させることができます。 概要テーブルは義務的であって、任意であるか、または禁止されたプロトコルでことを箇条書きします。 概要テーブルは順応を保証しませんが、すべてのプロトコル機能を記述したのをチェックするのにimplementerを助けるのに役立ってください。
The summary table will consist of, as a minimum, four (4) columns: Protocol Feature, Section Reference, Status, and References/Footnotes. The author may add columns if they further explain or clarify the protocol.
概要テーブルは最小限としての4(4)コラムから成るでしょう: 特徴、セクション参照、状態、および参照/脚注について議定書の中で述べてください。 さらにプロトコルを説明するか、またははっきりさせるなら、作者はコラムを加えるかもしれません。
In the Protocol Feature column, list the protocol's characteristics, for example, a command word. We recommend grouping series of related transactions under descriptive headers, for example, RECEPTION.
プロトコルFeatureコラムでは、プロトコルの特性、例えばコマンド言葉をリストアップしてください。 私たちは、例えば、描写的であるヘッダー、RECEPTIONの下で関連する取引のシリーズを分類することを勧めます。
Section reference directs the implementer to the section, paragraph, or page that describes the protocol feature in detail.
セクション参照はセクション、パラグラフ、またはページへの詳細にプロトコル機能について説明するimplementerを指示します。
Status indicates whether the feature is mandatory, optional, or prohibited. The author can use either a separate column for each possibility, or a single column with appropriate codes. These codes need to be defined at the start of the summary table to avoid confusion. Possible status codes:
状態は、特徴が義務的であるか、任意であるか、または禁止されているかを示します。 作者は各可能性のための別欄か適切なコードに従ったシングル・コラムのどちらかを使用できます。 これらのコードは、混乱を避けるために概要テーブルの始めで定義される必要があります。 可能なステータスコード:
M - must or mandatory
MN - must not
O - optional
S - should
SN - should not
X - prohibited
M--必須か義務的なミネソタ--O(任意のS)でないことがそうするべきである必須である、SN--、X--禁止するべきではありません。
In the References/Footnotes column authors can point to other RFCs that are necessary to consider in implementing this protocol feature, or any footnotes necessary to explain the implementation further.
References/脚注では、コラム作者は他のさらに実現について説明するのに必要なこのプロトコル機能、またはどんな脚注も実行する際に考えるのに必要なRFCsを示すことができます。
The STD 3/RFC 1122/RFC 1123 provides examples of summary tables.
STD3/RFC1122/RFC1123は概要テーブルに関する例を提供します。
3.3 State Machine Descriptions
3.3 州のマシン記述
A convenient method of presenting a protocol's behavior is as a state-machine model. That is, a protocol can be described by a series of states resulting from a command, operation, or transaction. State-machine models define the variables and constants that
州マシンモデルとしてプロトコルの振舞いを提示する便利な方法があります。 コマンド、操作、または取引から生じる一連の州がすなわち、プロトコルについて説明できます。 州マシンモデルが変数と定数を定義する、それ
Scott Best Current Practice [Page 13] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[13ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
establish a state, the events that cause state transitions and the actions that result from those transitions. Through these models, an understanding of the protocol's dynamic operation as sequence of state transitions that occur for any given event is possible. State transitions can be detailed by diagrams, tables, or time lines.
状態、状態遷移を引き起こす出来事、およびそれらの変遷から生じる動作を確立してください。 これらのモデルを通して、どんな与えられた出来事のためにも起こる状態遷移の系列としてのプロトコルのダイナミックな操作の理解は可能です。 ダイヤグラム、テーブル、またはタイムラインは状態遷移を詳しく述べることができます。
Note that state-machine models are never to take the place of detailed text description of the specification. They are adjuncts to the text. The protocol specification shall always take precedence in the case of a conflict.
州マシンモデルが仕様の詳細なテキスト記述の決して代理をすることになっていないことに注意してください。 それらはテキストへの付属物です。 プロトコル仕様は闘争の場合でいつも優先するものとします。
When using a state transition diagram, show each possible protocol state as a box connected by state transition arcs. The author should label each arc with the event that causes the transition, and, in parentheses, any actions taken during the transition. The STD 5/RFC 1112 provides an example of such a diagram. As ASCII text is the preferred storage format for RFCs, only simple diagrams are possible. Tables can summarize more complex or extensive state transitions.
状態遷移ダイヤグラムを使用するときには、箱が状態遷移アークで接続したので、それぞれの可能なプロトコル状態を見せてください。 作者はそして括弧(変遷の間に取られたどんな行動)で変遷を引き起こす出来事に伴う各アークをラベルするべきです。 STD5/RFC1112はそのようなダイヤグラムに関する例を提供します。 ASCIIテキストがRFCsに、都合のよい格納形式であるので、簡単なダイヤグラムだけが可能です。 テーブルは複雑であるか大規模な状態遷移をまとめることができます。
In a state transition table, the different events are listed
vertically and the different states are listed horizontally. The
form, action/new state, represents state transitions and actions.
Commas separate multiple actions, and succeeding lines are used as
required. The authors should present multiple actions in the order
they must be executed, if relevant. Letters that follow the state
indicate an explanatory footnote. The dash ('-') indicates an
illegal transition. The STD 51/RFC 1661 provides an example of such
a state transition table. The initial columns and rows of that table
follow as an example:
状態遷移テーブルでは、異なった出来事は垂直に記載されています、そして、異なった州は水平に記載されています。 フォーム(動作/新しい状態)は状態遷移と動作を表します。 コンマは複数の動作を切り離します、そして、続く線は必要に応じて使用されます。 作者は実行されていて、関連していた状態でそれらがオーダーでなければならないのにおける複数の動作を提示するべきです。 状態に続く手紙が脚注を示します。 ダッシュ('--')は不法な変遷を示します。 STD51/RFC1661はそのような状態遷移テーブルに関する例を提供します。 そのテーブルの初期のコラムと列は例として従います:
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
| 状態| 0 1 2 3 4 5回の出来事| 閉じられた初期の始めは、停止を閉じるのを止めました。------+----------------------------------------------------------- 上がる| 2irc、scr/6--、--、--、--下になってください| - - 0 tls/1 0 1オープン| tls/1 1irc、scr/6 3r 5r 5r Close| 0 tlf/0 2 2 4 4| +に| - - - - str/4str/5TO| - - - - tlf/2tlf/3
The STD 18/RFC 904 also presents state transitions in table format. However, it lists transitions in the form n/a, where n is the next state and a represents the action. The method in RFC 1661 is preferred as new state logically follows action. In addition, RFC 904's Appendix C models transitions as the Cartesian product of two state machines. This is a more complex representation that may be
また、STD18/RFC904はテーブル形式における状態遷移を提示します。 しかしながら、それはなし、nがどこの次の状態であるか、そして、aが表す書式に変遷を記載します。動作。 新しい州が動作に論理的に続いて、RFC1661の方法は好まれます。 さらに、RFC904のAppendix Cは2台の州のマシンのデカルト積として変遷をモデル化します。 これはそれが、より複雑な表現であるかもしれません。
Scott Best Current Practice [Page 14] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[14ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
difficult to comprehend for those readers that are unfamiliar with the format. We recommend that authors present tables as defined in the previous paragraph.
形式になじみがないそれらの読者のために理解するのは難しいです。 私たちは、作者が前のパラグラフで定義されるようにテーブルを寄贈することを勧めます。
A final method of representing state changes is by a time line. The two sides of the time line represent the machines involved in the exchange. The author lists the states the machines enter as time progresses (downward) along the outside of time line. Within the time line, show the actions that cause the state transitions. An example:
州の変化を表す最終的な方法はタイムラインを使用します。 タイムラインの2つの側が交換にかかわるマシンを表します。 時間の外部に沿った時間発展(下向きである)が立ち並ぶとき、作者はマシンが入る州を記載します。 タイムラインの中では、状態遷移を引き起こす動作を示してください。 例:
client server
クライアントサーバ
| |
| | LISTEN
SYN_SENT |----------------------- |
| \ syn j |
| ----------------->| SYN_RCVD
| |
| ------------------|
| syn k, ack j+1 / |
ESTABLISHED |<---------------------- |
| |
| | | | _が送ったSYNを聴いてください。|----------------------- | | \syn j| | ----------------->| SYN_RCVD| | | ------------------| | syn k、ack j+1/| 設立されます。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
4 Document Checklist
4ドキュメントチェックリスト
The following is a checklist based on the above guidelines that can be applied to a document:
↓これはドキュメントに適用できる上記のガイドラインに基づくチェックリストです:
o Does it identify the security risks? Are countermeasures for each
potential attack provided? Are the effects of the security
measures on the operating environment detailed?
o Does it explain the purpose of the protocol or procedure? Are the
intended functions and services addressed? Does it describe how it
relates to existing protocols?
o Does it consider scaling and stability issues?
o Have procedures for assigning numbers been coordinated with IANA?
o Does it discuss how to manage the protocol being specified? Is a
MIB defined?
o Is a target audience defined?
o Does it reference or explain the algorithms used in the protocol?
o Does it give packet diagrams in recommended form, if applicable?
o Is there a change log?
o Does it describe differences from previous versions, if
applicable?
o Does it separate explanatory portions of the document from
requirements?
o Does it give examples of protocol operation?
o それはセキュリティ危険を特定しますか? 各起こり得るかもしれない攻撃のための対策を提供しますか? 環境がそれでわかるo Doesについて詳述したという作動への安全策の効果はプロトコルか手順の目的ですか? 意図している機能とサービスは記述されますか? それはどう既存のプロトコルに関連するかを説明しますか?それがスケーリングと安定性であると考えるo Doesはそれが議論するo Doesに指定されていて、どうプロトコルを管理するかを発行します(IANAと共に調整された数を割り当てるためのo Have手順)-- それが切り離すそれで適切であるならそれがパケットダイヤグラムを与えるプロトコルo Doesで中古のアルゴリズムが、中で勧めた形成するのが参照をつけるか、またはわかる定義されたMIB--対象者が定義したo Is--o Doesが--それが旧バージョンで、適切な状態で違いについて説明するそこの変化が登録するo Is--o Does--o Doesは要件からのドキュメントの説明している部分ですか?--それがプロトコル操作に関する例を出すo Does?
Scott Best Current Practice [Page 15] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[15ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
o Does it specify behavior in the face of incorrect operation by
other implementations?
o Does it delineate which packets should be accepted for processing
and which should be ignored?
o If multiple descriptions of a requirement are given, does it
identify one as binding?
o How many optional features does it specify? Does it separate them
into option classes?
o Have all combinations of options or option classes been examined
for incompatibility?
o Does it explain the rationale and use of options?
o Have all mandatory and optional requirements be identified and
documented by the accepted key words that define Internet
requirement levels?
o Does it conform to the current internationalization policies of
the IETF?
o Are the recommended meanings for common Internet terms used?
o If not, are new or altered definitions for terms given in a
glossary?
o それは他の実現による不正確な操作に直面して振舞いを指定しますか?それは、1つが拘束力があると認識しますか?要件の複数の記述が与えられているそれが図で表わすそれのパケットが処理のために受け入れられるべきであり、無視されるべきであるo Does--o If、多くのオプション機能がそれをするo Howは指定します-- それをする、オプションかオプションのクラスのすべての組み合わせが不一致?o Doesがないかどうか調べられて、それでオプション?oのHaveのすべて義務的で任意の要件の原理と使用が特定されるのがわかるということであり、インターネット要件レベルを定義する受け入れられたキーワード--それがIETFの現在の国際化方針に従わせるo Does--o Areによるお勧めの意味を記録したオプションのクラスo Haveへの別々のそれら一般的なインターネット用語はo Ifを使用しました; 用語集で用語の新しいか変えられた定義を与えますか?
5 Security Considerations
5 セキュリティ問題
This document does not define a protocol or procedure that could be subject to an attack. It establishes guidelines for the information that should be included in RFCs that are to be submitted to the standards track. In the area of security, IETF standards authors are called on to define clearly the threats faced by the protocol and the way the protocol does or does not provide security assurances to the user.
このドキュメントは攻撃を受けることがあるかもしれないプロトコルか手順を定義しません。 それは標準化過程に提出されることになっているRFCsに含まれるべきである情報のためのガイドラインを確立します。 セキュリティ、明確に定義する作者が呼びかけられるIETF規格の領域では、プロトコルによって直面されていた脅威とプロトコルがするか、またはする道が安全保証をユーザに提供しません。
6 References
6つの参照箇所
[RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル(IP)」、STD5、RFC791 1981年9月。
[RFC 904] Mills, D., "Exterior Gateway Protocol formal
specification", RFC 904, April 1984.
[RFC904] 工場、D.、「外のゲートウェイプロトコル形式仕様」、RFC904、1984年4月。
[RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34,
RFC 1058, June 1988.
[RFC1058] ヘドリック、C.、「ルーティング情報プロトコル」、STD34、RFC1058、1988年6月。
[RFC 1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
ブレーデン、R.、[RFC1122]「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
Scott Best Current Practice [Page 16] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[16ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
[RFC 1123] Braden, R., "Requirements for Internet hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とSupport」、STD3、RFC1123、10月1989日
[RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[RFC1311] ポステル、J.、「STD注意への序論」、RFC1311、1992年3月。
[RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
[RFC1350] Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年7月。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC1662] シンプソン、W.、「HLDCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. (http://www.iana.org)
[RFC1700] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 ( http://www.iana.org )
[RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC1939] メイヤーズ、J.、およびM.ローズ、「バージョン3インチ、STD53、RFC1939、1996年POP--5月。」
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
August 1996.
[RFC1983] マルキン、G.、「インターネットユーザの用語集」、FYI18、RFC1983、1996年8月。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、RFC2026、1996年インターネット標準化過程--10月。」
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Moy、[RFC2328]J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC2223] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Language", RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、1998年1月。
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin、S.、「IABセキュリティー体系ワークショップのレポート」、RFC2316、1998年4月。
Scott Best Current Practice [Page 17] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[17ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
7 Acknowledgments
7つの承認
Peter Desnoyers and Art Mellor began the work on this document. Others that contributed were:
ピーターDesnoyersとArtメラーはこのドキュメントへの作業を始めました。 貢献した他のものは以下の通りでした。
Bernard Aboba
Harald T. Alvestrand
Fred Baker
Scott Bradner
Brian Carpenter
Robert Elz
Dirk Fieldhouse
Dale Francisco
Gary Malkin
Neal McBurnett
Thomas Narten
Craig Partridge
Vern Paxson
Mike O'Dell
Henning Schulzrinne
Kurt Starsinic
James Watt
バーナード・Abobaハラルド・T.Alvestrandフレッド・ベイカー・スコット・ブラドナーブライアン・大工のロバート・Elz Dirk Fieldhouseデール・フランシスコゲーリー・マルキン・ニール・McBurnettトーマス・Nartenクレイグ・Partridgeバーン・パクソン・マイク・オデル・ヘニング・Schulzrinneカート・Starsinicジェームズ・ワット
8 Editor's Address
8エディタのアドレス
Gregor D. Scott Director, Defense Information Systems Agency ATTN: JIEO-JEBBC Ft. Monmouth, NJ 07703-5613 USA
防衛情報システム庁ATTNのグレガーD.スコットディレクター: JIEO-JEBBCフィート モンマス、ニュージャージー07703-5613米国
Phone: (732) 427-6856 Fax: (732) 532-0853 EMail: scottg@ftm.disa.mil
以下に電話をしてください。 (732) 427-6856 Fax: (732) 532-0853 メールしてください: scottg@ftm.disa.mil
Scott Best Current Practice [Page 18] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[18ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
9 Appendix
9付録
CHANGES FROM DRAFT -06
草稿-06からの変化
The following changes were made following IESG review:
以下の変化は人工の次のIESGが論評するということでした:
References to RFC 1543 were changed to RFC 2223 that obsoleted it.
RFC1543の参照はそれを時代遅れにしたRFC2223に変わりました。
In section 2.1, "export control" was dropped as a valid reason for not selecting a security mechanism. In addition, ambiguous or conflicting sentences were removed.
セクション2.1では、「輸出管理」はセキュリティー対策を選択しない正当な理由として落とされました。 さらに、あいまいであるか闘争している文は取り除かれました。
In section 2.1 reference made to RFC 2315 as an additional source of information.
追加情報源としてRFC2315に行われたセクション2.1参照で。
Section 2.5 was changed to highlight the Change Log's purpose as assistance to implementers.
implementersに対する支援としてChange Logの目的を強調するためにセクション2.5を変えました。
The IANA Considerations section (2.13) was rewritten to highlight that the IANA guidelines document is work in progress but should be used when it becomes available.
IANA Considerations部(2.13)は、IANAガイドラインが処理中の作業であると記録するハイライトに書き直されましたが、利用可能になるとき、使用されるべきです。
Section 3.4 Character Sets was deleted and replaced by section 2.17 Internationalization.
セクション3.4 文字コードをセクション2.17Internationalizationに削除して、取り替えました。
Spelling and grammar corrections were made.
スペルと文法修正をしました。
CHANGES FROM DRAFT -05
草稿-05からの変化
A sentence pointing to a pending document that further addresses IANA considerations was added to section 2.13. The current draft of that document is draft-iesg-iana-considerations-02.txt. A clause stating that the IANA established the assignment policies was removed since it appeared to conflict with the intent of the referenced ID. Placeholders for the BCP and RFC number have been added to the text and reference section.
さらにIANA問題を記述する未定のドキュメントを示す文はセクション2.13に追加されました。 そのドキュメントの現在の草稿は草稿iesg-iana問題02.txtです。 参照をつけられたIDの意図と衝突するように見えたので、IANAが課題方針を確立したと述べる節は取り除かれました。 BCPとRFC番号のためのプレースホルダはテキストと参照部に追加されました。
A new section (2.5) requiring change logs as documents progress along the standards track was added.
ドキュメントが標準化過程に沿って進歩をしながらチェンジログを必要とする新しいセクション(2.5)は加えられました。
References to RFC 2044 were changed to RFC 2279 that obsoleted it.
RFC2044の参照はそれを時代遅れにしたRFC2279に変わりました。
Spelling and grammar corrections were made.
スペルと文法修正をしました。
CHANGES FROM DRAFT -04
草稿-04からの変化
A paragraph pointing to a pending document that further addresses security was updated.
さらにセキュリティを記述する未定のドキュメントを示すパラグラフをアップデートしました。
Scott Best Current Practice [Page 19] RFC 2360 Guide for Internet Standards Writers June 1998
スコット最も良い現在の習慣[19ページ]RFC2360は1998年6月にインターネット規格のために作家を誘導します。
10 Full Copyright Statement
10 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネット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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Scott Best Current Practice [Page 20]
スコットBest現在の習慣[20ページ]
一覧
スポンサーリンク
