[要約] 要約：RFC 7998は、XML形式の文書をRFC形式に変換するためのツールである「xml2rfc」バージョン3の準備に関する情報を提供しています。 目的：このRFCの目的は、xml2rfcツールのバージョン3の機能と使用方法を説明し、RFC文書の作成プロセスを改善するためのガイドラインを提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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形式にする必要があります。そのデータは、「準備ツール」と呼ばれるプログラムによって追加されます。このツールは、多くの場合、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.
2つの設定の違いはわずかです。たとえば、最初のページのボイラープレート出力と日付出力です。
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が提供する準備ツールの機能についてのみ説明していることに注意してください。他のユーザーは、独自のフォーマットのニーズに合わせて、独自の作業に似た準備ツールを作成する場合があります。ただし、出力形式の開発者は、独自のフォーマッターを作成するために準備ツールを変更する必要はありません。準備されたテキストを使用できればよいだけです。 IETF提供の準備ツールは、2つの異なるモードで実行されます。ツールがインターネットドラフトの送信および処理中に実行される場合の「I-D」モードと、RFCの生成中にツールがRFC Production Centerによって実行される場合の「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モード」と呼びます。ツールがエラーを検出しない場合、送信されたファイルと準備されたファイルの2つの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生成モードで準備ツールを実行し、AUTH48（[PUB-PROCESS]を参照）中に作成者が結果を利用できるようにするため、最終的な出力がどのようになるかを確認できます。ドキュメントがAUTH48レビューに合格すると、RPCは準備ツールを正規のRFC生成モードで最後にもう一度実行し、正規化された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-Dの場合と同様に、準備された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は、何かが発生した場合にエラーと見なし、すべての警告とエラーを人間が読める形式で説明するテキストを提供します。準備ツールは、XML入力を処理するときに、これらのエラーと警告をできるだけ多くチェックする必要があります。現時点では、ツールは準備されたXMLからのテキスト出力に対してidnitsを実行する可能性があります。以下のリストには、これらのエラーと警告の一部が含まれていますが、展開されたバージョンの準備ツールには、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>要素に、「3」以外の値を持つ「version」属性がある場合、エラーが発生します。 <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>要素がない場合は、準備ツールが実行されているモードに基づいてname属性を持つ<seriesInfo>要素を追加します（ "Internet-Draft" forドラフトモードおよびRFC生産モードの「RFC」）および入力ファイル名からインターネットドラフトの拡張子を除いた値であり、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>要素に、「day」、「month」、および「year」属性を持つ<date>要素が含まれているが、示された日付が過去3日より前または未来である場合、警告を出します。 <rfc>要素の<front>要素に、 "date"、 "month"、および "year"属性のすべてではなく一部を含む<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.
「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"を除いて、要素の属性のデフォルト値を入力します。一部のデフォルト値はRELAX NGスキーマにあり、その他の値は[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 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先祖が<boilerplate>のセクションの場合は、「exclude」を使用します。o toc = "include"を持つ子孫のセクションの場合は、「include」を使用します。祖先セクションの入力にtoc = "exclude"がある場合、これはエラーです。
o else for sections that are children of a section with toc="exclude", use "exclude".
o 他に、toc = "exclude"のセクションの子であるセクションの場合は、 "exclude"を使用します。
o else for sections that are deeper than rfc/@tocDepth, use "exclude"
o それ以外の場合、rfc / @ tocDepthよりも深いセクションについては、「除外」を使用します
o else use "include"
o それ以外の場合は「include」を使用します
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.
IDモードで、値が「true」である「removeInRFC」属性を持つ<note>または<section>要素がある場合は、「このメモは削除する前に」というテキストを含む要素の上部に段落を追加します。 RFCとして発行します。」または「このセクション...」。ただし、その正確なテキストで構成される段落がすでに存在する場合を除きます。
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.
これらの手順により、入力ドキュメントで複数の異なる方法で表現できるアイデアが、準備されたドキュメントで1つの方法でのみ見つかるようになります。
Normalize the values of "month" attributes in all <date> elements in <front> elements in <rfc> elements to numeric values.
<rfc>要素の<front>要素にあるすべての<date>要素の「月」属性の値を数値に正規化します。
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」、または「surname」要素（それぞれ）と照合します。 。 2つが同じ場合は、「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」属性を削除し、タイトルとともに<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>要素に追加します。アプリケーションは、<rfc>要素の<submissionType "および" consensus "属性、<workgroup>要素、および<seriesInfo>要素の" status "および" stream "属性を使用して、[ [RFC7991]の付録Aで説明されているように、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」属性を使用して、A.1で説明されているように、使用するTrust Legal Provisions（TLP）のどの部分とどのバージョンを決定します。 [RFC7991]。
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>要素については、要素に1つ以上の<seriesinfo>子要素があり、<seriesinfo>要素の「name」属性が「RFC」、「Internet-Draft」、「DOI」、または「ターゲット」が何であるかが明確なその他の値。このステップのRFC、インターネットドラフト、およびデジタルオブジェクト識別子（DOI）の特定のURLは、RFCエディターとIESGによって後で指定されます。これらのURLは、v3形式が採用される前後で異なる場合もあります。
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>要素に追加します。 「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の場合、<display>要素の「to」属性によって変更されるように、「anchor」属性の値で<reference>要素と<referencegroup>要素を字句順に並べ替えます。 。 RFCエディターは、字句ソートのルールを決定する必要があります。このドキュメントの作成者は、これについての合意を得ることは困難な作業になることを認めています。
Add "pn" attributes for all parts. Parts are:
すべてのパーツに「オン」属性を追加します。パーツは次のとおりです。
o <section> in <middle>: pn='s-1.4.2'
o <references>: pn='s-12' or pn='s-12.1'
o <abstract>: pn='s-abstract'
o <note>: pn='s-note-2'
o <section> in <boilerplate>: pn='s-boilerplate-1'
o <table>: pn='t-3'
o <figure>: pn='f-4'
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'で、「target」属性が<reference>または<referencegroup>要素を指す場合、「derivedContent」は「target」属性（または<displayreference>要素の「to」属性）の値ですターゲットの<reference>の場合）。
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'で、「target」属性が<section>、<figure>、または<table>を指す場合、「derivedContent」は「セクション2.3」、「図12 "、または"表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」値を「file：」スキームを使用するURIに置き換えます。処理中のファイルからの相対パス。このステップに関する警告については、セクション7を参照してください。これは、最も一般的なオーサリングアプローチの1つです。
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」に処理されるシェルメタ文字列（「 `」、「$ USER」など）がある場合は、エラーが発生します。 「src」属性を、処理中のファイルへの相対パスで「file：」スキームを使用するURIに置き換えます。このルールは、<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'がある場合、データは「src」属性にあり、URIスキームが「data：」である必要があります。 「src」URIスキームが「file：」、「http：」、または「https：」の場合、URLを解決します。 「src」属性を「data：」URIに置き換え、「originalSrc」属性をURIの値に追加します。 "http："および "https：" URIスキームの場合、 "data：" URIのメディアタイプはHTTP応答のContent-Typeになります。 「file：」URIスキームの場合、「data：」URIのメディアタイプはヒューリスティックスで推測する必要があります（これはおそらく悪い考えです）。これは、バイナリイメージを含むが「binary-art」以外のタイプを使用するコンテンツの場合も失敗します。注：この機能は現在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>要素のコンテンツに移動する必要があります。この手順では、「binary-art」以外のすべての推奨タイプがテキストであると想定していることに注意してください。
* 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："の場合、<artwork>要素のコンテンツに、 "src"のURIからの解決されたテキストの適切にエスケープされた形式を入力します。属性。 「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」値を「file：」スキームを使用するURIに置き換えます。処理中のファイルに対する相対パス。このステップに関する警告については、セクション7を参照してください。これは、最も一般的なオーサリングアプローチの1つです。
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」に処理されるシェルメタ文字列（「 `」、「$ USER」など）がある場合は、エラーが発生します。 「src」属性を、処理中のファイルへの相対パスで「file：」スキームを使用するURIに置き換えます。このルールは、<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プロダクションモードで、値が「true」の「removeInRFC」属性を持つ<note>または<section>要素がある場合は、その要素を削除します。
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プロダクションモードの場合は、このRFCのDOIを持つ<link>要素があるかどうかを確認します。そうでない場合は、次の形式のいずれかを追加します。 /dx.doi.org/10.17487/rfc2109」。 URIは[RFC7669]で説明されています。この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プロダクションモードの場合、このRFCになったInternet-Draftのファイル名が<link rel = "convertedFrom" href = "https://datatracker.ietf.org/の形式の<link>要素があるかどうかを確認します。 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>の「scripts」属性を入力します。
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" />など）を含めるインターネットドラフトの作成者は、それらのファイルのコンテンツをドラフトにインライン化してからインターネットに送信する必要があります。 -ドラフトプロセッサ。 （インターネットドラフトプロセッサがXMLファイルと付随するファイルの同時送信を許可する可能性がありますが、これは、セキュリティ、移植性、および複雑さの観点から厄介なようです。）すべてのローカルファイルをインライン化するオプションがある準備ツールは、非常に便利です。そのオプションは、セクション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.
ローカル準備ツールで役立つ可能性のある機能は、「全インライン」オプションの逆であり、「すべて抽出」です。これにより、v3 RFCまたはInternet-Draftを持っているユーザーは、<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外部参照を処理すると、実装が外部リソースに自動的にアクセスするようになるため、準備ツールの実装がさまざまな脅威にさらされる可能性があります。信頼できないソースからの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 Editor、「Publication Process」、<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プロトコル内でのExtensible Markup Language（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。、「Assigning Digital Object Identifiers to RFCs」、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。、and O. Kolkman、Ed。、 "RFC Streams、Headers、and Boilerplates"、RFC 7841、DOI 10.17487 / RFC7841、May 2016、<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。、「The "xml2rfc" Version 3 Vocabulary」、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
ポール・ホフマンICANN
Email: paul.hoffman@icann.org
Joe Hildebrand Mozilla
Joe Hildebrand Mozilla
Email: joe-ietf@cursive.net