[要約] RFC 5657は、進行中の標準案への進展に関する相互運用性と実装レポートのガイダンスを提供するものです。その目的は、標準案の進展に必要な情報を提供し、相互運用性と実装の品質を向上させることです。
Network Working Group L. Dusseault
Request for Comments: 5657 Messaging Architects
BCP: 9 R. Sparks
Updates: 2026 Tekelec
Category: Best Current Practice September 2009
Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard
標準のドラフトへの進歩のための相互操作と実装レポートに関するガイダンス
Abstract
概要
Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report.
プロトコルを標準のドラフトに進めるには、プロトコルの相互操作と実装の文書化が必要です。歴史的なレポートは、形式とレベルのコンテンツが大きく異なり、新しいレポート作成者が利用できるガイダンスはほとんどありません。このドキュメントは、既存のプロセスを更新し、相互運用性と実装レポートで適切なものの詳細を提供します。
Status of This 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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンス通知
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Content Requirements ............................................4
3. Format ..........................................................5
4. Feature Coverage ................................................6
5. Special Cases ...................................................8
5.1. Deployed Protocols .........................................8
5.2. Undeployed Protocols .......................................8
5.3. Schemas, Languages, and Formats ............................8
5.4. Multiple Contributors, Multiple Implementation Reports .....9
5.5. Test Suites ................................................9
5.6. Optional Features, Extensibility Features .................10
6. Examples .......................................................10
6.1. Minimal Implementation Report .............................11
6.2. Covering Exceptions .......................................11
7. Security Considerations ........................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................12
The Draft Standard level, and requirements for standards to meet it, are described in [RFC2026]. For Draft Standard, not only must two implementations interoperate, but also documentation (the report) must be provided to the IETF. The entire paragraph covering this documentation reads:
標準レベルのドラフト、およびそれを満たすための標準の要件は、[RFC2026]に記載されています。ドラフト標準の場合、2つの実装が相互運用するだけでなく、IETFにドキュメント（レポート）も提供する必要があります。このドキュメントをカバーする段落全体が読み取ります。
The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6)
ワーキンググループチェアは、これらの実装の相互操作のテストに関するドキュメントとともに、ドラフトまたはインターネットの標準ステータスの仕様を適格にする特定の実装を文書化する責任があります。ドキュメントには、個々のオプションと機能の各サポートに関する情報を含める必要があります。このドキュメントは、プロトコルアクションリクエストでエリアディレクターに提出する必要があります。（セクション6を参照）
Moving documents along the standards track can be an important signal to the user and implementor communities, and the process of submitting a standard for advancement can help improve that standard or the quality of implementations that participate. However, the barriers seem to be high for advancement to Draft Standard, or at the very least confusing. This memo may help in guiding people through one part of advancing specifications to Draft Standard. It also changes some of the requirements made in RFC 2026 in ways that are intended to maintain or improve the quality of reports while reducing the burden of creating them.
標準のトラックに沿ったドキュメントを移動することは、ユーザーと実装者コミュニティにとって重要なシグナルであり、進歩の基準を提出するプロセスは、参加する実装の標準または品質を改善するのに役立ちます。ただし、障壁は、標準を起草するための進歩、または少なくとも混乱を招くために高いようです。このメモは、標準をドラフトするために仕様を進めるための一部を介して人々を導くのに役立つかもしれません。また、RFC 2026で作成された要件の一部を、レポートの品質を維持または改善しながら、それらを作成する負担を軽減することを目的とした方法で変更します。
Having and demonstrating sufficient interoperability is a gating requirement for advancing a protocol to Draft Standard. Thus, the primary goal of an implementation report is to convince the IETF and the IESG that the protocol is ready for Draft Standard. This goal can be met by summarizing the interoperability characteristics and by providing just enough detail to support that conclusion. Side benefits may accrue to the community creating the report in the form of bugs found or fixed in tested implementations, documentation that can help future implementors, or ideas for other documents or future revisions of the protocol being tested.
十分な相互運用性を持ち、実証することは、標準をドラフトするためにプロトコルを進めるためのゲーティング要件です。したがって、実装レポートの主な目標は、IETFとIESGにプロトコルがドラフト標準の準備ができていることを納得させることです。この目標は、相互運用性の特性を要約し、その結論をサポートするのに十分な詳細を提供することにより、達成できます。副次的な利点は、テスト済みの実装、将来の実装者に役立つドキュメント、またはテスト対象のプロトコルの将来の改訂のアイデアを支援するドキュメントで見つかった、または修正されたバグの形でレポートを作成するコミュニティに発生する可能性があります。
Different kinds of documentation are appropriate for widely deployed standards than for standards that are not yet deployed. Different test approaches are appropriate for standards that are not typical protocols: languages, formats, schemas, etc. This memo discusses how reports for these standards may vary in Section 5.
まだ展開されていない標準よりも広く展開されている標準には、さまざまな種類のドキュメントが適切です。異なるテストアプローチは、典型的なプロトコルではない標準に適しています：言語、形式、スキーマなど。このメモは、これらの標準のレポートがセクション5でどのように異なるかについて説明します。
Implementation should naturally focus on the final version of the RFC. If there's any evidence that implementations are interoperating based on Internet-Drafts or earlier versions of the specification, or if interoperability was greatly aided by mailing list clarifications, this should be noted in the report.
実装は、RFCの最終バージョンに自然に焦点を当てる必要があります。インターネットドラフトまたは仕様の以前のバージョンに基づいて実装が相互運用しているという証拠がある場合、または相互運用性がメーリングリストの明確化によって大いに助けられた場合、これはレポートに記載されている必要があります。
The level of detail in reports accepted in the past has varied widely. An example of a submitted report that is not sufficient for demonstrating interoperability is (in its entirety): "A partial list of implementations include: Cray SGI Netstar IBM HP Network Systems Convex". This report does not state how it is known that these implementations interoperate (was it through public lab testing? internal lab testing? deployment?). Nor does it capture whether implementors are aware of, or were asked about, any features that proved to be problematic. At a different extreme, reports have been submitted that contain a great amount of detail about the test methodology, but relatively little information about what worked and what failed to work.
過去に受け入れられたレポートの詳細レベルは大きく異なります。相互運用性を実証するのに十分ではない提出されたレポートの例は（全体として）次のとおりです。このレポートは、これらの実装が相互運用することがどのように知られているかを述べていません（公共ラボテストを通じて、内部ラボテスト？展開？）。また、問題があることが証明された機能を実装者が認識しているか、尋ねられたかどうかも把握していません。別の極端に、テスト方法に関する詳細な詳細を含むレポートが提出されていますが、何が機能し、何が機能しなかったかについての情報は比較的少ない情報です。
This memo is intended to clarify what an implementation report should contain and to suggest a reasonable form for most implementation reports. It is not intended to rule out good ideas. For example, this memo can't take into account all process variations such as documents going to Draft Standard twice, nor can it consider all types of standards. Whenever the situation varies significantly from what's described here, the IESG uses judgement in determining whether an implementation report meets the goals above.
このメモは、実装レポートに何を含めるべきかを明確にし、ほとんどの実装レポートに合理的なフォームを提案することを目的としています。良いアイデアを排除することを意図したものではありません。たとえば、このメモは、標準を2回ドラフトするドキュメントなどのすべてのプロセスバリエーションを考慮することも、すべてのタイプの標準を考慮することもできません。状況がここで説明されていることから大きく異なるときはいつでも、IESGは、実装レポートが上記の目標を満たしているかどうかを判断する際に判断を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14 [RFC2119]に記載されているように解釈される。
The implementation report MUST identify the author of the report, who is responsible for characterizing the interoperability quality of the protocol. The report MAY identify other contributors (testers, those who answered surveys, or those who contributed information) to share credit or blame. The report MAY provide a list of report reviewers who corroborate the characterization of interoperability quality, or name an active working group (WG) that reviewed the report.
実装レポートは、プロトコルの相互運用性の品質を特徴付ける責任があるレポートの著者を特定する必要があります。報告書は、クレジットや責任を共有するために、他の貢献者（テスター、調査に応答した人、または情報に貢献した人）を特定する場合があります。このレポートは、相互運用性の品質の特性評価を裏付けるレポートレビューアのリストを提供するか、レポートをレビューしたアクティブワーキンググループ（WG）に名前を付けることができます。
Some of the requirements of RFC 2026 are relaxed with this update:
RFC 2026の要件の一部は、このアップデートで緩和されています。
o The report MAY name exactly which implementations were tested. A requirement to name implementations was implied by the description of the responsibility for "documenting the specific implementations" in RFC 2026. However, note that usually identifying implementations will help meet the goals of implementation reports. If a subset of implementations was tested or surveyed, it would also help to explain how that subset was chosen or self-selected. See also the note on implementation independence below.
o レポートには、どの実装がテストされたかを正確に名前を付けることができます。実装に名前を付ける要件は、RFC 2026の「特定の実装の文書化」の責任の説明によって暗示されました。ただし、通常、実装を特定することは、実装レポートの目標を達成するのに役立つことに注意してください。実装のサブセットがテストまたは調査された場合、そのサブセットがどのように選択されたか、または自己選択されたかを説明するのにも役立ちます。以下の実装独立性に関するメモも参照してください。
o The report author MAY choose an appropriate level of detail to document feature interoperability, rather than document each individual feature. See note on granularity of features below.
o レポート著者は、個々の機能を文書化するのではなく、機能の相互運用性を文書化するための適切なレベルの詳細を選択できます。以下の機能の粒度に関するメモを参照してください。
o A contributor other than a WG chair MAY submit an implementation report to an Area Director (AD).
o WG椅子以外の貢献者は、エリアディレクター（AD）に実装レポートを提出できます。
o Optional features that are not implemented, but are important and do not harm interoperability, MAY, exceptionally and with approval of the IESG, be left in a protocol at Draft Standard. See Section 5.6 for documentation requirements and an example of where this is needed.
o 実装されていないが重要であり、相互運用性に害を及ぼさないオプションの機能は、例外的に、IESGの承認を得て、ドラフト標準のプロトコルに残されている可能性があります。ドキュメント要件とこれが必要な場所の例については、セクション5.6を参照してください。
Note: Independence of implementations is mentioned in the RFC 2026 requirements for Draft Standard status. Independent implementations should be written by different people at different organizations using different code and protocol libraries. If it's necessary to relax this definition, it can be relaxed as long as there is evidence to show that success is due more to the quality of the protocol than to out-of-band understandings or common code. If there are only two implementations of an undeployed protocol, the report SHOULD identify the implementations and their "genealogy" (which libraries were used or where the codebase came from). If there are many more implementations, or the protocol is in broad deployment, it is not necessary to call out which two of the implementations demonstrated interoperability of each given feature -- a reader may conclude that at least some of the implementations of that feature are independent.
注：実装の独立性は、ドラフト標準ステータスのRFC 2026要件に記載されています。独立した実装は、さまざまなコードライブラリとプロトコルライブラリを使用して、さまざまな組織のさまざまな人々によって作成される必要があります。この定義を緩和する必要がある場合、成功が帯域外の理解や共通コードよりもプロトコルの質に起因することを示す証拠がある限り、リラックスできます。非展開プロトコルの実装が2つしかない場合、レポートは実装とその「系図」（ライブラリが使用されたか、コードベースがどこから来たのか）を特定する必要があります。さらに多くの実装がある場合、またはプロトコルが広範囲に展開されている場合、2つの実装が各特定の機能の相互運用性を実証した2つの実装を呼び出す必要はありません。読者は、その機能の実装の少なくとも一部があると結論付けることができます。独立。
Note: The granularity of features described in a specification is necessarily very detailed. In contrast, the granularity of an implementation report need not be as detailed. A report need not list every "MAY", "SHOULD", and "MUST" in a complete matrix across implementations. A more effective approach might be to characterize the interoperability quality and testing approach, then call out any known problems in either testing or interoperability.
注：仕様で説明されている機能の粒度は、必然的に非常に詳細です。対照的に、実装レポートの粒度は詳細である必要はありません。レポートには、実装全体の完全なマトリックスにすべての「5月」、「必要」、および「必須」をリストする必要はありません。より効果的なアプローチは、相互運用性の品質とテストアプローチを特徴付けることであり、テストまたは相互運用性のいずれかで既知の問題を呼び出すことです。
The format of implementation and interoperability reports MUST be ASCII text with line breaks for readability. As with Internet-Drafts, no 8-bit characters are currently allowed. It is acceptable, but not necessary, for a report to be formatted as an Internet-Draft.
実装および相互運用性レポートの形式は、読みやすさのためにラインブレークを備えたASCIIテキストでなければなりません。インターネットドラフトと同様に、8ビット文字は現在許可されていません。レポートをインターネットドラフトとしてフォーマットする必要はありませんが、必要ではありません。
Here is a simple outline that an implementation report MAY follow in part or in full:
実装レポートが部分的または完全に続く可能性があるという簡単な概要を次に示します。
Title: Titles of implementation reports are strongly RECOMMENDED to contain one or more RFC number for consistent lookup in a simple archive. In addition, the name or a common mnemonic of the standard should be in the title. An example might look like "Implementation Report for the Example Name of Some Protocol (ENSP) RFC XXXX".
タイトル：実装レポートのタイトルは、単純なアーカイブで一貫したルックアップのために1つ以上のRFC番号を含めるように強くお勧めします。さらに、標準の名前または一般的なニーモニックはタイトルにある必要があります。例は、「一部のプロトコル（ENSP）RFC XXXXの例の実装レポート」のように見えるかもしれません。
Author: Identify the author of the report.
著者：レポートの著者を特定します。
Summary: Attest that the standard meets the requirements for Draft Standard and name who is attesting it. Describe how many implementations were tested or surveyed. Quickly characterize the deployment level and where the standard can be found in deployment. Call out, and if possible, briefly describe any notably difficult or poorly interoperable features and explain why these still meet the requirement. Assert any derivative conclusions: if a high-level system is tested and shown to work, then we may conclude that the normative requirements of that system (all sub-system or lower-layer protocols, to the extent that a range of features is used) have also been shown to work.
概要：標準は、ドラフト標準の要件とそれを証明している名前の要件を満たしていることを証明してください。テストまたは調査された実装の数を説明してください。展開レベルと、展開時に標準を見つけることができる場所をすばやく特徴付けます。呼び出し、可能であれば、特に難しいまたは不十分な相互運用可能な機能について簡単に説明し、これらがまだ要件を満たしている理由を説明します。デリバティブの結論を主張する：高レベルのシステムがテストされ、機能することが示されている場合、そのシステムの規範的要件（すべてのサブシステムまたは低層プロトコルは、さまざまな機能が使用される範囲で結論付けることができます。）も機能することが示されています。
Methodology: Describe how the information in the report was obtained. This should be no longer than the summary.
方法論：レポートの情報がどのように得られたかを説明してください。これは概要よりもはもうないはずです。
Exceptions: This section might read "Every feature was implemented, tested, and widely interoperable without exception and without question". If that statement is not true, then this section should cover whether any features were thought to be problematic. Problematic features need not disqualify a protocol from Draft Standard, but this section should explain why they do not (e.g., optional, untestable, trace, or extension features). See the example in Section 6.2.
例外：このセクションでは、「すべての機能が実装、テストされ、例外なく、疑いなく広く相互運用可能」と読み取られる場合があります。その声明が真実でない場合、このセクションでは、機能が問題であると考えられていたかどうかをカバーする必要があります。問題のある機能は、ドラフト標準からプロトコルを失格させる必要はありませんが、このセクションでは、それらがそうでない理由を説明する必要があります（例：オプション、未熟、トレース、または拡張機能）。セクション6.2の例を参照してください。
Detail sections: Any other justifying or background information can be included here. In particular, any information that would have made the summary or methodology sections more than a few paragraphs long may be created as a detail section and referenced.
詳細セクション：他の正当化または背景情報はここに含めることができます。特に、概要または方法論のセクションを数段落以上にした情報は、詳細セクションとして作成され、参照される場合があります。
In this section, it would be good to discuss how the various considerations sections played out. Were the security considerations accurate and dealt with appropriately in implementations? Was real internationalization experience found among the tested implementations? Did the implementations have any common monitoring or management functionality (although note that documenting the interoperability of a management standard might be separate from documenting the interoperability of the protocol itself)? Did the IANA registries or registrations, if any, work as intended?
このセクションでは、さまざまな考慮事項セクションがどのように展開されたかを議論することは良いことです。セキュリティ上の考慮事項は正確で、実装に適切に対処されましたか？テストされた実装の間で実際の国際化の経験が見つかりましたか？実装には、一般的な監視または管理機能がありましたか（管理基準の相互運用性を文書化することは、プロトコル自体の相互運用性を文書化することとは別のものである可能性があることに注意してください）。IANAレジストリまたは登録は、もしあれば、意図したとおりに機能しましたか？
Appendix sections: It's not necessary to archive test material such as test suites, test documents, questionnaire text, or questionnaire responses. However, if it's easy to preserve this information, appendix sections allow readers to skip over it if they are not interested. Preserving detailed test information can help people doing similar or follow-on implementation reports, and can also help new implementors.
付録セクション：テストスイート、テストドキュメント、アンケートテキスト、アンケートの回答などのテスト資料をアーカイブする必要はありません。ただし、この情報を簡単に保存できない場合は、付録セクションで読者が興味がない場合はスキップできます。詳細なテスト情報を保存することで、同様のまたはフォローオン実装レポートを実行するのに役立ち、新しい実装者にも役立ちます。
What constitutes a "feature" for the purposes of an interoperability report has been frequently debated. Good judgement is required in finding a level of detail that adequately demonstrates coverage of the requirements. Statements made at too high a level will result in a document that can't be verified and hasn't adequately challenged that the testing accidentally missed an important failure to interoperate. On the other hand, statements at too fine a level result in an exponentially exploding matrix of requirement interaction that overburdens the testers and report writers. The important information in the resulting report would likely be hard to find in the sea of detail, making it difficult to evaluate whether the important points of interoperability have been addressed.
相互運用性レポートの目的のために「機能」を構成するものが頻繁に議論されています。要件のカバレッジを適切に実証する詳細レベルを見つける際には、適切な判断が必要です。あまりにも高いレベルで作成されたステートメントは、検証できず、テストが誤って相互運用の重要な失敗を誤って逃したことを十分に挑戦していないドキュメントをもたらします。一方、あまりにも素晴らしいAレベルでのステートメントは、テスターを過剰に抑制し、作家を報告する要件相互作用の指数関数的に爆発するマトリックスをもたらします。結果のレポートの重要な情報は、詳細な海で見つけるのが難しい可能性が高く、相互運用性の重要なポイントが対処されているかどうかを評価することを困難にしています。
The best interoperability reports will organize statements of interoperability at a level of detail just sufficient to convince the reader that testing has covered the full set of requirements and in particular that the testing was sufficient to uncover any places where interoperability does not exist. Reports similar to that for RTP/RTCP (an excerpt appears below) are more useful than an exhaustive checklist of every normative statement in the specification.
最良の相互運用性レポートは、テストが要件の完全なセットをカバーしていること、特にテストが相互運用性が存在しない場所を明らかにするのに十分であることを読者に納得させるのに十分なレベルの詳細性の相互運用性の声明を整理します。RTP/RTCP（抜粋が以下に表示される）と同様のレポートは、仕様のすべての規範的なステートメントの徹底的なチェックリストよりも有用です。
10. Interoperable exchange of receiver report packets.
10. 受信者レポートパケットの相互運用可能な交換。
o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic.
o パス：多くの実装、VATでUCLラットをテストし、VAT/VICでCisco IP/TVをテストしました。
11. Interoperable exchange of receiver report packets when not receiving data (ie: the empty receiver report which has to be sent first in each compound RTCP packet when no-participants are transmitting data).
11. データを受信していない場合のレシーバーレポートパケットの相互運用可能な交換（IE：参加者なしでデータを送信しているときに各化合物RTCPパケットで最初に送信する必要がある空の受信者レポート）。
o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic.
o パス：多くの実装、VATでUCLラットをテストし、VAT/VICでCisco IP/TVをテストしました。
...
...
8. Interoperable transport of RTP via TCP using the encapsulation defined in the audio/video profile
8. オーディオ/ビデオプロファイルで定義されたカプセル化を使用したTCPを介したRTPの相互運用可能な輸送
o FAIL: no known implementations. This has been removed from the audio/video profile.
o 失敗：既知の実装はありません。これは、オーディオ/ビデオプロファイルから削除されました。
Excerpts from http://www.ietf.org/iesg/implementation/report-avt-rtp-rtcp.txt
http://www.ietf.org/iesg/implementation/Report-avt-rtp-rtcp.txtからの抜粋
Consensus can be a good tool to help determine the appropriate level for such feature descriptions. A working group can make a strong statement by documenting its consensus that a report sufficiently covers a specification and that interoperability has been demonstrated.
コンセンサスは、このような機能の説明に適したレベルを決定するのに役立つ優れたツールになります。ワーキンググループは、レポートが仕様を十分にカバーし、相互運用性が実証されているというコンセンサスを文書化することにより、強力な声明を発表することができます。
When a protocol is deployed, results obtained from laboratory testing are not as useful to the IETF as learning what is actually working in deployment. To this end, it may be more informative to survey implementors or operators. A questionnaire or interview can elicit information from a wider number of sources. As long as it is known that independent implementations can work in deployment, it is more useful to discover what problems exist, rather than gather long and detailed checklists of features and options.
プロトコルが展開されると、実験室のテストから得られた結果は、展開で実際に機能しているものを学習するほどIETFにとって有用ではありません。この目的のために、実装者またはオペレーターを調査する方が有益かもしれません。アンケートまたはインタビューは、より多くの情報源から情報を引き出すことができます。独立した実装が展開に機能することが知られている限り、機能とオプションの長い詳細なチェックリストを収集するのではなく、どのような問題が存在するかを発見することがより便利です。
It is appropriate to provide finer-grained detail in reports for protocols that do not yet have a wealth of experience gained through deployment. In particular, some complicated, flexible or powerful features might show interoperability problems when testers start to probe outside the core use cases. RFC 2026 requires "sufficient successful operational experience" before progressing a standard to Draft, and notes that:
展開を通じて豊富な経験を獲得していないプロトコルのレポートで、より細かい詳細を提供することが適切です。特に、テスターがコアユースケースの外側の外で調査を開始すると、複雑な、柔軟性、または強力な機能がいくつか示される可能性があります。RFC 2026は、ドラフトするために基準を進める前に「十分な成功した運用体験」を必要とし、次のように述べています。
Draft Standard may still require additional or more widespread field experience, since it is possible for implementations based on Draft Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments.
ドラフトスタンダードは、生産環境で大規模な使用を受ける場合に予期せぬ行動を実証するためのドラフト標準仕様に基づいた実装が可能であるため、さらに広範なフィールドエクスペリエンスを必要とする場合があります。
When possible, reports for protocols without much deployment experience should anticipate common operational considerations. For example, it would be appropriate to put additional emphasis on overload or congestion management features the protocol may have.
可能であれば、展開経験のないプロトコルのレポートは、一般的な運用上の考慮事項を予測する必要があります。たとえば、プロトコルが持つ可能性のある過負荷または輻輳管理機能にさらに重点を置くことが適切です。
Standards that are not on-the-wire protocols may be special cases for implementation reports. The IESG SHOULD use judgement in what kind of implementation information is acceptable for these kinds of standards. ABNF (RFC 4234) is an example of a language for which an implementation report was filed: it is interoperable in that protocols are specified using ABNF and these protocols can be successfully implemented and syntax verified. Implementations of ABNF include the RFCs that use it as well as ABNF checking software. Management Information Base (MIB, [RFC3410]) modules are sometimes documented in implementation reports, and examples of that can be found in the archive of implementation reports.
ワイヤのプロトコルではない標準は、実装レポートの特別なケースである可能性があります。IESGは、これらの種類の標準でどのような実装情報が受け入れられるかについて判断を使用する必要があります。ABNF（RFC 4234）は、実装レポートが提出された言語の例です。これは、ABNFを使用してプロトコルが指定され、これらのプロトコルを正常に実装および検証できるという言語の例です。ABNFの実装には、それを使用するRFCとABNFチェックソフトウェアが含まれます。管理情報ベース（MIB、[RFC3410]）モジュールは、実装レポートに文書化されることがあり、その例は実装レポートのアーカイブに記載されています。
The interoperability reporting requirements for some classes of documents may be discussed in separate documents. See [METRICSTEST] for example.
ドキュメントの一部のクラスの相互運用性の報告要件については、個別のドキュメントで説明できます。たとえば[MetricStest]を参照してください。
If it's easiest to divide up the work of implementation reports by implementation, the result -- multiple implementation reports -- MAY be submitted to the sponsoring Area Director one-by-one. Each report might cover one implementation, including:
実装レポートの作業を実装ごとに分割するのが最も簡単な場合は、結果 - 複数の実装レポート - がスポンサーエリアディレクターに1つずつ提出する場合があります。各レポートは、次のような1つの実装をカバーする場合があります。
identification of the implementation;
実装の識別。
an affirmation that the implementation works in testing (or better, in deployment);
実装がテストで機能する（または展開でより良い）という肯定。
whether any features are known to interoperate poorly with other implementations;
他の実装との相互操作が不十分であることが知られている機能が知られているかどうか。
which optional or required features are not implemented (note that there are no protocol police to punish this disclosure, we should instead thank implementors who point out unimplemented or unimplementable features especially if they can explain why); and
どのオプションまたは必要な機能が実装されていないか（この開示を罰するプロトコル警察はないことに注意してください。代わりに、特に理由を説明できる場合は、実装されていないまたは不可解な機能を指摘してくれた実装者に感謝する必要があります）。と
who is submitting this report for this implementation.
この実装のためにこのレポートを提出している人。
These SHOULD be collated into one document for archiving under one title, but can be concatenated trivially even if the result has several summary sections or introductions.
これらは、1つのタイトルの下でアーカイブするために1つのドキュメントに照合する必要がありますが、結果にいくつかの要約セクションまたは紹介がある場合でも、些細なことに連結することができます。
Some automated tests, such as automated test clients, do not test interoperability directly. When specialized test implementations are necessary, tests can at least be constructed from real-world protocol or document examples. For example:
自動化されたテストクライアントなどの一部の自動テストでは、相互運用性を直接テストしません。専門的なテストの実装が必要な場合、テストは少なくとも実際のプロトコルまたはドキュメントの例から構築できます。例えば：
- ABNF [RFC4234] itself was tested by combining real-world examples -- uses of ABNF found in well-known RFCs -- and feeding those real-world examples into ABNF checkers. As the well-known RFCs were themselves interoperable and in broad deployment, this served as both a deployment proof and an interoperability proof. [RFC4234] progressed from Proposed Standard through Draft Standard to Standard and is obsoleted by [RFC5234].
- ABNF [RFC4234]自体は、実世界の例（よく知られているRFCで見つかったABNFの使用）を組み合わせて、それらの実際の例をABNFチェッカーに供給することによってテストされました。よく知られているRFCはそれ自体が相互運用可能であり、幅広い展開において、これは展開証明と相互運用性の両方の証明の両方として機能しました。[RFC4234]は、提案された標準からドラフト標準まで進行し、[RFC5234]によって廃止されました。
- Atom [RFC4287] clients might be tested by finding that they consistently display the information in a test Atom feed, constructed from real-world examples that cover all the required and optional features.
- Atom [RFC4287]クライアントは、必要なすべての機能とオプションの機能をカバーする実際の例から構築されたテスト原子フィードに情報を一貫して表示することを発見してテストされる場合があります。
- MIB modules can be tested with generic MIB browsers, to confirm that different implementations return the same values for objects under similar conditions.
- MIBモジュールは、一般的なMIBブラウザーでテストすることができ、異なる実装が同様の条件下で同じ値を返すことを確認できます。
As a counter-example, the automated WWW Distributed Authoring and Versioning (WebDAV) test client Litmus (http://www.webdav.org/neon/litmus/) is of limited use in demonstrating interoperability for WebDAV because it tests completeness of server implementations and simple test cases. It does not test real-world use or whether any real WebDAV clients implement a feature properly or at all.
反例として、自動化されたWWW分散オーサリングおよびバージョン（WebDAV）テストクライアントLitmus（http://www.webdav.org/neon/litmus/）は、サーバーの完全性をテストするため、Webdavの相互運用性を実証するのに限られた使用です。実装と簡単なテストケース。実際の使用をテストすることはなく、実際のWebDavクライアントが機能を適切にまたはまったく実装しているかどうかはテストしません。
Optional features need not be shown to be implemented everywhere. However, they do need to be implemented somewhere, and more than one independent implementation is required. If an optional feature does not meet this requirement, the implementation report must say so and explain why the feature must be kept anyway versus being evidence of a poor-quality standard.
オプションの機能をどこでも実装することを示す必要はありません。ただし、どこかで実装する必要があり、複数の独立した実装が必要です。オプションの機能がこの要件を満たしていない場合、実装レポートはそう言って、質の低い基準の証拠であるのに対して、とにかく機能をとにかく保持しなければならない理由を説明する必要があります。
Extensibility points and versioning features are particularly likely to need this kind of treatment. When a protocol version 1 is released, the protocol version field itself is likely to be unused. Before any other versions exist, it can't really be demonstrated that this particular field or option is implemented.
拡張性ポイントとバージョンの機能は、この種の治療が特に必要になる可能性が高いです。プロトコルバージョン1がリリースされると、プロトコルバージョンフィールド自体が未使用の可能性があります。他のバージョンが存在する前に、この特定のフィールドまたはオプションが実装されていることを実際に実証することはできません。
Some good, extremely brief, examples of implementation reports can be found in the archives:
いくつかの優れた、非常に短い、実装レポートの例は、アーカイブにあります。
http://www.ietf.org/iesg/implementation/report-ppp-lcp-ext.html
http://www.ietf.org/iesg/implementation/report-otp.html
In some cases, perfectly good implementation reports are longer than necessary, but may preserve helpful information:
場合によっては、完全に優れた実装レポートは必要以上に長くなりますが、有用な情報を保持する可能性があります。
http://www.ietf.org/iesg/implementation/report-rfc2329.txt
http://www.ietf.org/iesg/implementation/report-rfc4234.txt
A large number of SMTP implementations support SMTP pipelining, including: (1) Innosoft's PMDF and Sun's SIMS. (2) ISODE/ MessagingDirect's PP. (3) ISOCOR's nPlex. (4) software.com's post.office. (5) Zmailer. (6) Smail. (7) The SMTP server in Windows 2000. SMTP pipelining has been widely deployed in these and other implementations for some time, and there have been no reported interoperability problems.
多数のSMTP実装は、以下を含むSMTPパイプラインをサポートしています。（1）InnosoftのPMDFとSunのSims。（2）Isode/ MessagingDirectのpp。（3）Isocorのnplex。（4）Software.comのPost.Office。（5）Zmailer。（6）Smail。（7）Windows 2000のSMTPサーバー。SMTPパイプラインは、これらおよびその他の実装にしばらくの間広く展開されており、相互運用性の問題は報告されていません。
This implementation report can also be found at http://www.ietf.org//iesg/implementation/report-smtp-pipelining.txt but the entire report is already reproduced above. Since SMTP pipelining had no interoperability problems, the implementation report was able to provide all the key information in a very terse format. The reader can infer from the different vendors and platforms that the codebases must, by and in large, be independent.
この実装レポートは、http：//www.ietf.org//iesg/implementation/report-smtp-pipelining.txtにもありますが、レポート全体はすでに上記で再現されています。SMTP Pipelingには相互運用性の問題がなかったため、実装レポートは非常に簡潔な形式ですべての重要な情報を提供することができました。読者は、さまざまなベンダーやプラットフォームから、コードベースが、大規模で、独立している必要があると推測できます。
This implementation report would only be slightly improved by a positive affirmation that there have been probes or investigations asking about interoperability problems rather than merely a lack of problem reports, and by stating who provided this summary report.
この実装レポートは、単なる問題レポートの欠如ではなく、相互運用性の問題について尋ねるプローブまたは調査が行われたという肯定的な肯定によってのみ、わずかに改善され、誰がこの要約レポートを提供したかを述べることによってのみ改善されます。
The RFC2821bis (SMTP) implementation survey asked implementors what features were not implemented. The VRFY and EXPN commands showed up frequently in the responses as not implemented or disabled. That implementation report might have followed the advice in this document, had it already existed, by justifying the interoperability of those features up front or in an "exceptions" section if the outline defined in this memo were used:
RFC2821BIS（SMTP）実装調査では、実装者に実装されていない機能が尋ねました。VRFYおよびEXPNコマンドは、実装または無効になっていないため、応答に頻繁に現れました。このメモで定義されているアウトラインが使用されている場合、これらの機能の相互運用性を正当化するか、「例外」セクションで、このドキュメントのアドバイスに従っていた場合、このドキュメントのアドバイスに従っていた可能性があります。
VRFY and EXPN commands are often not implemented or are disabled. This does not pose an interoperability problem for SMTP because EXPN is an optional features and its support is never relied on. VRFY is required, but in practice it is not relied on because servers can legitimately reply with a non-response. These commands should remain in the standard because they are sometimes used by administrators within a domain under controlled circumstances (e.g. authenticated query from within the domain). Thus, the occasional utility argues for keeping these features, while the lack of problems for end-users means that the interoperability of SMTP in real use is not in the least degraded.
VRFYおよびEXPNコマンドは、多くの場合、実装されていないか、無効にされます。Expnはオプションの機能であり、そのサポートは決して依存していないため、これはSMTPの相互運用性の問題を引き起こすことはありません。VRFYは必要ですが、実際には、サーバーが非応答で合法的に返信できるため、実際には依存していません。これらのコマンドは、制御された状況下でドメイン内の管理者によって使用されることがあるため、標準にとどまる必要があります（例：ドメイン内からの認証クエリ）。したがって、時折のユーティリティはこれらの機能を維持することを主張しますが、エンドユーザーの問題の欠如は、実際の使用におけるSMTPの相互運用性が少なくとも劣化していないことを意味します。
This memo introduces no new security considerations.
このメモは、新しいセキュリティ上の考慮事項を紹介しません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[METRICSTEST] Bradner, S. and V. Paxson, "Advancement of metrics specifications on the IETF Standards Track", Work in Progress, July 2007.
[MetricStest] Bradner、S。およびV. Paxson、「IETF標準トラックでのメトリック仕様の進歩」、2007年7月の作業。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4287]ノッティンガム、M。、編and R. Sayre、ed。、「The Atom Syndication Format」、RFC 4287、2005年12月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
Authors' Addresses
著者のアドレス
Lisa Dusseault Messaging Architects
Lisa Dusseault Messaging Architects
EMail: lisa.dusseault@gmail.com
Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
ロバートスパークステケレック17210キャンベルロードスイート250ダラス、テキサス75254-4203 USA
EMail: RjS@nostrum.com