Network Working Group S. Bradner
Request for Comments: 2551 Harvard University
WCP: IX I April MCMXCIX
Obsoletes: MMXXVI
Category: Worst Current Practice
Network Working Group S. Bradner
Request for Comments: 2551 Harvard University
WCP: IX I April MCMXCIX
Obsoletes: MMXXVI
Category: Worst Current Practice
The Roman Standards Process -- Revision III
罗马标准过程——第三次修订
Status of this Memo
本备忘录的状况
This document specifies a Roman Worst Current Practices for the Roman Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了罗马人社区目前最差的做法，并要求讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Statement
版权声明
Copyright (C) The Internet Society (MCMXCIX). All Rights Reserved.
版权所有（C）互联网协会（MCMXCIX）。版权所有。
Abstract
摘要
This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.
本备忘录记录了罗马社区用于协议和程序标准化的过程。它定义了标准化过程中的各个阶段、在各个阶段之间移动文档的要求以及在此过程中使用的文档类型。它还解决了与标准过程相关的知识产权和版权问题。
Table of Contents
目录
I. INTRODUCTION................................................III
I.I Roman Standards.......................................III
I.II The Roman Standards Process...........................III
I.III Organization of This Document..........................VI
II. ROMAN STANDARDS-RELATED PUBLICATIONS.........................VI
II.I Requests for Comments (RFCs)...........................VI
II.II Roman-Drafts.........................................VIII
III ROMAN STANDARD SPECIFICATIONS................................IX
III.I Technical Specification (TS)...........................IX
III.II Applicability Statement (AS)...........................IX
III.III Requirement Levels..................................... X
IV. THE ROMAN STANDARDS TRACK....................................XI
IV.I Standards Track Maturity Levels.......................XII
IV.I.I Proposed Standard.....................................XII
IV.I.II Draft Standard.......................................XIII
IV.I.III Roman Standard........................................XIV
IV.II Non-Standards Track Maturity Levels...................XIV
IV.II.I Experimental..........................................XIV
IV.II.II Informational..........................................XV
IV.II.III Procedures for Experimental and Informational RFCs.....XV
IV.II.IV Historic..............................................XVI
I. INTRODUCTION................................................III
I.I Roman Standards.......................................III
I.II The Roman Standards Process...........................III
I.III Organization of This Document..........................VI
II. ROMAN STANDARDS-RELATED PUBLICATIONS.........................VI
II.I Requests for Comments (RFCs)...........................VI
II.II Roman-Drafts.........................................VIII
III ROMAN STANDARD SPECIFICATIONS................................IX
III.I Technical Specification (TS)...........................IX
III.II Applicability Statement (AS)...........................IX
III.III Requirement Levels..................................... X
IV. THE ROMAN STANDARDS TRACK....................................XI
IV.I Standards Track Maturity Levels.......................XII
IV.I.I Proposed Standard.....................................XII
IV.I.II Draft Standard.......................................XIII
IV.I.III Roman Standard........................................XIV
IV.II Non-Standards Track Maturity Levels...................XIV
IV.II.I Experimental..........................................XIV
IV.II.II Informational..........................................XV
IV.II.III Procedures for Experimental and Informational RFCs.....XV
IV.II.IV Historic..............................................XVI
V. Worst Current Practice (WCP) RFCs............................XVI
V.I WCP Review Process...................................XVII
VI. THE ROMAN STANDARDS PROCESS................................XVIII
VI.I Standards Actions...................................XVIII
VI.I.I Initiation of Action................................XVIII
VI.I.II RESG Review and Approval............................XVIII
VI.I.III Publication...........................................XIX
VI.II Advancing in the Standards Track...................... XX
VI.III Revising a Standard...................................XXI
VI.IV Retiring a Standard...................................XXI
VI.V Conflict Resolution and Appeals......................XXII
VI.V.I Working Group Disputes...............................XXII
VI.V.II Process Failures....................................XXIII
VI.V.III Questions of Applicable Procedure...................XXIII
VI.V.IV Appeals Procedure....................................XXIV
VII. EXTERNAL STANDARDS AND SPECIFICATIONS......................XXIV
VII.I Use of External Specifications........................XXV
VII.I.I Incorporation of an Open Standard.....................XXV
VII.I.II Incorporation of a Other Specifications...............XXV
VII.I.III Assumption...........................................XXVI
VIII. NOTICES AND RECORD KEEPING................................XXVI
IX. VARYING THE PROCESS.......................................XXVII
IX.I The Variance Procedure..............................XXVII
IX.II Exclusions.........................................XXVIII
X. INTELLECTUAL PROPERTY RIGHTS.............................XXVIII
X.I. General Policy.....................................XXVIII
X.II Confidentiality Obligations..........................XXIX
X.III Rights and Permissions...............................XXIX
X.III.I All Contributions....................................XXIX
X.III.II Standards Track Documents.............................XXX
X.III.III Determination of Reasonable and
Non-discriminatory Terms.............................XXXI
X.IV. Notices..............................................XXXI
XI. ACKNOWLEDGMENTS........................................XXXIII
XII. SECURITY CONSIDERATIONS................................XXXIII
XIII. REFERENCES..............................................XXXIV
XIV. DEFINITIONS OF TERMS....................................XXXIV
XV. AUTHOR'S ADDRESS.........................................XXXV
APPENDIX A: GLOSSARY OF ACRONYMS..............................XXXVI
Full Copyright Statement.....................................XXXVII
V. Worst Current Practice (WCP) RFCs............................XVI
V.I WCP Review Process...................................XVII
VI. THE ROMAN STANDARDS PROCESS................................XVIII
VI.I Standards Actions...................................XVIII
VI.I.I Initiation of Action................................XVIII
VI.I.II RESG Review and Approval............................XVIII
VI.I.III Publication...........................................XIX
VI.II Advancing in the Standards Track...................... XX
VI.III Revising a Standard...................................XXI
VI.IV Retiring a Standard...................................XXI
VI.V Conflict Resolution and Appeals......................XXII
VI.V.I Working Group Disputes...............................XXII
VI.V.II Process Failures....................................XXIII
VI.V.III Questions of Applicable Procedure...................XXIII
VI.V.IV Appeals Procedure....................................XXIV
VII. EXTERNAL STANDARDS AND SPECIFICATIONS......................XXIV
VII.I Use of External Specifications........................XXV
VII.I.I Incorporation of an Open Standard.....................XXV
VII.I.II Incorporation of a Other Specifications...............XXV
VII.I.III Assumption...........................................XXVI
VIII. NOTICES AND RECORD KEEPING................................XXVI
IX. VARYING THE PROCESS.......................................XXVII
IX.I The Variance Procedure..............................XXVII
IX.II Exclusions.........................................XXVIII
X. INTELLECTUAL PROPERTY RIGHTS.............................XXVIII
X.I. General Policy.....................................XXVIII
X.II Confidentiality Obligations..........................XXIX
X.III Rights and Permissions...............................XXIX
X.III.I All Contributions....................................XXIX
X.III.II Standards Track Documents.............................XXX
X.III.III Determination of Reasonable and
Non-discriminatory Terms.............................XXXI
X.IV. Notices..............................................XXXI
XI. ACKNOWLEDGMENTS........................................XXXIII
XII. SECURITY CONSIDERATIONS................................XXXIII
XIII. REFERENCES..............................................XXXIV
XIV. DEFINITIONS OF TERMS....................................XXXIV
XV. AUTHOR'S ADDRESS.........................................XXXV
APPENDIX A: GLOSSARY OF ACRONYMS..............................XXXVI
Full Copyright Statement.....................................XXXVII
I. INTRODUCTION
一、导言
This memo documents the process currently used by the Roman community for the standardization of protocols and procedures. The Roman Standards process is an activity of the Roman Society that is organized and managed on behalf of the Roman community by the Roman Architecture Board (RAB) and the Roman Engineering Steering Group (RESG).
本备忘录记录了罗马社区目前用于协议和程序标准化的过程。罗马标准程序是罗马社会的一项活动，由罗马建筑委员会（RAB）和罗马工程指导小组（RESG）代表罗马社区组织和管理。
I.I Roman Standards
一、罗马标准
The Roman, a loosely-organized international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Roman Standards. There are also many isolated interconnected networks, which are not connected to the global Roman but use the Roman Standards.
Roman是一个松散组织的自治互联网络国际合作组织，通过自愿遵守Roman标准定义的开放协议和程序，支持主机到主机的通信。还有许多孤立的互联网络，它们没有连接到全球Roman，而是使用Roman标准。
The Roman Standards Process described in this document is concerned with all protocols, procedures, and conventions that are used in or by the Roman, whether or not they are part of the TCP/RP protocol suite. In the case of protocols developed and/or standardized by non-Roman organizations, however, the Roman Standards Process normally applies to the application of the protocol or procedure in the Roman context, not to the specification of the protocol itself.
本文件中描述的罗马标准流程涉及罗马人或罗马人使用的所有协议、程序和约定，无论它们是否属于TCP/RP协议套件的一部分。然而，对于非罗马组织制定和/或标准化的协议，罗马标准流程通常适用于协议或程序在罗马环境中的应用，而不是协议本身的规范。
In general, a Roman Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Roman.
一般来说，罗马标准是一种稳定且易于理解的规范，具有技术能力，具有多个独立且可互操作的实现，具有丰富的操作经验，享有重要的公众支持，并且在罗马标准的某些或所有部分都很有用。
I.II The Roman Standards Process
I.II罗马标准程序
In outline, the process of creating a Roman Standard is straightforward: a specification undergoes a period of development and several iterations of review by the Roman community and revision based upon experience, is adopted as a Standard by the appropriate body (see below), and is published. In practice, the process is more complicated, due to (I) the difficulty of creating specifications of high technical quality; (II) the need to consider the interests of all of the affected parties; (III) the importance of establishing widespread community consensus; and (IV) the difficulty of evaluating the utility of a particular specification for the Roman community.
总而言之，创建罗马标准的过程很简单：规范经过一段时间的开发和罗马社区的多次审查，并根据经验进行修订，由适当的机构作为标准采用（见下文），然后发布。在实践中，该过程更为复杂，因为（I）难以制定高技术质量的规范；（ii）需要考虑所有受影响方的利益；（三） 建立广泛的社会共识的重要性；（IV）评估特定规范对罗马社区的效用的困难。
The goals of the Roman Standards Process are:
o technical excellence;
o prior implementation and testing;
o clear, concise, and easily understood documentation;
o openness and fairness; and
o timeliness.
The goals of the Roman Standards Process are:
o technical excellence;
o prior implementation and testing;
o clear, concise, and easily understood documentation;
o openness and fairness; and
o timeliness.
The procedures described in this document are designed to be fair, open, and objective; to reflect existing (proven) practice; and to be flexible.
本文件中描述的程序旨在公平、公开和客观；反映现有（经验证的）实践；而且要灵活。
o These procedures are intended to provide a fair, open, and objective basis for developing, evaluating, and adopting Roman Standards. They provide ample opportunity for participation and comment by all interested parties. At each stage of the standardization process, a specification is repeatedly discussed and its merits debated in open meetings and/or public electronic mailing lists, and it is made available for review via world-wide on-line directories.
o 这些程序旨在为制定、评估和采用罗马标准提供公平、公开和客观的基础。它们为所有相关方的参与和评论提供了充分的机会。在标准化过程的每个阶段，规范都会在公开会议和/或公开电子邮件列表中反复讨论，讨论其优点，并通过全球在线目录进行审查。
o These procedures are explicitly aimed at recognizing and adopting generally-accepted practices. Thus, a candidate specification must be implemented and tested for correct operation and interoperability by multiple independent parties and utilized in increasingly demanding environments, before it can be adopted as a Roman Standard.
o 这些程序明确旨在承认和采用普遍接受的做法。因此，候选规范必须由多个独立方实施并测试其正确的操作和互操作性，并在要求越来越高的环境中使用，然后才能作为罗马标准采用。
o These procedures provide a great deal of flexibility to adapt to the wide variety of circumstances that occur in the standardization process. Experience has shown this flexibility to be vital in achieving the goals listed above.
o 这些程序提供了很大的灵活性，以适应标准化过程中出现的各种情况。经验表明，这种灵活性对于实现上述目标至关重要。
The goal of technical competence, the requirement for prior implementation and testing, and the need to allow all interested parties to comment all require significant time and effort. On the other hand, today's rapid development of networking technology demands timely development of standards. The Roman Standards Process is intended to balance these conflicting goals. The process is believed to be as short and simple as possible without sacrificing technical excellence, thorough testing before adoption of a standard, or openness and fairness.
技术能力的目标、预先实施和测试的要求以及允许所有相关方发表意见的需要都需要大量的时间和精力。另一方面，当今网络技术的快速发展要求及时制定标准。罗马标准程序旨在平衡这些相互冲突的目标。该过程被认为是尽可能短和简单的，不会牺牲技术优势、采用标准前的彻底测试或公开性和公平性。
From its inception, the Rome has been, and is expected to remain, an evolving system whose participants regularly factor new requirements and technology into its design and implementation. Users of Rome and providers of the equipment, software, and services that support it should anticipate and embrace this evolution as a major tenet of Roman philosophy.
从一开始，罗马系统就一直是一个不断发展的系统，并且预计将继续是一个不断发展的系统，其参与者定期将新的需求和技术纳入其设计和实施中。罗马的用户和支持它的设备、软件和服务提供商应该预见并接受这一演变，将其作为罗马哲学的一项主要原则。
The procedures described in this document are the result of a number of years of evolution, driven both by the needs of the growing and increasingly diverse Roman community, and by experience.
本文件中描述的程序是多年发展的结果，受不断增长和日益多样化的罗马社区的需求以及经验的推动。
I.III Organization of This Document
一、本文件的组织
Section II describes the publications and archives of the Roman Standards Process. Section III describes the types of Roman standard specifications. Section IV describes the Roman standards specifications track. Section V describes Worst Current Practice RFCs. Section VI describes the process and rules for Roman standardization. Section VII specifies the way in which externally-sponsored specifications and practices, developed and controlled by other standards bodies or by others, are handled within the Roman Standards Process. Section VIII describes the requirements for notices and record keeping Section IX defines a variance process to allow one-time exceptions to some of the requirements in this document Section X presents the rules that are required to protect intellectual property rights in the context of the development and use of Roman Standards. Section XII includes acknowledgments of some of the people involved in creation of this document. Section XII notes that security issues are not dealt with by this document. Section XII contains a list of numeral references. Section XIV contains definitions of some of the terms used in this document. Section XV lists the author's email and postal addresses. Appendix A contains a list of frequently-used acronyms.
第二节描述了罗马标准过程的出版物和档案。第三节描述了罗马标准规范的类型。第四节介绍了罗马标准规范轨道。第五节描述了最差的当前实践RFC。第六节描述了罗马标准化的过程和规则。第七节规定了由其他标准机构或其他方制定和控制的外部赞助规范和实践在罗马标准流程中的处理方式。第八节描述了通知和记录保存的要求。第九节定义了允许对本文件中某些要求进行一次性例外的变更流程。第十节介绍了在制定和使用罗马标准时保护知识产权所需的规则。第十二节包括对参与创建本文件的部分人员的确认。第十二节指出，本文件不涉及安全问题。第十二节包含数字参考列表。第十四节包含本文件中使用的一些术语的定义。第十五节列出了作者的电子邮件和邮政地址。附录A列出了常用的缩略语。
II. Roman STANDARDS-RELATED PUBLICATIONS
二,。罗马标准相关出版物
II.I Requests for Comments (RFCs)
二、 一、征求意见书（RFC）
Each distinct version of a Roman standards-related specification is published as part of the "Request for Comments" (RFC) document series. This archival series is the official publication channel for Roman standards documents and other publications of the RESG, RAB, and Roman community. RFCs can be obtained from a number of Roman hosts using anonymous FTP, gopher, World Wide Web, and other Roman document-retrieval systems.
罗马标准相关规范的每个不同版本均作为“征求意见”（RFC）文件系列的一部分发布。本档案系列是罗马标准文件和RESG、RAB和罗马社区其他出版物的官方出版渠道。可以使用匿名FTP、gopher、万维网和其他罗马文档检索系统从许多罗马主机上获取RFC。
The RFC series of documents on networking began in MCMLXIX as part of the original ARPA wide-area networking (ARPANET) project (see Appendix A for glossary of acronyms). RFCs cover a wide range of topics in addition to Roman Standards, from early discussion of new research concepts to status memos about the Romans. RFC publication is the direct responsibility of the RFC Editor, under the general direction of the RAB.
关于网络的RFC系列文件始于MCMLXIX，作为原始ARPA广域网络（ARPANET）项目的一部分（首字母缩写词词汇表见附录A）。RFC除了罗马人的标准外，还涵盖了广泛的主题，从新研究概念的早期讨论到罗马人的现状备忘录。RFC出版由RFC编辑在RAB的总体指导下直接负责。
The rules for formatting and submitting an RFC are defined in [V]. Every RFC is available in ASCII text. Some RFCs are also available in other formats. The other versions of an RFC may contain material (such as diagrams and figures) that is not present in the ASCII version, and it may be formatted differently.
[V]中定义了RFC的格式和提交规则。每个RFC都有ASCII文本。一些RFC还提供其他格式。RFC的其他版本可能包含ASCII版本中不存在的材料（如图表和图形），并且其格式可能不同。
*********************************************************
* *
* A stricter requirement applies to standards-track *
* specifications: the ASCII text version is the *
* definitive reference, and therefore it must be a *
* complete and accurate specification of the standard, *
* including all necessary diagrams and illustrations. *
* *
*********************************************************
*********************************************************
* *
* A stricter requirement applies to standards-track *
* specifications: the ASCII text version is the *
* definitive reference, and therefore it must be a *
* complete and accurate specification of the standard, *
* including all necessary diagrams and illustrations. *
* *
*********************************************************
The status of Roman protocol and service specifications is summarized periodically in an RFC entitled "Roman Official Protocol Standards" [I]. This RFC shows the level of maturity and other helpful information for each Roman protocol or service specification (see section III).
罗马协议和服务规范的状态在名为“罗马官方协议标准”[I]的RFC中定期总结。此RFC显示了每个Roman协议或服务规范的成熟度级别和其他有用信息（参见第三节）。
Some RFCs document Roman Standards. These RFCs form the 'STD' subseries of the RFC series [IV]. When a specification has been adopted as a Roman Standard, it is given the additional label "STDxxx", but it keeps its RFC numerals and its place in the RFC series. (see section IV.I.III)
一些RFC记录了罗马标准。这些RFC构成RFC系列的“STD”子系列[IV]。当一个规范被采纳为罗马标准时，它会被附加标签“STDxxx”，但它会保留其RFC数字及其在RFC系列中的位置。（见第IV.I.III节）
Some RFCs standardize the results of community deliberations about statements of principle or conclusions about what is the best way to perform some operations or RETF process function. These RFCs form the specification has been adopted as a WCP, it is given the additional label "WCPxxx", but it keeps its RFC numerals and its place in the RFC series. (see section V)
一些RFC标准化了社区讨论的结果，即关于执行某些操作或RETF过程功能的最佳方式的原则声明或结论。这些RFC构成的规范已被作为WCP采用，它被赋予额外的标签“WCPxxx”，但它保留其RFC数字及其在RFC系列中的位置。（见第五节）
Not all specifications of protocols or services for Rome should or will become Roman Standards or WCPs. Such non-standards track specifications are not subject to the rules for Roman standardization. Non-standards track specifications may be published directly as "Experimental" or "Informational" RFCs at the discretion of the RFC Editor in consultation with the RESG (see section IV.II).
并非所有针对罗马的协议或服务规范都应该或将成为罗马标准或WCP。此类非标准轨道规范不受罗马标准化规则的约束。非标准轨道规范可直接发布为“实验性”或“信息性”RFC，由RFC编辑与RESG协商决定（见第IV.II节）。
********************************************************
* *
* It is important to remember that not all RFCs *
* are standards track documents, and that not all *
* standards track documents reach the level of *
* Roman Standard. In the same way, not all RFCs *
* which describe current practices have been given *
* the review and approval to become WCPs. See *
* RFC-MDCCXCVI [VI] for further information. *
* *
********************************************************
********************************************************
* *
* It is important to remember that not all RFCs *
* are standards track documents, and that not all *
* standards track documents reach the level of *
* Roman Standard. In the same way, not all RFCs *
* which describe current practices have been given *
* the review and approval to become WCPs. See *
* RFC-MDCCXCVI [VI] for further information. *
* *
********************************************************
II.II Roman-Drafts
二、 罗马汇票
During the development of a specification, draft versions of the document are made available for informal review and comment by placing them in the RETF's "Roman-Drafts" directory, which is replicated on a number of Roman hosts. This makes an evolving working document readily available to a wide audience, facilitating the process of review and revision.
在制定规范的过程中，通过将文档的草稿版本放在RETF的“Roman Drafts”目录中，可供非正式审查和评论，该目录在许多Roman主机上复制。这使得一份不断演变的工作文件随时可供广大读者查阅，从而促进审查和修订进程。
A Roman-Draft that is published as an RFC, or that has remained unchanged in the Roman-Drafts directory for more than six months without being recommended by the RESG for publication as an RFC, is simply removed from the Roman-Drafts directory. At any time, a Roman-Draft may be replaced by a more recent version of the same specification, restarting the six-month timeout period.
作为RFC发布的罗马草案，或在罗马草案目录中保持不变超过六个月而未被RESG推荐作为RFC发布的罗马草案，只需从罗马草案目录中删除即可。在任何时候，罗马草案可能会被同一规范的最新版本所取代，从而重新启动六个月的超时期限。
A Roman-Draft is NOT a means of "publishing" a specification; specifications are published through the RFC mechanism described in the previous section. Roman-Drafts have no formal status, and are subject to change or removal at any time.
罗马草案不是“发布”规范的手段；规范通过上一节中描述的RFC机制发布。罗马汇票没有正式地位，随时可能更改或删除。
********************************************************
* *
* Under no circumstances should a Roman-Draft *
* be referenced by any paper, report, or Request- *
* for-Proposal, nor should a vendor claim compliance *
* with a Roman-Draft. *
* *
********************************************************
********************************************************
* *
* Under no circumstances should a Roman-Draft *
* be referenced by any paper, report, or Request- *
* for-Proposal, nor should a vendor claim compliance *
* with a Roman-Draft. *
* *
********************************************************
Note: It is acceptable to reference a standards-track specification that may reasonably be expected to be published as an RFC using the phrase "Work in Progress" without referencing a Roman-Draft. This may also be done in a standards track document itself as long as the specification in which the reference is made would stand as a complete and understandable document with or without the reference to the "Work in Progress".
注：可以参考标准轨道规范，该规范可以合理预期将作为RFC发布，使用短语“正在进行的工作”，而不参考罗马草案。这也可以在标准跟踪文件本身中进行，只要所引用的规范是一份完整且可理解的文件，无论是否提及“正在进行的工作”。
III. Roman STANDARD SPECIFICATIONS
三、 罗马标准规范
Specifications subject to the Roman Standards Process fall into one of two categories: Technical Specification (TS) and Applicability Statement (AS).
符合罗马标准流程的规范分为两类：技术规范（TS）和适用性声明（AS）。
III.I Technical Specification (TS)
三、 一、技术规范（TS）
A Technical Specification is any description of a protocol, service, procedure, convention, or format. It may completely describe all of the relevant aspects of its subject, or it may leave one or more parameters or options unspecified. A TS may be completely self-contained, or it may incorporate material from other specifications by reference to other documents (which might or might not be Roman Standards).
技术规范是对协议、服务、程序、惯例或格式的任何描述。它可以完全描述其主题的所有相关方面，也可以不指定一个或多个参数或选项。TS可以是完全独立的，也可以通过参考其他文件（可能是罗马标准，也可能不是罗马标准）纳入其他规范中的材料。
A TS shall include a statement of its scope and the general intent for its use (domain of applicability). Thus, a TS that is inherently specific to a particular context shall contain a statement to that effect. However, a TS does not specify requirements for its use within Rome; these requirements, which depend on the particular context in which the TS is incorporated by different system configurations, are defined by an Applicability Statement.
TS应包括其范围声明和使用的一般意图（适用范围）。因此，本质上特定于特定上下文的TS应包含这样一个声明。但是，TS没有规定在罗马境内使用的要求；这些要求取决于TS由不同系统配置合并的特定环境，由适用性声明定义。
III.II Applicability Statement (AS)
三、 二适用性声明（AS）
An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Roman capability. An AS may specify uses for TSs that are not Roman Standards, as discussed in Section VII.
适用性声明规定了如何以及在什么情况下应用一个或多个TSs来支持特定能力。AS可规定非罗马标准的TSs用途，如第七节所述。
An AS identifies the relevant TSs and the specific way in which they are to be combined, and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented. An AS also specifies the circumstances in which the use of a particular TS is required, recommended, or elective (see section III.III).
AS识别相关的TS和它们组合的具体方式，并且还可以指定必须实现的TS参数或TS协议的子功能的特定值或范围。AS还规定了需要、建议或选择使用特定TS的情况（见第III.III节）。
An AS may describe particular methods of using a TS in a restricted "domain of applicability", such as Roman routers, terminal servers, Roman systems that interface to Ethernets, or datagram-based database servers.
AS可以描述在受限的“适用域”中使用TS的特定方法，例如罗马路由器、终端服务器、与以太网接口的罗马系统或基于数据报的数据库服务器。
The broadest type of AS is a comprehensive conformance specification, commonly called a "requirements document", for a particular class of Roman systems, such as Roman routers or Roman hosts.
AS最广泛的类型是一种综合一致性规范，通常称为“需求文档”，用于特定类别的罗马系统，如罗马路由器或罗马主机。
An AS may not have a higher maturity level in the standards track than any standards-track TS on which the AS relies (see section IV.I). For example, a TS at Draft Standard level may be referenced by an AS at the Proposed Standard or Draft Standard level, but not by an AS at the Standard level.
AS在标准轨道中的成熟度不得高于AS所依赖的任何标准轨道TS（见第IV.I节）。例如，标准草案级别的TS可以由拟定标准或标准草案级别的AS引用，但不能由标准级别的AS引用。
III.III Requirement Levels
三、 三、需求水平
An AS shall apply one of the following "requirement levels" to each of the TSs to which it refers:
AS应将以下“需求水平”之一应用于其所指的每个TSs：
(a) Required: Implementation of the referenced TS, as specified by the AS, is required to achieve minimal conformance. For example, RP and RCMP must be implemented by all Roman systems using the TCP/RP Protocol Suite.
(a) 必需：as规定的引用TS的实现是实现最低合规性所必需的。例如，RP和RCMP必须由使用TCP/RP协议套件的所有罗马系统实现。
(b) Recommended: Implementation of the referenced TS is not required for minimal conformance, but experience and/or generally accepted technical wisdom suggest its desirability in the domain of applicability of the AS. Vendors are strongly encouraged to include the functions, features, and protocols of Recommended TSs in their products, and should omit them only if the omission is justified by some special circumstance. For example, the TELNET protocol should be implemented by all systems that would benefit from remote access.
(b) 建议：最低合规性不需要实施参考TS，但经验和/或普遍接受的技术智慧表明其在AS适用领域的可取性。强烈鼓励供应商在其产品中包含推荐TSs的功能、特性和协议，并且只有在某些特殊情况下有理由省略时才应省略这些功能、特性和协议。例如，TELNET协议应该由所有受益于远程访问的系统实现。
(c) Elective: Implementation of the referenced TS is optional within the domain of applicability of the AS; that is, the AS creates no explicit necessity to apply the TS. However, a particular vendor may decide to implement it, or a particular user may decide that it is a necessity in a specific environment. For example, the DECNET MIB could be seen as valuable in an environment where the DECNET protocol is used.
(c) 可选：在AS的适用范围内，参考TS的实施是可选的；也就是说，AS不产生应用TS的明确必要性。但是，特定供应商可能决定实施TS，或者特定用户可能决定在特定环境中实施TS。例如，在使用DECNET协议的环境中，DECNET MIB可以被视为有价值的。
As noted in section IV.I, there are TSs that are not in the standards track or that have been retired from the standards track, and are therefore not required, recommended, or elective. Two additional "requirement level" designations are available for these TSs:
如第IV.I节所述，有些TSs不在标准轨道上，或者已经退出标准轨道，因此不需要、不推荐或不可选。这些TSs还有两个额外的“需求级别”名称：
(d) Limited Use: The TS is considered to be appropriate for use only in limited or unique circumstances. For example, the usage of a protocol with the "Experimental" designation should generally be limited to those actively involved with the experiment.
(d) 有限使用：TS仅适用于有限或独特的情况。例如，带有“实验”名称的协议的使用通常应限于积极参与实验的人员。
(e) Not Recommended: A TS that is considered to be inappropriate for general use is labeled "Not Recommended". This may be because of its limited functionality, specialized nature, or historic status.
(e) 不推荐：被认为不适合一般使用的TS标有“不推荐”。这可能是因为其功能有限、专业性或历史地位。
Although TSs and ASs are conceptually separate, in practice a standards-track document may combine an AS and one or more related TSs. For example, Technical Specifications that are developed specifically and exclusively for some particular domain of applicability, e.g., for mail server hosts, often contain within a single specification all of the relevant AS and TS information. In such cases, no useful purpose would be served by deliberately distributing the information among several documents just to preserve the formal AS/TS distinction. However, a TS that is likely to apply to more than one domain of applicability should be developed in a modular fashion, to facilitate its incorporation by multiple ASs.
虽然TSs和ASs在概念上是分开的，但在实践中，标准跟踪文档可以将AS和一个或多个相关TSs结合起来。例如，专门为某些特定适用领域（例如，邮件服务器主机）制定的技术规范通常在单个规范中包含所有相关AS和TS信息。在这种情况下，故意在多个文件之间分发信息，只是为了保留正式的AS/TS区别，是没有任何用处的。然而，可能应用于多个适用领域的TS应以模块化方式开发，以便于多个ASs将其合并。
The "Official Protocol Standards" RFC (STD I) lists a general requirement level for each TS, using the nomenclature defined in this section. This RFC is updated periodically. In many cases, more detailed descriptions of the requirement levels of particular protocols and of individual features of the protocols will be found in appropriate ASs.
“官方协议标准”RFC（STD I）使用本节定义的术语列出了每个TS的一般要求级别。此RFC定期更新。在许多情况下，在适当的ASs中可以找到特定协议的需求级别和协议的各个特性的更详细描述。
IV. THE ROMAN STANDARDS TRACK
四、 罗马标准赛道
Specifications that are intended to become Roman Standards evolve through a set of maturity levels known as the "standards track". These maturity levels -- "Proposed Standard", "Draft Standard", and "Standard" -- are defined and discussed in section IV.I. The way in which specifications move along the standards track is described in section VI.
旨在成为罗马标准的规范通过一组称为“标准轨道”的成熟度级别进行演变。这些成熟度水平——“拟定标准”、“标准草案”和“标准”——在第IV.I节中进行了定义和讨论。规范沿着标准轨道移动的方式见第六节。
Even after a specification has been adopted as a Roman Standard, further evolution often occurs based on experience and the recognition of new requirements. The nomenclature and procedures of Roman standardization provide for the replacement of old Roman
即使在一个规范被采纳为罗马标准之后，进一步的发展也往往基于经验和对新需求的认可。罗马标准化的命名法和程序规定了旧罗马标准的替换
Standards with new ones, and the assignment of descriptive labels to indicate the status of "retired" Roman Standards. A set of maturity levels is defined in section IV.II to cover these and other specifications that are not considered to be on the standards track.
具有新标准的标准，以及指定描述性标签，以表明“退役”罗马标准的状态。第IV.II节定义了一组成熟度水平，以涵盖这些规范和其他不被视为符合标准的规范。
IV.I Standards Track Maturity Levels
四、 我跟踪成熟度水平
Roman specifications go through stages of development, testing, and acceptance. Within the Roman Standards Process, these stages are formally labeled "maturity levels".
罗马规范经历了开发、测试和验收阶段。在罗马标准流程中，这些阶段被正式标记为“成熟度级别”。
This section describes the maturity levels and the expected characteristics of specifications at each level.
本节描述了成熟度级别和每个级别规范的预期特征。
IV.I.I Proposed Standard
四、 一、我提出的标准
The entry-level maturity for the standards track is "Proposed Standard". A specific action by the RESG is required to move a specification onto the standards track at the "Proposed Standard" level.
标准轨道的入门级成熟度为“拟议标准”。要求RESG采取具体行动，在“拟定标准”级别将规范纳入标准轨道。
A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances.
提议的标准规范通常是稳定的，解决了已知的设计选择，被认为是很好理解的，已经得到了重要的社区审查，并且似乎有足够的社区兴趣被认为是有价值的。然而，进一步的经验可能会导致规范在发展之前发生变化，甚至收回。
Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation.
通常，将规范指定为拟定标准既不需要实施也不需要操作经验。然而，这样的经验是非常可取的，并且通常会代表一个支持提议的标准指定的有力论据。
The RESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Roman protocols or that specifies behavior that may have significant operational impact on the Roman.
在授予实质性影响核心Roman协议或规定可能对Roman协议产生重大运营影响的行为的规范拟议标准状态之前，RESG可能需要实施和/或运营经验。
A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the RESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions.
提议的标准在其要求方面不应有已知的技术遗漏。然而，即使存在已知的技术遗漏，当规范被认为是有用和必要的（及时的）时，RESG可以放弃该要求，以允许规范发展到提议的标准状态。
Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended.
实施者应将提议的标准视为不成熟的规范。为了获得经验并验证、测试和澄清规范，需要实施这些规范。但是，由于如果发现问题或确定更好的解决方案，可能会更改拟议标准的内容，因此不建议将此类标准的实施部署到对中断敏感的环境中。
IV.I.II Draft Standard
四、 I.II标准草案
A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful.
一个规范，其中至少有两个来自不同代码库的独立且可互操作的实现已经开发出来，并且已经获得了足够的成功操作经验，可以提升到“标准草案”级别。在本节中，“可互操作”是指在功能上等同或可互换的系统或过程组件。如果实施需要专利技术或其他受控技术，则单独实施还必须是单独实施许可过程的结果。标准草案的提升是状态上的一个重大进步，表明人们坚信规范是成熟的，将是有用的。
The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed.
对至少两个独立且可互操作的实现的要求适用于规范的所有选项和特性。如果一个或多个选项或功能尚未在至少两个可互操作的实现中演示，则只有在删除这些选项或功能的情况下，规范才能升级到标准草案级别。
The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Roman 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 VI)
工作组主席负责记录使规范符合草案或罗马标准状态的具体实现，以及关于测试这些实现的互操作性的文档。文档必须包括关于每个选项和功能的支持信息。该文件应与协议行动请求一起提交给区域总监。（见第六节）
A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. A 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.
无论是在语义上，还是作为开发实现的基础上，标准草案都必须被充分理解并被认为是相当稳定的。标准草案可能仍然需要更多或更广泛的现场经验，因为在生产环境中大规模使用时，基于标准草案规范的实施可能会表现出不可预见的行为。
A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption sensitive environment.
标准草案通常被视为最终规范，修改可能只是为了解决遇到的具体问题。在大多数情况下，供应商将标准草案的实现部署到对中断敏感的环境中是合理的。
IV.I.III Roman Standard
四、 I.III罗马标准
A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Roman Standard level. A Roman Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Roman community.
已获得重大实施和成功运营经验的规范可提升至罗马标准水平。罗马标准（可以简单地称为标准）的特点是技术高度成熟，并且普遍认为特定的协议或服务为罗马社区提供了重大利益。
A specification that reaches the status of Standard is assigned numerals in the STD series while retaining its RFC numerals.
达到标准状态的规范在STD系列中分配数字，同时保留其RFC数字。
IV.II Non-Standards Track Maturity Levels
四、 II非标准跟踪成熟度水平
Not every specification is on the standards track. A specification may not be intended to be a Roman Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Roman Standard, or have otherwise fallen into disuse or disfavor.
并非所有规范都符合标准。规范可能不是罗马标准，也可能是最终标准化，但尚未进入标准轨道。规范可能已被较新的罗马标准取代，或已被废弃或不受欢迎。
Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Roman Standards in any sense.
不在标准轨道上的规范标有三个“偏离轨道”的成熟度级别之一：“实验性”、“信息性”或“历史性”。带有这些标签的文件在任何意义上都不是罗马标准。
IV.II.I Experimental
四、 二、一、实验性
The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Roman technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Roman research effort (e.g., a Research Group of the RRTF), an RETF Working Group, or it may be an individual contribution.
“实验”名称通常表示作为某些研究或开发工作一部分的规范。此类规范发布用于罗马技术界的一般信息，并作为工作的档案记录，仅需考虑编辑因素，并验证是否与标准过程进行了充分协调（见下文）。实验规范可以是有组织的罗马研究工作（例如，RRTF的研究小组）、RETF工作组的成果，也可以是个人贡献。
IV.II.II Informational
四、 二、信息
An "Informational" specification is published for the general information of the Roman community, and does not represent a Roman community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section IV.II.III).
“信息”规范是为罗马社区的一般信息而发布的，并不代表罗马社区的共识或建议。信息性指定旨在及时发布来自许多来源的范围非常广泛的负责任的信息性文件，仅需考虑编辑因素，并验证是否与标准过程进行了充分协调（见第四节第二节第三节）。
Specifications that have been prepared outside of the Roman community and are not incorporated into the Roman Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor.
在罗马社区之外编制的规范，未根据第10节的任何规定纳入罗马标准过程，经业主许可和RFC编辑同意，可作为信息RFC发布。
IV.II.III Procedures for Experimental and Informational RFCs
四、 II.III实验和信息RFC程序
Unless they are the result of RETF Working Group action, documents intended to be published with Experimental or Informational status should be submitted directly to the RFC Editor. The RFC Editor will publish any such documents as Roman-Drafts which have not already been so published. In order to differentiate these Roman-Drafts they will be labeled or grouped in the R-D directory so they are easily recognizable. The RFC Editor will wait two weeks after this publication for comments before proceeding further. The RFC Editor is expected to exercise his or her judgment concerning the editorial suitability of a document for publication with Experimental or Informational status, and may refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Roman activity or falls below the technical and/or editorial standard for RFCs.
除非是RETF工作组行动的结果，否则拟以实验或信息状态发布的文件应直接提交给RFC编辑。RFC编辑将以罗马草稿的形式发布尚未发布的任何此类文件。为了区分这些罗马草稿，它们将在R-D目录中标记或分组，以便易于识别。RFC编辑将在本出版物发布后等待两周，以征求意见，然后再继续。RFC编辑应就试验性或信息性文件的编辑适用性作出判断，并可拒绝发布RFC编辑专家认为与罗马活动无关或低于RFC技术和/或编辑标准的文件。
To ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Roman Standards Process, the RESG and the RFC Editor have agreed that the RFC Editor will refer to the RESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the RETF community. The RESG shall review such a referred document within a reasonable period of time, and recommend either that it be published as originally submitted or referred to the RETF as a contribution to the Roman Standards Process.
为确保非标准轨道实验和信息名称不会被滥用，以规避罗马标准流程，RESG和RFC编辑同意，RFC编辑将参考RESG提交的任何实验或信息发布文件，RFC编辑认为，可能与RETF社区内正在完成或预期完成的工作有关。RESG应在合理的时间内审查此类参考文件，并建议将其作为最初提交的文件发布，或作为对罗马标准流程的贡献提交给RETF。
If (a) the RESG recommends that the document be brought within the RETF and progressed within the RETF context, but the author declines to do so, or (b) the RESG considers that the document proposes
如果（a）RESG建议将该文件纳入RETF并在RETF环境下进行，但作者拒绝这样做，或（b）RESG认为该文件建议
something that conflicts with, or is actually inimical to, an established RETF effort, the document may still be published as an Experimental or Informational RFC. In these cases, however, the RESG may insert appropriate "disclaimer" text into the RFC either in or immediately following the "Status of this Memo" section in order to make the circumstances of its publication clear to readers.
与已建立的RETF工作相冲突或实际上不利于RETF工作的内容，该文档仍可能作为实验性或信息性RFC发布。但是，在这些情况下，RESG可以在RFC中插入适当的“免责声明”文本，或者在“本备忘录的状态”部分中插入，或者紧跟在“本备忘录的状态”部分之后，以使读者清楚其发布的情况。
Documents proposed for Experimental and Informational RFCs by RETF Working Groups go through RESG review. The review is initiated using the process described in section VI.I.I.
RETF工作组为实验性和信息性RFC提出的文件将通过RESG审查。使用第VI.I.I节中描述的流程启动审查。
IV.II.IV Historic
四、 二、四、历史性
A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.)
已被较新规范取代或因任何其他原因被视为过时的规范被指定为“历史”级别。（纯粹主义者认为这个词应该是“历史的”；然而，在这一点上，“历史的”的用法是历史的。）
Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section VII.)
注：标准轨道规范通常不得依赖于成熟度较低的其他标准轨道规范或非标准轨道规范，而非其他标准机构的参考规范。（见第七节。）
V. WORST CURRENT PRACTICE (WCP) RFCs
五、最差现行做法（WCP）RFC
The WCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A WCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the RETF community can define and ratify the community's worst current thinking on a statement of principle or on what is believed to be the worst way to perform some operations or RETF process function.
RFC系列的WCP子系列旨在使实践和社区讨论结果标准化。WCP文件遵循与标准跟踪文件相同的基本程序集，因此，RETF社区可以通过该文件定义和批准社区在原则声明或被认为是执行某些操作或RETF过程功能的最差方式上的最差当前想法。
Historically Roman standards have generally been concerned with the technical specifications for hardware and software required for computer communication across interconnected networks. However, since Rome itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of Rome follow some common guidelines for policies and operations. While these guidelines are generally different in scope and style from protocol standards, their establishment needs a similar process for consensus building.
历史上，罗马标准通常涉及互联网络中计算机通信所需的硬件和软件的技术规范。然而，由于罗马本身由各种各样的组织运营的网络组成，具有不同的目标和规则，良好的用户服务要求罗马的运营商和管理员遵循一些共同的策略和操作指南。虽然这些指南的范围和风格与议定书标准一般不同，但它们的制定需要一个类似的建立共识的过程。
While it is recognized that entities such as the RAB and RESG are composed of individuals who may participate, as individuals, in the technical work of the RETF, it is also recognized that the entities
虽然公认RAB和RESG等实体由个人组成，他们可以作为个人参与RETF的技术工作，但也公认实体
themselves have an existence as leaders in the community. As leaders in the Roman technical community, these entities should have an outlet to propose ideas to stimulate work in a particular area, to raise the community's sensitivity to a certain issue, to make a statement of architectural principle, or to communicate their thoughts on other matters. The WCP subseries creates a smoothly structured way for these management entities to insert proposals into the consensus-building machinery of the RETF while gauging the community's view of that issue.
他们自己作为社区的领导者而存在。作为罗马技术社区的领导者，这些实体应该有一个渠道来提出想法，以刺激特定领域的工作，提高社区对某个问题的敏感性，陈述建筑原则，或就其他事项交流他们的想法。WCP子系列为这些管理实体创建了一种结构流畅的方式，在评估社区对该问题的看法的同时，将提案插入RETF的共识构建机制。
Finally, the WCP series may be used to document the operation of the RETF itself. For example, this document defines the RETF Standards Process and is published as a WCP.
最后，WCP系列可用于记录RETF本身的操作。例如，本文档定义了RETF标准流程，并作为WCP发布。
V.I WCP Review Process
V.I WCP审查流程
Unlike standards-track documents, the mechanisms described in WCPs are not well suited to the phased roll-in nature of the three stage standards track and instead generally only make sense for full and immediate instantiation.
与标准跟踪文档不同，WCPs中描述的机制不太适合三阶段标准跟踪的阶段性滚动，而通常只适用于完整和即时的实例化。
The WCP process is similar to that for proposed standards. The WCP is submitted to the RESG for review, (see section VI.I.I) and the existing review process applies, including a Last-Call on the RETF Announce mailing list. However, once the RESG has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical approval of the RETF.
WCP流程与拟议标准类似。WCP提交给RESG审查（见第VI.I.I节），现有审查流程适用，包括RETF公告邮件列表上的最后一次通话。但是，一旦RESG批准了该文件，该过程将结束并发布该文件。由此产生的文件被视为具有RETF的技术批准。
Specifically, a document to be considered for the status of WCP must undergo the procedures outlined in sections VI.I, and VI.IV of this document. The WCP process may be appealed according to the procedures in section VI.V.
具体而言，要考虑WCP状态的文件必须遵循本文件第六节第一节和第六节第四节中概述的程序。可根据第VI.V节中的程序对WCP流程提出上诉。
Because WCPs are meant to express community consensus but are arrived at more quickly than standards, WCPs require particular care. Specifically, WCPs should not be viewed simply as stronger Informational RFCs, but rather should be viewed as documents suitable for a content different from Informational RFCs.
由于WCP旨在表达社区共识，但比标准更快达成，因此WCP需要特别小心。具体而言，WCP不应仅仅被视为更强的信息性RFC，而应被视为适合不同于信息性RFC内容的文档。
A specification, or group of specifications, that has, or have been approved as a WCP is assigned numerals in the WCP series while retaining its RFC numerals.
已被批准或已被批准为WCP的规范或规范组在WCP系列中分配数字，同时保留其RFC数字。
VI. THE ROMAN STANDARDS PROCESS
六、 罗马标准程序
The mechanics of the Roman Standards Process involve decisions of the RESG concerning the elevation of a specification onto the standards track or the movement of a standards-track specification from one maturity level to another. Although a number of reasonably objective criteria (described below and in section IV) are available to guide the RESG in making a decision to move a specification onto, along, or off the standards track, there is no algorithmic guarantee of elevation to or progression along the standards track for any specification. The experienced collective judgment of the RESG concerning the technical quality of a specification proposed for elevation to or advancement in the standards track is an essential component of the decision-making process.
罗马标准过程的机制涉及RESG关于将规范提升到标准轨道或将标准轨道规范从一个成熟度级别移动到另一个成熟度级别的决策。尽管有许多合理客观的标准（如下和第四节所述）可用于指导RESG决定将规范移动到标准轨道上、沿着标准轨道移动或离开标准轨道，但对于任何规范，没有算法保证沿着标准轨道升高或前进。RESG对拟提升至或提升至标准轨道的规范的技术质量进行经验丰富的集体判断是决策过程的重要组成部分。
VI.I Standards Actions
六、 一、标准行动
A "standards action" -- entering a particular specification into, advancing it within, or removing it from, the standards track -- must be approved by the RESG.
“标准行动”——在标准轨道中输入、推进或删除特定规范——必须得到RESG的批准。
VI.I.I Initiation of Action
六、 一、行动的启动
A specification that is intended to enter or advance in the Roman standards track shall first be posted as a Roman-Draft (see section II.II) unless it has not changed since publication as an RFC. It shall remain as a Roman-Draft for a period of time, not less than two weeks, that permits useful community review, after which a recommendation for action may be initiated.
拟进入或推进罗马标准轨道的规范应首先作为罗马草案发布（见第II.II节），除非其作为RFC发布后未发生变化。它应作为罗马草案保留一段时间，不少于两周，以便社区进行有益的审查，之后可提出行动建议。
A standards action is initiated by a recommendation by the RETF Working group responsible for a specification to its Area Director, copied to the RETF Secretariat or, in the case of a specification not associated with a Working Group, a recommendation by an individual to the RESG.
标准行动由负责规范的RETF工作组向其区域总监提出建议，复制给RETF秘书处，或者，如果规范与工作组无关，则由个人向RESG提出建议。
VI.I.II RESG Review and Approval
六、 I.II RESG审查和批准
The RESG shall determine whether or not a specification submitted to it according to section VI.I.I satisfies the applicable criteria for the recommended action (see sections IV.I and IV.II), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended.
RESG应确定根据第VI.I.I节向其提交的规范是否满足建议措施的适用标准（见第IV.I节和第IV.II节），此外，还应确定本规范的技术质量和清晰度是否与本规范推荐的成熟度水平的预期一致。
In order to obtain all of the information necessary to make these determinations, particularly when the specification is considered by the RESG to be extremely important in terms of its potential impact
为了获得做出这些决定所需的所有信息，特别是当RESG认为规范在其潜在影响方面极其重要时
on Rome or on the suite of Roman protocols, the RESG may, at its discretion, commission an independent technical review of the specification.
在罗马或罗马协议套件上，RESG可自行决定委托对规范进行独立技术审查。
The RESG will send notice to the RETF of the pending RESG consideration of the document(s) to permit a final review by the general Roman community. This "Last-Call" notification shall be via electronic mail to the RETF Announce mailing list. Comments on a Last-Call shall be accepted from anyone, and should be sent as directed in the Last-Call announcement.
RESG将向RETF发送待决RESG对文件审议的通知，以允许普通罗马社区进行最终审查。“最后一次呼叫”通知应通过电子邮件发送至RETF公告邮件列表。应接受任何人对最后一次通话的评论，并应按照最后一次通话公告中的指示发送评论。
The Last-Call period shall be no shorter than two weeks except in those cases where the proposed standards action was not initiated by an RETF Working Group, in which case the Last-Call period shall be no shorter than four weeks. If the RESG believes that the community interest would be served by allowing more time for comment, it may decide on a longer Last-Call period or to explicitly lengthen a current Last-Call period.
最后一次通知期不得短于两周，除非拟议的标准行动不是由RETF工作组发起的，在这种情况下，最后一次通知期不得短于四周。如果RESG认为允许更多时间发表评论有助于社区利益，它可以决定更长的最后通话时间或明确延长当前的最后通话时间。
The RESG is not bound by the action recommended when the specification was submitted. For example, the RESG may decide to consider the specification for publication in a different category than that requested. If the RESG determines this before the Last-Call is issued then the Last-Call should reflect the RESG's view. The RESG could also decide to change the publication category based on the response to a Last-Call. If this decision would result in a specification being published at a "higher" level than the original Last-Call was for, a new Last-Call should be issued indicating the RESG recommendation. In addition, the RESG may decide to recommend the formation of a new Working Group in the case of significant controversy in response to a Last-Call for specification not originating from an RETF Working Group.
RESG不受提交规范时建议的操作的约束。例如，RESG可以决定考虑在与请求的不同类别中发布的规范。如果RESG在发出最后一次呼叫之前确定这一点，则最后一次呼叫应反映RESG的观点。RESG还可以根据对上次呼叫的响应来决定更改出版物类别。如果该决定将导致在比最初的最后一次调用“更高”的级别上发布规范，则应发出新的最后一次调用，指示RESG建议。此外，如果因响应非RETF工作组发出的规范要求而产生重大争议，RESG可决定建议成立新的工作组。
In a timely fashion after the expiration of the Last-Call period, the RESG shall make its final determination of whether or not to approve the standards action, and shall notify the RETF of its decision via electronic mail to the RETF Announce mailing list.
在最后一次催缴期结束后，RESG应及时做出是否批准标准行动的最终决定，并应通过电子邮件向RETF公告邮件列表通知RETF其决定。
VI.I.III Publication
六、 I.III出版物
If a standards action is approved, notification is sent to the RFC Editor and copied to the RETF with instructions to publish the specification as an RFC. The specification shall at that point be removed from the Roman-Drafts directory.
如果批准了标准操作，则通知将发送到RFC编辑器，并复制到RETF，说明如何将规范发布为RFC。此时，规范应从罗马草案目录中删除。
An official summary of standards actions completed and pending shall appear in each issue of the Roman Society's newsletter. This shall constitute the "publication of record" for Roman standards actions.
已完成和待定的标准行动的官方摘要应出现在每期罗马社会通讯中。这应构成罗马标准行动的“记录发布”。
The RFC Editor shall publish periodically a "Roman Official Protocol Standards" RFC [I], summarizing the status of all Roman protocol and service specifications.
RFC编辑应定期发布“罗马官方协议标准”RFC[I]，总结所有罗马协议和服务规范的状态。
VI.II Advancing in the Standards Track
六、 二、在标准轨道上前进
The procedure described in section VI.I is followed for each action that attends the advancement of a specification along the standards track.
第VI.I节中描述的程序适用于参与沿着标准轨道推进规范的每个行动。
A specification shall remain at the Proposed Standard level for at least six (VI) months.
规范应保持在拟定标准水平至少六（VI）个月。
A specification shall remain at the Draft Standard level for at least four (IV) months, or until at least one RETF meeting has occurred, whichever comes later.
规范应保持在标准草案水平至少四（IV）个月，或直到至少召开一次RETF会议，以较晚者为准。
These minimum periods are intended to ensure adequate opportunity for community review without severely impacting timeliness. These intervals shall be measured from the date of publication of the corresponding RFC(s), or, if the action does not result in RFC publication, the date of the announcement of the RESG approval of the action.
这些最短期限旨在确保在不严重影响及时性的情况下有足够的机会进行社区审查。这些时间间隔应从相应RFC发布之日起计算，或者，如果行动未导致RFC发布，则从RESG批准行动的公告之日起计算。
A specification may be (indeed, is likely to be) revised as it advances through the standards track. At each stage, the RESG shall determine the scope and significance of the revision to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions are expected, but a significant revision may require that the specification accumulate more experience at its current maturity level before progressing. Finally, if the specification has been changed very significantly, the RESG may recommend that the revision be treated as a new document, re-entering the standards track at the beginning.
随着规范在标准轨道上的推进，它可能（事实上，很可能）被修订。在每个阶段，RESG应确定规范修订的范围和意义，并在必要和适当的情况下修改建议的措施。预计会有小的修订，但重大的修订可能需要规范在其当前成熟度水平上积累更多的经验，然后才能继续进行。最后，如果规范发生了重大变化，RESG可能会建议将修订作为新文件处理，从一开始就重新进入标准轨道。
Change of status shall result in republication of the specification as an RFC, except in the rare case that there have been no changes at all in the specification since the last publication. Generally, desired changes will be "batched" for incorporation at the next level in the standards track. However, deferral of changes to the next standards action on the specification will not always be possible or desirable; for example, an important typographical error, or a technical error that does not represent a change in overall function
状态变更应导致规范作为RFC重新发布，除非自上次发布以来规范中很少发生任何变更。通常，所需的变更将“分批”纳入标准轨道的下一级。然而，将变更推迟到下一个规范标准行动并不总是可行或可取的；例如，一个重要的印刷错误，或者一个不代表整体功能变化的技术错误
of the specification, may need to be corrected immediately. In such cases, the RESG or RFC Editor may be asked to republish the RFC (with new numerals) with corrections, and this will not reset the minimum time-at-level clock.
可能需要立即纠正规范中的错误。在这种情况下，可能会要求RESG或RFC编辑器重新发布带有更正的RFC（带有新数字），这不会重置时钟级别的最短时间。
When a standards-track specification has not reached the Roman Standard level but has remained at the same maturity level for twenty-four (XXIV) months, and every twelve (XII) months thereafter until the status is changed, the RESG shall review the vrability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the RESG shall approve termination or continuation of the development effort, at the same time the RESG shall decide to maintain the specification at the same maturity level or to move it to Historic status. This decision shall be communicated to the RETF by electronic mail to the RETF Announce mailing list to allow the Roman community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort.
如果标准轨道规范未达到罗马标准水平，但在二十四（XXIV）个月内保持相同的到期水平，并且此后每隔十二（XII）个月，直到状态发生变化，RESG应审查负责该规范的标准化工作的可行性和技术的有用性。每次审查后，RESG应批准开发工作的终止或继续，同时RESG应决定将规范保持在相同的成熟度水平或将其移至历史状态。该决定应通过电子邮件发送至RETF公告邮件列表，以使罗马社区有机会发表意见。这项规定的目的不是威胁工作组的合法和积极努力，而是提供一种行政机制来终止垂死的努力。
VI.III Revising a Standard
六、 三修订标准
A new version of an established Roman Standard must progress through the full Roman standardization process as if it were a completely new specification. Once the new version has reached the Standard level, it will usually replace the previous version, which will be moved to Historic status. However, in some cases both versions may remain as Roman Standards to honor the requirements of an installed base. In this situation, the relationship between the previous and the new versions must be explicitly stated in the text of the new version or in another appropriate document (e.g., an Applicability Statement; see section III.II).
已确立的罗马标准的新版本必须经过完整的罗马标准化过程，就像它是一个全新的规范一样。一旦新版本达到标准级别，它通常将取代以前的版本，并将移动到历史状态。然而，在某些情况下，这两个版本可能仍然是罗马标准，以满足安装基础的要求。在这种情况下，必须在新版本文本或其他适当文件（例如适用性声明；见第III.II节）中明确说明以前版本和新版本之间的关系。
VI.IV Retiring a Standard
六、 四、退出标准
As the technology changes and matures, it is possible for a new Standard specification to be so clearly superior technically that one or more existing standards track specifications for the same function should be retired. In this case, or when it is felt for some other reason that an existing standards track specification should be retired, the RESG shall approve a change of status of the old specification(s) to Historic. This recommendation shall be issued with the same Last-Call and notification procedures used for any other standards action. A request to retire an existing standard can originate from a Working Group, an Area Director or some other interested party.
随着技术的变化和成熟，一个新的标准规范可能在技术上具有明显的优势，以至于一个或多个相同功能的现有标准跟踪规范应该失效。在这种情况下，或由于其他原因认为现有标准轨道规范应失效时，RESG应批准将旧规范的状态更改为历史规范。发布本建议时，应采用与任何其他标准行动相同的最后通知和通知程序。撤销现有标准的请求可由工作组、区域主管或其他相关方提出。
VI.V Conflict Resolution and Appeals
六、 五冲突解决和上诉
Disputes are possible at various stages during the RETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved, however there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion. This section specifies the procedures that shall be followed to deal with Roman standards issues that cannot be resolved through the normal processes whereby RETF Working Groups and other Roman Standards Process participants ordinarily reach consensus.
在RETF过程的各个阶段都可能发生争议。这一过程的设计应尽可能使双方达成妥协，并达成真正的共识，但有时即使是最理性和最有知识的人也无法达成一致。为了实现公开和公平的目标，这些冲突必须通过公开审查和讨论的过程来解决。本节规定了处理罗马标准问题时应遵循的程序，这些问题无法通过RETF工作组和其他罗马标准过程参与者通常达成共识的正常过程解决。
VI.V.I Working Group Disputes
六、 V.I工作组争端
An individual (whether a participant in the relevant Working Group or not) may disagree with a Working Group recommendation based on his or her belief that either (a) his or her own views have not been adequately considered by the Working Group, or (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. The first issue is a difficulty with Working Group process; the latter is an assertion of technical error. These two types of disagreement are quite different, but both are handled by the same process of review.
个人（无论是否为相关工作组的参与者）可能不同意工作组的建议，因为他或她认为（a）他或她自己的观点未被工作组充分考虑，或（b）工作组做出了不正确的技术选择，使工作组产品的质量和/或完整性受到重大威胁。第一个问题是工作组程序的困难；后者是技术错误的断言。这两种类型的分歧是完全不同的，但都是通过相同的审查过程来处理的。
A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s), who may involve other members of the Working Group (or the Working Group as a whole) in the discussion.
不同意工作组建议的人应首先与工作组主席讨论该事项，工作组主席可能会让工作组（或整个工作组）的其他成员参与讨论。
If the disagreement cannot be resolved in this way, any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute.
如果无法通过这种方式解决分歧，任何相关方均可提请工作组所在区域的区域总监注意。区域主管应尝试解决争议。
If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the RESG as a whole. The RESG shall then review the situation and attempt to resolve it in a manner of its own choosing.
如果区域总监无法解决分歧，则任何相关方均可向RESG整体提出上诉。然后，RESG应审查情况，并尝试以自己选择的方式解决问题。
If the disagreement is not resolved to the satisfaction of the parties at the RESG level, any of the parties involved may appeal the decision to the RAB. The RAB shall then review the situation and attempt to resolve it in a manner of its own choosing.
如果分歧未能得到解决，且RESG级别的各方均不满意，则任何相关方均可向RAB上诉该决定。然后，RAB应审查情况，并尝试以自己选择的方式解决问题。
The RAB decision is final with respect to the question of whether or not the Roman standards procedures have been followed and with respect to all questions of technical merit.
对于是否遵循罗马标准程序以及所有技术价值问题，RAB的决定是最终决定。
VI.V.II Process Failures
六、 V.II过程故障
This document sets forward procedures required to be followed to ensure openness and fairness of the Roman Standards Process, and the technical vrability of the standards created. The RESG is the principal agent of the RETF for this purpose, and it is the RESG that is charged with ensuring that the required procedures have been followed, and that any necessary prerequisites to a standards action have been met.
本文件规定了确保罗马标准过程的公开性和公平性以及所制定标准的技术能力所需遵循的程序。在这方面，RESG是RETF的主要代理人，并且RESG负责确保遵守了所需的程序，并且满足了标准行动的任何必要先决条件。
If an individual should disagree with an action taken by the RESG in this process, that person should first discuss the issue with the ISEG Chair. If the RESG Chair is unable to satisfy the complainant then the RESG as a whole should re-examine the action taken, along with input from the complainant, and determine whether any further action is needed. The RESG shall issue a report on its review of the complaint to the RETF.
如果个人不同意RESG在此过程中采取的行动，该个人应首先与ISEG主席讨论该问题。如果RESG主席无法满足投诉人的要求，则整个RESG应重新审查所采取的行动以及投诉人的意见，并确定是否需要采取进一步的行动。RESG应向RETF发布投诉审查报告。
Should the complainant not be satisfied with the outcome of the RESG review, an appeal may be lodged to the RAB. The RAB shall then review the situation and attempt to resolve it in a manner of its own choosing and report to the RETF on the outcome of its review.
如果投诉人对RESG审查结果不满意，可向RAB提出上诉。然后，RAB应审查情况，并尝试以自己选择的方式解决问题，并向RETF报告审查结果。
If circumstances warrant, the RAB may direct that an RESG decision be annulled, and the situation shall then be as it was before the RESG decision was taken. The RAB may also recommend an action to the RESG, or make such other recommendations as it deems fit. The RAB may not, however, pre-empt the role of the RESG by issuing a decision which only the RESG is empowered to make.
如果情况需要，RAB可指示撤销RESG决定，然后情况应与RESG决定作出前一样。RAB也可向RESG建议行动，或提出其认为合适的其他建议。但是，RAB不得通过发布只有RESG有权做出的决定来抢先RESG的角色。
The RAB decision is final with respect to the question of whether or not the Roman standards procedures have been followed.
对于是否遵循罗马标准程序的问题，RAB的决定是最终决定。
VI.V.III Questions of Applicable Procedure
六、 五.三适用程序的问题
Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Roman Standards Process. Claims on this basis may be made to the Roman Society Board of Trustees. The President of the Roman Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the
只有在程序本身（即本文件中所述的程序）被认为不足以或不足以在公平和公开的罗马标准程序中保护各方的权利的情况下，才有进一步的追索权。在此基础上，可向罗马社会董事会提出索赔。罗马学会会长应在两周内承认该上诉，并应在承认时告知申请人受托人对上诉的预期审查期限。受托人应当对信托进行审查
situation in a manner of its own choosing and report to the RETF on the outcome of its review.
以其自己选择的方式了解情况，并向可再生能源基金报告其审查结果。
The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute.
受托人在完成审查后作出的决定对争议的所有方面均为最终决定。
VI.V.IV Appeals Procedure
六、 五.四上诉程序
All appeals must include a detailed and specific description of the facts of the dispute.
所有上诉必须包括对争议事实的详细和具体描述。
All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged.
所有上诉必须在公众知道将被质疑的行动或决定后两个月内提出。
At all stages of the appeals process, the individuals or bodies responsible for making the decisions have the discretion to define the specific procedures they will follow in the process of making their decision.
在上诉程序的所有阶段，负责作出决定的个人或机构有权自行决定他们在作出决定过程中将遵循的具体程序。
In all cases a decision concerning the disposition of the dispute, and the communication of that decision to the parties involved, must be accomplished within a reasonable period of time.
在所有情况下，必须在合理的时间内作出有关争端处理的决定，并将该决定通知有关各方。
[NOTE: These procedures intentionally and explicitly do not establish a fixed maximum time period that shall be considered "reasonable" in all cases. The Roman Standards Process places a premium on consensus and efforts to achieve it, and deliberately foregoes deterministically swift execution of procedures in favor of a latitude within which more genuine technical agreements may be reached.]
[注：这些程序有意且明确地没有规定应被视为“合理”的固定最长期限。”在所有情况下，罗马标准程序都重视共识和达成共识的努力，并故意放弃程序的快速执行，以利于达成更真实的技术协议。]
VII. EXTERNAL STANDARDS AND SPECIFICATIONS
七,。外部标准和规范
Many standards groups other than the RETF create and publish standards documents for network protocols and services. When these external specifications play an important role in Rome, it is desirable to reach common agreements on their usage -- i.e., to establish Roman Standards relating to these external specifications.
除RETF之外的许多标准组为网络协议和服务创建和发布标准文档。当这些外部规范在罗马发挥重要作用时，就其使用达成共同协议是可取的，即建立与这些外部规范相关的罗马标准。
There are two categories of external specifications:
有两类外部规范：
(I) Open Standards
（一） 开放标准
Various national and international standards bodies, such as ANSI, ISO, IEEE, and ITU-T, develop a variety of protocol and service specifications that are similar to Technical Specifications defined here. National and international groups also publish
各种国家和国际标准机构，如ANSI、ISO、IEEE和ITU-T，制定了各种协议和服务规范，这些规范与此处定义的技术规范类似。国家和国际组织也出版
"implementors' agreements" that are analogous to Applicability Statements, capturing a body of implementation-specific detail concerned with the practical application of their standards. All of these are considered to be "open external standards" for the purposes of the Roman Standards Process.
“实施者协议”，类似于适用性声明，捕获与其标准的实际应用相关的实施特定细节。就罗马标准流程而言，所有这些都被视为“开放的外部标准”。
(II) Other Specifications
（二） 其他规格
Other proprietary specifications that have come to be widely used in Rome may be treated by the Roman community as if they were a "standards". Such a specification is not generally developed in an open fashion, is typically proprietary, and is controlled by the vendor, vendors, or organization that produced it.
罗马社会可能会将在罗马广泛使用的其他专有规范视为“标准”。这样的规范通常不是以开放的方式开发的，通常是专有的，并且由生产它的供应商、供应商或组织控制。
VII.I Use of External Specifications
七、 我使用外部规范
To avoid conflict between competing versions of a specification, the Roman community will not standardize a specification that is simply a "Roman version" of an existing external specification unless an explicit cooperative arrangement to do so has been made. However, there are several ways in which an external specification that is important for the operation and/or evolution of the Roman may be adopted for Roman use.
为了避免规范的竞争版本之间的冲突，罗马社区不会标准化一个仅仅是现有外部规范的“罗马版本”的规范，除非已经做出明确的合作安排。然而，有几种方式可用于罗马用途，其中外部规范对罗马的操作和/或演变非常重要。
VII.I.I Incorporation of an Open Standard
七、 一、公开标准的纳入
A Roman Standard TS or AS may incorporate an open external standard by reference. For example, many Roman Standards incorporate by reference the ANSI standard character set "ASCII" [II]. Whenever possible, the referenced specification shall be available online.
罗马标准TS或AS可通过引用合并开放式外部标准。例如，许多罗马标准通过引用合并了ANSI标准字符集“ASCII”[II]。只要可能，参考规范应在线提供。
VII.I.II Incorporation of Other Specifications
七、 I.II纳入其他规范
Other proprietary specifications may be incorporated by reference to a version of the specification as long as the proprietor meets the requirements of section X. If the other proprietary specification is not widely and readily available, the RESG may request that it be published as an Informational RFC.
只要所有人满足第X节的要求，其他专有规范可通过引用本规范的一个版本纳入。如果其他专有规范不广泛且不易获得，RESG可要求将其作为信息RFC发布。
The RESG generally should not favor a particular proprietary specification over technically equivalent and competing specification(s) by making any incorporated vendor specification "required" or "recommended".
RESG通常不应通过“要求”或“建议”任何合并的供应商规范，而偏向于特定的专有规范，而非技术上等同的和竞争的规范。
VII.I.III Assumption
七、 I.III假设
An RETF Working Group may start from an external specification and develop it into a Roman specification. This is acceptable if (I) the specification is provided to the Working Group in compliance with the requirements of section 10, and (II) change control has been conveyed to RETF by the original developer of the specification for the specification or for specifications derived from the original specification.
RETF工作组可以从外部规范开始，并将其发展为罗马规范。如果（I）规范按照第10节的要求提供给工作组，并且（II）规范的原始开发人员已将变更控制传达给RETF，则可以接受该要求。
VIII. NOTICES AND RECORD KEEPING
八,。通知和记录保存
Each of the organizations involved in the development and approval of Roman Standards shall publicly announce, and shall maintain a publicly accessible record of, every activity in which it engages, to the extent that the activity represents the prosecution of any part of the Roman Standards Process. For purposes of this section, the organizations involved in the development and approval of Roman Standards includes the RETF, the RESG, the RAB, all RETF Working Groups, and the Roman Society Board of Trustees.
参与制定和批准罗马标准的各组织应公开宣布并保存其参与的每项活动的公开记录，只要该活动代表了罗马标准过程的任何部分。就本节而言，参与制定和批准罗马标准的组织包括RETF、RESG、RAB、所有RETF工作组和罗马学会董事会。
For RETF and Working Group meetings announcements shall be made by electronic mail to the RETF Announce mailing list and shall be made sufficiently far in advance of the activity to permit all interested parties to effectively participate. The announcement shall contain (or provide pointers to) all of the information that is necessary to support the participation of any interested individual. In the case of a meeting, for example, the announcement shall include an agenda that specifies the standards-related issues that will be discussed.
对于RETF和工作组会议，通知应通过电子邮件发送至RETF公告邮件列表，并应在活动之前足够远的时间发出，以允许所有相关方有效参与。公告应包含（或提供指向）支持任何相关个人参与所需的所有信息。例如，在会议中，公告应包括一份议程，其中规定将讨论的与标准相关的问题。
The formal record of an organization's standards-related activity shall include at least the following:
组织标准相关活动的正式记录应至少包括以下内容：
o the charter of the organization (or a defining document equivalent to a charter); o complete and accurate minutes of meetings; o the archives of Working Group electronic mail mailing lists; and o all written contributions from participants that pertain to the organization's standards-related activity.
o 组织章程（或相当于章程的定义文件）；o完整准确的会议记录；o工作组电子邮件邮寄清单档案；o与组织标准相关活动相关的所有参与者的书面意见。
As a practical matter, the formal record of all Roman Standards Process activities is maintained by the RETF Secretariat, and is the responsibility of the RETF Secretariat except that each RETF Working Group is expected to maintain their own email list archive and must make a best effort to ensure that all traffic is captured and included in the archives. Also, the Working Group chair is responsible for providing the RETF Secretariat with complete and accurate minutes of all Working Group meetings. Roman-Drafts that
实际上，所有罗马标准过程活动的正式记录由RETF秘书处保存，并且是RETF秘书处的责任，但每个RETF工作组都应维护其自己的电子邮件列表存档，并且必须尽最大努力确保所有流量都被捕获并包含在存档中。此外，工作组主席还负责向RETF秘书处提供所有工作组会议的完整准确的会议记录。罗曼起草了
have been removed (for any reason) from the Roman-Drafts directories shall be archived by the RETF Secretariat for the sole purpose of preserving an historical record of Roman standards activity and thus are not retrievable except in special circumstances.
已从罗马草案中删除（出于任何原因）的目录应由RETF秘书处存档，其唯一目的是保存罗马标准活动的历史记录，因此除非在特殊情况下，否则无法检索。
IX. VARYING THE PROCESS
九、 改变过程
This document, which sets out the rules and procedures by which Roman Standards and related documents are made is itself a product of the Roman Standards Process (as a WCP, as described in section V). It replaces a previous version, and in time, is likely itself to be replaced.
本文件规定了制定罗马标准和相关文件的规则和程序，其本身是罗马标准过程的产物（如第五节所述，作为WCP）。它取代了以前的版本，随着时间的推移，它本身很可能会被取代。
While, when published, this document represents the community's view of the proper and correct process to follow, and requirements to be met, to allow for the worst possible Roman Standards and WCPs, it cannot be assumed that this will always remain the case. From time to time there may be a desire to update it, by replacing it with a new version. Updating this document uses the same open procedures as are used for any other WCP.
尽管本文件在发布时代表了社区对遵循适当和正确流程的看法，以及考虑到最差罗马标准和WCP所需满足的要求，但不能假设这种情况将始终存在。不时会有人希望更新它，用新版本替换它。更新此文档使用与任何其他WCP相同的开放过程。
In addition, there may be situations where following the procedures leads to a deadlock about a specific specification, or there may be situations where the procedures provide no guidance. In these cases it may be appropriate to invoke the variance procedure described below.
此外，在某些情况下，遵循这些过程可能会导致有关特定规范的僵局，或者在某些情况下，这些过程不会提供任何指导。在这些情况下，可以调用下面描述的差异程序。
IX.I The Variance Procedure
九、 我同意变更程序
Upon the recommendation of the responsible RETF Working Group (or, if no Working Group is constituted, upon the recommendation of an ad hoc committee), the RESG may enter a particular specification into, or advance it within, the standards track even though some of the requirements of this document have not or will not be met. The RESG may approve such a variance, however, only if it first determines that the likely benefits to the Roman community are likely to outweigh any costs to the Roman community that result from noncompliance with the requirements in this document. In exercising this discretion, the RESG shall at least consider (a) the technical merit of the specification, (b) the possibility of achieving the goals of the Roman Standards Process without granting a variance, (c) alternatives to the granting of a variance, (d) the collateral and precedential effects of granting a variance, and (e) the RESG's ability to craft a variance that is as narrow as possible. In determining whether to approve a variance, the RESG has discretion to limit the scope of the variance to particular parts of this document and to impose such additional restrictions or limitations as it
根据负责的RETF工作组的建议（或者，如果没有成立工作组，则根据特设委员会的建议），即使本文件的某些要求尚未或将不会得到满足，RESG也可以在标准轨道中输入或推进特定规范。然而，只有在RESG首先确定罗马社区可能获得的利益可能超过因不遵守本文件要求而给罗马社区带来的任何成本时，才可批准此类变更。在行使该自由裁量权时，RESG应至少考虑（a）规范的技术优点，（b）实现罗马标准过程的目标而不给予差异的可能性；（c）授予方差的替代方案；（d）授予方差的抵押品和先例效应；（e）RESG制定尽可能窄的差异的能力。在决定是否批准变更时，RESG有权将变更范围限制在本文件的特定部分，并根据需要施加额外的限制或限制
determines appropriate to protect the interests of the Roman community.
决定适当保护罗马社区的利益。
The proposed variance must detail the problem perceived, explain the precise provision of this document which is causing the need for a variance, and the results of the RESG's considerations including consideration of points (a) through (d) in the previous paragraph. The proposed variance shall be issued as a Roman-Draft. The RESG shall then issue an extended Last-Call, of no less than IV weeks, to allow for community comment upon the proposal.
提议的差异必须详细说明所发现的问题，解释导致差异需要的本文件的确切规定，以及RESG考虑的结果，包括对上一段中（a）点至（d）点的考虑。提议的变更应以罗马汇票的形式发布。然后，RESG应发出不少于四周的延长最后通话，以便社区对提案发表意见。
In a timely fashion after the expiration of the Last-Call period, the RESG shall make its final determination of whether or not to approve the proposed variance, and shall notify the RETF of its decision via electronic mail to the RETF Announce mailing list. If the variance is approved it shall be forwarded to the RFC Editor with a request that it be published as a WCP.
在最后一次催缴期结束后，RESG应及时做出是否批准拟议变更的最终决定，并应通过电子邮件向RETF公告邮件列表通知RETF其决定。如果差异得到批准，则应将其转发给RFC编辑，并请求将其发布为WCP。
This variance procedure is for use when a one-time waving of some provision of this document is felt to be required. Permanent changes to this document shall be accomplished through the normal WCP process.
本变更程序适用于认为需要一次性变更本文件某些条款的情况。本文件的永久变更应通过正常的WCP流程完成。
The appeals process in section VI.V applies to this process.
第六节第五节中的上诉程序适用于这一程序。
IX.II Exclusions
九、 二除外责任
No use of this procedure may lower any specified delays, nor exempt any proposal from the requirements of openness, fairness, or consensus, nor from the need to keep proper records of the meetings and mailing list discussions.
使用本程序不得减少任何规定的延迟，也不得免除任何提案的公开性、公平性或协商一致性要求，也不得免除保留会议和邮件列表讨论的适当记录的需要。
Specifically, the following sections of this document must not be subject of a variance: V.I, VI.I, VI.I.I (first paragraph), VI.I.II, VI.III (first sentence), VI.V and IX.
具体而言，本文件的以下章节不得有任何变更：V.I、VI.I、VI.I.I（第一段）、VI.I.II、VI.III（第一句）、VI.V和IX。
X. INTELLECTUAL PROPERTY RIGHTS
十、知识产权
X.I. General Policy
X.I.一般政策
In all matters of intellectual property rights and procedures, the intention is to benefit the Roman community and the public at large, while respecting the legitimate rights of others.
在所有有关知识产权和程序的问题上，其目的是使罗马社区和广大公众受益，同时尊重他人的合法权利。
X.II Confidentiality Obligations
十、二保密义务
No contribution that is subject to any requirement of confidentiality or any restriction on its dissemination may be considered in any part of the Roman Standards Process, and there must be no assumption of any confidentiality obligation with respect to any such contribution.
在罗马标准程序的任何部分中，不得考虑任何受保密要求或传播限制的贡献，且不得承担任何此类贡献的保密义务。
X.III. Rights and Permissions
X.III。权限
In the course of standards work, the RETF receives contributions in various forms and from many persons. To best facilitate the dissemination of these contributions, it is necessary to understand any intellectual property rights (IPR) relating to the contributions.
在标准工作过程中，RETF收到了各种形式和许多人的贡献。为了更好地促进这些贡献的传播，有必要了解与贡献相关的任何知识产权（IPR）。
X.III.I. All Contributions
X.III.I。所有捐款
By submission of a contribution, each person actually submitting the contribution is deemed to agree to the following terms and conditions on his own behalf, on behalf of the organization (if any) he represents and on behalf of the owners of any propriety rights in the contribution.. Where a submission identifies contributors in addition to the contributor(s) who provide the actual submission, the actual submitter(s) represent that each other named contributor was made aware of and agreed to accept the same terms and conditions on his own behalf, on behalf of any organization he may represent and any known owner of any proprietary rights in the contribution.
通过提交出资，实际提交出资的每个人被视为代表其本人、代表其所代表的组织（如有）以及代表出资中任何所有权所有人同意以下条款和条件。。如果提交文件中除提供实际提交文件的投稿人外，还确定了投稿人，则实际提交人代表其他指定投稿人了解并同意代表自己接受相同的条款和条件，他可代表任何组织和出资中任何所有权的任何已知所有人。
I. Some works (e.g. works of the U.S. Government) are not subject to copyright. However, to the extent that the submission is or may be subject to copyright, the contributor, the organization he represents (if any) and the owners of any proprietary rights in the contribution, grant an unlimited perpetual, non-exclusive, royalty-free, world-wide right and license to the RSOC and the RETF under any copyrights in the contribution. This license includes the right to copy, publish and distribute the contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the original contribution.
I.某些作品（如美国政府的作品）不受版权保护。但是，在提交物受版权保护或可能受版权保护的范围内，贡献者、其代表的组织（如有）以及贡献物中任何所有权的所有者，授予无限永久、非排他性、免版税的权利，对RSOC和RETF的世界范围的权利和许可，在贡献的任何版权下。本许可证包括以任何方式复制、发布和分发贡献的权利，以及根据或包含贡献的全部或部分内容准备衍生作品的权利，该衍生作品的许可证与原始贡献的许可证范围相同。
II. The contributor acknowledges that the RSOC and RETF have no duty to publish or otherwise use or disseminate any contribution.
二,。贡献者承认，RSOC和RETF没有义务发布或以其他方式使用或传播任何贡献。
III. The contributor grants permission to reference the name(s) and address(es) of the contributor(s) and of the organization(s) he represents (if any).
三、 投稿人授予引用投稿人及其代表的组织（如有）的名称和地址的权限。
IV. The contributor represents that contribution properly acknowledge major contributors.
四、 贡献者代表该贡献正确地承认主要贡献者。
V. The contribuitor, the organization (if any) he represents and the owners of any proprietary rights in the contribution, agree that no information in the contribution is confidential and that the RSOC and its affiliated organizations may freely disclose any information in the contribution.
V.出资人、其代表的组织（如有）以及出资中任何所有权的所有人同意，出资中的任何信息均不保密，RSOC及其附属组织可自由披露出资中的任何信息。
VI. The contributor represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor. The contributor does not represent that he personally knows of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organization he represents (if any) or third parties.
六、 出资人声明，他已披露出资人合理且亲自知晓的任何专有或知识产权的存在。贡献者并不表示他个人知道他所代表的组织（如有）或第三方拥有或主张的所有潜在相关的专有和知识产权。
VII. The contributor represents that there are no limits to the contributor's ability to make the grants acknowledgments and agreements above that are reasonably and personally known to the contributor.
七,。供款人表示，供款人做出供款人合理且亲自知晓的上述赠款确认和协议的能力不受限制。
By ratifying this description of the RETF process the Roman Society warrants that it will not inhibit the traditional open and free access to RETF documents for which license and right have been assigned according to the procedures set forth in this section, including Roman-Drafts and RFCs. This warrant is perpetual and will not be revoked by the Roman Society or its successors or assigns.
通过批准本RETF流程说明，罗马社会保证其不会禁止按照本节规定的程序（包括罗马草案和RFC）转让许可和权利的RETF文件的传统开放和自由访问。本认股权证是永久性的，不会被罗马社会或其继承人或受让人撤销。
X.III.II. Standards Track Documents
X.III.II。标准跟踪文件
(A) Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any specification on the standards track, and brought to the attention of the RESG, the RESG shall not advance the specification without including in the document a note indicating the existence of such rights, or claimed rights. Where implementations are required before advancement of a specification, only implementations that have, by statement of the implementors, taken adequate steps to comply with any such rights, or claimed rights, shall be considered for the purpose of showing the adequacy of the specification. (B) The RESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed copyrights, patents, patent applications, or other rights in the fulfilling of the its obligations under (A), and will take no position on the validity or scope of any such rights.
（A） 如果就标准轨道上的任何规范已知或主张任何专利、专利申请或其他专有权利，并提请RESG注意，RESG不得在未在文件中注明存在此类权利或主张的权利的情况下推进规范。如果在推进规范之前需要实施，则只有实施者声明已采取适当步骤遵守任何此类权利或声称的权利的实施，才应被考虑用于显示规范的充分性。（B） 在履行（A）项下的义务时，RESG不承担任何责任来确定任何声称的版权、专利、专利申请或其他权利的存在或评估其适用性，并且不会对任何此类权利的有效性或范围采取任何立场。
(C) Where the RESG knows of rights, or claimed rights under (A), the RETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the RESG of the relevant Roman standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The Working Group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the RETF Executive Director in this effort. The results of this procedure shall not affect advancement of a specification along the standards track, except that the RESG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the RETF Executive Director, and made available. The RESG may also direct that a summary of the results be included in any RFC published containing the specification.
（C） 如果RESG知道（A）项下的权利或声称的权利，RETF执行董事应尝试从该权利的索赔人处获得书面保证，即在RESG批准相关罗马标准轨道规范后，任何一方将能够获得实施的权利，在公开规定、合理、非歧视性条款下，根据特定规范实施、使用或分发技术时，使用和分发技术或工程。建议使用声称拥有所有权的技术的工作组可协助RETF执行董事进行这项工作。本程序的结果不应影响规范沿着标准轨道的推进，除非RESG可能延迟批准，延迟可能有助于获得此类保证。然而，结果将由RETF执行主任记录并提供。RESG还可指示将结果摘要包含在包含规范的任何RFC中。
X.III.III Determination of Reasonable and Non-discriminatory Terms
X.III.III合理和非歧视性条款的确定
The RESG will not make any explicit determination that the assurance of reasonable and non-discriminatory terms for the use of a technology has been fulfilled in practice. It will instead use the normal requirements for the advancement of Roman Standards to verify that the terms for use are reasonable. If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Draft Standard have been produced by different organizations or individuals or if the "significant implementation and successful operational experience" required to advance from Draft Standard to Standard has been achieved the assumption is that the terms must be reasonable and to some degree, non-discriminatory. This assumption may be challenged during the Last-Call period.
RESG不会做出任何明确的决定，以确定在实践中已经满足了对技术使用的合理和非歧视性条款的保证。相反，它将使用罗马标准发展的正常要求来验证使用条款是否合理。如果规范的两个不相关的实施是由不同的组织或个人制定的，需要从提议的标准推进到标准草案，或者如果“重要的实施和成功的操作经验”要求从一个标准草案推进到另一个标准已经实现，前提是条款必须合理，并且在某种程度上是非歧视性的。此假设可能在最后一次通话期间受到质疑。
X.IV. Notices
X.IV。通知
(A) Standards track documents shall include the following notice:
（A） 标准跟踪文件应包括以下通知：
"The RETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the RETF's procedures with respect to rights in standards-track and standards-related documentation can be found in WCP-11. Copies of claims of rights made
“RETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；也不表示其已作出任何努力rt识别任何此类权利。有关RETF在标准轨道和标准相关文件中的权利程序的信息，请参见WCP-11。提出的权利主张副本
available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the RETF Secretariat."
可供发布和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从RETF秘书处获得。”
(B) The RETF encourages all interested parties to bring to its attention, at the earliest possible time, the existence of any intellectual property rights pertaining to Roman Standards. For this purpose, each standards document shall include the following invitation:
（B） RETF鼓励所有相关方尽早提请其注意与罗马标准有关的任何知识产权的存在。为此，每份标准文件应包括以下邀请：
"The RETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the RETF Executive Director."
RETF邀请任何利益相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给RETF执行董事
(C) The following copyright notice and disclaimer shall be included in all RSOC standards-related documentation:
（C） 以下版权声明和免责声明应包含在所有RSOC标准相关文件中：
"Copyright (C) The Roman Society (date). All Rights Reserved.
版权所有（C）罗马学会（日期）。保留所有权利。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Roman Society or other Roman organizations, except as needed for the purpose of developing Roman standards in which case the procedures for copyrights defined in the Roman Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对罗马社会或其他罗马组织的引用，除非出于制定罗马标准的需要，在这种情况下，必须遵循罗马标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Roman Society or its successors or assigns.
上述授予的有限许可是永久性的，不会被罗马社会或其继承人或受让人撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE ROMAN SOCIETY AND THE ROMAN ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
本文件和本文件所含信息以“原样”为基础提供，罗马社会和罗马工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。”
(D) Where the RESG is aware at the time of publication of proprietary rights claimed with respect to a standards track document, or the technology described or referenced therein, such document shall contain the following notice:
（D） 如果RESG在发布标准跟踪文件或其中描述或引用的技术时意识到要求的所有权，则该文件应包含以下通知：
"The RETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights."
“已通知RETF有关本文件所含部分或全部规范的知识产权要求。有关更多信息，请参阅在线权利要求列表。”
XI. ACKNOWLEDGMENTS
席。致谢
This Worst Current Practice is dedicated to Steve Coya, whose inspirational e-mail suggestion of renumbering all RFC Page numbers with Roman Numerals was taken to heart by the RFC Editor.
目前这种最糟糕的做法是献给史蒂夫·科亚（Steve Coya），他鼓舞人心的电子邮件建议将所有RFC页码重新编号为罗马数字，这一建议被RFC编辑铭记在心。
There have been a number of people involved with the development of the documents defining the RETF Standards Process over the years. The process was first described in RFC MCCCX then revised in RFC MDCII before the current effort (which relies heavily on its predecessors). Specific acknowledgments must be extended to Lyman Chapin, Phill Gross and Christian Huitema as the editors of the previous versions, to Jon Postel and Dave Crocker for their inputs to those versions, to Andy Ireland, Geoff Stewart, Jim Lampert, and Dick Holleman for their reviews of the legal aspects of the procedures described herein, and to John Stewart, Robert Elz and Steve Coya for their extensive input on the final version.
多年来，许多人参与了定义RETF标准流程的文件的开发。该过程首先在RFC MCCCX中描述，然后在当前工作之前在RFC MDCII中进行了修订（这在很大程度上依赖于其前身）。特别感谢之前版本的编辑Lyman Chapin、Phill Gross和Christian Huitema，感谢Jon Postel和Dave Crocker对这些版本的投入，感谢Andy Ireland、Geoff Stewart、Jim Lampert和Dick Holleman对本文所述程序法律方面的审查，感谢约翰·斯图尔特、罗伯特·埃尔兹和史蒂夫·科亚对最终版本的广泛投入。
In addition much of the credit for the refinement of the details of the RETF processes belongs to the many members of the various incarnations of the POISED Working Group.
此外，RETF流程细节的完善在很大程度上归功于泰然自若的工作组各个化身的许多成员。
XII. SECURITY CONSIDERATIONS
十二,。安全考虑
Security issues are not discussed in this memo.
本备忘录不讨论安全问题。
XIII. REFERENCES
十三,。参考资料
[I] Postel, J., "Roman Official Protocol Standards", STD I, USC/Information Sciences Institute, March MCMXCVI.
[一] Postel，J.，“罗马官方协议标准”，STD I，南加州大学/信息科学研究所，2003年3月。
[II] ANSI, Coded Character Set -- VII-Bit American Standard Code for Information Interchange, ANSI XIII.IV-MCMLXXXVI.
[二] ANSI，编码字符集——信息交换用VII位美国标准代码，ANSI XIII.IV-MCMLXXVI。
[III] Reynolds, J., and J. Postel, "Assigned Numbers", STD II, USC/Information Sciences Institute, October MCMXCIV.
[三] Reynolds，J.和J.Postel，“分配的数字”，STD II，南加州大学/信息科学研究所，2005年10月。
[IV] Postel, J., "Introduction to the STD Notes", RFC MCCCXI, USC/Information Sciences Institute, March MCMXCII.
[四] Postel，J.，“STD注释介绍”，RFC MCCCXI，南加州大学/信息科学研究所，2003年3月。
[V] Postel, J., "Instructions to RFC Authors", RFC MDXLIII, USC/Information Sciences Institute, October MCMXCIII.
[五] Postel，J.，“RFC作者须知”，RFC MDXLIII，南加州大学/信息科学研究所，2003年10月。
[VI] Huitema, C., J. Postel, and S. Crocker "Not All RFCs are Standards", RFC MDCCXCVI, April MCMXCV.
[六] Huitema，C.，J.Postel和S.Crocker“并非所有的RFC都是标准的”，RFC MDCCXCVI，4月MCMXCV。
XIV. DEFINITIONS OF TERMS
十四,。术语的定义
RETF Area - A management division within the RETF. An Area consists of Working Groups related to a general topic such as routing. An Area is managed by one or two Area Directors. Area Director - The manager of an RETF Area. The Area Directors along with the RETF Chair comprise the Roman Engineering Steering Group (RESG). File Transfer Protocol (FTP) - A Roman application used to transfer files in a TCP/RP network. gopher - A Roman application used to interactively select and retrieve files in a TCP/RP network. Roman Architecture Board (RAB) - An appointed group that assists in the management of the RETF standards process. Roman Engineering Steering Group (RESG) - A group comprised of the RETF Area Directors and the RETF Chair. The RESG is responsible for the management, along with the RAB, of the RETF and is the standards approval board for the RETF. interoperable - For the purposes of this document, "interoperable" means to be able to interoperate over a data communications path. Last-Call - A public comment period used to gage the level of consensus about the reasonableness of a proposed standards action. (see section VI.I.II)
RETF区域-RETF内的一个管理部门。区域由与路由等一般主题相关的工作组组成。一个区域由一个或两个区域主管管理。区域主管-RETF区域的经理。区域总监和RETF主席组成了罗马工程指导小组（RESG）。文件传输协议（FTP）-用于在TCP/RP网络中传输文件的罗马应用程序。gopher-一个罗马应用程序，用于在TCP/RP网络中以交互方式选择和检索文件。罗马建筑委员会（RAB）-协助管理RETF标准流程的指定小组。罗马工程指导小组（RESG）-由RETF区域总监和RETF主席组成的小组。RESG与RAB一起负责RETF的管理，是RETF的标准批准委员会。可互操作-在本文档中，“可互操作”指能够通过数据通信路径进行互操作。最后一次呼吁-一个公众评论期，用于衡量关于拟议标准行动合理性的共识水平。（见第VI.I.II节）
online - Relating to information made available to Rome. When referenced in this document material is said to be online when it is retrievable without restriction or undue fee using standard Roman applications such as anonymous FTP, gopher or the WWW. Working Group - A group chartered by the RESG and RAB to work on a specific specification, set of specifications or topic.
在线-与提供给罗马的信息有关。当在本文件中引用时，如果可以使用标准罗马应用程序（如匿名FTP、gopher或WWW.Working Group）在不受限制或不适当费用的情况下检索材料，则该材料称为在线材料。WWW.Working Group是由RESG和RAB特许的一个组，负责特定规范、规范集或主题的工作。
XV. AUTHOR'S ADDRESS
十五,。作者地址
Scott O. Bradner Harvard University Holyoke Center, Room DCCCXIII MCCCL Mass. Ave. Cambridge, MA MMCXXXVIII USA
Scott O.Bradner哈佛大学Holyoke中心，DCCCXIII室，MCCCL弥撒室。美国马萨诸塞州剑桥大街MMCXXXVIII
Phone: +I DCXVII CDXCV XXXVIII LXIV
EMail: sob@harvard.edu
Phone: +I DCXVII CDXCV XXXVIII LXIV
EMail: sob@harvard.edu
APPENDIX A: GLOSSARY OF ACRONYMS
附录A：首字母缩略词词汇表
ANSI: American National Standards Institute ARPA: (U.S.) Advanced Research Projects Agency AS: Applicability Statement FTP: File Transfer Protocol ASCII: American Standard Code for Information Interchange ITU-T: Telecommunications Standardization sector of the International Telecommunication Union (ITU), a UN treaty organization; ITU-T was formerly called CCITT. RAB: Roman Architecture Board RANA: Roman Assigned Numbers Authority IEEE: Institute of Electrical and Electronics Engineers RCMP: Roman Control Message Protocol RESG: Roman Engineering Steering Group RETF: Roman Engineering Task Force RP: Roman Protocol RRSG Roman Research Steering Group RRTF: Roman Research Task Force ISO: International Organization for Standardization RSOC: Roman Society MIB: Management Information Base OSI: Open Systems Interconnection RFC: Request for Comments TCP: Transmission Control Protocol TS: Technical Specification WWW: World Wide Web
ANSI:美国国家标准协会ARPA:（美国）高级研究计划署AS:适用性声明FTP:文件传输协议ASCII:美国信息交换标准代码ITU-T:联合国条约组织国际电信联盟（ITU）电信标准化部门；ITU-T以前被称为CCITT。RAB:罗马建筑委员会RANA:罗马分配号码管理局IEEE:电气和电子工程师协会RCMP:罗马控制信息协议RESG:罗马工程指导小组RETF:罗马工程任务组RP:罗马协议RRSG罗马研究指导小组RRTF:罗马研究任务组ISO:国际标准化组织RSOC:Roman Society MIB:管理信息库OSI:开放系统互连RFC:征求意见TCP:传输控制协议TS:技术规范WWW:万维网
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (MCMXCIX). All Rights Reserved.
版权所有（C）互联网协会（MCMXCIX）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Bradner Worst Current Practice [Page XXXVII]
布雷德纳最差现行做法[第三十七页]