Internet Architecture Board (IAB) P. Hoffman
Request for Comments: 7998 ICANN
Category: Informational J. Hildebrand
ISSN: 2070-1721 Mozilla
December 2016
Internet Architecture Board (IAB) P. Hoffman
Request for Comments: 7998 ICANN
Category: Informational J. Hildebrand
ISSN: 2070-1721 Mozilla
December 2016
"xml2rfc" Version 3 Preparation Tool Description
“xml2rfc”第3版准备工具说明
Abstract
摘要
This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.
本文档描述了在部署新的xml2rfc版本3规范时预期创建的“准备工具”的一些方面。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7998.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7998.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. xml2rfc v3 Prep Tool Usage Scenarios . . . . . . . . . . . . 4
3. Internet-Draft Submission . . . . . . . . . . . . . . . . . . 4
4. Canonical RFC Preparation . . . . . . . . . . . . . . . . . . 5
5. What the v3 Prep Tool Does . . . . . . . . . . . . . . . . . 5
5.1. XML Sanitization . . . . . . . . . . . . . . . . . . . . 6
5.1.1. XInclude Processing . . . . . . . . . . . . . . . . . 6
5.1.2. DTD Removal . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. Processing Instruction Removal . . . . . . . . . . . 6
5.1.4. Validity Check . . . . . . . . . . . . . . . . . . . 6
5.1.5. Check "anchor" . . . . . . . . . . . . . . . . . . . 6
5.2. Defaults . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. "version" Insertion . . . . . . . . . . . . . . . . . 6
5.2.2. "seriesInfo" Insertion . . . . . . . . . . . . . . . 7
5.2.3. <date> Insertion . . . . . . . . . . . . . . . . . . 7
5.2.4. "prepTime" Insertion . . . . . . . . . . . . . . . . 7
5.2.5. <ol> Group "start" Insertion . . . . . . . . . . . . 7
5.2.6. Attribute Default Value Insertion . . . . . . . . . . 7
5.2.7. Section "toc" attribute . . . . . . . . . . . . . . . 7
5.2.8. "removeInRFC" Warning Paragraph . . . . . . . . . . . 8
5.3. Normalization . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. "month" Attribute . . . . . . . . . . . . . . . . . . 8
5.3.2. ASCII Attribute Processing . . . . . . . . . . . . . 8
5.3.3. "title" Conversion . . . . . . . . . . . . . . . . . 9
5.4. Generation . . . . . . . . . . . . . . . . . . . . . . . 9
5.4.1. "expiresDate" Insertion . . . . . . . . . . . . . . . 9
5.4.2. <boilerplate> Insertion . . . . . . . . . . . . . . . 9
5.4.2.1. Compare <rfc> "submissionType" and <seriesInfo>
"stream" . . . . . . . . . . . . . . . . . . . . 9
5.4.2.2. "Status of this Memo" Insertion . . . . . . . . . 9
5.4.2.3. "Copyright Notice" Insertion . . . . . . . . . . 10
5.4.3. <reference> "target" Insertion . . . . . . . . . . . 10
5.4.4. <name> Slugification . . . . . . . . . . . . . . . . 10
5.4.5. <reference> Sorting . . . . . . . . . . . . . . . . . 10
5.4.6. "pn" Numbering . . . . . . . . . . . . . . . . . . . 10
5.4.7. <iref> Numbering . . . . . . . . . . . . . . . . . . 11
5.4.8. <xref> Processing . . . . . . . . . . . . . . . . . . 11
5.4.8.1. "derivedContent" Insertion (with Content) . . . . 11
5.4.8.2. "derivedContent" Insertion (without Content) . . 11
5.4.9. <relref> Processing . . . . . . . . . . . . . . . . . 12
5.5. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5.1. <artwork> Processing . . . . . . . . . . . . . . . . 12
5.5.2. <sourcecode> Processing . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. xml2rfc v3 Prep Tool Usage Scenarios . . . . . . . . . . . . 4
3. Internet-Draft Submission . . . . . . . . . . . . . . . . . . 4
4. Canonical RFC Preparation . . . . . . . . . . . . . . . . . . 5
5. What the v3 Prep Tool Does . . . . . . . . . . . . . . . . . 5
5.1. XML Sanitization . . . . . . . . . . . . . . . . . . . . 6
5.1.1. XInclude Processing . . . . . . . . . . . . . . . . . 6
5.1.2. DTD Removal . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. Processing Instruction Removal . . . . . . . . . . . 6
5.1.4. Validity Check . . . . . . . . . . . . . . . . . . . 6
5.1.5. Check "anchor" . . . . . . . . . . . . . . . . . . . 6
5.2. Defaults . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. "version" Insertion . . . . . . . . . . . . . . . . . 6
5.2.2. "seriesInfo" Insertion . . . . . . . . . . . . . . . 7
5.2.3. <date> Insertion . . . . . . . . . . . . . . . . . . 7
5.2.4. "prepTime" Insertion . . . . . . . . . . . . . . . . 7
5.2.5. <ol> Group "start" Insertion . . . . . . . . . . . . 7
5.2.6. Attribute Default Value Insertion . . . . . . . . . . 7
5.2.7. Section "toc" attribute . . . . . . . . . . . . . . . 7
5.2.8. "removeInRFC" Warning Paragraph . . . . . . . . . . . 8
5.3. Normalization . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. "month" Attribute . . . . . . . . . . . . . . . . . . 8
5.3.2. ASCII Attribute Processing . . . . . . . . . . . . . 8
5.3.3. "title" Conversion . . . . . . . . . . . . . . . . . 9
5.4. Generation . . . . . . . . . . . . . . . . . . . . . . . 9
5.4.1. "expiresDate" Insertion . . . . . . . . . . . . . . . 9
5.4.2. <boilerplate> Insertion . . . . . . . . . . . . . . . 9
5.4.2.1. Compare <rfc> "submissionType" and <seriesInfo>
"stream" . . . . . . . . . . . . . . . . . . . . 9
5.4.2.2. "Status of this Memo" Insertion . . . . . . . . . 9
5.4.2.3. "Copyright Notice" Insertion . . . . . . . . . . 10
5.4.3. <reference> "target" Insertion . . . . . . . . . . . 10
5.4.4. <name> Slugification . . . . . . . . . . . . . . . . 10
5.4.5. <reference> Sorting . . . . . . . . . . . . . . . . . 10
5.4.6. "pn" Numbering . . . . . . . . . . . . . . . . . . . 10
5.4.7. <iref> Numbering . . . . . . . . . . . . . . . . . . 11
5.4.8. <xref> Processing . . . . . . . . . . . . . . . . . . 11
5.4.8.1. "derivedContent" Insertion (with Content) . . . . 11
5.4.8.2. "derivedContent" Insertion (without Content) . . 11
5.4.9. <relref> Processing . . . . . . . . . . . . . . . . . 12
5.5. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5.1. <artwork> Processing . . . . . . . . . . . . . . . . 12
5.5.2. <sourcecode> Processing . . . . . . . . . . . . . . . 14
5.6. RFC Production Mode Cleanup . . . . . . . . . . . . . . . 14
5.6.1. <note> Removal . . . . . . . . . . . . . . . . . . . 14
5.6.2. <cref> Removal . . . . . . . . . . . . . . . . . . . 15
5.6.3. <link> Processing . . . . . . . . . . . . . . . . . . 15
5.6.4. XML Comment Removal . . . . . . . . . . . . . . . . . 15
5.6.5. "xml:base" and "originalSrc" Removal . . . . . . . . 15
5.6.6. Compliance Check . . . . . . . . . . . . . . . . . . 15
5.7. Finalization . . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. "scripts" Insertion . . . . . . . . . . . . . . . . . 16
5.7.2. Pretty-Format . . . . . . . . . . . . . . . . . . . . 16
6. Additional Uses for the Prep Tool . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . 17
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
5.6. RFC Production Mode Cleanup . . . . . . . . . . . . . . . 14
5.6.1. <note> Removal . . . . . . . . . . . . . . . . . . . 14
5.6.2. <cref> Removal . . . . . . . . . . . . . . . . . . . 15
5.6.3. <link> Processing . . . . . . . . . . . . . . . . . . 15
5.6.4. XML Comment Removal . . . . . . . . . . . . . . . . . 15
5.6.5. "xml:base" and "originalSrc" Removal . . . . . . . . 15
5.6.6. Compliance Check . . . . . . . . . . . . . . . . . . 15
5.7. Finalization . . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. "scripts" Insertion . . . . . . . . . . . . . . . . . 16
5.7.2. Pretty-Format . . . . . . . . . . . . . . . . . . . . 16
6. Additional Uses for the Prep Tool . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . 17
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
As initially described in [RFC6949], the canonical format (the data that is the authorized, recognized, accepted, and archived version of the document) of the RFC Series has been plain text to date: it is now changing to XML (using the xml2rfc v3 vocabulary [RFC7991]).
正如[RFC6949]中最初所述，RFC系列的规范格式（即文档的授权、认可、接受和存档版本的数据）到目前为止一直是纯文本：现在正在更改为XML（使用xml2rfc v3词汇表[RFC7991]）。
However, most people will read RFCs in other formats, such as HTML, PDF, ASCII text, or other formats not yet in existence. In order to ensure as much uniformity in text output as possible across formats (and with the canonical XML itself), there is a desire that the translation from XML into the other formats will be straightforward syntactic translation. To make that happen, a good amount of data will need to be in the XML format that is not there today. That data will be added by a program called the "prep tool", which will often run as a part of the xml2rfc process.
然而，大多数人会阅读其他格式的RFC，如HTML、PDF、ASCII文本或其他尚不存在的格式。为了确保不同格式（以及规范XML本身）的文本输出尽可能一致，人们希望从XML到其他格式的转换是直接的语法转换。要做到这一点，大量的数据将需要采用XML格式，而目前还没有这种格式。这些数据将由一个名为“prep工具”的程序添加，该程序通常作为xml2rfc过程的一部分运行。
This document specifies the steps that the prep tool will have to take. When changes to the xml2rfc v3 vocabulary [RFC7991] are made, this document is likely to be updated at the same time.
本文件规定了准备工具必须采取的步骤。当对xml2rfc v3词汇表[RFC7991]进行更改时，可能会同时更新此文档。
The details (particularly any vocabularies) described in this document are expected to change based on experience gained in implementing the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards-compatible with the details described in this document.
本文档中描述的详细信息（尤其是词汇表）预计将根据在实施新发布工具集过程中获得的经验进行更改。修订后的文档将在工具集完成后发布，以捕获这些更改。其他实施者不得期望这些更改与本文档中描述的细节保持向后兼容。
The prep tool will have several settings:
准备工具将有几个设置：
o Internet-Draft preparation
o 因特网草稿编制
o Canonical RFC preparation
o 规范RFC制备
There are only a few differences between the two settings: for example, the boilerplate output and the date output on the front page.
这两种设置之间只有一些区别：例如，首页上的样板输出和日期输出。
Note that this document only describes what the IETF-sponsored prep tool does. Others might create their own work-alike prep tools for their own formatting needs. However, an output format developer does not need to change the prep tool in order to create their own formatter: they only need to be able to consume prepared text. The IETF-sponsored prep tool runs in two different modes: "I-D" mode when the tool is run during Internet-Draft submission and processing and "RFC production mode" when the tool is run by the RFC Production Center while producing an RFC.
请注意，本文档仅描述IETF赞助的准备工具的功能。其他人可能会根据自己的格式需求创建自己的工作准备工具。但是，输出格式开发人员不需要更改prep工具来创建自己的格式化程序：他们只需要能够使用准备好的文本。IETF赞助的准备工具以两种不同的模式运行：“I-D”模式，当该工具在互联网草稿提交和处理期间运行时，以及“RFC生产模式”，当该工具在生产RFC时由RFC生产中心运行时。
This tool is described as if it is a separate tool so that we can reason about its architectural properties. In actual implementation, it might be a part of a larger suite of functionality.
这个工具被描述为一个独立的工具，这样我们就可以对它的架构属性进行推理。在实际实现中，它可能是更大的功能套件的一部分。
When the IETF draft submission tool accepts xml2rfc version 3 vocabulary [RFC7991] (referred to as "v3" hereafter) as an input format, the submission tool runs the submitted file through the prep tool. This is called "I-D mode" in this document. If the tool finds no errors, it keeps two XML files: the submitted file and the prepped file.
当IETF草稿提交工具接受xml2rfc版本3词汇表[RFC7991]（以下称为“v3”）作为输入格式时，提交工具通过准备工具运行提交的文件。这在本文件中称为“I-D模式”。如果工具没有发现错误，它将保留两个XML文件：提交的文件和准备好的文件。
The prepped file provides a record of what a submitter was attesting to at the time of submission. It represents a self-contained record of what any external references resolved to at the time of submission.
准备好的文件提供了提交人在提交时证明的内容的记录。它表示提交时任何外部引用解析到的内容的自包含记录。
The prepped file is used by the IETF formatters to create outputs such as HTML, PDF, and text (or the tools act in a way indistinguishable from this). The message sent out by the draft submission tool includes a link to the submitted XML as well as the other outputs, including the prepped XML.
IETF格式化程序使用预先准备好的文件来创建输出，如HTML、PDF和文本（或者工具的行为方式与此无法区分）。草稿提交工具发送的消息包括指向已提交XML的链接以及其他输出（包括预处理的XML）。
The prepped XML can be used by tools not yet developed to output new formats that have as similar output as possible to the current IETF formatters. For example, if the IETF creates a .mobi output renderer later, it can run that renderer on all of the prepped XML that has been saved, ensuring that the content of included external references and all of the part numbers and boilerplate will be the same as what was produced by the previous IETF formatters at the time the document was first uploaded.
尚未开发的工具可以使用预先准备好的XML输出新格式，这些新格式的输出与当前的IETF格式化程序的输出尽可能相似。例如，如果IETF稍后创建.mobi输出渲染器，它可以在所有已保存的预处理XML上运行该渲染器，确保包含的外部参考文件的内容以及所有零件号和样板文件与首次上传文件时先前IETF格式化程序生成的内容相同。
During editing, the RPC will run the prep tool in canonical RFC production mode and make the results available to the authors during AUTH48 (see [PUB-PROCESS]) so they can see what the final output would look like. When the document has passed AUTH48 review, the RPC runs the prep tool in canonical RFC production mode one last time, locks down the canonicalized XML, runs the formatters for the publication formats, and publishes all of those.
在编辑期间，RPC将在规范RFC生产模式下运行prep工具，并在AUTH48期间将结果提供给作者（请参见[PUB-PROCESS]），以便他们可以看到最终输出的样子。当文档通过AUTH48审阅时，RPC最后一次以规范化RFC生产模式运行prep工具，锁定规范化XML，运行发布格式的格式化程序，并发布所有这些格式。
This document assumes that the prep tool will be used by the RPC in the manner described in this document; they may use something different or with different configuration.
本文件假设RPC将以本文件所述方式使用准备工具；他们可能会使用不同的东西或不同的配置。
Similar to the case for I-Ds, the prepped XML can be used later to re-render the output formats or to generate new formats.
与I-Ds的情况类似，准备好的XML可以稍后用于重新呈现输出格式或生成新格式。
The steps listed here are in order of processing. In all cases where the prep tool would "add" an attribute or element, if that attribute or element already exists, the prep tool will check that the attribute or element has valid values. If the value is incorrect, the prep tool will warn with the old and new values, then replace the incorrect value with the new value.
此处列出的步骤按处理顺序排列。在准备工具将“添加”属性或元素的所有情况下，如果该属性或元素已经存在，准备工具将检查该属性或元素是否具有有效值。如果值不正确，准备工具将用新旧值发出警告，然后用新值替换不正确的值。
Currently, the IETF uses a tool called "idnits" [IDNITS] to check text input to the Internet-Drafts posting process. idnits indicates if it encountered anything it considers an error and provides text describing all of the warnings and errors in a human-readable form. The prep tool should probably check for as many of these errors and warnings as possible when it is processing the XML input. For the moment, tooling might run idnits on the text output from the prepared XML. The list below contains some of these errors and warnings, but the deployed version of the prep tool may contain additional steps to include more or the checks from idnits.
目前，IETF使用一种称为“idnits”[idnits]的工具来检查互联网草稿发布过程中的文本输入。idnits指出它是否遇到了它认为是错误的任何东西，并以人类可读的形式提供描述所有警告和错误的文本。prep工具在处理XML输入时，应该尽可能多地检查这些错误和警告。目前，工具可能会对准备好的XML的文本输出运行idnits。下面的列表包含其中一些错误和警告，但部署的prep工具版本可能包含额外的步骤，以包含更多或来自idnits的检查。
These steps will ensure that the input document is properly formatted and that all XML processing has been performed.
这些步骤将确保输入文档的格式正确，并且执行了所有XML处理。
Process all <x:include> elements. Note: XML <x:include> elements may include more <x:include> elements (with relative references resolved against the base URI potentially modified by a previously inserted xml:base attribute). The tool may be configurable with a limit on the depth of recursion.
处理所有<x:include>元素。注意：XML<x:include>元素可能包含更多的<x:include>元素（根据之前插入的XML:base属性可能修改的基本URI解析相对引用）。该工具可以配置为限制递归深度。
Fully process any Document Type Definitions (DTDs) in the input document, then remove the DTD. At a minimum, this entails processing the entity references and includes for external files.
完全处理输入文档中的任何文档类型定义（DTD），然后删除DTD。至少，这需要处理实体引用并包括外部文件的引用。
Remove processing instructions.
删除处理说明。
Check the input against the RELAX NG (RNG) in [RFC7991]. If the input is not valid, give an error.
对照[RFC7991]中的RELAX NG（RNG）检查输入。如果输入无效，请给出一个错误。
Check all elements for "anchor" attributes. If any "anchor" attribute begins with "s-", "f-", "t-", or "i-", give an error.
检查所有元素的“锚定”属性。如果任何“锚定”属性以“s-”、“f-”、“t-”或“i-”开头，请给出一个错误。
These steps will ensure that all default values have been filled in to the XML, in case the defaults change at a later date. Steps in this section will not overwrite existing values in the input file.
这些步骤将确保所有默认值都已填充到XML中，以防以后更改默认值。本节中的步骤不会覆盖输入文件中的现有值。
If the <rfc> element has a "version" attribute with a value other than "3", give an error. If the <rfc> element has no "version" attribute, add one with the value "3".
如果<rfc>元素的“version”属性的值不是“3”，则给出一个错误。如果<rfc>元素没有“version”属性，则添加一个值为“3”的属性。
If the <front> element of the <rfc> element does not already have a <seriesInfo> element, add a <seriesInfo> element with the name attribute based on the mode in which the prep tool is running ("Internet-Draft" for Draft mode and "RFC" for RFC production mode) and a value that is the input filename minus any extension for Internet-Drafts, and is a number specified by the RFC Editor for RFCs.
如果<rfc>元素的<front>元素还没有<seriesInfo>元素，则添加一个<seriesInfo>元素，该元素的名称属性基于准备工具运行的模式（“Internet草稿”表示草稿模式，“rfc”表示rfc生产模式）和一个值，该值是输入文件名减去Internet草稿的任何扩展名，和是RFC编辑器为RFC指定的数字。
If the <front> element in the <rfc> element does not contain a <date> element, add it and fill in the "day", "month", and "year" attributes from the current date. If the <front> element in the <rfc> element has a <date> element with "day", "month", and "year" attributes, but the date indicated is more than three days in the past or is in the future, give a warning. If the <front> element in the <rfc> element has a <date> element with some but not all of the "day", "month", and "year" attributes, give an error.
如果<rfc>元素中的<front>元素不包含<date>元素，则添加该元素并从当前日期开始填写“日”、“月”和“年”属性。如果<rfc>元素中的<front>元素具有带有“日”、“月”和“年”属性的<date>元素，但显示的日期过去或将来超过三天，则发出警告。如果<rfc>元素中的<front>元素有一个<date>元素，其中包含一些但不是全部的“日”、“月”和“年”属性，则给出一个错误。
If the input document includes a "prepTime" attribute of <rfc>, exit with an error.
如果输入文档包含<rfc>的“prepTime”属性，则退出时出错。
Fill in the "prepTime" attribute of <rfc> with the current datetime.
用当前日期时间填写<rfc>的“prepTime”属性。
Add a "start" attribute to every <ol> element containing a group that does not already have a start.
向包含尚未开始的组的每个<ol>元素添加“开始”属性。
Fill in any default values for attributes on elements, except "keepWithNext" and "keepWithPrevious" of <t>, and "toc" of <section>. Some default values can be found in the RELAX NG schema, while others can be found in the prose describing the elements in [RFC7991].
除了<t>的“keepWithNext”和“keepWithPrevious”以及<section>的“toc”之外，为元素的属性填写任何默认值。一些默认值可以在RELAXNG模式中找到，而其他值可以在[RFC7991]中描述元素的散文中找到。
For each <section>, modify the "toc" attribute to be either "include" or "exclude":
对于每个<section>，将“toc”属性修改为“include”或“exclude”：
o for sections that have an ancestor of <boilerplate>, use "exclude"
o 对于祖先为<样板文件>的节，请使用“排除”
o else for sections that have a descendant that has toc="include", use "include". If the ancestor section has toc="exclude" in the input, this is an error.
o 否则，对于具有toc=“include”子代的节，请使用“include”。如果祖先部分在输入中有toc=“exclude”，则这是一个错误。
o else for sections that are children of a section with toc="exclude", use "exclude".
o 对于toc=“排除”节的子节，请使用“排除”。
o else for sections that are deeper than rfc/@tocDepth, use "exclude"
o 否则，对于比rfc/@tocDepth更深的部分，请使用“排除”
o else use "include"
o 否则使用“包括”
In I-D mode, if there is a <note> or <section> element with a "removeInRFC" attribute that has the value "true", add a paragraph to the top of the element with the text "This note is to be removed before publishing as an RFC." or "This section...", unless a paragraph consisting of that exact text already exists.
在I-D模式下，如果有一个<note>或<section>元素具有值为“true”的“removeInRFC”属性，则在元素顶部添加一个段落，文字为“此注释在作为RFC发布之前将被删除”或“This section…”，除非已经存在由该确切文字组成的段落。
These steps will ensure that ideas that can be expressed in multiple different ways in the input document are only found in one way in the prepared document.
这些步骤将确保可以在输入文档中以多种不同方式表达的想法只能在准备好的文档中以一种方式找到。
Normalize the values of "month" attributes in all <date> elements in <front> elements in <rfc> elements to numeric values.
将<rfc>元素中<front>元素中所有<date>元素中的“month”属性值规范化为数值。
In every <email>, <organization>, <street>, <city>, <region>, <country>, and <code> element, if there is an "ascii" attribute and the value of that attribute is the same as the content of the element, remove the "ascii" element and issue a warning about the removal.
在每个<email>、<organization>、<street>、<city>、<region>、<country>和<code>元素中，如果存在“ascii”属性且该属性的值与该元素的内容相同，请删除“ascii”元素并发出有关删除的警告。
In every <author> element, if there is an "asciiFullname", "asciiInitials", or "asciiSurname" attribute, check the content of that element against its matching "fullname", "initials", or "surname" element (respectively). If the two are the same, remove the "ascii*" element and issue a warning about the removal.
在每个<author>元素中，如果存在“asciiFullname”、“asciiInitials”或“asciiSurname”属性，请分别对照其匹配的“fullname”、“initials”或“姓氏”元素检查该元素的内容。如果两者相同，请删除“ascii*”元素并发出有关删除的警告。
For every <section>, <note>, <figure>, <references>, and <texttable> element that has a (deprecated) "title" attribute, remove the "title" attribute and insert a <name> element with the title from the attribute.
对于具有（不推荐使用的）“title”属性的每个<section>、<note>、<figure>、<references>和<texttable>元素，请删除“title”属性，并从属性中插入带有title的<name>元素。
These steps will generate new content, overriding existing similar content in the input document. Some of these steps are important enough that they specify a warning to be generated when the content being overwritten does not match the new content.
这些步骤将生成新内容，覆盖输入文档中现有的类似内容。其中一些步骤非常重要，它们指定了在被覆盖的内容与新内容不匹配时生成的警告。
If in I-D mode, fill in "expiresDate" attribute of <rfc> based on the <date> element of the document's <front> element.
如果处于I-D模式，则根据文档的<front>元素的<date>元素填写<rfc>的“expiresDate”属性。
Create a <boilerplate> element if it does not exist. If there are any children of the <boilerplate> element, produce a warning that says "Existing boilerplate being removed. Other tools, specifically the draft submission tool, will treat this condition as an error" and remove the existing children.
如果不存在<boilerplate>元素，则创建该元素。如果<boilerplate>元素有任何子元素，则生成一条警告，说明“正在删除现有的样板文件。其他工具，特别是草稿提交工具，会将此情况视为错误”，并删除现有的子元素。
Verify that <rfc> "submissionType" and <seriesInfo> "stream" are the same if they are both present. If either is missing, add it. Note that both have a default value of "IETF".
验证<rfc>“submissionType”和<seriesInfo>“stream”是否相同（如果两者都存在）。如果缺少其中一个，请添加它。请注意，两者都有一个默认值“IETF”。
Add the "Status of this Memo" section to the <boilerplate> element with current values. The application will use the "submissionType", and "consensus" attributes of the <rfc> element, the <workgroup> element, and the "status" and "stream" attributes of the <seriesInfo> element, to determine which boilerplate from [RFC7841] to include, as described in Appendix A of [RFC7991].
使用当前值将“此备忘录的状态”部分添加到<boilerplate>元素中。如[RFC7991]附录A所述，应用程序将使用<rfc>元素的“submissionType”和“consensus”属性、<workgroup>元素以及<seriesInfo>元素的“status”和“stream”属性来确定要包括[RFC7841]中的哪个样板文件。
Add the "Copyright Notice" section to the <boilerplate> element. The application will use the "ipr" and "submissionType" attributes of the <rfc> element and the <date> element to determine which portions and which version of the Trust Legal Provisions (TLP) to use, as described in A.1 of [RFC7991].
将“版权声明”部分添加到<boilerplate>元素中。应用程序将使用<rfc>元素和<date>元素的“ipr”和“submissionType”属性来确定要使用的信托法律条款（TLP）的哪些部分和版本，如[RFC7991]的A.1所述。
For any <reference> element that does not already have a "target" attribute, fill the target attribute in if the element has one or more <seriesinfo> child element(s) and the "name" attribute of the <seriesinfo> element is "RFC", "Internet-Draft", or "DOI" or other value for which it is clear what the "target" should be. The particular URLs for RFCs, Internet-Drafts, and Digital Object Identifiers (DOIs) for this step will be specified later by the RFC Editor and the IESG. These URLs might also be different before and after the v3 format is adopted.
对于尚未具有“target”属性的任何<reference>元素，如果该元素具有一个或多个<serieinfo>子元素，并且<serieinfo>元素的“name”属性为“RFC”、“internetdraft”或“DOI”或其他明确“target”应该是什么的值，请填写目标属性。RFC编辑器和IESG稍后将指定此步骤中RFC、Internet草稿和数字对象标识符（DOI）的特定URL。在采用v3格式之前和之后，这些URL也可能不同。
Add a "slugifiedName" attribute to each <name> element that does not contain one; replace the attribute if it contains a value that begins with "n-".
为每个不包含“slugifiedName”属性的<name>元素添加一个“slugifiedName”属性；如果属性包含以“n-”开头的值，请替换该属性。
If the "sortRefs" attribute of the <rfc> element is true, sort the <reference> and <referencegroup> elements lexically by the value of the "anchor" attribute, as modified by the "to" attribute of any <displayreference> element. The RFC Editor needs to determine what the rules for lexical sorting are. The authors of this document acknowledge that getting consensus on this will be a difficult task.
如果<rfc>元素的“sortRefs”属性为true，则根据任何<displayreference>元素的“to”属性修改的“anchor”属性的值对<reference>和<referencegroup>元素进行词汇排序。RFC编辑器需要确定词法排序的规则。本文件的作者承认，在这方面达成共识将是一项艰巨的任务。
Add "pn" attributes for all parts. Parts are:
为所有零件添加“pn”属性。各部分包括：
o <section> in <middle>: pn='s-1.4.2'
o <section> in <middle>: pn='s-1.4.2'
o <references>: pn='s-12' or pn='s-12.1'
o <references>: pn='s-12' or pn='s-12.1'
o <abstract>: pn='s-abstract'
o <abstract>: pn='s-abstract'
o <note>: pn='s-note-2'
o <note>: pn='s-note-2'
o <section> in <boilerplate>: pn='s-boilerplate-1'
o <section> in <boilerplate>: pn='s-boilerplate-1'
o <table>: pn='t-3'
o <table>: pn='t-3'
o <figure>: pn='f-4'
o <figure>: pn='f-4'
o <artwork>, <aside>, <blockquote>, <dt>, <li>, <sourcecode>, <t>:
pn='p-[section]-[counter]'
o <artwork>, <aside>, <blockquote>, <dt>, <li>, <sourcecode>, <t>:
pn='p-[section]-[counter]'
In every <iref> element, create a document-unique "pn" attribute. The value of the "pn" attribute will start with 'i-', and use the item attribute, the subitem attribute (if it exists), and a counter to ensure uniqueness. For example, the first instance of "<iref item='foo' subitem='bar'>" will have the "irefid" attribute set to 'i-foo-bar-1'.
在每个<iref>元素中，创建一个文档唯一的“pn”属性。“pn”属性的值将以“i-”开头，并使用item属性、subitem属性（如果存在）和计数器来确保唯一性。例如，“<iref item='foo'subitem='bar'>”的第一个实例将“irefid”属性设置为“i-foo-bar-1”。
For each <xref> element that has content, fill the "derivedContent" with the element content, having first trimmed the whitespace from ends of content text. Issue a warning if the "derivedContent" attribute already exists and has a different value from what was being filled in.
对于每个包含内容的<xref>元素，首先修剪内容文本末尾的空白，然后用元素内容填充“derivedContent”。如果“derivedContent”属性已经存在并且与所填写的属性具有不同的值，则发出警告。
For each <xref> element that does not have content, fill the "derivedContent" attribute based on the "format" attribute.
对于没有内容的每个<xref>元素，根据“format”属性填充“derivedContent”属性。
o For a value of "counter", the "derivedContent" is set to the section, figure, table, or ordered list number of the element with an anchor equal to the <xref> target.
o 对于“counter”的值，“derivedContent”设置为元素的节、图、表或有序列表编号，其锚点等于<xref>目标。
o For format='default' and the "target" attribute points to a <reference> or <referencegroup> element, the "derivedContent" is the value of the "target" attribute (or the "to" attribute of a <displayreference> element for the targeted <reference>).
o 对于format='default'和指向<reference>或<referencegroup>元素的“target”属性，“derivedContent”是“target”属性的值（或指向<reference>的<displayreference>元素的“to”属性）。
o For format='default' and the "target" attribute points to a <section>, <figure>, or <table>, the "derivedContent" is the name of the thing pointed to, such as "Section 2.3", "Figure 12", or "Table 4".
o 对于format='default'和指向<section>、<figure>或<table>的“target”属性，“derivedContent”是指向的对象的名称，例如“section 2.3”、“figure 12”或“table 4”。
o For format='title', if the target is a <reference> element, the "derivedContent" attribute is the name of the reference, extracted from the <title> child of the <front> child of the reference.
o 对于format='title'，如果目标是<reference>元素，“derivedContent”属性是引用的名称，从引用的<front>子元素的<title>子元素中提取。
o For format='title', if the target element has a <name> child element, the "derivedContent" attribute is the text content of that <name> element concatenated with the text content of each descendant node of <name> (that is, stripping out all of the XML markup, leaving only the text).
o 对于format='title'，如果目标元素有<name>子元素，“derivedContent”属性是该<name>元素的文本内容，该元素与<name>的每个子节点的文本内容连接在一起（也就是说，去掉所有XML标记，只留下文本）。
o For format='title', if the target element does not contain a <name> child element, the "derivedContent" attribute is the value of the "target" attribute with no other adornment. Issue a warning if the "derivedContent" attribute already exists and has a different value from what was being filled in.
o 对于format='title'，如果目标元素不包含<name>子元素，“derivedContent”属性是不带其他装饰的“target”属性的值。如果“derivedContent”属性已经存在并且与所填写的属性具有不同的值，则发出警告。
If any <relref> element's "target" attribute refers to anything but a <reference> element, give an error.
如果任何<relref>元素的“target”属性引用的不是<reference>元素，则给出一个错误。
For each <relref> element, fill in the "derivedLink" attribute.
对于每个<relref>元素，填写“derivedLink”属性。
These steps will include external files into the output document.
这些步骤将在输出文档中包含外部文件。
1. If an <artwork> element has a "src" attribute where no scheme is specified, copy the "src" attribute value to the "originalSrc" attribute, and replace the "src" value with a URI that uses the "file:" scheme in a path relative to the file being processed. See Section 7 for warnings about this step. This will likely be one of the most common authoring approaches.
1. 如果<artwork>元素具有未指定方案的“src”属性，请将“src”属性值复制到“originalSrc”属性，并将“src”值替换为一个URI，该URI在与正在处理的文件相关的路径中使用“file:”方案。有关此步骤的警告，请参见第7节。这可能是最常见的创作方法之一。
2. If an <artwork> element has a "src" attribute with a "file:" scheme, and if processing the URL would cause the processor to retrieve a file that is not in the same directory, or a subdirectory, as the file being processed, give an error. If the "src" has any shellmeta strings (such as "`", "$USER", and so on) that would be processed, give an error. Replace the "src" attribute with a URI that uses the "file:" scheme in a path relative to the file being processed. This rule attempts to prevent <artwork src='file:///etc/passwd'> and similar security issues. See Section 7 for warnings about this step.
2. 如果<artwork>元素具有带有“file:”方案的“src”属性，并且如果处理URL会导致处理器检索与正在处理的文件不在同一目录或子目录中的文件，则给出一个错误。如果“src”有任何要处理的shellmeta字符串（如“`”、“$USER”等），请给出一个错误。将“src”属性替换为URI，该URI在与正在处理的文件相关的路径中使用“file:”方案。此规则试图阻止<artwork src=file:///etc/passwd“>和类似的安全问题。有关此步骤的警告，请参见第7节。
3. If an <artwork> element has a "src" attribute, and the element has content, give an error.
3. 如果<artwork>元素具有“src”属性，并且该元素具有内容，则给出一个错误。
4. If an <artwork> element has type='svg' and there is an "src" attribute, the data needs to be moved into the content of the <artwork> element.
4. 如果<artwork>元素具有type='svg'，并且存在“src”属性，则需要将数据移动到<artwork>元素的内容中。
* If the "src" URI scheme is "data:", fill the content of the <artwork> element with that data and remove the "src" attribute.
* 如果“src”URI方案是“data:”，则用该数据填充<artwork>元素的内容并删除“src”属性。
* If the "src" URI scheme is "file:", "http:", or "https:", fill the content of the <artwork> element with the resolved XML from the URI in the "src" attribute. If there is no "originalSrc" attribute, add an "originalSrc" attribute with the value of the URI and remove the "src" attribute.
* 如果“src”URI方案是“file:”、“http:”或“https:”，则在“src”属性中用URI中解析的XML填充<artwork>元素的内容。如果没有“originalSrc”属性，则添加一个具有URI值的“originalSrc”属性，并删除“src”属性。
* If the <artwork> element has an "alt" attribute, and the SVG does not have a <desc> element, add the <desc> element with the contents of the "alt" attribute.
* 如果<artwork>元素有一个“alt”属性，而SVG没有<desc>元素，则添加带有“alt”属性内容的<desc>元素。
5. If an <artwork> element has type='binary-art', the data needs to be in an "src" attribute with a URI scheme of "data:". If the "src" URI scheme is "file:", "http:", or "https:", resolve the URL. Replace the "src" attribute with a "data:" URI, and add an "originalSrc" attribute with the value of the URI. For the "http:" and "https:" URI schemes, the mediatype of the "data:" URI will be the Content-Type of the HTTP response. For the "file:" URI scheme, the mediatype of the "data:" URI needs to be guessed with heuristics (this is possibly a bad idea). This also fails for content that includes binary images but uses a type other than "binary-art". Note: since this feature can't be used for RFCs at the moment, this entire feature might be
5. 如果<artwork>元素具有type='binary-art'，则数据需要位于URI模式为“data:”的“src”属性中。如果“src”URI方案是“file:”、“http:”或“https:”，请解析URL。将“src”属性替换为“data:”URI，并使用URI的值添加“originalSrc”属性。对于“http:”和“https:”URI方案，“data:”URI的mediatype将是http响应的内容类型。对于“file:”URI方案，“data:”URI的mediatype需要通过启发式来猜测（这可能是个坏主意）。对于包含二进制图像但使用非“二进制艺术”类型的内容，此操作也失败。注意：由于此功能目前无法用于RFC，因此整个功能可能无法使用
6. If an <artwork> element does not have type='svg' or type='binary-art' and there is an "src" attribute, the data needs to be moved into the content of the <artwork> element. Note that this step assumes that all of the preferred types other than "binary-art" are text, which is possibly wrong.
6. 如果<artwork>元素没有type='svg'或type='binary-art'，并且存在“src”属性，则需要将数据移动到<artwork>元素的内容中。请注意，此步骤假设除“二进制艺术”之外的所有首选类型都是文本，这可能是错误的。
* If the "src" URI scheme is "data:", fill the content of the <artwork> element with the correctly escaped form of that data and remove the "src" attribute.
* 如果“src”URI方案是“data:”，则使用正确转义的数据形式填充<artwork>元素的内容，并删除“src”属性。
* If the "src" URI scheme is "file:", "http:", or "https:", fill the content of the <artwork> element with the correctly escaped form of the resolved text from the URI in the "src" attribute. If there is no "originalSrc" attribute, add an "originalSrc" attribute with the value of the URI and remove the "src" attribute.
* 如果“src”URI方案是“file:”、“http:”或“https:”，则在“src”属性中使用URI中解析文本的正确转义形式填充<artwork>元素的内容。如果没有“originalSrc”属性，则添加一个具有URI值的“originalSrc”属性，并删除“src”属性。
1. If a <sourcecode> element has a "src" attribute where no scheme is specified, copy the "src" attribute value to the "originalSrc" attribute and replace the "src" value with a URI that uses the "file:" scheme in a path relative to the file being processed. See Section 7 for warnings about this step. This will likely be one of the most common authoring approaches.
1. 如果<sourcecode>元素有一个“src”属性，其中没有指定任何方案，则将“src”属性值复制到“originalSrc”属性，并将“src”值替换为一个URI，该URI在相对于正在处理的文件的路径中使用“file:”方案。有关此步骤的警告，请参见第7节。这可能是最常见的创作方法之一。
2. If a <sourcecode> element has a "src" attribute with a "file:" scheme, and if processing the URL would cause the processor to retrieve a file that is not in the same directory, or a subdirectory, as the file being processed, give an error. If the "src" has any shellmeta strings (such as "`", "$USER", and so on) that would be processed, give an error. Replace the "src" attribute with a URI that uses the "file:" scheme in a path relative to the file being processed. This rule attempts to prevent <sourcecode src='file:///etc/passwd'> and similar security issues. See Section 7 for warnings about this step.
2. 如果<sourcecode>元素具有带有“file:”方案的“src”属性，并且如果处理URL会导致处理器检索与正在处理的文件不在同一目录或子目录中的文件，则给出一个错误。如果“src”有任何要处理的shellmeta字符串（如“`”、“$USER”等），请给出一个错误。将“src”属性替换为URI，该URI在与正在处理的文件相关的路径中使用“file:”方案。此规则试图阻止<sourcecode src=file:///etc/passwd“>和类似的安全问题。有关此步骤的警告，请参见第7节。
3. If a <sourcecode> element has a "src" attribute, and the element has content, give an error.
3. 如果<sourcecode>元素具有“src”属性，并且该元素具有内容，则给出一个错误。
4. If a <sourcecode> element has a "src" attribute, the data needs to be moved into the content of the <sourcecode> element.
4. 如果<sourcecode>元素具有“src”属性，则需要将数据移动到<sourcecode>元素的内容中。
* If the "src" URI scheme is "data:", fill the content of the <sourcecode> element with that data and remove the "src" attribute.
* 如果“src”URI方案是“data:”，则用该数据填充<sourcecode>元素的内容并删除“src”属性。
* If the "src" URI scheme is "file:", "http:", or "https:", fill the content of the <sourcecode> element with the resolved XML from the URI in the "src" attribute. If there is no "originalSrc" attribute, add an "originalSrc" attribute with the value of the URI and remove the "src" attribute.
* 如果“src”URI方案是“file:”、“http:”或“https:”，则在“src”属性中用URI中解析的XML填充<sourcecode>元素的内容。如果没有“originalSrc”属性，则添加一个具有URI值的“originalSrc”属性，并删除“src”属性。
These steps provide extra cleanup of the output document in RFC production mode.
这些步骤提供了RFC生产模式下输出文档的额外清理。
In RFC production mode, if there is a <note> or <section> element with a "removeInRFC" attribute that has the value "true", remove the element.
在RFC生产模式中，如果有一个<note>或<section>元素具有值为“true”的“removeInRFC”属性，请删除该元素。
If in RFC production mode, remove all <cref> elements.
如果处于RFC生产模式，则移除所有<cref>元素。
1. If in RFC production mode, remove all <link> elements whose "rel" attribute has the value "alternate".
1. 如果处于RFC生产模式，请删除其“rel”属性值为“alternate”的所有<link>元素。
2. If in RFC production mode, check if there is a <link> element with the current ISSN for the RFC series (2070-1721); if not, add <link rel="item" href="urn:issn:2070-1721">.
2. 如果处于RFC生产模式，请检查RFC系列（2070-1721）是否有具有当前ISSN的<link>元素；如果没有，请添加<link rel=“item”href=“urn:issn:2070-1721”>。
3. If in RFC production mode, check if there is a <link> element with a DOI for this RFC; if not, add one of the form <link rel="describedBy" href="https://dx.doi.org/10.17487/rfcdd"> where "dd" is the number of the RFC, such as "https://dx.doi.org/10.17487/rfc2109". The URI is described in [RFC7669]. If there was already a <link> element with a DOI for this RFC, check that the "href" value has the right format. The content of the href attribute is expected to change in the future.
3. 如果处于RFC生产模式，请检查是否有一个<link>元素具有此RFC的DOI；如果不是，请添加一个表单https://dx.doi.org/10.17487/rfcdd“>其中“dd”是RFC的编号，例如”https://dx.doi.org/10.17487/rfc2109". [RFC7669]中描述了URI。如果此RFC已有一个带有DOI的<link>元素，请检查“href”值的格式是否正确。href属性的内容预计将在将来更改。
4. If in RFC production mode, check if there is a <link> element with the file name of the Internet-Draft that became this RFC the form <link rel="convertedFrom" href="https://datatracker.ietf.org/doc/draft-tttttttttt/">. If one does not exist, give an error.
4. 如果处于RFC生产模式，请检查是否存在一个<link>元素，该元素的文件名为成为此RFC的Internet草稿，格式为<link rel=“convertedFrom”href=”https://datatracker.ietf.org/doc/draft-tttttttttt/">. 如果不存在，请给出一个错误。
If in RFC production mode, remove XML comments.
如果处于RFC生产模式，请删除XML注释。
If in RFC production mode, remove all "xml:base" or "originalSrc" attributes from all elements.
如果处于RFC生产模式，请从所有元素中删除所有“xml:base”或“originalSrc”属性。
If in RFC production mode, ensure that the result is in full compliance to the v3 schema, without any deprecated elements or attributes and give an error if any issues are found.
如果处于RFC生产模式，请确保结果完全符合v3模式，没有任何不推荐的元素或属性，如果发现任何问题，请给出错误。
These steps provide the finishing touches on the output document.
这些步骤为输出文档提供了最后的润色。
Determine all the characters used in the document and fill in the "scripts" attribute for <rfc>.
确定文档中使用的所有字符，并填写<rfc>的“脚本”属性。
Pretty-format the XML output. (Note: there are many tools that do an adequate job.)
将XML输出格式化。（注意：有许多工具可以完成足够的工作。）
There will be a need for Internet-Draft authors who include files from their local disk (such as for <artwork src="mydrawing.svg"/>) to have the contents of those files inlined to their drafts before submitting them to the Internet-Draft processor. (There is a possibility that the Internet-Draft processor will allow XML files and accompanying files to be submitted at the same time, but this seems troublesome from a security, portability, and complexity standpoint.) For these users, having a local copy of the prep tool that has an option to just inline all local files would be terribly useful. That option would be a proper subset of the steps given in Section 5.
对于包含本地磁盘文件（例如，<artwork src=“mydrawing.svg”/>）的Internet草稿作者，在将其提交给Internet草稿处理程序之前，需要将这些文件的内容内联到草稿中。（互联网草稿处理程序可能允许同时提交XML文件和附带文件，但从安全性、可移植性和复杂性的角度来看，这似乎很麻烦。）对于这些用户，拥有一个prep工具的本地副本，它可以选择只内联所有本地文件，这将非常有用。该选项是第5节中给出的步骤的适当子集。
A feature that might be useful in a local prep tool would be the inverse of the "just inline" option would be "extract all". This would allow a user who has a v3 RFC or Internet-Draft to dump all of the <artwork> and <sourcecode> elements into local files instead of having to find each one in the XML. This option might even do as much validation as possible on the extracted <sourcecode> elements. This feature might also remove some of the features added by the prep tool (such as part numbers and "slugifiedName" attributes starting with "n-") in order to make the resulting file easier to edit.
在本地准备工具中可能有用的一个特性是“justinline”选项的反义词是“extractall”。这将允许拥有v3 RFC或Internet草稿的用户将所有<artwork>和<sourcecode>元素转储到本地文件中，而不必在XML中查找每个元素。此选项甚至可以对提取的<sourcecode>元素执行尽可能多的验证。此功能还可能删除准备工具添加的某些功能（例如零件号和以“n-”开头的“slugifiedName”属性），以便更容易编辑生成的文件。
Steps in this document attempt to prevent the <artwork> and <sourcecode> entities from exposing the contents of files outside the directory in which the document being processed resides. For example, values starting with "/", "./", or "../" should generate errors.
本文档中的步骤试图防止<artwork>和<sourcecode>实体暴露正在处理的文档所在目录之外的文件内容。例如，以“/”、“/”或“./”开头的值应生成错误。
The security considerations in [RFC3470] apply here. Specifically, processing XML-external references can expose a prep-tool implementation to various threats by causing the implementation to access external resources automatically. It is important to disallow arbitrary access to such external references within XML data from untrusted sources.
[RFC3470]中的安全注意事项适用于此处。具体来说，处理XML外部引用会使prep工具实现自动访问外部资源，从而使其面临各种威胁。禁止从不受信任的源任意访问XML数据中的此类外部引用非常重要。
[IDNITS] IETF Tools, "Idnits Tool", <https://tools.ietf.org/tools/idnits/>.
[IDNITS]IETF工具，“IDNITS工具”<https://tools.ietf.org/tools/idnits/>.
[PUB-PROCESS] RFC Editor, "Publication Process", <https://www.rfc-editor.org/pubprocess/>.
[PUB-PROCESS]RFC编辑器，“发布过程”<https://www.rfc-editor.org/pubprocess/>.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, January 2003, <http://www.rfc-editor.org/info/rfc3470>.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，DOI 10.17487/RFC3470，2003年1月<http://www.rfc-editor.org/info/rfc3470>.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <http://www.rfc-editor.org/info/rfc6949>.
[RFC6949]Flanagan，H.和N.Brownlee，“RFC系列格式要求和未来发展”，RFC 6949，DOI 10.17487/RFC6949，2013年5月<http://www.rfc-editor.org/info/rfc6949>.
[RFC7669] Levine, J., "Assigning Digital Object Identifiers to RFCs", RFC 7669, DOI 10.17487/RFC7669, October 2015, <http://www.rfc-editor.org/info/rfc7669>.
[RFC7669]Levine，J.，“将数字对象标识符分配给RFC”，RFC 7669，DOI 10.17487/RFC7669，2015年10月<http://www.rfc-editor.org/info/rfc7669>.
[RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, <http://www.rfc-editor.org/info/rfc7841>.
[RFC7841]Halpern，J.，Ed.，Daigle，L.，Ed.，和O.Kolkman，Ed.，“RFC流，标题和样板”，RFC 7841，DOI 10.17487/RFC78412016年5月<http://www.rfc-editor.org/info/rfc7841>.
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <http://www.rfc-editor.org/info/rfc7991>.
[RFC7991]Hoffman，P.“xml2rfc”版本3词汇表”，RFC 7991，DOI 10.17487/RFC7991，2016年12月<http://www.rfc-editor.org/info/rfc7991>.
IAB Members at the Time of Approval
批准时的IAB成员
The IAB members at the time this memo was approved were (in alphabetical order):
本备忘录批准时，IAB成员为（按字母顺序排列）：
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
贾里·阿克科·拉尔夫·德罗姆斯·泰德·哈迪·乔·希尔德布兰德·罗斯·霍斯利·李·霍华德·埃里克·诺德马克·罗伯特·斯帕克斯·安德鲁·沙利文·戴夫·泰勒·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
Many people contributed valuable ideas to this document. Special thanks go to Robert Sparks for his in-depth review and contributions early in the development of this document and to Julian Reschke for his help getting the document structured more clearly.
许多人对这份文件提出了宝贵的意见。特别感谢Robert Sparks在本文件编制初期所做的深入审查和贡献，以及Julian Reschke为使文件结构更加清晰所做的帮助。
Authors' Addresses
作者地址
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org
Joe Hildebrand Mozilla
乔·希尔德布兰德·莫齐拉
Email: joe-ietf@cursive.net
Email: joe-ietf@cursive.net