Network Working Group A. Rousskov
Request for Comments: 4228 The Measurement Factory
Category: Informational December 2005
Network Working Group A. Rousskov
Request for Comments: 4228 The Measurement Factory
Category: Informational December 2005
Requirements for an IETF Draft Submission Toolset
IETF草案提交工具集的要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.
本文件规定了IETF工具集的要求，以促进互联网草案提交、验证和发布。
Table of Contents
目录
1. Introduction ....................................................2
2. Scope ...........................................................2
3. Notation and Terminology ........................................3
4. Status Quo ......................................................4
5. Overall Toolset Operation .......................................6
6. Upload Page .....................................................9
7. Check Action ....................................................9
7.1. Preprocessing .............................................10
7.2. Processing ................................................11
7.3. Storage ...................................................11
7.4. Extraction ................................................12
7.5. Validation ................................................13
7.5.1. Absolute Requirements ..............................14
7.5.2. Desirable Features .................................15
7.5.3. DoS Thresholds .....................................17
7.5.4. WG Approval ........................................17
8. Check Page .....................................................18
8.1. External Meta-Data ........................................19
9. Post Now Action ................................................20
9.1. Receipt Page ..............................................20
10. Adjust Action .................................................21
11. Adjust Page ...................................................21
12. Post Manually Action ..........................................22
13. Receipt Page ..................................................22
1. Introduction ....................................................2
2. Scope ...........................................................2
3. Notation and Terminology ........................................3
4. Status Quo ......................................................4
5. Overall Toolset Operation .......................................6
6. Upload Page .....................................................9
7. Check Action ....................................................9
7.1. Preprocessing .............................................10
7.2. Processing ................................................11
7.3. Storage ...................................................11
7.4. Extraction ................................................12
7.5. Validation ................................................13
7.5.1. Absolute Requirements ..............................14
7.5.2. Desirable Features .................................15
7.5.3. DoS Thresholds .....................................17
7.5.4. WG Approval ........................................17
8. Check Page .....................................................18
8.1. External Meta-Data ........................................19
9. Post Now Action ................................................20
9.1. Receipt Page ..............................................20
10. Adjust Action .................................................21
11. Adjust Page ...................................................21
12. Post Manually Action ..........................................22
13. Receipt Page ..................................................22
14. Bypassing the Toolset .........................................22
15. Email Interface ...............................................23
16. Implementation Stages .........................................25
17. Testing .......................................................26
18. Security Considerations .......................................27
19. Compliance ....................................................27
Appendix A. Comparison with Current Procedures ....................28
Appendix B. Acknowledgements ......................................29
Normative References ..............................................30
Informative References ............................................30
14. Bypassing the Toolset .........................................22
15. Email Interface ...............................................23
16. Implementation Stages .........................................25
17. Testing .......................................................26
18. Security Considerations .......................................27
19. Compliance ....................................................27
Appendix A. Comparison with Current Procedures ....................28
Appendix B. Acknowledgements ......................................29
Normative References ..............................................30
Informative References ............................................30
Public Internet-Drafts are the primary means of structured communication within the IETF. Current Internet-Draft submission and posting mechanisms hinder efficient and timely communication while creating an unnecessary load on the IETF Secretariat. The IETF Tools team recommends formalization and automation of the current mechanisms. This document contains specific automation requirements.
公共互联网草案是IETF内部结构化通信的主要手段。当前的互联网草案提交和发布机制阻碍了高效和及时的沟通，同时给IETF秘书处造成了不必要的负担。IETF工具团队建议对当前机制进行形式化和自动化。本文档包含特定的自动化要求。
The IETF Secretariat and many IETF participants have long been proponents of automation. This document attempts to reflect their known needs and wishes, as interpreted by the Tools team.
IETF秘书处和许多IETF参与者长期以来一直是自动化的支持者。本文档试图反映他们已知的需求和愿望，正如工具团队所解释的那样。
The Draft Submission Toolset discussed in this document is about getting a single new version of an Internet-Draft from an IETF participant to the IETF draft repository. A single draft version may include several formats, and dealing with those formats is in scope for the Toolset. Definition and sources of draft meta-information (to be used in Secretariat databases and elsewhere) are in scope. Submitter authentication and submission authorization are in scope.
本文档中讨论的草案提交工具集是关于从IETF参与者向IETF草案存储库获取互联网草案的单个新版本。单个草稿版本可能包括多种格式，处理这些格式在工具集的范围内。元信息草案的定义和来源（将在秘书处数据库和其他地方使用）在范围之内。提交者身份验证和提交授权在范围内。
Draft posting may result in various notifications sent to interested parties. While this document recommends a subset of notification targets, details of notifications are out of scope.
草稿投递可能导致向相关方发送各种通知。虽然本文档推荐了通知目标的子集，但通知的详细信息超出了范围。
Creation of new drafts or new draft versions as well as manipulation, visualization, and interaction with the drafts already in the repository are out of scope. Draft expiration and archiving of old draft versions are out of scope.
创建新草案或新草案版本以及操作、可视化以及与存储库中已有草案的交互超出了范围。草稿过期和旧草稿版本的存档超出范围。
The set of requirements in this document is not meant to be comprehensive or final. Other IETF documents or procedures may require additional functionality from the Toolset. For example, it is possible that the Toolset will be required to handle draft source formats other than plain text and XML.
本文件中的一系列要求并非全面或最终要求。其他IETF文件或程序可能需要工具集的附加功能。例如，可能需要该工具集来处理纯文本和XML以外的草稿源格式。
The following terms are to be interpreted according to their definitions below.
以下术语应根据以下定义进行解释。
posted draft: A draft accepted into the public IETF draft repository and, hence, publicly available from the IETF web site. Posting of a draft does not imply any IETF or IESG review and endorsement.
已发布草稿：一份已被纳入公共IETF草稿库的草稿，因此可从IETF网站公开获取。草案的发布并不意味着IETF或IESG的审查和认可。
draft version: A meant-to-be-public snapshot of an Internet-Draft with a meant-to-be-unique version number. Also known as "draft revision".
草稿版本：具有唯一版本号的Internet草稿的拟公开快照。也称为“修订草案”。
draft format: Any draft source or presentation format, including original and preprocessed XML, original or generated plain text as well as PDF, PostScript, and HTML formats.
草稿格式：任何草稿源或演示文稿格式，包括原始和预处理的XML、原始或生成的纯文本以及PDF、PostScript和HTML格式。
primary draft format: The first available draft format from the following list: plain text, PDF, PostScript, or XML.
主要草稿格式：以下列表中第一个可用的草稿格式：纯文本、PDF、PostScript或XML。
WG-named draft: A draft for which identifier (a.k.a. filename) is known and starts with "draft-SPECIAL-", where SPECIAL is one of the following strings: "ietf", "iab", "iesg", "rfc-editor", or "irtf". Abbreviated as "WGN draft". Exceptions notwithstanding, WG-named drafts are usually controlled by IETF working groups or similar IETF-related bodies (and vice versa). The handling of such naming exceptions is outside of this document's scope.
WG命名草稿：已知标识符（又称文件名）并以“草稿特殊-”开头的草稿，其中特殊是以下字符串之一：“ietf”、“iab”、“iesg”、“rfc编辑器”或“irtf”。缩写为“WGN草案”。尽管有例外，工作组命名的草案通常由IETF工作组或类似的IETF相关机构控制（反之亦然）。此类命名异常的处理超出了本文档的范围。
individual draft: A draft other than a WGN draft.
单独汇票：除WGN汇票以外的汇票。
submitter: A human or software agent initiating submission of an Internet-Draft version for validation or posting. In some cases, the Secretariat staff does the actual submission, but always on behalf of a submitter. In some cases (including but not limited to malicious attacks), the submitter is not the draft author.
提交者：一个人或软件代理发起互联网草稿版本的提交以供验证或发布。在某些情况下，秘书处工作人员负责实际提交，但始终代表提交人。在某些情况下（包括但不限于恶意攻击），提交人不是草稿作者。
expected submitter: A submitter that is authorized by IETF rules to post a given draft. This includes a draft author or editor (listed in the draft text), a corresponding WG Chair, or an IESG member.
预期提交人：经IETF规则授权发布给定草案的提交人。这包括草案作者或编辑（在草案文本中列出）、相应的工作组主席或IESG成员。
authorized submitter: An expected submitter authenticated by the Toolset. Authentication is initially limited to verifying submitter access to submitter's email address.
授权提交人：通过工具集验证的预期提交人。身份验证最初仅限于验证提交人对提交人电子邮件地址的访问权限。
immediately: Without human interaction or artificial software delays and within a few seconds.
立即：无人机交互或人工软件延迟，几秒钟内。
The Toolset is specified using a set of normative requirements. These requirements are English phrases ending with an "(Rnnn/s)" indication, where "nnn" is a unique requirement number, and "s" is a single-letter code ("a", "b", or "c") specifying the implementation stage for the requirement. Implementation stages are documented in Section 16.
该工具集是使用一组规范性要求指定的。这些要求是以“（Rnnn/s）”表示结尾的英语短语，其中“nnn”是唯一的要求编号，“s”是单字母代码（“a”、“b”或“c”），指定了要求的实施阶段。第16节记录了实施阶段。
This document specifies the interface and functionality of the Toolset, not the details of a Toolset implementation. However, implementation hints or examples are often useful. To avoid mixup with Toolset requirements, such hints and examples are often marked with a "Hint:" prefix. Implementation hints do not carry any normative force, and a different implementation may be the best choice.
本文档指定了工具集的接口和功能，而不是工具集实现的详细信息。然而，实现提示或示例通常是有用的。为了避免与工具集需求混淆，此类提示和示例通常用“提示：”前缀标记。实现提示不具有任何规范效力，不同的实现可能是最佳选择。
This section summarizes the process for draft submission and posting as it exists at the time of writing.
本节总结了撰写本文时存在的草稿提交和过账流程。
To get an Internet-Draft posted on the IETF web site, an IETF participant emails the draft text to the IETF Secretariat, along with an informal note asking the Secretariat to post the draft. Secretariat staff reads the note, reviews the draft according to a checklist, and then approves or rejects the submission. Draft approval triggers the corresponding announcement to be sent to appropriate IETF mailing lists. Every 4 hours, approved drafts are automatically copied to the IETF drafts repository and become available on the IETF web site.
为了在IETF网站上发布互联网草案，IETF参与者通过电子邮件将草案文本发送给IETF秘书处，并附上一份非正式通知，要求秘书处发布草案。秘书处工作人员阅读说明，根据清单审查草案，然后批准或拒绝提交的材料。草案批准触发相应的公告发送至相应的IETF邮件列表。每4小时，经批准的草稿将自动复制到IETF草稿库，并在IETF网站上可用。
Collectively, IETF participants submit thousands of Internet-Drafts per year (in the year 2000, about 3,000 drafts were submitted; 2002: 5k; 2004: 7k [secretariat]). About 30-50% of posted drafts are WG-named drafts (among some 2,100 drafts, there were about 380 new and 290 updated WGN drafts posted in 2003). While no rejection statistics are available, the vast majority of submitted drafts are approved by the Secretariat for posting.
IETF参与者每年提交数千份互联网草案（2000年提交了约3000份草案；2002年：5k；2004年：7k[秘书处]）。大约30-50%的发布草案是工作组命名的草案（在大约2100份草案中，2003年发布了大约380份新草案和290份更新的工作组命名草案）。虽然没有拒绝统计数字，但绝大多数提交的草案都得到了秘书处的批准，以便张贴。
It usually takes the Secretariat a few minutes to review a given draft. However, since the Secretariat staff does not work 24/7, does not work in all time zones, and has other responsibilities, and since approved drafts are posted in batches every 4 hours, it may take from several hours to several days to get a draft posted. Due to much higher demand and fixed processing capacity, postings during the last weeks before IETF face-to-face meetings take much longer, creating a long queue of unprocessed drafts that are then announced nearly simultaneously.
秘书处审查某一草案通常需要几分钟的时间。然而，由于秘书处工作人员不全天候工作，不在所有时区工作，并负有其他责任，而且由于核准的草稿每4小时分批张贴，因此张贴草稿可能需要几个小时到几天的时间。由于更高的需求和固定的处理能力，在IETF面对面会议之前的最后几周内发布的时间要长得多，从而产生了一长串未处理的草稿，然后几乎同时发布。
To give IETF face-to-face meeting participants time to review relevant documents, the Secretariat does not accept Internet-Draft submissions close to IETF meetings (regardless of whether a draft is relevant to the upcoming meeting or not).
为了让IETF面对面会议参与者有时间审查相关文件，秘书处不接受在IETF会议附近提交的互联网草案（无论草案是否与即将召开的会议相关）。
Many Working Groups have come up with ad hoc solutions to cope with posting delays. For example, many draft snapshots are "temporarily" published on personal web sites or sent (completely or in part) to the group list. Alternative means of publication may effectively replace official IETF interfaces, with only a few major draft revisions ending up posted on the IETF web site.
许多工作组已经提出了临时解决方案来应对张贴延迟。例如，许多快照草稿“临时”发布在个人网站上，或发送（全部或部分）到组列表中。替代出版手段可能有效地取代IETF官方接口，只有少数主要修订草案最终发布在IETF网站上。
Informal interfaces for submitting and posting drafts discourage automation. Lack of submission automation increases Secretariat load, complicates automated indexing and cross-referencing of the drafts, and, for some authors, leads to stale drafts not being updated often enough.
提交和发布草稿的非正式界面不利于自动化。缺乏提交自动化增加了秘书处的工作量，使草案的自动索引和交叉引用复杂化，并且对一些作者来说，导致过时的草案没有得到足够频繁的更新。
Beyond a short Secretariat checklist, submitted drafts are not checked for compliance with IETF requirements for archival documents, and submitters are not notified of any violations. As a result, the IESG and RFC Editor may have to spend resources (and delay approval) resolving violations with draft authors. Often, these violations can be detected automatically and would have been fixed by draft authors if the authors knew about them before requesting publication of the draft.
除了简短的秘书处清单外，未检查提交的草案是否符合IETF对档案文件的要求，提交人也未收到任何违规通知。因此，IESG和RFC编辑可能不得不花费资源（并延迟批准）来解决草案作者的违规行为。通常情况下，这些违规行为可以自动检测到，如果作者在请求发布草案之前就知道这些违规行为，那么这些违规行为将由草案作者修复。
Technically, anybody and anything can submit a draft to the Secretariat. There is no reliable authentication mechanism in place. Initial submissions of WGN drafts require WG Chair approval, which can be faked just like the submission request itself. No malicious impersonations or fake approvals have been reported to date, however.
从技术上讲，任何人和任何东西都可以向秘书处提交草案。没有可靠的身份验证机制。WGN草案的初始提交需要工作组主席的批准，这可以像提交请求本身一样伪造。然而，到目前为止，尚未报告恶意模仿或虚假批准。
Lack of authentication is not perceived as a serious problem, possibly because serious falsification are likely to be noticed before serious damage can be done. Due to the informal and manual nature of the submission mechanism, its massive automated abuse is unlikely to cause anything but a short denial of draft posting service and, hence, is probably not worth defending against. However, future automation may result in a different trade-off.
缺乏认证并不被视为严重问题，可能是因为在造成严重损害之前，很可能会发现严重的伪造行为。由于提交机制的非正式和手动性质，其大规模的自动滥用除了短期拒绝草稿投递服务外，不太可能导致任何事情，因此，可能不值得为其辩护。然而，未来的自动化可能会导致不同的权衡。
This section provides a high-level description for the proposed Toolset. The description is meant to show overall operation and order; please refer to other sections for details specific to each step.
本节为建议的工具集提供高级描述。说明旨在显示整体操作和顺序；有关每个步骤的详细信息，请参阅其他章节。
A typical submitter goes through a sequence of 2-4 web pages and associated actions. The number of pages depends on the draft validation and meta-data extraction results. For example, validating the draft without posting it requires interacting with two web pages: Upload and Check. The common case of posting a valid draft without manual meta-data adjustments takes three web pages (Upload, Check, Receipt).
一个典型的提交者会经历一系列2-4个网页和相关操作。页数取决于草稿验证和元数据提取结果。例如，在不发布草稿的情况下验证草稿需要与两个网页交互：上载和检查。发布有效草稿而不进行手动元数据调整的常见情况需要三个网页（上传、检查、接收）。
Here is a brief overview of pages and actions:
以下是页面和操作的简要概述：
Upload page: The interface to copy a draft from the submitter's computer to the Toolset staging area (Section 6). Multiple formats are accepted. The draft is sent to the Check action.
上传页面：将草稿从提交人的计算机复制到工具集暂存区的界面（第6节）。可接受多种格式。草稿将发送到检查操作。
Check action: Stores the draft in the Toolset staging area, extracts draft meta-data, validates the submission (Section 7). Produces the Check page.
检查操作：将草稿存储在工具集暂存区域，提取草稿元数据，验证提交（第7节）。生成检查页。
Check page: Displays draft interpretation and validation results (Section 8). A draft preview may also be given on this page. After reviewing the draft interpretation and validation results, the submitter has four basic choices: (a) auto-post draft "as is" now; (b) make manual corrections and submit the draft to Secretariat for manual posting later; (c) cancel submission; or (d) do nothing. The automated posting option may not be available for drafts with validation errors.
检查页面：显示草案解释和验证结果（第8节）。本页还可提供预览草稿。在审查草案的解释和验证结果后，提交人有四个基本选择：（a）现在自动发布“原样”草案；（b） 进行手动更正，并将草稿提交秘书处，以便以后手动过账；（c） 取消提交；或（d）什么也不做。自动过帐选项可能不适用于存在验证错误的草稿。
Automated posting: If the submitter decides to proceed with automated posting from the Check page, the system authenticates the submitter and may also check whether the submitter is allowed to post the draft. If the submitter is authorized, the draft is immediately posted, deleted from the staging area, and the submitter is notified of the result via email and a Receipt page (Section 9).
自动投递：如果提交人决定从检查页面进行自动投递，系统将对提交人进行身份验证，并可能检查是否允许提交人投递草稿。如果提交人获得授权，草案将立即发布，从暂存区删除，并通过电子邮件和收据页面通知提交人结果（第9节）。
Manual adjustment and posting: If the submitter decides to adjust the meta-data, the draft remains in the Toolset staging area, and the Adjust action (Section 10) presents the submitter with an Adjust page (Section 11). When the submitter makes the adjustments and proceeds with manual posting, a pointer to the stored draft and its adjusted meta-data is sent to the Secretariat for manual
手动调整和发布：如果提交人决定调整元数据，草稿将保留在工具集暂存区域，调整操作（第10节）将向提交人显示调整页面（第11节）。当提交人进行调整并继续手动过账时，将向秘书处发送指向存储的草稿及其调整后元数据的指针，以供手动过账
processing (Section 12). The submitter is notified of the pending Secretariat request via email and a Receipt page.
处理（第12节）。提交人通过电子邮件和收据页面收到待决秘书处请求的通知。
Cancellation: If the submitter decides to explicitly cancel the submission, the submission state (including the draft) is immediately deleted from the Toolset staging area and an appropriate Receipt page is generated without further actions (R123/a). Cancellation of posted drafts is out of this document scope.
取消：如果提交人决定明确取消提交，提交状态（包括草稿）将立即从工具集暂存区域中删除，并生成相应的接收页面，无需进一步操作（R123/a）。已过账汇票的取消不在此文档范围内。
Receipt page: Contains details of a successful or failed draft submission and informs the submitter of the next appropriate step(s) related to submission result.
接收页：包含成功或失败的草稿提交的详细信息，并通知提交人与提交结果相关的下一个适当步骤。
The following informal diagram illustrates the basic submission logic:
以下非正式图表说明了基本提交逻辑：
/---> Post Now
/
Upload --> Check -+-----> Adjust ---> Send to Secretariat
\
\---> Cancel
/---> Post Now
/
Upload --> Check -+-----> Adjust ---> Send to Secretariat
\
\---> Cancel
If the submitter does nothing while the Toolset is expecting some response, the abandoned submission times out (R124/a). The timeout value depends on the submission state. Hint: A timeout value of one hour is probably large enough unless the Toolset is waiting for some kind of a 3rd party confirmation (e.g., WG Chair approval). Doing nothing is functionally equivalent to explicitly canceling the submission, except that explicit cancellation requires immediate removal of submission state while the state of submissions marked as abandoned is garbage-collected.
如果提交者在工具集期待响应时什么也不做，则放弃的提交将超时（R124/a）。超时值取决于提交状态。提示：一小时的超时值可能足够大，除非工具集正在等待某种第三方确认（例如，工作组主席批准）。不执行任何操作在功能上等同于显式取消提交，只是显式取消需要立即删除提交状态，而标记为放弃的提交状态是垃圾收集的。
The staging area maintenance algorithms must keep the area in a consistent, correct state in the presence of denial-of-service (DoS) attacks attempting to overwhelm the area with fake submissions in various stages (R67/a). Hint: denial of service to legitimate users is acceptable under DoS attack conditions, but corruption of the storage area is not.
在出现拒绝服务（DoS）攻击时，暂存区维护算法必须保持该区域处于一致、正确的状态，这些攻击试图在各个阶段以虚假提交覆盖该区域（R67/a）。提示：在DoS攻击条件下，对合法用户的拒绝服务是可以接受的，但存储区域的损坏是不能接受的。
The "web pages" this text is referring to are distinct dialogs that may be visible to the submitter under the same or different URL and that are supported by a single or several server-side programs.
本文所指的“网页”是不同的对话框，提交者可以在相同或不同的URL下看到这些对话框，并且这些对话框由一个或多个服务器端程序支持。
The Toolset must handle multiple submitters simultaneously submitting the same draft (R72/a) and a single submitter simultaneously submitting two drafts (R73/a). The latter might happen, for example, when the submitter is using several browser windows to submit several
该工具集必须处理多个提交人同时提交同一草稿（R72/a）和一个提交人同时提交两份草稿（R73/a）。后者可能发生，例如，当提交者使用多个浏览器窗口提交多个文件时
drafts or is submitting drafts via email interface. The term "simultaneously" means that submission processing times overlap.
草稿或正在通过电子邮件界面提交草稿。术语“同时”表示提交处理时间重叠。
Hint: Except for the Upload page, pages contain a submission session identifier to provide actions with access to stored information. The identifier is specific to the submission rather than the draft version or the submitter. While the nature of the web interface allows the session identifier to be invisible to the submitter, email communication would need to identify the session so that the recipient (and Toolset) know the context.
提示：除上载页面外，页面包含提交会话标识符，以提供对存储信息的访问权限。标识符特定于提交文件，而不是草稿版本或提交人。虽然web界面的性质允许提交者看不到会话标识符，但电子邮件通信需要识别会话，以便收件人（和工具集）知道上下文。
Hint: A single action may correspond to multiple server-side programs and, vice versa, a single program may implement several actions. This document does not mandate any specific technology (e.g., Common Gateway Interface (CGI), PHP, and/or Java servlets) to implement server-side support. The implementer experience, code reuse across web and email interfaces, and other factors will determine the right technology choice.
提示：单个操作可能对应于多个服务器端程序，反之亦然，单个程序可能实现多个操作。本文档不强制使用任何特定技术（例如，公共网关接口（CGI）、PHP和/或Java servlet）来实现服务器端支持。实现者经验、跨web和电子邮件接口的代码重用以及其他因素将决定正确的技术选择。
Hint: Actions preserve and exchange state by storing it along with the draft. Grouping all submission-specific information in one subdirectory named using the session identifier may increase robustness and simplify debugging. Session creation and destruction can then be logged in a global index.
提示：操作通过将状态与草稿一起存储来保存和交换状态。将所有提交特定的信息分组到一个使用会话标识符命名的子目录中，可以提高健壮性并简化调试。然后，会话创建和销毁可以记录在全局索引中。
Ways to partially or completely bypass the Toolset are documented in Section 14.
部分或完全绕过工具集的方法见第14节。
It must be possible to transfer the Toolset from one management team to another, to incorporate work by volunteers, and to allow for public review of the developed code. To meet these goals, the Toolset source codes should be publicly available (R152/b) and there should be an interface to report bugs and request enhancements (R145/b). Development should be structured to avoid lock-in to proprietary platforms or backends. The Tools team believes that developing the Toolset sources under one or more open source licenses following the Open Source Definition [OSD] would provide an effective way of meeting these requirements at reasonable cost. Care should be taken that the licenses selected allow code from different implementers to be mixed.
必须能够将工具集从一个管理团队转移到另一个管理团队，纳入志愿者的工作，并允许公众审查已开发的代码。为了实现这些目标，工具集源代码应该是公开的（R152/b），并且应该有一个报告bug和请求增强的接口（R145/b）。开发的结构应避免锁定到专有平台或后端。工具团队认为，按照开源定义[OSD]在一个或多个开源许可证下开发工具集源代码将提供一种以合理成本满足这些要求的有效方法。应注意选择的许可证允许来自不同实现者的代码混合。
Hint: Placing the Toolset source repository at an open-source-friendly project management site like SourceForge.net would provide the IETF community with a decent, ready-to-use interface to access the code, documentation, bug reports, and discussion forums. Establishing and documenting a simple interface between the Toolset and external software (e.g., the Secretariat draft posting scripts) would facilitate availability checks.
提示：将工具集源代码存储库放置在开源友好的项目管理站点（如SourceForge.net）将为IETF社区提供一个体面的、随时可用的界面，以访问代码、文档、错误报告和讨论论坛。在工具集和外部软件（如秘书处张贴脚本草稿）之间建立并记录一个简单的接口，将有助于检查可用性。
The Toolset is meant to be compatible with the Secretariat's tools for handling drafts. Hint: Such compatibility can be achieved by appropriately implementing the Toolset or, in some cases, by modifying existing Secretariat tools.
该工具集旨在与秘书处处理草稿的工具兼容。提示：这种兼容性可以通过适当地实现工具集，或者在某些情况下，通过修改现有的秘书处工具来实现。
To upload a draft, the submitter goes to a well-known page on the IETF web site (R1/b). There, the draft text can be uploaded using an HTML file upload form. This form provides fields to upload the plain text format of the draft (R2/a) and all other formats allowed by IETF draft publication rules (R3/b). At the time of writing, these formats are: XML ([RFC2629] and [writing-rfcs]), PDF, and PostScript.
为了上传草稿，提交人进入IETF网站（R1/b）上的知名页面。在那里，可以使用HTML文件上传表单上传草稿文本。此表单提供了用于上传草案纯文本格式（R2/a）和IETF草案发布规则（R3/b）允许的所有其他格式的字段。在撰写本文时，这些格式是：XML（[RFC2629]和[writing RFC]）、PDF和PostScript。
Submitted forms are handled by the Check action documented in Section 7.
提交的表格由第7节中记录的检查行动处理。
The Upload page also has a validate-only flag, indicating that an uploaded draft must not be posted and may be deleted immediately after the validation (R74/b). Regardless of the validation results, the stored draft meta-data is marked so that validation-only drafts can be identified and deleted first by garbage collector for the Toolset staging area (R75/b). Drafts uploaded in a validate-only mode cannot be posted (R76/b); they would need to be uploaded again, without the validate-only flag, and the validation results page should explain that (R77/b). This flag is useful for tools using online validation, especially for bulk draft processing. Hint: it may be better to implement this flag as a hidden HTML input field to simplify the interface for human submitters.
上传页面还有一个仅验证标志，表示上传的草稿不得发布，并可在验证后立即删除（R74/b）。不管验证结果如何，存储的草稿元数据都会被标记，以便工具集暂存区域（R75/b）的垃圾收集器可以首先识别和删除仅验证草稿。以仅验证模式上载的草稿无法发布（R76/b）；它们需要再次上传，没有validate only标志，validation results页面应该对此进行解释（R77/b）。此标志对于使用在线验证的工具非常有用，特别是对于批量草稿处理。提示：最好将此标志实现为隐藏的HTML输入字段，以简化人类提交者的界面。
The Check action preprocesses a submission, generates plain text format (if needed, see R70), stores the submitted draft (all formats) in the staging area, and then extracts meta-data and validates each format (R6/a). Errors and warnings are indicated to the submitter in the response via computer-friendly tag(s) and human-friendly text (R7/a).
检查操作预处理提交，生成纯文本格式（如果需要，请参见R70），将提交的草稿（所有格式）存储在暂存区域，然后提取元数据并验证每种格式（R6/a）。在回复中，通过计算机友好标签和人类友好文本（R7/a）向提交人指示错误和警告。
If any error is found, automated posting becomes impossible (R113/a). This rule applies to all errors, even those that do not refer to R113 and do not explicitly prohibit automated posting. If automated posting is not possible, the Toolset still gives the submitter an option of sending the draft for manual validation and posting (R114/a). Since each submission is treated in isolation, the submitter also has an option of correcting the problem and resubmitting the draft for automated posting.
如果发现任何错误，则无法自动过帐（R113/a）。此规则适用于所有错误，即使是那些不涉及R113且未明确禁止自动过帐的错误。如果无法实现自动过帐，则该工具集仍为提交人提供发送草稿以进行手动验证和过帐（R114/a）的选项。由于每次提交都是单独处理的，提交人还可以选择更正问题并重新提交草稿以进行自动发布。
The manual validation and posting route is a Toolset bypass mechanism (see Section 14) not meant for fixing problems with the draft itself. The Secretariat does not generally correct submitted drafts. If the draft needs tweaking to match submitter's intent, then the draft should be corrected by the submitter and resubmitted.
手动验证和发布路线是一种工具集旁路机制（见第14节），不用于解决草稿本身的问题。秘书处一般不更正提交的草案。如果草稿需要调整以符合提交人的意图，则提交人应更正草稿并重新提交。
It is an error to submit a draft that has neither plain text nor XML source format (R68/a). XML source is acceptable without accompanying plain text only if the Toolset successfully generates a draft in plain text format from the XML source, as a part of the processing step documented below (R69/b). These rules imply that PDF- or PostScript-only drafts cannot be auto-posted. Moreover, even manual Secretariat involvement cannot help with posting these drafts, as the IETF policy is to always require a plain text format in addition to PDF or PostScript. Furthermore, drafts containing PDF or PostScript format must not be auto-posted until the Toolset can validate that their content matches the plain text format (R143/a).
提交既没有纯文本也没有XML源格式（R68/a）的草稿是错误的。只有当工具集成功地从XML源生成纯文本格式的草稿时，作为下面记录的处理步骤（R69/b）的一部分，才可以接受不附带纯文本的XML源。这些规则意味着PDF或PostScript格式的草稿不能自动发布。此外，即使是秘书处的手动参与也无助于发布这些草案，因为IETF的政策是除了PDF或PostScript之外，始终需要纯文本格式。此外，包含PDF或PostScript格式的草稿在工具集验证其内容与纯文本格式（R143/a）匹配之前不得自动发布。
The draft format acceptance rules above are meant to decrease the chances that multiple posted draft formats for a single draft contain substantially different documents. With experience, the rules may be simplified so that, for example, only submissions containing nothing but XML or plain text sources can be posted without Secretariat involvement and all other submissions require manual actions to match formats or extract meta-data.
上述草案格式接受规则旨在减少单个草案的多个已发布草案格式包含实质性不同文档的可能性。根据经验，这些规则可以简化，例如，只有只包含XML或纯文本来源的提交书可以在没有秘书处参与的情况下发布，而所有其他提交书都需要手动匹配格式或提取元数据。
Submitting compressed drafts is a desirable feature, especially for submitters behind slow or content-altering links. Compressed draft formats may be accepted (R150/c). Compressed formats, if any, must be decompressed during the preprocessing step (R151/c) so that other processors do not have to deal with compressed formats. Hint: While this specification does not document a list of supported compression standards, it is expected that such popular methods as "zip" and "gzip" should be accepted if compression is supported. Accepting a collection of draft formats within a single compressed archive may also be desirable.
提交压缩草稿是一项理想的功能，特别是对于那些链接速度慢或内容变化大的提交者来说。可接受压缩草稿格式（R150/c）。压缩格式（如果有）必须在预处理步骤（R151/c）期间解压缩，以便其他处理器不必处理压缩格式。提示：虽然本规范没有记录支持的压缩标准列表，但如果支持压缩，则可以接受“zip”和“gzip”等流行方法。在单个压缩档案中接受草稿格式的集合也是可取的。
XML source containing XML processor <rfc? include="..."> instructions (PIs) is preprocessed to include references (R8/b). This step is needed to remove external dependencies from XML sources and to simplify tools processing posted XML. This document refers to such XML processor instructions as "include PIs".
包含XML处理器的XML源<rfc？include=“…”>指令（PI）经过预处理以包含引用（R8/b）。要从XML源中删除外部依赖项并简化处理已发布XML的工具，需要此步骤。本文档引用了“包含PI”等XML处理器指令。
The XML preprocessor uses public database(s) to resolve PI references (R85/b). The Toolset documentation specifies what databases are used and how PIs are mapped to database entries (R86/b). The Toolset must
XML预处理器使用公共数据库解析PI引用（R85/b）。工具集文档指定使用哪些数据库以及如何将PI映射到数据库条目（R86/b）。工具集必须
not rely on PIs' existence (R87/b) because some XML sources will be preprocessed before the submission or will be written without PIs. Hint: Local up-to-date copies of Marshall Rose's reference databases at xml.resource.org can be used.
不要依赖PIs的存在（R87/b），因为一些XML源将在提交之前进行预处理，或者在没有PIs的情况下编写。提示：可以使用xml.resource.org上Marshall Rose参考数据库的本地最新副本。
Both original and preprocessed XML sources may be posted later. The original source with include PIs may be useful to the RFC Editor and generation of diffs (against future or past original sources). The preprocessed source without include PIs becomes the default public XML source of the posted draft (R10/b). If any of the include PIs known to the Toolset cannot be handled, an error is recorded (R11/b), and the submitter is encouraged to do the preprocessing locally, before submitting the draft (R111/b).
原始和预处理的XML源都可能在以后发布。包含PI的原始源可能对RFC编辑器和差异生成（针对未来或过去的原始源）有用。未包含PIs的预处理源将成为已发布草稿（R10/b）的默认公共XML源。如果工具集已知的任何include PI无法处理，则会记录错误（R11/b），并鼓励提交者在提交草稿（R111/b）之前在本地进行预处理。
Uncompressed draft formats other than XML are not preprocessed.
不预处理XML以外的未压缩草稿格式。
When no plain text format of the draft is submitted, but XML sources are available, the Toolset attempts to generate plain text format from submitted XML sources (R70/b).
如果未提交草稿的纯文本格式，但XML源可用，工具集将尝试从提交的XML源（R70/b）生成纯文本格式。
If XML sources are available, the Toolset generates HTML draft format (R112/c). HTML generation failures should result in warnings, not errors (R115/c). HTML generation is not meant to be implemented until the Enhancement Stage is reached (R130/a). In general, HTML generation is desirable because HTML drafts are usually easier to navigate than plain text drafts due to improved overall readability and links. As any Enhancement Stage feature, HTML generation may be dropped or drastically changed to reflect then-current IETF consensus and the experience of the first two implementation stages.
如果XML源可用，该工具集将生成HTML草稿格式（R112/c）。HTML生成失败应导致警告，而不是错误（R115/c）。在达到增强阶段（R130/a）之前，不会实现HTML生成。一般来说，HTML生成是可取的，因为HTML草稿通常比纯文本草稿更容易导航，因为它提高了整体可读性和链接。与任何增强阶段功能一样，HTML生成可能会被删除或彻底更改，以反映当时的IETF共识和前两个实现阶段的经验。
Hint: The Toolset implementers should not assume that draft formats generated by the same tool from the same source format have essentially the same content. The generation tool may have options that allow authors to generate content exclusive to a specific generated format. Such options might be abused.
提示：工具集实现者不应假设由同一工具从同一源格式生成的草稿格式具有基本相同的内容。生成工具可能具有允许作者生成特定生成格式专有内容的选项。这种选择可能被滥用。
The Check action needs to store all draft formats so that successfully validated drafts can later be auto-posted at submitter request. The action stores all submitted formats of the draft in a staging area dedicated to the Toolset (R12/a). If, after garbage collection, the staging area is full (i.e., the total used size has reached the configured maximum capacity), the submitter and the Secretariat are notified of a fatal error (R13/a).
检查操作需要存储所有草稿格式，以便成功验证的草稿可以在提交者请求时自动过帐。该操作将所有提交的草稿格式存储在专用于工具集（R12/a）的暂存区域中。如果在垃圾收集之后，暂存区域已满（即，总使用大小已达到配置的最大容量），则提交者和秘书处将收到致命错误（R13/a）的通知。
The Toolset extracts meta-data from the following stored draft formats: plain text (R131/a), XML (R132/b), and other (R133/c). If a meta-data extraction fails, the Toolset records an error (R15/a). Meta-data extraction is necessary to validate and post the draft. Extraction from all formats is necessary to validate that all meta-data matches across all formats (in addition to and before the Toolset can validate that the contents matches as well).
该工具集从以下存储的草稿格式中提取元数据：纯文本（R131/a）、XML（R132/b）和其他（R133/c）。如果元数据提取失败，工具集将记录错误（R15/a）。元数据提取对于验证和发布草稿是必要的。为了验证所有格式中的所有元数据是否匹配，必须从所有格式中进行提取（在工具集验证内容是否匹配之前）。
Section 16 documents a non-obvious implementation schedule related to the above requirements. When only partial support for format interpretation is available, only interpreted formats are subject to extraction and validation requirements. In other words, if the Toolset does not yet support interpretation of a given format, then the corresponding information is stored and made available "as is", regardless of the actual content.
第16节记录了与上述要求相关的非明显实施时间表。当仅部分支持格式解释时，仅解释的格式受提取和验证要求的约束。换句话说，如果工具集还不支持对给定格式的解释，那么不管实际内容如何，相应的信息都会“按原样”存储和提供。
The draft interpreter extracts the following meta-data from each draft format (R16/a):
草稿解释器从每个草稿格式（R16/a）中提取以下元数据：
identifier: Also known as draft "filename". For example, "draft-ietf-sieve-vacation-13".
标识符：也称为草稿“文件名”。例如，“草案-ietf-SIFE-13”。
version: A non-negative integer number representing draft version number (also known as draft revision number). For example, the number 7 in "draft-ietf-sieve-vacation-07". The number is usually rendered using two digits, padding with "0" if necessary.
版本：表示草稿版本号（也称为草稿修订号）的非负整数。例如，“draft-ietf-sieve-vacation-07”中的数字7。数字通常使用两位数字呈现，必要时用“0”填充。
name: The common part of all draft identifiers for all versions of the same draft. In other words, a draft identifier without the version component. For example, "draft-ietf-sieve-vacation" in "draft-ietf-sieve-vacation-07".
名称：同一草稿的所有版本的所有草稿标识符的公共部分。换句话说，一个没有版本组件的草案标识符。例如，“草案-ietf-SIFE-VAILATE-07”中的“草案ietf筛选假期”。
WG ID: Working Group identifier. For example, "sieve" in "draft-ietf-sieve-vacation-07" is a WG ID. The WG ID value is empty for drafts that are not WG-named drafts.
工作组ID：工作组标识符。例如，“draft-ietf-sieve-vacation-07”中的“sieve”是工作组ID。对于非工作组命名的草稿，工作组ID值为空。
WG flag: True for WGN drafts and false for all other drafts. For example, "true" for "draft-ietf-sieve-vacation-13". This flag only influences the further handling of initial (version 00) draft submissions, as far as the current document is concerned.
WG标志：对于WGN草稿为True，对于所有其他草稿为false。例如，“草案-ietf-SIFE-VIEWATE-13”中的“true”。就当前文件而言，此标志仅影响初始（00版）提交文件草案的进一步处理。
title: A human-friendly draft title. For example, the title of this document is "Requirements for an IETF Draft Submission Toolset".
标题：人性化的草案标题。例如，本文件的标题为“IETF草案提交工具集的要求”。
authors: A list of all draft authors. Each author's name and email address are extracted.
作者：所有草稿作者的列表。提取每个作者的姓名和电子邮件地址。
abstract: The draft abstract text.
摘要：草案摘要文本。
creation date: The draft version creation date.
创建日期：草稿版本创建日期。
expiration date: The draft version expiration date.
失效日期：草稿版本的失效日期。
size: The number of pages and octets in the primary format of the draft. The definition of a page depends on the format and may be imprecise or arbitrary for some formats.
大小：草稿主要格式的页数和八位字节数。页面的定义取决于格式，对于某些格式可能不精确或任意。
Failure to extract any field results in error (R95/a).
未能提取任何字段将导致错误（R95/a）。
The Toolset requires author email addresses because they are essential for notifying co-authors that their draft has been posted. If there are no such notifications, a submitter adding a co-author to the draft without the co-author's consent may not be caught for a while. Such "surprise" co-authorships have happened in the past and can be quite annoying. However, since the Toolset does not solicit co-authors' consent to post a valid draft (and such solicitation would not go beyond email control verification anyway), it is not possible to stop a malicious submitter from adding co-authors without their knowledge.
该工具集需要作者电子邮件地址，因为这些地址对于通知合作作者其草稿已发布至关重要。如果没有此类通知，未经合著者同意向草案中添加合著者的提交人可能暂时不会被抓获。这种“令人惊讶”的合著在过去已经发生过，可能会很烦人。但是，由于该工具集不会征求合著者同意发布有效的草稿（而且这种征求无论如何都不会超出电子邮件控制验证），因此无法阻止恶意提交者在合著者不知情的情况下添加合著者。
Like other meta-data items above, draft creation and expiration dates are extracted from the draft; their values do not depend on the actual submission time (i.e., the time the Check action starts). However, the validation procedure (see Section 7.5) may declare any extracted date invalid after taking into consideration current (i.e., submission) time, IETF draft expiration rules, and other factors external to the draft.
与上面的其他元数据项一样，草稿的创建和到期日期都是从草稿中提取出来的；它们的值不取决于实际提交时间（即检查操作开始的时间）。然而，在考虑到当前（即提交）时间、IETF草案到期规则和草案外部的其他因素后，验证程序（见第7.5节）可宣布任何提取日期无效。
Drafts need to be validated to catch broken submissions. Validation also helps educate or warn authors of problems that may become show-stoppers when the draft is sent for IETF Last Call and IESG review. IETF standards have to follow a set of syntax and semantics requirements (see the "ID-NITS" document at <http://www.ietf.org/ID-Checklist.html>. Most of those requirements are not enforced for Internet-Drafts. However, following them may improve draft quality, reduce the IESG load, and increase the chances of the draft being approved as an RFC.
需要对草稿进行验证，以捕获损坏的提交。验证也有助于教育或警告作者，当草案被发送给IETF最后一次呼叫和IESG审查时，可能会成为表演障碍的问题。IETF标准必须遵循一组语法和语义要求（参见<http://www.ietf.org/ID-Checklist.html>。大多数这些要求不适用于互联网草稿。但是，遵循这些要求可能会提高草稿质量，减少IESG负载，并增加草稿被批准为RFC的机会。
When validating a given draft, it is important to distinguish between absolute requirements and desirable draft properties. Both categories are checked for, but violations have different effects depending on the category. The two categories are detailed in the following subsections.
验证给定草案时，区分绝对要求和理想草案属性是很重要的。这两个类别都会被检查，但违规行为会根据类别的不同而产生不同的影响。以下小节详细介绍了这两个类别。
When a valid draft is being posted and submitter authorization or co-author notification is performed, validation results should be included in the email (R81/b) so that the submitter can see meta-data extraction and validation warnings. Note that these results cannot include errors since only valid drafts can be posted.
发布有效草稿并执行提交人授权或合著者通知时，验证结果应包含在电子邮件（R81/b）中，以便提交人可以看到元数据提取和验证警告。请注意，这些结果不能包含错误，因为只能发布有效的草稿。
Violating any of these requirements would prevent a draft from being automatically posted (R17/a). The offending draft would have to be fixed or submitted for manual posting, with an explanation as to why the absolute requirements need to be violated (or why the Validator mis-detected violations). These explanations may speed up the Secretariat posting decision and may help the Secretariat to improve the Toolset implementation.
违反任何这些要求都会阻止草稿自动发布（R17/a）。有问题的草稿必须修复或提交手动过帐，并解释为什么需要违反绝对要求（或者为什么验证器错误地检测到违反情况）。这些解释可能会加快秘书处的张贴决定，并可能有助于秘书处改进工具集的实施。
1. All available meta-data entries must match across all submitted draft formats (R18/a). For example, if the interpreter managed to extract a draft title from both the plain text and the PDF format, both titles must match. This requirement prevents accidental submission of mismatching formats.
1. 所有可用元数据条目必须在所有提交的草稿格式（R18/a）中匹配。例如，如果口译员设法从纯文本和PDF格式中提取一个草稿标题，则两个标题必须匹配。此要求可防止意外提交不匹配的格式。
2. Version 00 of a Working Group draft has a corresponding Working Group approval (R20/a). This approval can be relayed before or after the first draft submission, by a Chair or Secretary of the WG. See Section 7.5.4 for related requirements.
2. 工作组草案的00版具有相应的工作组批准（R20/a）。该批准可在提交初稿之前或之后由工作组主席或秘书转达。相关要求见第7.5.4节。
3. The draft ID must be correct (R22/a), including the draft version number value and format. Single-digit draft version numbers must be left-padded with "0". Draft version numbers must start with zero and increase by one with every new version. To satisfy this requirement, the Toolset would have to consult the repository of already posted drafts, including expired ones. If the IETF infrastructure cannot handle version numbers greater than 99, the Toolset must reject them (R158/a).
3. 草稿ID必须正确（R22/a），包括草稿版本号值和格式。单位数草稿版本号必须用“0”填充。草稿版本号必须从零开始，每增加一个新版本，就增加一个。为了满足这一要求，工具集必须查阅已经发布的草稿（包括过期的草稿）的存储库。如果IETF基础设施无法处理大于99的版本号，则工具集必须拒绝它们（R158/a）。
4. An IETF IPR Statement and other boilerplate required for drafts according to [RFC3978] and [RFC3979] (or successors) must appear in the draft text (R23/a).
4. 根据[RFC3978]和[RFC3979]（或后续文件）起草的草案所需的IETF IPR声明和其他样板必须出现在草案文本（R23/a）中。
5. The extracted creation date of the draft version must be within 3 days of the actual submission date (R159/a). Hint: Implementers should be careful to handle creation dates that appear to be in the past or in the future, due to possible time zone differences. Making the most forgiving/permissive assumption about the time zone should suffice.
5. 草稿版本的提取创建日期必须在实际提交日期（R159/a）后3天内。提示：由于可能的时区差异，实现者应该小心处理似乎在过去或将来的创建日期。对时区做出最宽容/宽容的假设就足够了。
6. The draft version expiration date obeys IETF draft expiration rules.
6. 草稿版本的到期日期遵循IETF草稿到期规则。
7. No IETF submission blackout period applies. Hint: IETF blackouts must be enforced based on submission time, not possible draft creation time.
7. 不适用IETF提交中断期。提示：IETF断电必须基于提交时间，而不是可能的草稿创建时间。
8. Posting the draft must not result in any DoS attack threshold to be crossed (R97/a). Specific thresholds are documented in Section 7.5.3.
8. 发布草稿不得导致超过任何DoS攻击阈值（R97/a）。具体阈值记录在第7.5.3节中。
9. XML sources (if available) are valid with respect to the XML format [XML] (R153/c) and XML Document Type Definition (DTD) for IETF drafts (R154/c). Note that during the first two implementation stages, the corresponding validation failures result in warnings and not errors (see Section 7.5.2).
9. XML源（如果可用）对于IETF草案（R154/c）的XML格式[XML]（R153/c）和XML文档类型定义（DTD）是有效的。请注意，在前两个实施阶段，相应的验证失败会导致警告而不是错误（参见第7.5.2节）。
The XML DTD for IETF drafts is documented in [RFC2629] with recent changes available in [writing-rfcs]. Hint: Bill Fenner's "RFC 2629 validator" at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ (or its derivative) may be useful for XML format and DTD validation.
IETF草案的XML DTD记录在[RFC2629]中，最近的更改可在[writing RFC]中获得。提示：Bill Fenner的“RFC 2629验证器”位于http://rtg.ietf.org/~fenner/ietf/xml2rfc valid/（或其衍生物）可能对XML格式和DTD验证有用。
Hint: If the extracted meta-data differs in the submitted draft formats, the Toolset should use the meta-data from the most "formal" format when populating the form entries for manual submission. On the other hand, if most extracted entries come from a less "formal" format, the Toolset may choose that format instead. For example, XML source can be considered more "formal" than plain text format. The Toolset may also offer the submitter an option to specify which format should be used for populating the form. It is probably a bad idea to mix-and-match the conflicting entries extracted from multiple formats. Instead, either one format should be chosen when populating the form or the form should contain several meta-data sections, one for each format. The error messages will contain the exact mismatch information.
提示：如果提取的元数据与提交的草稿格式不同，则在填充手动提交的表单条目时，工具集应使用最“正式”格式的元数据。另一方面，如果大多数提取的条目来自不太“正式”的格式，则工具集可能会选择该格式。例如，可以认为XML源比纯文本格式更“正式”。该工具集还可以为提交者提供一个选项，以指定填充表单时应使用的格式。混合和匹配从多种格式中提取的冲突条目可能不是一个好主意。相反，填充表单时应选择一种格式，或者表单应包含多个元数据部分，每种格式一个。错误消息将包含确切的不匹配信息。
Hint: The Toolset should accept dates without the day of the month, as long as IETF rules do not prohibit them. The Toolset should make the most forgiving/permissive assumption about the actual day of the month when validating day-less dates.
提示：只要IETF规则不禁止日期，工具集应该接受不带月日的日期。在验证无天数日期时，工具集应该对当月的实际日期做出最宽容/允许的假设。
Violating any of the following requirements does not prevent the submitter from auto-posting the draft (R24/a) but results in a warning (R160/a). Each warning explains the corresponding violation and provides advice on how to comply (R161/b). Hint: To ease maintenance and encourage 3rd party updates, detailed explanations
违反以下任何要求都不会阻止提交人自动发布草稿（R24/a），但会导致警告（R160/a）。每个警告都解释了相应的违规行为，并提供了如何遵守的建议（R161/b）。提示：为了便于维护和鼓励第三方更新，请提供详细说明
and/or advice may be available as a resource separate from the Toolset.
和/或建议可以作为工具集之外的资源提供。
1. All automatically testable nits in the "ID-NITS" document at <http://www.ietf.org/ID-Checklist.html> (R116/b) and automatically testable guidelines at <http://www.ietf.org/ietf/1id-guidelines.txt> (R157/b). The Toolset should use external tools to check these nits and guidelines rather than embed checking code (R117/a). Hint: Henrik Levkowetz's idnits tool can be used (http://tools.ietf.org/tools/idnits/) and other tools can be written or adopted.
1. 位于“ID-nits”文档中的所有自动可测试NIT<http://www.ietf.org/ID-Checklist.html>（R116/b）和自动测试指南<http://www.ietf.org/ietf/1id-guidelines.txt>（R157/b）。工具集应该使用外部工具来检查这些NIT和指南，而不是嵌入检查代码（R117/a）。提示：可以使用Henrik Levkowetz的idnits工具(http://tools.ietf.org/tools/idnits/)可以编写或采用其他工具。
2. New draft versions are expected (R21/b). For example, version 00 of an individual draft is always expected, while posting a new version of a draft already under the IESG review should generate a warning.
2. 预计会有新的草案版本（R21/b）。例如，个人草稿的版本00总是预期的，而发布已在IESG审查中的草稿的新版本时，应生成警告。
3. If both XML and plain text formats are submitted, the submitted plain text matches what can be generated based on submitted XML (R146/b).
3. 如果提交了XML和纯文本格式，则提交的纯文本与基于提交的XML（R146/b）生成的内容相匹配。
4. The previous version, if any, was posted at least 24 hours ago (R96/b). This warning may prevent some human errors, especially when multiple authors may post the same draft.
4. 以前的版本（如有）至少在24小时前发布（R96/b）。此警告可能会防止某些人为错误，尤其是当多个作者可能发布同一草稿时。
5. XML sources (if available) are valid with respect to the XML format (R155/b) and XML DTD for IETF drafts (R156/b). These requirements become absolute after the second implementation phase. See Section 7.5.1 for related information.
5. XML源（如果可用）对于XML格式（R155/b）和IETF草案的XML DTD（R156/b）是有效的。在第二个实施阶段之后，这些要求变得绝对。有关信息，请参见第7.5.1节。
When comparing generated and submitted plain text formats to satisfy R146, a standard word-based diff is sufficient for initial Toolset implementations (R147/b). However, a custom fuzzy matching function can be developed (R148/c) to minimize false warnings due to, for example, draft text formatting differences. When differences are detected, a complete diff may be provided on a separate page (R149/c), in addition to the warning.
当比较生成和提交的纯文本格式以满足R146的要求时，基于单词的标准差异对于初始工具集实现（R147/b）就足够了。但是，可以开发自定义模糊匹配功能（R148/c），以最大限度地减少由于草稿文本格式差异等原因而产生的错误警告。当检测到差异时，除了警告之外，还可以在单独的页面（R149/c）上提供完整的差异。
Hint: When comparing generated and submitted plain text formats, the Toolset may try several recent xml2rfc versions for plain text generation, to eliminate warnings due to differences among xml2rfc versions.
提示：在比较生成的和提交的纯文本格式时，工具集可能会尝试使用几个最新的xml2rfc版本生成纯文本，以消除由于xml2rfc版本之间的差异而产生的警告。
The following table documents DoS attack thresholds for various draft categories. Daily limits correspond to all drafts (and all draft formats) within the category. Other thresholds may be introduced and these initial thresholds may be adjusted as necessary. The thresholds are likely to become more smart/dynamic with experience.
下表记录了各种草案类别的DoS攻击阈值。每日限额对应于类别内的所有草稿（和所有草稿格式）。可引入其他阈值，并可根据需要调整这些初始阈值。根据经验，阈值可能会变得更加智能/动态。
DoS attack thresholds:
拒绝服务攻击阈值：
+---------------------------------+--------------+-----------+
| category | versions/day | MB/day |
+---------------------------------+--------------+-----------+
| drafts with the same draft name | 3 | 5 |
| drafts with the same submitter | 10 | 15 |
| WGN drafts with the same WG ID | 30 | 45 |
| all drafts | 400 | 200 |
+---------------------------------+--------------+-----------+
+---------------------------------+--------------+-----------+
| category | versions/day | MB/day |
+---------------------------------+--------------+-----------+
| drafts with the same draft name | 3 | 5 |
| drafts with the same submitter | 10 | 15 |
| WGN drafts with the same WG ID | 30 | 45 |
| all drafts | 400 | 200 |
+---------------------------------+--------------+-----------+
The thresholds are meant to limit destructive effects of DoS attacks (e.g., full disks cause other tasks to fail), allow for capacity planning (e.g., how much storage space the Toolset needs), and limit annoying side effects of "too many" drafts being posted (e.g., when a person receives posting notifications about a given draft or a given working group). The Toolset should warn the Secretariat if total submissions are approaching any threshold (R134/b). Hint: Bandwidth available for submissions may need to be throttled (on a network subnet basis?) to make reaching the daily size quota (with malicious intent) difficult.
这些阈值旨在限制DoS攻击的破坏性影响（例如，磁盘已满导致其他任务失败），允许容量规划（例如，工具集需要多少存储空间），并限制发布“过多”草稿的恼人副作用（例如，当一个人收到关于给定草稿或给定工作组的发布通知时）。如果提交的总数量接近任何阈值（R134/b），该工具集应警告秘书处。提示：可能需要限制提交可用的带宽（基于网络子网？），以达到每日大小配额（怀有恶意）困难。
For version 00 of a WGN draft, the Toolset checks for an existing WG approval (R125/a). If (a) no approval exists, and (b) the Toolset does not support the "waiting for WG approval" feature, the Toolset records an error (R135/a).
对于WGN草案的版本00，工具集检查现有的工作组批准（R125/a）。如果（a）不存在批准，并且（b）工具集不支持“等待工作组批准”功能，工具集将记录错误（R135/a）。
If (a) no approval exists, (b) the Toolset supports the "waiting for WG approval" feature, and (c) the draft cannot be posted even if WG approval is received, then the Toolset records a warning that a WG approval would be required once all errors preventing draft from posting are fixed (R137/b).
如果（a）不存在批准，（b）工具集支持“等待工作组批准”功能，以及（c）即使收到工作组批准，也无法发布草稿，则工具集会记录一条警告，即一旦所有阻止草稿发布的错误得到纠正，就需要工作组批准（R137/b）。
If (a) no approval exists, (b) the Toolset supports the "waiting for WG approval" feature, and (c) the draft can be posted if WG approval is received, then the Toolset explains the situation to the submitter and asks whether an explicit approval from the WG should be solicited or expected (R126/b). If the approval should be solicited, it is
如果（a）不存在批准，（b）工具集支持“等待工作组批准”功能，以及（c）如果收到工作组批准，则可以发布草稿，然后工具集向提交人解释情况，并询问是否应征求或期望工作组的明确批准（R126/b）。如果应该征求批准，则为
solicited by the software or the submitter. If appropriate, the Toolset puts the submission into a "waiting for WG approval" state until the expected approval is available (R127/b). Otherwise, the Toolset records a "no WG approval is expected" error (R138/b).
由软件或提交者请求。如果合适，该工具集将提交文件置于“等待工作组批准”状态，直到预期批准可用（R127/b）。否则，工具集会记录一个“不需要工作组批准”错误（R138/b）。
The details of manual or automated solicitation for WG approval is outside the scope of this document. Hint: Initially, the submitter will be responsible for soliciting a WG Chair approval, but this process should eventually be automated.
手动或自动征求工作组批准的详细信息不在本文件范围内。提示：最初，提交人将负责征求工作组主席的批准，但这个过程最终应该是自动化的。
Details of the approval recording and access interfaces as well as the mechanism to resume the submission upon approval are out of this document's scope.
批准记录和访问接口的详细信息以及批准后恢复提交的机制不在本文件范围内。
The Check page, created by the Check action, displays extracted draft meta-data and validation results (R25/a). The purpose of the page is to allow the submitter to verify whether the stored draft and automatically extracted meta-data match the submitter's intent and to be informed of validation problems.
由检查操作创建的检查页面显示提取的草稿元数据和验证结果（R25/a）。该页面的目的是允许提交人验证存储的草稿和自动提取的元数据是否符合提交人的意图，并告知验证问题。
Meta-data items specified in Section 7.4 that failed validation checks must be marked specially (rather than silently omitted or ignored) (R26/b). Hint: rendering those items in red, with links to corresponding validation errors or warnings, may force authors to pay attention.
第7.4节中规定的未通过验证检查的元数据项必须特别标记（而不是默默省略或忽略）（R26/b）。提示：将这些项目呈现为红色，并带有相应验证错误或警告的链接，可能会迫使作者注意。
Validation messages include both errors and warnings. Each validation message refers to normative document(s) containing the corresponding validation rules (R27/b).
验证消息包括错误和警告。每个验证信息均指包含相应验证规则（R27/b）的规范性文件。
The Check page allows the submitter to enter external meta-data (Section 8.1) (R28/a). If validation was successful, an "automatically post the draft now" button is provided (R29/a). Regardless of validation results, "adjust and post manually" and "cancel" buttons are provided (R30/a).
检查页面允许提交人输入外部元数据（第8.1节）（R28/a）。如果验证成功，将提供“立即自动发布草稿”按钮（R29/a）。无论验证结果如何，都会提供“手动调整和发布”和“取消”按钮（R30/a）。
The Check page provides a preview of the draft plain text format (R31/a), with a link to see how the entire draft (with all its formats) would look if posted (R82/b). Hint: the Check page preview should be sufficiently long to let authors detect obvious draft mismatch or misinterpretation errors but short enough to avoid dominating the page. Displaying the first line of the draft through the last line of the abstract may be sufficient.
检查页面提供草稿纯文本格式（R31/a）的预览，并提供一个链接，以查看整个草稿（及其所有格式）在发布（R82/b）时的外观。提示：检查页面预览应该足够长，以让作者检测到明显的草稿不匹配或误解错误，但要足够短，以避免占据页面的主导地位。将草稿的第一行显示到摘要的最后一行就足够了。
For draft updates, the Check page reports the time and the submitter of the last update (R83/b). This information is especially useful
对于草稿更新，检查页面报告上次更新的时间和提交者（R83/b）。这些信息特别有用
when multiple authors are working on the same draft. The page also provides a link to generate a diff against the last posted version (R84/c).
当多个作者在同一草稿上工作时。该页面还提供了一个链接，用于根据上次发布的版本（R84/c）生成差异。
The Check page solicits the following meta-data from the submitter. This information must be supplied by submitter because it cannot be extracted from the draft:
检查页面向提交者请求以下元数据。此信息必须由提交人提供，因为无法从草稿中提取：
Submitter email address (R32/a). When submitter is not an expected submitter (see Section 3), automated posting is not possible and the draft has to go through the Secretariat (R98). Hint: A set of checkboxes next to extracted author names along with a "none of the above" checkbox with an input field would suffice. A list of drafts replaced by this draft (R33/c). This is useful to make replaced drafts invisible. This document does not specify any actions necessary to actually replace an existing draft because existing draft manipulation is out of scope, and because security concerns and other complications of such actions would be better addressed by a separate specification. Primary email address for discussion of this draft (R71/b). Hint: The Toolset can suggest the WG mailing list address for WGN drafts, (submitting) author address for individual drafts, or even the first email address in draft text. Offering a few likely addresses instead of relying exclusively on user input would also reduce the number of typos.
提交人电子邮件地址（R32/a）。如果提交人不是预期的提交人（见第3节），则不可能自动过账，草案必须通过秘书处（R98）。提示：在提取的作者姓名旁边有一组复选框，再加上一个带有输入字段的“none of the Over”复选框就足够了。由本草案（R33/c）替换的草案列表。这有助于使替换的草稿不可见。本文件未规定实际替换现有草案所需的任何行动，因为现有草案操纵超出范围，并且此类行动的安全问题和其他复杂问题最好通过单独的规范解决。讨论本草案的主要电子邮件地址（R71/b）。提示：该工具集可以建议WGN草稿的工作组邮件列表地址，个人草稿的作者地址，甚至草稿文本中的第一个电子邮件地址。提供一些可能的地址，而不是完全依赖用户输入，也可以减少打字错误的数量。
Except for the submitter email address, external meta-data is optional (R109/a).
除了提交者的电子邮件地址外，外部元数据是可选的（R109/a）。
If a given submitter email address belongs to an expected submitter (i.e., belongs to one of the categories below), the Toolset performs submitter authentication during a Post Now action (R19/a). Otherwise, an error is reported (R118/a).
如果给定的提交者电子邮件地址属于预期的提交者（即，属于以下类别之一），则工具集在立即发布操作（R19/a）期间执行提交者身份验证。否则，将报告错误（R118/a）。
The following possible expected submitters are identified by the Toolset, without any Secretariat intervention:
工具集确定了以下可能的预期提交人，无需秘书处干预：
For version 00 of a draft, any submitter (R119/a). For version N+1 of a draft, an author of version N of the same draft (R120/a). This requirement only needs to be satisfied for drafts for which Nth version was posted using the Toolset; other drafts may not have the meta-information available that is required to reliably get a list of authors. For a WGN draft, a Chair of the corresponding WG (R121/b). For any draft, an IESG member (R122/c).
对于草案的00版，任何提交人（R119/a）。对于草案的N+1版，指同一草案（R120/a）的N版作者。仅当使用工具集发布了第N个版本的草稿时，才需要满足此要求；其他草稿可能没有可靠获取作者列表所需的元信息。对于工作组草案，由相应工作组的主席（R121/b）主持。对于任何草案，IESG成员（R122/c）。
The Post Now action checks that the draft has been successfully validated (R34/a), validates external meta-data (including submitter email address) (R35/a), and posts the draft (R36/a). The submitter is notified of the action progress and the final result (R37/a).
立即发布操作检查草稿是否已成功验证（R34/a），验证外部元数据（包括提交者电子邮件地址）（R35/a），并发布草稿（R36/a）。将行动进度和最终结果通知提交人（R37/a）。
The external meta-data contains the submitter's email address. As a part of the validation procedure, the Post Now action authorizes the submitter. The initial action implementation checks that the submitter has access to email sent to that address (R38/a). Eventually, the Toolset should accept client certificates signed by IETF, PGP-signed email, and/or other forms of client-side authentication to eliminate the weak and annoying email access check (R110/c). If submitter authentication fails, the submission eventually and silently times out (R39/a).
外部元数据包含提交者的电子邮件地址。作为验证程序的一部分，立即发布行动授权提交人。初始操作实施检查提交者是否有权访问发送到该地址（R38/a）的电子邮件。最后，该工具集应该接受IETF签署的客户端证书、PGP签署的电子邮件和/或其他形式的客户端身份验证，以消除弱而烦人的电子邮件访问检查（R110/c）。如果提交者身份验证失败，提交最终会自动超时（R39/a）。
The Toolset provides both web (R99/a) and email (R139/b) interfaces for confirming email access. Hint: To check submitter's access to email, the tool can email a hard-to-guess cookie or token to the submitter's address. To continue with the submission, the submitter is requested to paste the cookie at the specified URL, go to the token-holding URL, or respond to the email.
该工具集提供了确认电子邮件访问的web（R99/a）和电子邮件（R139/b）界面。提示：要检查提交者对电子邮件的访问，该工具可以通过电子邮件将难以猜测的cookie或令牌发送到提交者的地址。若要继续提交，将要求提交者将cookie粘贴到指定的URL、转到令牌持有URL或回复电子邮件。
Immediately after sending an email to the submitter, the Post Now action generates an intermediate Receipt page that explains Toolset expectations and provides the submitter with the submission ID (R100/a). That number allows the Secretariat to troubleshoot stuck submissions (R101/a) and can also be used for checking submission status without Secretariat involvement (R140/b).
在向提交人发送电子邮件后，立即发布操作将生成一个中间回执页面，该页面解释工具集期望值，并向提交人提供提交ID（R100/a）。该编号允许秘书处对卡住的提交进行故障排除（R101/a），也可用于检查提交状态，无需秘书处参与（R140/b）。
Immediately after posting the draft, the Toolset notifies all authors (with known email addresses) of the posting (R102/a). The notification email contains the information available on the "successful posting" Receipt page described below (R103/a).
发布草稿后，工具集立即通知所有作者（使用已知的电子邮件地址）发布（R102/a）。通知电子邮件包含下文所述的“成功投递”回执页面（R103/a）上的可用信息。
If draft posting is successful, the submission state is marked as available for deletion (R105/a) so that the garbage collection routine eventually deletes it.
如果草稿发布成功，提交状态将标记为可删除（R105/a），以便垃圾收集例程最终将其删除。
A successful Post Now action reports at least the following information on the final Receipt page (R104/a):
成功的“立即发布”操作会在最终接收页面（R104/A）上报告至少以下信息：
o the draft ID and a link to the draft status page.
o 草稿ID和指向草稿状态页面的链接。
o the draft title, authors, and abstract.
o 标题草案、作者和摘要。
o the submission ID.
o 提交ID。
o a link to the draft submission status page (when status queries are supported, see R140).
o 指向草稿提交状态页面的链接（支持状态查询时，请参阅R140）。
o the submitter's name and email address.
o 提交者的姓名和电子邮件地址。
The primary purpose of the Receipt page is to inform all draft authors that (supposedly) their draft has been posted. The secondary purpose is to let authors create a permanent record of the event and troubleshoot postings. The same information should be sent to other parties interested in the draft (e.g., to the WG mailing list), but 3rd-party notification specifics are out of this document's scope.
收据页面的主要目的是通知所有草稿作者他们的草稿已经过账。第二个目的是让作者创建事件的永久记录，并对发布进行故障排除。同样的信息应发送给对草案感兴趣的其他各方（例如，工作组邮件列表），但第三方通知细节不在本文件范围内。
The Adjust action generates the Adjust page (R40/a), populating it with available extracted meta-data and external meta-data, as well as validation results and a preview. Some information may be missing, depending on draft interpretation and the success of preview generation.
调整操作生成调整页面（R40/a），用可用的提取元数据和外部元数据以及验证结果和预览填充该页面。某些信息可能会丢失，具体取决于草案解释和预览生成的成功与否。
The Adjust page includes the same information as the Check page, but allows the submitter to adjust all extracted draft meta-data (and, naturally, external meta-data) at will (R41/a). Such adjustment is necessary when automated extraction failed to extract correct information. To avoid any mismatch between draft and its meta-data, adjusted drafts cannot be automatically posted and require manual validation by the Secretariat (R42/a). Secretariat staff can post drafts with adjusted meta-data as described in Section 14.
调整页面包含与检查页面相同的信息，但允许提交者随意调整所有提取的草稿元数据（当然还有外部元数据）（R41/a）。当自动提取无法提取正确信息时，需要进行此类调整。为避免草稿与其元数据之间的任何不匹配，调整后的草稿不能自动过账，需要秘书处手动验证（R42/a）。如第14节所述，秘书处工作人员可以发布带有调整后元数据的草稿。
The Adjust page allows the submitter to enter an informal comment explaining why adjustments are necessary and automated posting mode cannot be used (R48/a). Such comments may be essential for the Secretariat in their efforts to troubleshoot the problem.
“调整”页面允许提交人输入非正式评论，解释为什么需要进行调整且无法使用自动过帐模式（R48/a）。这些评论可能对秘书处解决问题的努力至关重要。
The "post manually" and "cancel" buttons are provided (R43/a). The former is backed by the Post Manually action (Section 12).
提供“手动投递”和“取消”按钮（R43/a）。前者由手动后操作（第12节）支持。
The Post Manually action sends adjusted meta-data and a draft pointer to the Secretariat for manual validation and posting (R44/a). A receipt page is generated, instructing the submitter to wait (R45/a). The Secretariat will notify the submitter once the draft is posted or rejected. This notification is sent by the Toolset if the Secretariat is using the Toolset to post the draft (R46/a).
“手动过账”行动将调整后的元数据和草稿指针发送至秘书处，以进行手动验证和过账（R44/a）。生成接收页面，指示提交者等待（R45/A）。一旦草案被张贴或拒绝，秘书处将通知提交人。如果秘书处正在使用工具集发布草案（R46/a），则此通知由工具集发送。
The Receipt page is generated by various actions to inform the submitter of the current submission status and further actions. The contents of the page is likely to be highly dependent on the action and state for which receipt is being generated. This section documents general requirements applicable to all actions and states.
接收页面由各种操作生成，用于通知提交人当前提交状态和进一步操作。页面内容可能高度依赖于生成收据的操作和状态。本节记录了适用于所有行动和状态的一般要求。
The Receipt page should give the submitter a Uniform Resource Identifier (URI) or another identifier that can be used by Secretariat for manual troubleshooting of the submission (R63/a). The identifier should be perpetual (R64/a) even though the associated details are likely to be eventually lost (e.g., draft submission data and logs are deleted from the staging area as a part of the garbage collection routine). Hint: Tools should distinguish old identifiers from invalid ones; when a given identifier is referring to deleted data, the tools accepting the identifier should inform their users that the identified submission is recognized, but the related information has expired.
接收页面应为提交人提供统一资源标识符（URI）或秘书处可用于手动解决提交问题的另一标识符（R63/a）。标识符应该是永久的（R64/a），即使相关的详细信息可能最终会丢失（例如，作为垃圾收集例程的一部分，草稿提交数据和日志会从暂存区域中删除）。提示：工具应该区分旧标识符和无效标识符；当给定标识符引用已删除的数据时，接受该标识符的工具应通知其用户已识别已识别的提交，但相关信息已过期。
The Receipt page should give the submitter a Secretariat point-of-contact to report submission problems (R65/a).
接收页面应为提交人提供一个秘书处联络点，以报告提交问题（R65/a）。
A buggy Toolset implementation or unusual circumstances may force a submitter to submit a draft to the Secretariat for manual processing. This can be done by choosing the "manual posting" route supported by the Toolset (R47/a) or, as a last resort, by emailing the draft directly to Secretariat. In either case, an informal "cover letter" has to accompany the draft. The letter should explain why the automated interface cannot be used.
错误的工具集实施或异常情况可能会迫使提交人向秘书处提交草稿，以供手动处理。这可以通过选择工具集（R47/a）支持的“手动投递”路线来实现，或者作为最后手段，将草稿直接通过电子邮件发送给秘书处。无论哪种情况，都必须随草案附上非正式的“求职信”。这封信应该解释为什么不能使用自动接口。
When processing manual submissions, the Secretariat may be able to use the Toolset. A Manual Check page similar to the default Check page provides authenticated Secretariat staff with editable meta-data fields and a "force posting" action (R50/b). The forced posting action accepts meta-data fields "as is", does not verify submitter access to email or WG draft authorization, and posts the draft as if
在处理手工提交的材料时，秘书处可以使用该工具集。与默认检查页面类似的手动检查页面为经过认证的秘书处工作人员提供可编辑的元数据字段和“强制过账”操作（R50/b）。强制发布操作“按原样”接受元数据字段，不验证提交者对电子邮件或工作组草稿授权的访问，并发布草稿
no validation errors were found (R51/b). The Manual Check page should still contain all the errors and warnings identical to those seen by ordinary submitters (R106/b) so that the Secretariat knows what the Toolset is unhappy about (if anything).
未发现任何验证错误（R51/b）。手动检查页面应仍然包含与普通提交人（R106/b）看到的错误和警告相同的所有错误和警告，以便秘书处知道工具集不满意的地方（如果有）。
Using manual processing may result in significant posting delays. Generated submission receipts or notifications ought to give the submitter an expected processing time estimate (R53/a).
使用人工处理可能会导致重大的过账延迟。生成的提交收据或通知应为提交人提供预期处理时间估计（R53/a）。
The intent of this mode is to provide a way for submitters to bypass bugs or limitations of the automated mechanisms in order to post an "unusual" draft or to post a draft under "unusual" circumstances. One example would be a draft that does not contain standard IETF boilerplate but has a special IESG permission to post the draft with the experimental boilerplate. Another example is a draft that fails automated validation tests due to a validator bug.
此模式的目的是为提交者提供一种绕过自动化机制的缺陷或限制的方法，以便发布“异常”草稿或在“异常”情况下发布草稿。一个例子是草案不包含标准IETF样板，但有IESG的特别许可，可以使用实验样板发布草案。另一个例子是由于验证器错误导致自动验证测试失败的草稿。
The bypass mode is also likely to be used (effectively) by the majority of submitters during the Trial stage of the Toolset implementation, when few submitters know about (or are allowed to use) the Toolset.
在工具集实现的试用阶段，大多数提交人也可能（有效地）使用旁路模式，而很少有提交人知道（或允许使用）工具集。
The Toolset should have an email interface for automated posting of valid drafts (R55/b). While virtually every documented Toolset functionality can, technically, be implemented behind an email interface, features other than posting of valid drafts are believed to be prohibitively awkward to implement or use via email.
该工具集应具有用于自动发布有效草稿的电子邮件界面（R55/b）。虽然从技术上讲，几乎所有记录在案的工具集功能都可以在电子邮件界面后面实现，但除了发布有效草稿之外的其他功能被认为难以通过电子邮件实现或使用。
The email interface accepts a draft as a set of email part(s) (one per draft format) (R56/b). For example, the plain text format can be submitted in the "body" of the email message, while XML source format can be optionally sent as an "attachment" of the same email message. Each part can either contain the actual format data (R141/b) or a single URL pointing to it (R142/c). In the latter case, the Toolset has to fetch the format data. Details of the URL-fetching option are not documented here, but it is assumed that HTTP URLs are supported (at least), and fetching errors are reported. This document does not specify how the format of each email part is determined, but it is assumed that MIME type and content would need to be analyzed.
电子邮件接口将草稿作为一组电子邮件部分（每个草稿格式一个）（R56/b）接受。例如，纯文本格式可以在电子邮件的“正文”中提交，而XML源格式可以选择性地作为同一电子邮件的“附件”发送。每个部分可以包含实际格式数据（R141/b）或指向它的单个URL（R142/c）。在后一种情况下，工具集必须获取格式数据。此处未记录URL抓取选项的详细信息，但假定支持（至少）HTTP URL，并报告抓取错误。本文档未指定如何确定每个电子邮件部分的格式，但假定需要分析MIME类型和内容。
After accepting the draft, the Toolset uses the sender's email address to select the submitter identity (R57/b), checks the submission (R58/b), and posts the draft if the check is successful (R59/b). The submitter should be notified of the outcome of the draft submission via email (R60/b). Other requirements for the web interface (including requirements on submission preprocessing, draft
接受草稿后，工具集使用发件人的电子邮件地址选择提交者身份（R57/b），检查提交（R58/b），并在检查成功时发布草稿（R59/b）。应通过电子邮件（R60/b）将提交草案的结果通知提交人。web界面的其他要求（包括提交预处理要求、草稿）
validation, submitter authentication, draft posting, and notification) apply to the email interface.
验证、提交者身份验证、草稿发布和通知）适用于电子邮件界面。
Therefore, a typical successful submission via email interface may result in the following exchange of messages ("T" is for "Toolset", "S" is for "submitter", and "A" is for "all authors and submitter"):
因此，通过电子邮件接口成功提交的典型案例可能会导致以下消息交换（“T”表示“工具集”，“S”表示“提交人”，“a”表示“所有作者和提交人”）：
S-->T: the draft version
S-->T:草稿版本
S<--T: a challenge to verify email access
S<--T：验证电子邮件访问的挑战
S-->T: a response to the challenge
S-->T：对挑战的回应
A<--T: warnings and the receipt
A<--T：警告和收据
where the message containing the challenge may include warnings as well.
其中，包含质询的消息也可能包含警告。
When draft validation fails, the following emails may be exchanged:
当草案验证失败时，可交换以下电子邮件：
S-->T: the draft version
S-->T:草稿版本
S<--T: errors and receipt
S<--T：错误和收据
Email parts/attachments that are not recognized as draft formats are not considered as draft formats. Such parts are ignored by the Toolset (R107/b), except that a warning is generated for each unrecognizable part containing more than whitespace (R108/b). These two requirements are meant to make the interface robust in the presence of email signatures and other parts outside of the submitter control.
未被识别为草稿格式的电子邮件部分/附件不被视为草稿格式。工具集（R107/b）会忽略这些零件，除非为每个包含超过空格的不可识别零件（R108/b）生成警告。这两个要求旨在使接口在存在电子邮件签名和提交者控制之外的其他部分时具有健壮性。
Hint: Toolset actions can be implemented to support email and web interfaces without code duplication.
提示：可以实现工具集操作来支持电子邮件和web界面，而无需重复代码。
While both web and email interfaces allow for fast posting of valid drafts, there are significant differences between the two interfaces. Primary advantages of the email interface are:
虽然web和电子邮件界面都允许快速发布有效的草稿，但这两个界面之间存在显著差异。电子邮件界面的主要优点是：
off-line mode: A submitter can do all the manual work required to submit a draft while being disconnected from the network. The email client actually submits the draft when connectivity is regained.
离线模式：提交者可以在与网络断开连接时完成提交草稿所需的所有手动工作。电子邮件客户端在恢复连接时实际提交草稿。
poor connectivity: Email systems are often better suited for automated transmission and re-transmission of emails when network connectivity is poor due to high packet loss ratios, transmission delays, and other problems.
连通性差：当网络连通性差时，由于高丢包率、传输延迟和其他问题，电子邮件系统通常更适合自动传输和重新传输电子邮件。
convenience: Some IETFers consider email interfaces as generally "more convenient".
方便：有些IETFER认为电子邮件界面通常是“更方便”的。
Primary advantages of the web interface are:
web界面的主要优点是：
confirmation: A submitter is given a chance to verify that automated extraction of meta-data produced reasonable results. Other useful confirmations are possible (e.g., "Are you sure you want to post a version of the draft that was updated 30 seconds ago by your co-author?").
确认：提交人有机会验证元数据的自动提取是否产生了合理的结果。其他有用的确认也是可能的（例如，“您确定要发布30秒前由您的合著者更新的草稿版本吗？”）。
validation: A submitter can validate the draft without posting it.
验证：提交人可以验证草稿而无需发布。
quality: Non-critical warnings may prompt the submitter to postpone posting to improve draft quality.
质量：非关键警告可能会提示提交者推迟发布，以提高草稿质量。
manual adjustments: The submitter can adjust extracted meta-data and ease Secretariat work on manually posting an unusual draft.
手动调整：提交者可以调整提取的元数据，并简化秘书处手动发布不寻常草稿的工作。
meta-data: The submitter can specify optional external meta-data (that cannot be extracted from the draft itself). For example, an email address for draft discussion can be specified.
元数据：提交者可以指定可选的外部元数据（不能从草稿本身提取）。例如，可以指定草稿讨论的电子邮件地址。
context help: The web interface makes it easy to provide links to extra information about input fields, errors, posting options, deadlines, etc.
上下文帮助：web界面可以很容易地提供有关输入字段、错误、发布选项、截止日期等额外信息的链接。
opaqueness: Files submitted via the web interface are arguably less susceptible to various in-transit transformations and misinterpretation than emails. Emails are often mutated by mail agents (e.g., automated disclaimers added by senders and extra line feeds added by recipients).
不透明性：与电子邮件相比，通过web界面提交的文件不易受到各种传输转换和误解的影响。电子邮件通常由邮件代理进行变异（例如，发件人添加的自动免责声明和收件人添加的额外行提要）。
convenience: Some IETFers consider web interfaces as generally "more convenient".
方便：一些IETFER认为Web界面通常是“更方便”的。
This section defines the Toolset implementation stages or phases. There are three consecutive stages, marked with letters "a", "b", or "c". Earlier-stage requirements must still be satisfied in later stages. All requirements need to be interpreted and evaluated in the context of the current stage and the currently implemented features. For example, requirement R68 applies to the first stage but refers to XML draft format that may not be supported until the second stage. A correct interpretation of R68 until XML support is added is "it is an error to submit a draft without a plain text format".
本节定义了工具集实现阶段。有三个连续的阶段，标有字母“a”、“b”或“c”。早期阶段的要求必须在后期阶段得到满足。所有需求都需要在当前阶段和当前实现的特性的上下文中进行解释和评估。例如，需求R68适用于第一阶段，但引用的XML草稿格式可能在第二阶段之前不受支持。在添加XML支持之前，对R68的正确解释是“提交没有纯文本格式的草案是错误的”。
Unless otherwise noted, requirements listed in later stages may be covered in earlier stages, but do not have to be. If the implementers decide to add some functionality from a future stage, they have to be very careful to satisfy all requirements related to that functionality. Unfortunately, there is no reliable, pragmatic way to identify "all requirements" related to a given feature.
除非另有说明，后期列出的要求可能在早期阶段涵盖，但不必如此。如果实现者决定在未来阶段添加一些功能，他们必须非常小心地满足与该功能相关的所有需求。不幸的是，没有可靠、实用的方法来识别与给定特性相关的“所有需求”。
(a) Trial Stage: Initial basic implementation to test major concepts and relieve the Secretariat from handling the most common submission case. This stage focuses on plain text draft submission via the web interface. The trial stage should take a dedicated professional about 45 calendar days to finish (i.e., to comply with all the listed requirements).
(a) 试验阶段：初步基本实施，以测试主要概念，并使秘书处不再处理最常见的提交案件。此阶段的重点是通过web界面提交纯文本草稿。试验阶段需要一名专业人员约45个日历日完成（即，遵守所有列出的要求）。
(b) Production Stage: Support for all major features. Once this stage is completed, the Secretariat should only handle unusual draft submissions. This stage should take about 100 calendar days to finish. Gradual release of implemented features is possible and expected. Specifically, the XML support is expected before email interface support.
(b) 生产阶段：支持所有主要功能。一旦这一阶段完成，秘书处应只处理不寻常的提交草稿。这一阶段需要大约100个日历日才能完成。逐步发布已实现的特性是可能的，也是预期的。具体地说，XML支持应该先于电子邮件接口支持。
(c) Enhancement Stage: A never-ending stage focusing on sophisticated features (e.g., draft interpretation or validation) that improve the overall quality of the Toolset. This stage is documented primarily to highlight the overall direction of the Toolset; its requirements are often imprecise and many are expected to change.
(c) 增强阶段：一个永无止境的阶段，专注于提高工具集整体质量的复杂功能（例如，草稿解释或验证）。记录此阶段主要是为了突出工具集的总体方向；它的要求往往不精确，许多要求可能会改变。
Implementation experience is likely to result in changes of the Toolset requirements. Such changes should be documented as a part of stage evaluation activities.
实施经验可能会导致工具集需求的变化。此类变更应记录为阶段评估活动的一部分。
Before letting the Toolset go live, thousands of posted drafts can be used to test the meta-data extraction algorithms. Such testing can minimize the number of drafts being sent on for manual handling because of meta-data extraction failure.
在使用该工具集之前，可以使用数千份发布的草稿来测试元数据提取算法。这样的测试可以最大限度地减少由于元数据提取失败而发送用于手动处理的草稿数量。
Other Toolset features may also be testable using posted drafts. A simple pair of scripts can be used to test basic functionality of the web and email interfaces.
其他工具集功能也可以使用发布的草稿进行测试。一对简单的脚本可用于测试web和电子邮件界面的基本功能。
Hint: The IESG may require test results before accepting the initial implementation. If automated, the above approach can be used for regression testing as well.
提示：IESG在接受初始实现之前可能需要测试结果。如果自动化，上述方法也可以用于回归测试。
Removing humans from the draft submission and posting process (a.k.a. automation) requires adding features to make the Toolset reliable in the presence of denial-of-service (DoS) attacks and attempts to corrupt the draft repository. Ideally, the Toolset needs to resist both premeditated malicious actions and good-intent accidents.
从草稿提交和发布过程中删除人员（也称为自动化）需要添加一些功能，以便在拒绝服务（DoS）攻击和试图破坏草稿存储库的情况下使工具集可靠。理想情况下，该工具集需要抵抗有预谋的恶意行为和善意事故。
This document contains specific requirements to minimize the impact of DoS attacks (e.g., R97). The requirements are designed with the assumption that it is acceptable for the Toolset to block valid submissions during a DoS attack as long as the Toolset maintainers are notified and already posted drafts are not damaged.
本文档包含将DoS攻击（如R97）的影响降至最低的具体要求。这些需求的设计假设只要工具集维护人员得到通知并且已经发布的草稿没有损坏，工具集在DoS攻击期间阻止有效提交是可以接受的。
This document also contains many specific requirements related to detection of drafts violating IETF posting rules. Those requirements help reduce the number of "bad" drafts posted by mistake but do not offer reliable protection from submitters with malicious intent: Since automated tools do not truly understand drafts (and will not do so in the foreseeable future), it is technically possible to post a rogue draft violating IETF posting rules. For example, a draft may contain abstract text that makes the IETF-approved IPR statements following the abstract meaningless or legally non-binding.
本文件还包含许多与检测违反IETF发布规则的草案相关的具体要求。这些要求有助于减少错误发布的“坏”草稿的数量，但无法提供可靠的保护，防止恶意提交者：由于自动化工具无法真正理解草稿（在可预见的未来也不会这样做），因此从技术上讲，发布违反IETF发布规则的恶意草稿是可能的。例如，草案可能包含抽象文本，使得IETF批准的知识产权声明在摘要之后变得毫无意义或不具有法律约束力。
Stronger submitter authentication may be required to deter malicious submitters. The documented authentication mechanism (i.e., read access to one's email) is deemed appropriate for deployment of the first versions of the Toolset, under close Secretariat supervision. Hint: to increase chances of detecting problems early enough, it may be a good idea to automatically inform a designated human of every posted submission (during initial deployment of the Toolset).
可能需要更强的提交者身份验证来阻止恶意提交者。在秘书处的密切监督下，文件化的身份验证机制（即对电子邮件的读访问）被认为适合于部署工具集的第一个版本。提示：为了增加尽早发现问题的机会，最好是在工具集的初始部署期间，自动将每个提交的信息通知给指定的人员。
A Toolset implementation is compliant with this specification if it satisfies all normative requirements (i.e., the phrases marked with "Rnnn" as defined in Section 3). Compliance should be evaluated for each implementation stage as some requirements do not apply to some stages.
如果工具集实现满足所有规范性要求（即第3节中定义的标有“Rnnn”的短语），则该工具集实现符合本规范。应评估每个实施阶段的合规性，因为某些要求不适用于某些阶段。
The IESG evaluates implementations and interprets requirements as necessary.
IESG根据需要评估实现并解释需求。
This section summarizes major differences between the draft submission approach currently in use by IETF and the proposed Toolset, including violations of the current IETF rules.
本节总结了IETF目前使用的草案提交方法与提议的工具集之间的主要差异，包括违反当前IETF规则的情况。
o The Toolset allows posting of XML and PDF draft formats. The XML format is not currently accepted by the Secretariat, and legality of PDF acceptance by the Secretariat has been questioned. XML sources should be accepted to enable IETF tools and participants to have access to raw draft meta-data and content. They are also useful to the RFC Editor and, hence, it is a good idea to validate and get them "into the system" early. The latter argument applies to PDF drafts as well, although the first Toolset versions are not expected to interpret PDF drafts.
o 该工具集允许发布XML和PDF草稿格式。秘书处目前不接受XML格式，秘书处接受PDF格式的合法性受到质疑。应接受XML源，以使IETF工具和参与者能够访问原始草案元数据和内容。它们对RFC编辑器也很有用，因此，尽早验证并“进入系统”是一个好主意。后一个参数也适用于PDF草稿，尽管第一个工具集版本预计不会解释PDF草稿。
o The Toolset may eventually generate HTML draft formats from XML draft sources (see R112). Currently, IETF does not provide HTML draft formats -- the Secretariat does not accept HTML sources and no HTML is generated from accepted draft sources. Note, however, that this document does not suggest that the Toolset should eventually accept drafts in HTML format.
o 该工具集最终可能会从XML草稿源生成HTML草稿格式（请参见R112）。目前，IETF不提供HTML草稿格式——秘书处不接受HTML源，也不从接受的草稿源生成HTML。但是，请注意，本文档并不建议工具集最终接受HTML格式的草稿。
o The Toolset defines "WGN draft" as a draft whose name starts with "draft-ietf-". All other drafts are treated as individual drafts. Currently, an IETF WG does not have to follow a single WG draft naming format. Thus, the 00 version of a draft that the WG considers a WG draft can be posted by the Toolset without WG consent. Affected WGs would have to deal with the consequences of their decision not to use a common naming format. The Tools team suggests that IETF requires WGs to name their drafts using a single format to minimize confusion. Hopefully, there are no humans named "Ietf" or, at least, none of them wants to auto-post individual drafts.
o 该工具集将“WGN草稿”定义为名称以“草稿ietf-”开头的草稿。所有其他汇票均视为单独汇票。目前，IETF工作组不必遵循单一的工作组草案命名格式。因此，工作组认为是工作组草案的草案的00版本可以在没有工作组同意的情况下由工具集发布。受影响的工作组必须处理其决定不使用通用命名格式的后果。工具团队建议IETF要求工作组使用单一格式命名其草稿，以尽量减少混淆。希望没有人叫“Ietf”，或者至少没有人想自动发布个人草稿。
o For some drafts, the Toolset verifies that the submitter is "expected" (e.g., an author of the previous draft version or WG Chair). Currently, the Secretariat does virtually no such verification, but an email submission interface and a human presence in the submission loop have apparently been sufficient to prevent massive automated attacks. The change is needed to prevent a simple script from using the web interface to overwrite posted IETF drafts with junk. Hopefully, the IETF will eventually have a decent authentication scheme making the submitter checks simpler, less rigid, and more transparent.
o 对于某些草稿，该工具集验证提交人是否“预期”（例如，先前草稿版本的作者或工作组主席）。目前，秘书处几乎不进行这种核查，但电子邮件提交界面和提交循环中的人员存在显然足以防止大规模自动攻击。需要进行更改，以防止简单脚本使用web界面用垃圾邮件覆盖已发布的IETF草稿。希望IETF最终会有一个像样的身份验证方案，使提交者检查更简单、更不严格、更透明。
o The Toolset will automatically notify authors of posted drafts. Currently, neither the submitter nor any of the co-authors are explicitly notified when the draft is posted. Notification is meant, in part, to allow co-authors to detect cases where their name is put on the authors list without permission. Eventually, there will be a general IETF mechanism to allow 3rd parties such as ADs, chairs, or reviewers to register for notifications about draft postings.
o 该工具集将自动通知提交草稿的作者。目前，无论是提交人还是任何合著者都没有在草稿发布时得到明确通知。在某种程度上，通知的意思是允许共同作者发现其姓名未经许可而被列入作者名单的情况。最终，将有一个通用的IETF机制，允许第三方（如广告、主席或评审员）注册关于草稿发布的通知。
o The Toolset may eventually accept compressed drafts (see R150). Currently, the Secretariat does not accept "zip" archives due to virus contamination concerns. A proper implementation of the Toolset must address such concerns, while the Secretariat may still need to reject certain formats if they are submitted via the manual route.
o 该工具集最终可能接受压缩草稿（请参见R150）。目前，由于病毒污染问题，秘书处不接受“zip”档案。工具集的适当实施必须解决这些问题，而秘书处可能仍然需要拒绝通过人工方式提交的某些格式。
The author gratefully acknowledges the contributions of Harald Tveit Alvestrand (Cisco), Brian E. Carpenter (IBM), Frank Ellermann, Bill Fenner (AT&T), Barbara B. Fuller (Foretec), Bruce Lilly, Henrik Levkowetz (Ericsson), Larry Masinter (Adobe), Keith Moore (University of Tennessee), Pekka Savola (Netcore), Henning Schulzrinne (Columbia University), and Stanislav Shalunov (Internet2).
作者感谢Harald Tveit Alvestrand（Cisco）、Brian E.Carpenter（IBM）、Frank Ellermann、Bill Fenner（AT&T）、Barbara B.Fuller（Foretec）、Bruce Lilly、Henrik Levkowetz（爱立信）、Larry Masinter（Adobe）、Keith Moore（田纳西大学）、Pekka Savola（Netcore）、Henning Schulzrinne的贡献（哥伦比亚大学）和Stanislav Shalunov（互联网2）。
Special thanks to Marshall Rose for his xml2rfc tool.
特别感谢Marshall Rose提供的xml2rfc工具。
Normative References
规范性引用文件
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3978，2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月。
[XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, http://www.w3.org/TR/1998/REC-xml-19980210.
[XML]万维网联盟，“可扩展标记语言（XML）1.0”，W3C XML，1998年2月，http://www.w3.org/TR/1998/REC-xml-19980210.
Informative References
资料性引用
[writing-rfcs] Rose, M., "Writing I-Ds and RFCs using XML (revised)", Work in Progress, April 2004.
[编写RFC]Rose，M.，“使用XML编写I-D和RFC（修订版）”，正在进行的工作，2004年4月。
[secretariat] "Private communication with the IETF Secretariat", 2004.
[秘书处]“与IETF秘书处的私人通信”，2004年。
[OSD] "The Open Source Definition, version 1.9", Open Source Initiative, 2005, available at http://www.opensource.org/docs/definition.php.
[OSD]“开放源码定义，1.9版”，开放源码倡议，2005年，可在http://www.opensource.org/docs/definition.php.
Author's Address
作者地址
Alex Rousskov The Measurement Factory
亚历克斯·罗斯科夫测量工厂
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。