Network Working Group L. Dusseault
Request for Comments: 5657 Messaging Architects
BCP: 9 R. Sparks
Updates: 2026 Tekelec
Category: Best Current Practice September 2009
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.
版权所有（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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第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
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]中描述了标准水平草案以及满足其要求的标准要求。对于标准草案，不仅两个实现必须互操作，还必须向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相信该协议已准备好起草标准。这一目标可以通过总结互操作性特征并提供足够的细节来支持这一结论来实现。以测试实现中发现或修复的bug、可帮助未来实现者的文档、其他文档或被测试协议的未来修订的想法的形式创建报告的社区可能会获得附带的好处。
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的最终版本。如果有任何证据表明实现是基于Internet草案或规范的早期版本进行互操作的，或者如果互操作性在很大程度上得到了邮件列表澄清的帮助，则应在报告中指出这一点。
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.
过去接受的报告的详细程度差别很大。提交的报告不足以证明互操作性的一个例子是（全部）：“部分实施清单包括：Cray SGI Netstar IBM HP Network Systems”。此报告没有说明如何知道这些实现是互操作的（是否通过公共实验室测试？内部实验室测试？部署？）。它也没有捕获实现者是否知道或被问及任何被证明有问题的特性。在另一个极端，提交的报告中包含了大量关于测试方法的细节，但关于哪些有效，哪些无效的信息相对较少。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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 除工作组主席以外的贡献者可向区域主任（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
注：RFC 2026标准草案状态要求中提到了实施的独立性。独立的实现应该由不同组织的不同人员使用不同的代码和协议库编写。如果有必要放宽这一定义，只要有证据表明成功更多地归功于协议的质量，而不是带外理解或通用代码，就可以放宽这一定义。如果一个未部署的协议只有两个实现，那么报告应该确定实现及其“谱系”（使用了哪些库或代码库来自哪里）。如果有更多的实现，或者该协议正在广泛部署中，则无需指出其中哪两个
implementations demonstrated interoperability of each given feature -- a reader may conclude that at least some of the implementations of that feature are independent.
实现展示了每个给定特性的互操作性——读者可能会得出结论，至少该特性的一些实现是独立的。
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.
注意：规范中描述的特性的粒度必须非常详细。相反，实施报告的粒度不需要如此详细。一份报告不需要在一个完整的矩阵中列出每个“可能”、“应该”和“必须”。更有效的方法可能是描述互操作性质量和测试方法，然后指出测试或互操作性中的任何已知问题。
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文本，并带有换行符，以确保可读性。与Internet草稿一样，当前不允许使用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".
标题：强烈建议实施报告的标题包含一个或多个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.
为了互操作性报告的目的，什么构成“特性”经常被争论。在找到充分证明需求覆盖范围的详细程度时，需要良好的判断。级别过高的声明将导致无法验证的文档，并且没有充分质疑测试意外错过了互操作的重要故障。另一方面，过于精细的语句会导致需求交互矩阵呈指数级爆炸，从而使测试人员和报告编写人员负担过重。由此产生的报告中的重要信息可能很难在浩如烟海的细节中找到，因此很难评估互操作性的要点是否得到了解决。
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 rat，使用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. 不接收数据时可互操作的接收器报告数据包交换（即：当没有参与者传输数据时，必须在每个复合RTCP数据包中首先发送的空接收器报告）。
o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic.
o 通过：许多实施，使用vat测试UCL rat，使用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
Excerpts from
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:
如果最容易将实施报告的工作按实施进行划分，那么结果——多个实施报告——可能会一个接一个地提交给发起区域主管。每个报告可能涵盖一个实施，包括：
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.
这些内容应整理成一个文档，以便在一个标题下存档，但即使结果有多个摘要部分或介绍，也可以简单地连接起来。
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]客户端时，可能会发现它们一致地在测试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）测试客户机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-ppp-lcp-ext.html
http://www.ietf.org/iesg/implementation/report-otp.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-rfc2329.txt
http://www.ietf.org/iesg/implementation/report-rfc4234.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的第（3）页和ISOCOR的nPlex。（4） 软件公司的邮局。（5） 兹迈勒。（6） 斯梅尔。（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管道没有互操作性问题，实施报告能够以非常简洁的格式提供所有关键信息。读者可以从不同的供应商和平台推断，基本上，代码库必须是独立的。
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命令通常未执行或被禁用。这不会对SMTP造成互操作性问题，因为EXPN是一个可选功能，它的支持永远不受依赖。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 34102002年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.，Ed.和R.Sayre，Ed.，“原子联合格式”，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消息传递架构师
EMail: lisa.dusseault@gmail.com
EMail: lisa.dusseault@gmail.com
Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA
美国德克萨斯州达拉斯市坎贝尔路250号Robert Sparks Tekelec 17210套房75254-4203
EMail: RjS@nostrum.com
EMail: RjS@nostrum.com