[要約] RFC 4228は、IETFのドラフト提出ツールセットの要件を定義しています。その目的は、IETFメンバーが効率的にドラフトを提出し、プロセスをスムーズに進めることです。
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).
Copyright（c）The Internet Society（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
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 Webサイトから公開されています。ドラフトの投稿は、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".
ドラフトバージョン：意図したインターネットドラフトのスナップショットを意味します。「ドラフト改訂」とも呼ばれます。
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名のドラフト：識別子（別名ファイル名）が既知であり、「ドラフト特別」から始まるドラフト。編集者「または「IRTF」。「WGNドラフト」と略されました。例外にもかかわらず、WG名のドラフトは通常、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ルールによって許可されている提出者は、特定のドラフトを投稿するために許可されています。これには、ドラフト著者または編集者（ドラフトテキストにリストされている）、対応するWG椅子、または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.
ツールセットは、一連の規範的要件を使用して指定されています。これらの要件は、「（rnn/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 Webサイトにインターネットドラフトを投稿するために、IETFの参加者がドラフトテキストをIETF事務局にメールで送信し、事務局にドラフトを投稿するよう依頼する非公式のメモをメールで送信します。事務局のスタッフはメモを読み取り、チェックリストに従ってドラフトをレビューし、提出を承認または拒否します。ドラフト承認は、適切なIETFメーリングリストに送信される対応する発表をトリガーします。4時間ごとに、承認されたドラフトがIETFドラフトリポジトリに自動的にコピーされ、IETF Webサイトで利用可能になります。
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年には、約3,000のドラフトが提出されました; 2002：5K; 2004：7K [Sectorariat]）。投稿されたドラフトの約30〜50％はWG名のドラフトです（約2,100のドラフトの中で、2003年に約380の新規および290の更新されたWGNドラフトが投稿されました）。拒否統計は利用できませんが、提出されたドラフトの大部分は、投稿のために事務局によって承認されています。
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.
通常、秘書は特定のドラフトをレビューするのに数分かかります。ただし、事務局のスタッフは24時間年中無休で動作し、すべての時間ゾーンで機能しないため、他の責任があり、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.
多くのワーキンググループは、投稿の遅延に対処するためのアドホックソリューションを考案しました。たとえば、多くのドラフトスナップショットは、個人Webサイトで「一時的に」公開されているか、グループリストに（完全または一部）送信されます。代替の出版手段は、公式のIETFインターフェイスを効果的に置き換える可能性があり、IETF Webサイトに掲載されることになってしまう主要なドラフトのリビジョンはごくわずかです。
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ドラフトの最初の提出には、WG椅子の承認が必要です。これは、提出リクエスト自体のように偽造できます。ただし、これまでに悪意のあるなりすましや偽の承認は報告されていません。
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個のWebページと関連するアクションのシーケンスを通過します。ページの数は、ドラフト検証とメタデータ抽出の結果に依存します。たとえば、ドラフトを投稿せずに検証するには、アップロードとチェックの2つのWebページとの対話が必要です。手動メタデータ調整なしで有効なドラフトを投稿する一般的なケースには、3つのWebページ（アップロード、チェック、領収書）が必要です。
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）を表示します。このページには、ドラフトプレビューも表示される場合があります。解釈と検証結果のドラフトを確認した後、提出者には4つの基本的な選択肢があります。（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 processing (Section 12). The submitter is notified of the pending Secretariat request via email and a Receipt page.
手動の調整と投稿：提出者がメタデータの調整を決定した場合、ドラフトはツールセットステージング領域に残り、調整アクション（セクション10）に提出者に調整ページ（セクション11）を提示します。提出者が調整を行い、手動の投稿で収益を上げると、保存されたドラフトへのポインターとその調整されたメタデータが手動処理のために事務局に送信されます（セクション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
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）。タイムアウト値は、提出状態によって異なります。ヒント：タイムアウト値は、ツールセットが何らかの種類のサードパーティの確認を待っていない限り、おそらく十分に大きくなります（WG椅子の承認など）。明示的なキャンセルには提出状態の即時除去が必要である一方で、放棄されたとマークされた提出の状態はゴミ収集が必要であることを除いて、何もしないことは、提出を明示的にキャンセルすることと機能的に同等です。
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.
ステージング領域のメンテナンスアルゴリズムは、さまざまな段階（R67/A）で偽の提出物でエリアを圧倒しようとするサービス拒否（DOS）攻撃の存在下で、領域を一貫した正しい状態に保つ必要があります。ヒント：正当なユーザーへのサービスの拒否は、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.
このテキストが言及している「Webページ」は、同じまたは異なる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 drafts or is submitting drafts via email interface. The term "simultaneously" means that submission processing times overlap.
ツールセットは、同じドラフト（R72/a）を同時に提出する複数の提出者と、2つのドラフト（R73/A）を同時に送信する単一の提出者を同時に送信する必要があります。後者は、たとえば、提出者がいくつかのブラウザーウィンドウを使用していくつかのドラフトを送信している場合、または電子メールインターフェイスを介してドラフトを提出している場合に発生する可能性があります。「同時に」という用語は、提出処理時間が重複することを意味します。
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.
ヒント：単一のアクションは、複数のサーバー側プログラムに対応する場合があり、その逆も同様で、単一のプログラムがいくつかのアクションを実装する場合があります。このドキュメントは、特定のテクノロジー（例：Common Gateway Interface（CGI）、PHP、および/またはJavaサーブレットなど）をサーバー側のサポートを実装することを義務付けていません。実装者のエクスペリエンス、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.
ヒント：アクションは、ドラフトとともに保存することにより、状態を保存し、交換します。セッション識別子を使用して名前が付けられた1つのサブディレクトリにすべての提出固有の情報をグループ化すると、堅牢性が高まり、デバッグが簡素化される場合があります。セッションの作成と破壊は、グローバルインデックスに記録できます。
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）にする必要があり、バグを報告して要求する強化（R145/B）を報告するインターフェイスが必要です。独自のプラットフォームやバックエンドへのロックインを避けるために、開発を構成する必要があります。ツールチームは、オープンソース定義[OSD]に続いて1つ以上のオープンソースライセンスの下でツールセットソースを開発すると、これらの要件を合理的なコストで効果的に満たす方法を提供すると考えています。選択されたライセンスにより、異なる実装者からのコードが混合されるようにすることに注意する必要があります。
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 Webサイト（R1/B）の有名なページに移動します。そこで、ドラフトテキストは、HTMLファイルアップロードフォームを使用してアップロードできます。このフォームは、ドラフトのプレーンテキスト形式（R2/A）とIETFドラフトパブリケーションルール（R3/B）で許可されている他のすべての形式をアップロードするフィールドを提供します。執筆時点では、これらの形式はXML（[rfc2629]および[writing-rfcs]）、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）。検証のみのフラグなしで、それらを再度アップロードする必要があり、検証結果ページは（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 = "...">命令（pis）は、参照（R8/b）を含むように前処理されます。この手順は、XMLソースから外部依存関係を削除し、投稿されたXMLを処理するツールを簡素化するために必要です。このドキュメントは、そのようなXMLプロセッサの命令を「PISを含む」と呼んでいます。
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 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.
XMLプリプロセッサは、パブリックデータベースを使用してPI参照（R85/B）を解決します。ツールセットドキュメントでは、データベースが使用されるデータベースと、データベースエントリ（R86/B）にPISがどのようにマッピングされるかを指定します。いくつかのXMLソースは提出前に前処理されるか、PIなしで書かれているため、ツールセットはPISの存在（R87/B）に依存してはなりません。ヒント：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ソースと前処理されたXMLソースの両方が後で投稿される場合があります。PISを含む元のソースは、RFCエディターとDIFFの生成に役立つ場合があります（将来または過去の元のソースに対して）。PISを含む前処理されたソースは、投稿されたドラフト（R10/B）のデフォルトのパブリックXMLソースになります。ツールセットに既知の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）ではなく警告につながるはずです。HTML生成は、強化段階に達するまで実装されることを意図していません（R130/A）。一般に、HTMLのドラフトは通常、全体的な読みやすさとリンクが改善されたため、プレーンテキストドラフトよりもナビゲートしやすいため、HTMLの生成が望ましいです。拡張段階の機能として、HTMLの生成は、当時のIETFコンセンサスと最初の2つの実装段階の経験を反映するために削除または劇的に変更される場合があります。
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".
識別子：ドラフト「ファイル名」とも呼ばれます。たとえば、「Draft-Iitf-Sieve-Vacation-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-Iitf-Sieve-Vacation-07」の7番。通常、数字は2桁を使用してレンダリングされ、必要に応じて「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".
名前：同じドラフトのすべてのバージョンのすべてのドラフト識別子の共通部分。言い換えれば、バージョンコンポーネントのないドラフト識別子。たとえば、「Draft-Iitf-Sieve-Sieve-Vacation-07」の「ドラフト-ITESIEVE-VACATION」。
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.
WG ID：ワーキンググループ識別子。たとえば、「Draft-Iitf-Sieve-Vacation-07」の「ふるい」はWG IDです。WG IDの値は、WG名のドラフトではないドラフトの場合は空です。
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ドラフトには当てはまり、他のすべてのドラフトにはfalse。たとえば、「Draft-Iitf-Sieve-Vacation-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.
サイズ：ドラフトの主要な形式のページ数とオクテット数。ページの定義は形式に依存し、一部の形式では不正確またはarbitrary意的な場合があります。
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.
上記の他のメタデータ項目と同様に、ドラフトの作成日と有効期限はドラフトから抽出されます。それらの値は、実際の提出時間（つまり、チェックアクションが開始される時間）に依存しません。ただし、検証手順（セクション7.5を参照）は、現在（つまり、提出）時間、IETFドラフトの有効期限ルール、およびドラフトの外部の要因を考慮した後、抽出された日付を無効にすることを宣言することができます。
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>の「id-nits」ドキュメントを参照してください。ただし、ドラフト。それらに従うことで、ドラフトの品質を改善し、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.
特定のドラフトを検証する場合、絶対要件と望ましいドラフトプロパティを区別することが重要です。どちらのカテゴリもチェックされますが、違反はカテゴリに応じて異なる効果があります。2つのカテゴリは、次のサブセクションで詳しく説明されています。
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）があります。この承認は、WGの議長または秘書によって、最初のドラフト提出の前または後に中継することができます。関連要件については、セクション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）必要があります。1桁のドラフトバージョン番号は、「0」で左パッドにする必要があります。ドラフトバージョン番号はゼロから始まり、新しいバージョンごとに1つ増加する必要があります。この要件を満たすために、ツールセットは、期限切れのドラフトを含む既に投稿されたドラフトのリポジトリを参照する必要があります。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の提出はありませんBlackout期間は適用されません。ヒント：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）に関して有効です。最初の2つの実装段階では、対応する検証障害により、エラーではなく警告が発生することに注意してください（セクション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]で文書化されており、[Red-RFCS]で最近の変更が利用可能です。ヒント：http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/（またはその誘導体）のビル・フェナーの「RFC 2629バリデーター」は、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ルールがそれらを禁止していない限り、ツールセットは月の日なしで日付を受け入れる必要があります。ツールセットは、1日のない日付を検証するときに、月の実際の日について最も寛容/寛容な仮定を作る必要があります。
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 and/or advice may be available as a resource separate from the Toolset.
以下の要件のいずれかに違反しても、提出者がドラフト（R24/A）の自動ポストを防ぐことはできませんが、警告（R160/A）になります。各警告は、対応する違反を説明し、準拠する方法（R161/B）に関するアドバイスを提供します。ヒント：メンテナンスを容易にし、サードパーティの更新を奨励するために、詳細な説明やアドバイスをツールセットとは別のリソースとして利用できる場合があります。
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. <http://www.ietf.org/id-checklist.html>（r116/b）の「id-nits」ドキュメントのすべての自動テスト可能なnitsおよび<http://www.ietf.orgの自動テスト可能なガイドライン/ietf/1id-guidelines.txt>（r157/b）。ツールセットは、外部ツールを使用して、Check Code（R117/A）を埋め込むのではなく、これらのnitとガイドラインをチェックする必要があります。ヒント：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ソース（利用可能な場合）は、IETFドラフトのXML形式（R155/B）およびXML DTD（R156/B）に対して有効です。これらの要件は、2番目の実装フェーズの後に絶対になります。関連情報については、セクション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を満たすために生成され提出されたプレーンテキスト形式を比較する場合、標準的な単語ベースのDIFFでは、初期ツールセット実装（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:
DOS攻撃しきい値：
+---------------------------------+--------------+-----------+
| 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の場合、ツールセットは既存のWG承認（R125/A）をチェックします。（a）承認が存在しない場合、（b）ツールセットが「WG承認の待機」機能をサポートしていない場合、ツールセットはエラー（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）ツールセットが「WG承認の待機」機能をサポートし、（c）WG承認を受け取った場合でもドラフトを投稿できない場合、ツールセットはWGの承認がWGの承認がそうであることを警告します。ドラフトの投稿を防ぐすべてのエラーが固定されたら、必要になります（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 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).
（a）承認が存在しない場合、（b）ツールセットは「WG承認の待機」機能をサポートし、（c）WG承認を受け取った場合にドラフトを投稿できる場合、ツールセットは提出者に状況を説明し、WGからの明示的な承認は、勧誘または予想される必要があります（R126/B）。承認を求める必要がある場合、ソフトウェアまたは提出者によって勧誘されます。必要に応じて、ツールセットは、期待される承認が利用可能になるまで（R127/B）まで「WG承認を待つ」状態に提出します。それ以外の場合、ツールセットは「WG承認なし」エラー（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.
WG承認のための手動または自動勧誘の詳細は、このドキュメントの範囲外です。ヒント：最初は、提出者はWG椅子の承認を求める責任を負いますが、このプロセスは最終的に自動化する必要があります。
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 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).
ドラフトの更新については、チェックページには、最後の更新の時間と提出者（R83/B）が報告されています。この情報は、複数の著者が同じドラフトに取り組んでいる場合に特に役立ちます。また、このページには、最後の投稿バージョン（R84/C）に対してdiffを生成するリンクも提供します。
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）を通過する必要があります。ヒント：抽出された著者名の横にある一連のチェックボックスと、入力フィールドを持つ「上記のいずれでもない」チェックボックスで十分です。このドラフトに置き換えられたドラフトのリスト（R33/C）。これは、交換されたドラフトを見えないものにするのに役立ちます。このドキュメントは、既存のドラフト操作が範囲外であるため、既存のドラフトを実際に置き換えるために必要なアクションを指定しません。また、そのようなアクションのセキュリティ上の懸念やその他の合併症は、別の仕様によってより適切に対処されるためです。このドラフトの議論のための主要なメールアドレス（R71/B）。ヒント：ツールセットは、WGNドラフトのWGメーリングリストアドレス、個々のドラフトの著者アドレス、またはドラフトテキストの最初のメールアドレスを提案できます。ユーザー入力のみに依存するのではなく、いくつかの可能性のあるアドレスを提供すると、タイプミスの数も減ります。
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).
特定の送信者のメールアドレスが予想される提出者に属している場合（つまり、以下のカテゴリの1つに属します）、ツールセットはPost Nowアクション（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の著者。この要件は、ツールセットを使用してNTHバージョンが投稿されたドラフトに対してのみ満たされる必要があります。他のドラフトには、著者のリストを確実に取得するために必要なメタ情報が利用できない場合があります。WGNドラフトの場合、対応するWG（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).
Post Actionは、ドラフトが正常に検証されたこと（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).
外部メタデータには、送信者のメールアドレスが含まれています。検証手順の一環として、Post Now Actionは提出者を承認します。最初のアクション実装は、送信者がそのアドレスに送信された電子メール（R38/A）にアクセスできることをチェックします。最終的に、ツールセットは、IETF、PGPに署名した電子メール、および/またはその他のフォームのクライアントサイド認証によって署名されたクライアント証明書を受け入れる必要があります。提出者認証が失敗した場合、最終的に提出し、静かに時間を取得します（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）インターフェイスの両方を提供します。ヒント：送信者の電子メールへのアクセスを確認するために、ツールは、困難なクッキーまたはトークンを提出者のアドレスにメールで送信できます。提出を続行するには、提出者が指定されたURLでCookieを貼り付け、トークンホルディング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).
送信者に電子メールを送信した直後、Post Now Actionは、ツールセットの期待を説明し、提出者に提出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）に使用できるとマークされているため、Garbage Collectionルーチンは最終的に削除されます。
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.
領収書ページの主な目的は、すべてのドラフト著者に（おそらく）ドラフトが投稿されていることを通知することです。二次的な目的は、著者にイベントの恒久的な記録を作成し、投稿をトラブルシューティングにできるようにすることです。同じ情報をドラフトに関心のある他の関係者（例：WGメーリングリスト）に送信する必要がありますが、3番目のパーティ通知の詳細はこのドキュメントの範囲外です。
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）または秘書が使用することができる別の識別子を提供する必要があります。関連する詳細が最終的に失われる可能性が高い場合でも、識別子は永久（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 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).
マニュアルの提出を処理する場合、事務局はツールセットを使用できる場合があります。デフォルトのチェックページと同様の手動チェックページは、編集可能なメタデータフィールドと「フォースポスト」アクション（R50/B）を備えた認証された事務局スタッフに提供されます。強制的な投稿アクションは、メタデータフィールドを「現状のまま」受け入れ、電子メールまたはWGドラフト認証への送信者アクセスを確認せず、検証エラーが見つからなかったかのようにドラフトを投稿します（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.
このモードの目的は、「異常な」ドラフトを投稿したり、「異常な」状況下でドラフトを投稿するために、自動化されたメカニズムのバグまたは制限をバイパスする方法を提供する方法を提供することです。1つの例は、標準の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.
電子メールインターフェイスは、ドラフトを電子メールパーツのセットとして受け入れます（ドラフト形式ごとに1つ）（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 validation, submitter authentication, draft posting, and notification) apply to the email interface.
ドラフトを受け入れた後、ツールセットは送信者の電子メールアドレスを使用して提出者ID（R57/B）を選択し、提出（R58/B）をチェックし、チェックが成功した場合（R59/B）ドラフトを投稿します。提出者は、電子メール（R60/B）を介して提出ドラフトの結果を通知する必要があります。Webインターフェイスのその他の要件（提出前処理、ドラフト検証、提出者認証、ドラフトの投稿、および通知に関する要件を含む）は、電子メールインターフェイスに適用されます。
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）を含む認識不可能な部分ごとに警告が生成されることを除きます。これらの2つの要件は、送信者制御以外の電子メール署名やその他の部品の存在下でインターフェイスを堅牢にすることを目的としています。
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と電子メールの両方のインターフェイスにより、有効なドラフトを迅速に投稿できますが、2つのインターフェイスには大きな違いがあります。電子メールインターフェイスの主な利点は次のとおりです。
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.
Meta-Data：提出者は、オプションの外部メタデータを指定できます（ドラフト自体から抽出できません）。たとえば、ドラフトディスカッションのメールアドレスを指定できます。
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」という文字でマークされた3つの連続したステージがあります。以前のステージの要件は、後の段階でまだ満たされなければなりません。すべての要件は、現在の段階と現在実装されている機能のコンテキストで解釈および評価する必要があります。たとえば、要件R68は第1段階に適用されますが、第2段階までサポートされていない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の投稿ルールに違反するRogue Draftを投稿する。たとえば、ドラフトには、抽象的な意味のないまたは法的に拘束力のない抽象的なIPRステートメントを作成する抽象的なテキストが含まれる場合があります。
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 Draft」を「Draft-Ited-」から始まるドラフトとして定義します。他のすべてのドラフトは、個々のドラフトとして扱われます。現在、IETF WGは、単一のWGドラフトネーミング形式に従う必要はありません。したがって、WGがWGドラフトを考慮するドラフトの00バージョンは、WGの同意なしにツールセットによって投稿できます。影響を受けるWGSは、共通の命名形式を使用しないという決定の結果に対処する必要があります。ツールチームは、IETFでは、混乱を最小限に抑えるために単一の形式を使用してWGSにドラフトに名前を付ける必要があることを示唆しています。うまくいけば、「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 一部のドラフトでは、ツールセットは、提出者が「予想」であることを確認します（例：以前のドラフトバージョンまたはWGチェアの著者）。現在、事務局は事実上そのような検証を行いませんが、電子メールの送信インターフェイスと提出ループでの人間の存在は、大規模な自動化された攻撃を防ぐのに十分なようです。この変更は、シンプルなスクリプトが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（Ericsson）、Larry Masinter（Adobe）、Keith Moore（テネシー大学）、Pekka Savola（Netcore）、Henning Schulzrinne（Columbia University）、およびStanislav Shalunov（Internet2）。
Special thanks to Marshall Rose for his xml2rfc tool.
XML2RFCツールを提供してくれたMarshall Roseに感謝します。
Normative References
引用文献
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年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] World Wide Webコンソーシアム、「拡張可能なマークアップ言語（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.
[Writing-RFCS] Rose、M。、「XMLを使用したI-DSおよび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
Alex Rousskov測定工場
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。