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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンスに関するお知らせ
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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.
過去に受け入れられたレポートの詳細レベルは大きく異なっています。相互運用性を証明するには十分ではない提出したレポートの例は、（全体的に）ある：「実装の部分的なリストが含まれます：クレイSGIネットスターIBM HPネットワークシステム凸面を」。このレポートは、これらの実装は、（それが公共のラボでのテストを介していた？社内ラボテスト？展開？）相互運用することが知られている方法を述べるものではありません。また、それは、実装者が認識しているかどうかをキャプチャしない、または問題があることが判明した任意の機能、について尋ねました。別の極端では、報告書は、テスト方法に関する詳細の偉大な量が、働いて、何を仕事に失敗したかについての比較的少ない情報が含まれている提出されています。
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.
このメモは、実装レポートが含まれている必要があり、ほとんどのインプリメンテーション・レポートのための合理的な形を提案するものを明確にすることを意図しています。良いアイデアを除外するものではありません。たとえば、このメモは、このような二回標準ドラフトしようとして文書として考慮に入れ、すべてのプロセス変動を取ることができない、またそれは、標準のすべてのタイプを考慮することができます。状況がここで説明しているものから大きく変化するたびに、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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）を名前を付けてもよい（MAY）。
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オプション機能実装されていないことが、重要であり、相互運用性、MAYに害を与えていない、非常にと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つの実装がある場合は、報告書は、実装とその「系譜」（ライブラリが使用されたか、コードベースはどこから来たのか）を特定すべきです。そこより多くの実装があり、またはプロトコルが広く展開している、実装の二つがそれぞれ所定の機能の相互運用性を実証しているコールアウトする必要がない場合 - 読者は、その機能の実装の少なくとも一部であると結論付けることができます独立しました。
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.
注：明細書に記載された特徴の粒度は必然的に非常に詳細です。これとは対照的に、実施報告書の粒度は、などの詳細である必要はありません。報告書は、「MAY」、「SHOULD」、そして「MUST」実装間で完全なマトリックス内のすべてのリストを表示する必要はありません。より効果的なアプローチは、その後の試験や相互運用性のいずれかのいずれかの既知の問題を呼び出し、相互運用性、品質とテスト手法を特徴付けることかもしれません。
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.
どのような相互運用性レポートの目的で「機能」を構成することは頻繁に議論されてきました。良い判断が適切な要件の適用範囲を示して詳細レベルを見つけるために必要とされます。高すぎるレベルで行われた計算書を検証することができず、十分にテストが誤って相互運用するための重要な失敗を逃したことに挑戦していない文書になります。一方、テスターやレポートライターをoverburdens要件の相互作用の指数関数的に爆発マトリックス中に微細すぎるレベルの結果でステートメント。結果のレポートで重要な情報は、おそらくそれが困難な相互運用性の重要なポイントは対処されているかどうかを評価すること、細部の海で見つけるのは難しいだろう。
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と同様の報告は、（抜粋は以下の表示されます）仕様内のすべての規範的な文の徹底的なチェックリストよりも便利です。
o PASS: Many implementations, tested UCL rat with vat,
Cisco IP/TV with vat/vic.
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.相互運用受信報告パケットの交換データを受信していない（すなわち無参加者がデータを送信していない場合、各化合物RTCPパケットに最初に送信する必要があり、空の受信報告）。
o PASS: Many implementations, tested UCL rat with vat,
Cisco IP/TV with vat/vic.
...
。。。
8. Interoperable transport of RTP via TCP using the encapsulation defined in the audio/video profile
オーディオ/ビデオプロファイルに定義されたカプセル化を使用して、TCPを介してRTPの8相互運用可能な輸送
o FAIL: no known implementations. This has been removed from the audio/video profile.
O FAIL：知られていない実装。これは、オーディオ/ビデオ・プロファイルから削除されました。
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の実装はABNFチェックソフトウェアだけでなく、それを使用するRFCが含まれます。管理情報ベース（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:
それは実装によって実装レポートの作業を分割するのが一番簡単だ場合、結果 - 複数の実装レポートは - スポンサーエリアディレクター一つずつに提出することができます。 ：各レポートには、一つの実施をカバーするかもしれません
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
これは、オプションや必要な機能が実装されていません（この開示を処罰する一切のプロトコル警察が存在しないことに注意してください、我々は、彼らが理由を説明することができれば、特に実装されていないかunimplementableの特徴を指摘する実装を代わりに感謝する必要があります）。そして
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つのタイトルの下にアーカイブするための一つの文書に照合する必要がありますが、結果はいくつかの要約セクションや紹介があったとしても自明連結することができます。
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の使用はよく知られているRFCをに見出さ - - とABNFチェッカにそれらの実例を供給ABNF [RFC4234]自体は、現実世界の例を組み合わせて試験しました。よく知られた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.
- アトム[RFC4287]クライアントは、彼らが一貫して、すべての必須およびオプション機能をカバーし、現実世界の例から構築、テスト、Atomフィードで情報を表示することを見つけることによってテストすることがあります。
- 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）テストクライアントリトマス（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.
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パイプラインは何の相互運用性の問題がなかったので、実装レポートは非常に簡潔な形式ですべての重要な情報を提供することができました。読者はコードベースは、によって、大規模で、独立している必要があり、異なるベンダやプラットフォームから推測することができます。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ブラドナー、S.とV.パクソン、「IETF標準化過程のメトリック仕様の推進」、進歩、2007年7月の作業。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、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]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、エド。そして、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.、エド。そして、R.セイヤー、エド。、 "Atom配信フォーマット"、RFC 4287、2005年12月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
Authors' Addresses
著者のアドレス
Lisa Dusseault Messaging Architects
リサDusseaultメッセージングアーキテクツ
EMail: lisa.dusseault@gmail.com
メールアドレス：lisa.dusseault@gmail.com
Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
ロバート・スパークスTekelec 17210キャンベル道スイート250、ダラス、テキサス州75254から4203 USA
EMail: RjS@nostrum.com
メールアドレス：RjS@nostrum.com