Network Working Group A. Rousskov
Request for Comments: 4228 The Measurement Factory
Category: Informational December 2005
Requirements for an IETF Draft Submission Toolset
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.
この文書はインターネットドラフトの提出、検証、および投稿を容易にするために、IETFツールセットの要件を指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Scope ...........................................................2
3. Notation and Terminology ........................................3
4. Status Quo ......................................................4
5. Overall Toolset Operation .......................................6
6. Upload Page .....................................................9
7. Check Action ....................................................9
7.1. Preprocessing .............................................10
7.2. Processing ................................................11
7.3. Storage ...................................................11
7.4. Extraction ................................................12
7.5. Validation ................................................13
7.5.1. Absolute Requirements ..............................14
7.5.2. Desirable Features .................................15
7.5.3. DoS Thresholds .....................................17
7.5.4. WG Approval ........................................17
8. Check Page .....................................................18
8.1. External Meta-Data ........................................19
9. Post Now Action ................................................20
9.1. Receipt Page ..............................................20
10. Adjust Action .................................................21
11. Adjust Page ...................................................21
12. Post Manually Action ..........................................22
13. Receipt Page ..................................................22
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-という名前のドラフト：「IESG」、「IETF」「IAB」、「RFC-：（ファイル名別名）識別子が知られており、SPECIALは、以下のいずれかのストリングです「ドラフトSPECIAL-」で始まるされているドラフトエディタ」、または "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.
ツールセットは、規範的な要件のセットを使用して指定されています。これらの要件は、「nnnは」固有の要件番号であり、「S」は、単一文字コード（「A」、「B」、または「C」が「（Rnnn / S）」表示、で終わる英語のフレーズであります）要件の実装ステージを指定します。実装の段階は、第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 [事務局]）年間インターネットドラフトの数千を提出します。投稿ドラフトの約30から50パーセントである（いくつかの2100のドラフトの中で、およそ380新しい290の更新WGNドラフト2003年に掲示があった）ドラフトをWG-命名。何の拒否統計が用意されていませんが、提出ドラフトの大半は、投稿のために、事務局によって承認されています。
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/7に動作しないので、すべての時間帯での作業、およびその他の責任を持っており、承認されたドラフトがバッチで4時間ごとに掲載されているので、それが取得するために数時間から数日かかる場合がありますされませんドラフトが投稿しました。はるかに高い需要と固定処理能力に、IETF対面会議前の最後の週の間ポスティングは、ほぼ同時に発表されている未処理のドラフトの長い行列を作成し、非常に長い時間がかかります。
To give IETF face-to-face meeting participants time to review relevant documents, the Secretariat does not accept Internet-Draft submissions close to IETF meetings (regardless of whether a draft is relevant to the upcoming meeting or not).
IETF対面会議に関連する文書をレビューするために、参加者の時間を与えるために、事務局は、IETFミーティング（関わらず、草案は、今後の会議に関連しているか否かの）に近いインターネットドラフトの提出は受け付けません。
Many Working Groups have come up with ad hoc solutions to cope with posting delays. For example, many draft snapshots are "temporarily" published on personal web sites or sent (completely or in part) to the group list. Alternative means of publication may effectively replace official IETF interfaces, with only a few major draft revisions ending up posted on the IETF web site.
多くのワーキンググループは、投稿の遅延に対処するためのアドホックソリューションが出ています。例えば、多くのドラフトスナップショットは、「一時的に」個人のウェブサイト上で公開されているか、グループリストに（完全または部分的に）送られました。出版物の代替手段が効果的にIETFのWebサイトに掲載し終わるだけでいくつかの主要なドラフトリビジョンで、公式IETFのインターフェイスを交換することができます。
Informal interfaces for submitting and posting drafts discourage automation. Lack of submission automation increases Secretariat load, complicates automated indexing and cross-referencing of the drafts, and, for some authors, leads to stale drafts not being updated often enough.
ドラフトを提出し、投稿するための非公式のインターフェイスは、自動化を阻止します。提出の自動化の欠如は、事務局の負荷を増大させ、自動インデックス作成およびドラフトの相互参照を複雑にし、そして、いくつかの作家のために、十分な頻度で更新されていない古い草稿につながります。
Beyond a short Secretariat checklist, submitted drafts are not checked for compliance with IETF requirements for archival documents, and submitters are not notified of any violations. As a result, the IESG and RFC Editor may have to spend resources (and delay approval) resolving violations with draft authors. Often, these violations can be detected automatically and would have been fixed by draft authors if the authors knew about them before requesting publication of the draft.
短い事務局のチェックリストを越えて、提出ドラフトはアーカイブ文書のためのIETFの要件に準拠してチェックされないと、提出者は、違反が通知されていません。その結果、IESGとRFC Editorはドラフト著者と違反を解決するリソースを費やす（および承認を遅らせる）する必要があります。多くの場合、これらの違反を自動的に検出することが可能と著者が草案の公表を要求する前にそれらについて知っていた場合は、ドラフトの著者によって固定されていたであろう。
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の議長の承認）のいくつかの種類を待っている場合を除き1時間のタイムアウト値は、おそらく十分な大きさです。何もしないことは明示的に放棄したとしてマークされた提出の状態がガベージコレクトされながら、その明示的なキャンセルは提出状態の即時除去を必要とする以外、提出をキャンセルする機能的に同等です。
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サーブレット）任意の特定の技術を強制しません。実装者の経験、ウェブや電子メールインタフェースで、コードの再利用、およびその他の要因は、右の技術選択を決定します。
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]合理的なコストでこれらの要件を満たす効果的な方法を提供することを考えています。ケアは、選択したライセンスが異なる実装からのコードが混在することを可能にするように注意しなければなりません。
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]と[書き込みのRFC]）、PDF、およびPostScript。
Submitted forms are handled by the Check action documented in Section 7.
提出されたフォームは、第7節に記載さチェック作用によって処理されます。
The Upload page also has a validate-only flag, indicating that an uploaded draft must not be posted and may be deleted immediately after the validation (R74/b). Regardless of the validation results, the stored draft meta-data is marked so that validation-only drafts can be identified and deleted first by garbage collector for the Toolset staging area (R75/b). Drafts uploaded in a validate-only mode cannot be posted (R76/b); they would need to be uploaded again, without the validate-only flag, and the validation results page should explain that (R77/b). This flag is useful for tools using online validation, especially for bulk draft processing. Hint: it may be better to implement this flag as a hidden HTML input field to simplify the interface for human submitters.
アップロードページには、アップロードされたドラフトが掲載されてはならないと検証（R74 / B）の直後に削除することができることを示し、検証専用フラグを持っています。検証のみのドラフトを同定し、ツールセットのステージング領域（R75 / B）のためのガベージコレクタによって最初に削除することができるようにかかわらず、検証結果を、記憶されたドラフトメタデータがマークされます。検証専用モードでアップロードされたドラフトは（R76 / b）に掲載することはできません。彼らは検証専用フラグせずに、再びアップロードする必要があるだろう、と検証結果のページには、その（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に加えて、テキスト形式を必要としているとして、これらのドラフトを投稿して助けることができません。ツールセットは、その内容がプレーンテキスト形式（R143 / A）と一致することを検証できるようになるまで、さらに、PDFやPostScript形式を含むドラフトは自動投稿であってはなりません。
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）の間に伸張しなければなりません。ヒント：この仕様はサポートされている圧縮規格の一覧を文書化しませんが、それは圧縮がサポートされている場合、「郵便番号」と「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プロセッサ<RFCを含むXMLソース？含ま= "...">命令（主任研究者）を参照（R8 / B）を含むように前処理されます。このステップは、XMLソースからの外部依存関係を削除すると、ツールの処理掲載XMLを単純化するために必要とされます。この文書では、「主任研究者を含める」のようなXMLプロセッサ命令を指します。
The XML preprocessor uses public database(s) to resolve PI references (R85/b). The Toolset documentation specifies what databases are used and how PIs are mapped to database entries (R86/b). The Toolset must 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）を解決するために、公開データベース（複数可）を使用しています。ツールセットのドキュメントでは、データベースが使用されているものとのPIは、データベースエントリ（R86 / B）にマップする方法を指定します。ツールセットは、いくつかのXMLソースを提出する前に前処理されるかのPIなしに書き込まれるので、PIの存在（R87 / B）に頼ってはいけません。ヒント：xml.resource.orgでマーシャルローズの参照データベースのローカル最新のコピーを使用することができます。
Both original and preprocessed XML sources may be posted later. The original source with include PIs may be useful to the RFC Editor and generation of diffs (against future or past original sources). The preprocessed source without include PIs becomes the default public XML source of the posted draft (R10/b). If any of the include PIs known to the Toolset cannot be handled, an error is recorded (R11/b), and the submitter is encouraged to do the preprocessing locally, before submitting the draft (R111/b).
どちらもオリジナルと前処理XMLソースは、後に掲載される場合があります。元のソースは、PIはRFC Editorと（将来又は過去のオリジナルソースに対する）差分の生成に有用であり得るが挙げられます。なしの前処理源は、PIは掲載ドラフト（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）を生じるはずです。強化段階が（R130 / A）に到達するまで、HTMLの生成が実装されることを意図されていません。 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".
識別子：また、草案「ファイル名」として知られています。例えば、 "ドラフト-IETF-篩休暇-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.
バージョン：（もドラフトリビジョン番号としても知られる）ドラフトバージョン番号を表す非負整数。例えば、 "ドラフト-IETF-篩休暇-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".
名前：同じドラフトのすべてのバージョンのすべてのドラフト識別子の共通部分。換言すれば、バージョンの成分を含まないドラフト識別子。例えば、 "ドラフト-IETF-篩休暇-07" で、 "ドラフト-IETF-ふるい-休暇"。
WG ID: Working Group identifier. For example, "sieve" in "draft-ietf-sieve-vacation-07" is a WG ID. The WG ID value is empty for drafts that are not WG-named drafts.
WG ID：ワーキンググループ識別子。たとえば、 "ふるい" "ドラフト-IETF-篩休暇-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のドラフトのための真と偽。例えば、 "ドラフト-IETF-篩休暇-13" のための "真"。このフラグは限り現在のドキュメントに関しては、初期（バージョン00）案の提出のさらなるハンドリングに影響を与えます。
title: A human-friendly draft title. For example, the title of this document is "Requirements for an IETF Draft Submission Toolset".
タイトル：人に優しい下書きのタイトル。たとえば、本書のタイトルは、「IETFドラフト提出ツールセットの要件」です。
authors: A list of all draft authors. Each author's name and email address are extracted.
著者：すべてのドラフト作成者のリスト。それぞれの作者の名前とメールアドレスが抽出されています。
abstract: The draft abstract text.
抽象的：ドラフト抽象的なテキスト。
creation date: The draft version creation date.
作成日時：ドラフト版の作成日付。
expiration date: The draft version expiration date.
有効期限：ドラフト版の有効期限。
size: The number of pages and octets in the primary format of the draft. The definition of a page depends on the format and may be imprecise or arbitrary for some formats.
サイズ：ドラフトの主な形式のページとオクテット数。ページの定義は、フォーマットに依存し、いくつかのフォーマットのための不正確または任意でよいです。
Failure to extract any field results in error (R95/a).
エラー（R95 / A）内の任意のフィールドの結果を抽出する障害。
The Toolset requires author email addresses because they are essential for notifying co-authors that their draft has been posted. If there are no such notifications, a submitter adding a co-author to the draft without the co-author's consent may not be caught for a while. Such "surprise" co-authorships have happened in the past and can be quite annoying. However, since the Toolset does not solicit co-authors' consent to post a valid draft (and such solicitation would not go beyond email control verification anyway), it is not possible to stop a malicious submitter from adding co-authors without their knowledge.
彼らは彼らの案が掲載された共著者に通知するために不可欠であるため、ツールセットは、著者の電子メールアドレスが必要です。そのような通知がない場合は、共著者の同意なしにドラフトに共著者を追加提出者は、しばらくの間、キャッチすることはできません。このような「驚き」の共同authorshipsは、過去に起こった、非常にいらいらすることができます。ツールセットが有効なドラフトを投稿する共著者の同意を求めるされません（と、そのような勧誘はとにかくメール制御の検証を超えて行かないだろう）しかし、彼らの知識がなくても共著者を追加することから悪質な提出者を停止することはできません。
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」のドキュメントを参照してください。これらの要件のほとんどは、Internet-のために適用されません下書きは。しかし、それらを以下のことは、ドラフトの品質を向上させる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）でなければなりません。一桁のドラフトバージョン番号は左詰めされなければならない「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.アンIETF IPRステートメントと[RFC3978]及び[RFC3979]（または後継）に係るドラフトに必要な他の定型は、ドラフトテキスト（R23 / A）で表示されなければなりません。
5. The extracted creation date of the draft version must be within 3 days of the actual submission date (R159/a). Hint: Implementers should be careful to handle creation dates that appear to be in the past or in the future, due to possible time zone differences. Making the most forgiving/permissive assumption about the time zone should suffice.
5.ドラフトバージョンの抽出された作成日は、実際の提出日（R159 / A）の3日以内でなければなりません。ヒント：実装者が原因の可能なタイムゾーンの違いに、過去や未来にあるように見えるの作成日付を処理するように注意する必要があります。タイムゾーンに関する最も寛容/許容仮定を作ることは十分です。
6. The draft version expiration date obeys IETF draft expiration rules.
6.ドラフト版の有効期限は、IETFのドラフトの有効期限の規則に従います。
7. No IETF submission blackout period applies. Hint: IETF blackouts must be enforced based on submission time, not possible draft creation time.
7.ませIETF提出停止期間は適用されません。ヒント：IETF停電が提出時間、ではない可能性草案の作成時間に基づいて実施されなければなりません。
8. Posting the draft must not result in any DoS attack threshold to be crossed (R97/a). Specific thresholds are documented in Section 7.5.3.
8.草案を投稿しても、DoS攻撃しきい値交差する（R97 / A）が発生してはなりません。特定のしきい値は、セクション7.5.3に記載されています。
9. XML sources (if available) are valid with respect to the XML format [XML] (R153/c) and XML Document Type Definition (DTD) for IETF drafts (R154/c). Note that during the first two implementation stages, the corresponding validation failures result in warnings and not errors (see Section 7.5.2).
9. XMLソースは（利用可能な場合）XML形式[XML]（R153 / c）およびIETFドラフトのXML文書型定義（DTD）（R154 / C）に対して有効です。最初の二つの実施段階で、対応する検証の失敗（セクション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は、[書き込みのRFC]で利用可能な最近の変化と[RFC2629]に記述されています。ヒント：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のルールがそれらを禁止していないとして、月の日なしで日付を受け入れる必要があります。日レス日付の検証時にツールセットは、月の実際の日についての最も寛容/許容仮定を行う必要があります。
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>で "ID-NITS" 文書（R116 / B）のすべて自動的にテスト可能なニットと<HTTPで自動的に検証可能なガイドライン：//www.ietf .ORG / IETF / 1ID-guidelines.txt>（R157 / B）。ツールセットは、これらのニットやガイドラインではなく、埋め込みコードチェック（R117 / A）を確認するために外部ツールを使用する必要があります。ヒント：ヘンリク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）が期待されています。 IESGレビューの下で、すでにドラフトの新バージョンを掲載することは、警告を生成する必要がありながら、例えば、個々のドラフトのバージョン00は、常に、期待されています。
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).
XMLとプレーンテキストの両方の形式が提出された場合3.提出され、プレーンテキストが送信された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.以前のバージョンであれば、（R96 / b）少なくとも24時間前に投稿されました。この警告は、複数の著者が同じドラフトを投稿して場合は特に、いくつかのヒューマンエラーを防ぐことができます。
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ドラフト（R156 / B）のためのXML形式（R155 / b）およびXML DTDに関して有効です。これらの要件は、第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）を開発することができます。差異が検出された場合、完全なdiffは警告に加えて、別のページ（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の承認があろうと警告を記録します（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の承認待ち」機能をサポートしており、WGの承認を受信した場合（c）の草案を掲載することができ、その後、ツールセットは、提出者に状況を説明し、かどうかを尋ねます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.
チェックページでは、（R82 / b）の掲示場合（そのすべてのフォーマットと）全体の草稿がどのように見えるかを見るためにリンクして、ドラフトテキスト形式（R31 / A）のプレビューを提供します。ヒント：チェック・ページのプレビューが著者は明らかにドラフトのミスマッチや誤った解釈の誤りが、ページを支配しないように十分に短いを検出させるために十分に長くなければなりません。抽象の最後のラインを通ってドラフトの最初の行を表示する十分であろう。
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）に対する差分を生成するためのリンクを提供します。
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).
所与の登録者のメールアドレスが期待サブミッターに属している場合、ツールセットポスト今アクション（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、同じドラフトのバージョンN（R120 / A）の作成者。この要件は、N番目のバージョンは、ツールセットを使用して投稿されたためにドラフトのために満足する必要があります。他のドラフトは確実に著者のリストを取得するために必要とされる可能なメタ情報を持っていないかもしれません。 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).
ポスト今すぐアクションはドラフトが正常に検証されたことを確認（R34 / A）、（R35 / A）（提出者の電子メールアドレスを含む）外部メタデータを検証し、ドラフト（R36 / A）をポストします。提出者は、アクションの進行状況と最終結果（R37 / A）が通知されます。
The external meta-data contains the submitter's email address. As a part of the validation procedure, the Post Now action authorizes the submitter. The initial action implementation checks that the submitter has access to email sent to that address (R38/a). Eventually, the Toolset should accept client certificates signed by IETF, PGP-signed email, and/or other forms of client-side authentication to eliminate the weak and annoying email access check (R110/c). If submitter authentication fails, the submission eventually and silently times out (R39/a).
外部メタデータは、送信者の電子メールアドレスが含まれています。検証手順の一環として、ポスト今すぐアクションが提出を承認します。提出者は、そのアドレス（R38 / A）に送られた電子メールへのアクセス権を持っていることを最初のアクションの実装をチェックします。最終的には、ツールセットは弱く、迷惑メールへのアクセスチェック（R110 / C）を除去するために、クライアントの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.
ツールセットは、両方のウェブ（R99 / a）および電子メール（R139 / b）は、電子メールのアクセスを確認するためのインターフェースを提供します。ヒント：電子メールへの送信者のアクセスを確認するには、ツールはハードに推測クッキーに電子メールを送るか、または送信者のアドレスにトークンすることができます。提出を続行するには、提出者は、指定されたURLにクッキーを貼り付けトークン保持URLにアクセスしてください、またはメールに返信するように要求されます。
Immediately after sending an email to the submitter, the Post Now action generates an intermediate Receipt page that explains Toolset expectations and provides the submitter with the submission ID (R100/a). That number allows the Secretariat to troubleshoot stuck submissions (R101/a) and can also be used for checking submission status without Secretariat involvement (R140/b).
すぐに提出者に電子メールを送信した後、ポストは今すぐ行動はツールセットの期待を説明し、提出ID（R100 / A）で提出を提供し、中間領収書のページを生成します。その数は、事務局が立ち往生提出（R101 / A）のトラブルシューティングすることができますし、また事務局の関与（R140 / B）せずに提出状況をチェックするために使用することができます。
Immediately after posting the draft, the Toolset notifies all authors (with known email addresses) of the posting (R102/a). The notification email contains the information available on the "successful posting" Receipt page described below (R103/a).
すぐにドラフトを掲示した後、ツールセットは、投稿（R102 / A）の（既知の電子メールアドレスを持つ）すべての著者に通知します。通知メールは、以下の「成功の投稿」領収ページ（R103 / A）で入手可能な情報が含まれています。
If draft posting is successful, the submission state is marked as available for deletion (R105/a) so that the garbage collection routine eventually deletes it.
ドラフトの投稿が成功した場合は、提出状態は、ガベージコレクションのルーチンは、最終的にそれを削除するように削除（R105 / A）のために利用可能としてマークされています。
A successful Post Now action reports at least the following information on the final Receipt page (R104/a):
最終領収ページ（R104 / a）の上に、少なくとも以下の情報成功後の今、アクションレポート：
o the draft ID and a link to the draft status page.
ドラフトIDとドラフトステータスページへのリンクO。
o the draft title, authors, and abstract.
下書きのタイトル、作成者、および抽象O。
o the submission ID.
提出ID O。
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.
領収書のページの主な目的は、（おそらく）その草案が掲載されたすべてのドラフト作成者に通知することです。第2の目的は、著者らは、イベントの永続的な記録を作成してみましょうとの投稿をトラブルシューティングするためです。同じ情報が（例えば、WGメーリングリストに）ドラフトに興味を持っている他の関係者に送信する必要がありますが、サードパーティの通知詳細は、このドキュメントの範囲外です。
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.
領収書ページが提出者に提出（R63 / A）のマニュアルトラブルシューティングのために事務局によって使用されることができるユニフォームリソース識別子（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.
このモードの目的は、提出者は「珍しい」草案を投稿するか、「異常な」状況下でドラフトを投稿するために、自動化メカニズムのバグや制限をバイパスするための方法を提供することです。一つの例は、標準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.
Eメールインターフェイスは、電子メールの一部（S）（ドラフト形式ごとに）（R56 / B）のセットとしてドラフトを受け付けます。 XMLソース・フォーマットは、必要に応じて、同じ電子メールメッセージの「添付ファイル」として送信することができるが、例えば、テキスト形式は、電子メールメッセージの「ボディ」に提出することができます。各部分は、いずれかの実際の形式のデータ（R141 / b）またはそれを指す単一のURL（R142 / c）を含むことができます。後者の場合には、ツールセットは、フォーマットデータをフェッチしなければなりません。 URLフェッチオプションの詳細については、ここでは文書化されていませんが、（少なくとも）のURLがサポートされているHTTPと仮定して、フェッチエラーが報告されています。この文書では、各電子メールの一部の形式はどのように決定されるかを指定しませんが、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.
草案を受け入れた後、ツールセットは、提出者の身元（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
< - 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.
ドラフト形式として認識されていない電子メールの部品/添付ファイルはドラフト形式として考慮されていません。そのような部品は、警告が空白（R108 / B）よりも多くを含む各認識できない部分に生成されることを除いて、ツールセット（R107 / B）によって無視されます。これらの二つの要件は、電子メールの署名と提出者の制御の外の他の部分の存在下で、インタフェースは堅牢にするために意図されています。
Hint: Toolset actions can be implemented to support email and web interfaces without code duplication.
ヒント：ツールセットのアクションは、コードの重複なしで電子メールやWebのインターフェイスをサポートするために実装することができます。
While both web and email interfaces allow for fast posting of valid drafts, there are significant differences between the two interfaces. Primary advantages of the email interface are:
ウェブと電子メールの両方のインターフェイスが有効なドラフトの高速な投稿を可能にしながら、二つのインタフェースとの間に有意な違いがあります。電子メールインタフェースの主な利点は以下のとおりです。
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".
利便性：一部のIETFersは、一般的に、「より便利に」とのメールのインターフェイスを検討してください。
Primary advantages of the web interface are:
Webインタフェースの主な利点は以下のとおりです。
confirmation: A submitter is given a chance to verify that automated extraction of meta-data produced reasonable results. Other useful confirmations are possible (e.g., "Are you sure you want to post a version of the draft that was updated 30 seconds ago by your co-author?").
確認は：提出者は、合理的な結果が得られたメタデータの自動抽出を検証する機会を与えられています。他の有用な確認は（例えば、「あなたはあなたの共著者で30秒前に更新されたドラフトのバージョンを投稿してもよろしいですか？」）も可能です。
validation: A submitter can validate the draft without posting it.
検証：提出者は、それを掲示せずにドラフトを検証することができます。
quality: Non-critical warnings may prompt the submitter to postpone posting to improve draft quality.
品質：非クリティカルな警告がドラフト品質を向上させるために掲示延期する提出者に促すことができます。
manual adjustments: The submitter can adjust extracted meta-data and ease Secretariat work on manually posting an unusual draft.
手動調整：提出者は、抽出されたメタデータを調整し、事務局を手動で異例のドラフトを掲示上の作業が容易になります。
meta-data: The submitter can specify optional external meta-data (that cannot be extracted from the draft itself). For example, an email address for draft discussion can be specified.
メタデータ：提出者（すなわちドラフト自体から抽出することができない）任意の外部のメタデータを指定することができます。例えば、ドラフトの議論のための電子メールアドレスを指定することができます。
context help: The web interface makes it easy to provide links to extra information about input fields, errors, posting options, deadlines, etc.
コンテキストヘルプは：Webインターフェイスは、それが簡単に入力フィールド、エラー、投稿オプション、期限などに関する追加情報へのリンクを提供することができます
opaqueness: Files submitted via the web interface are arguably less susceptible to various in-transit transformations and misinterpretation than emails. Emails are often mutated by mail agents (e.g., automated disclaimers added by senders and extra line feeds added by recipients).
不透明は：Webインターフェイス経由で送信ファイルは、間違いなく、様々な輸送中の変換やメールよりも誤解を受けにくいです。電子メールは、多くの場合、メールエージェント（例えば、送信者と余分な行が追加した自動化された免責事項は、受信者によって追加フィード）によって変異しています。
convenience: Some IETFers consider web interfaces as generally "more convenient".
利便性：一部のIETFersは、一般的に、「より便利に」などのWebインタフェースを考えます。
This section defines the Toolset implementation stages or phases. There are three consecutive stages, marked with letters "a", "b", or "c". Earlier-stage requirements must still be satisfied in later stages. All requirements need to be interpreted and evaluated in the context of the current stage and the currently implemented features. For example, requirement R68 applies to the first stage but refers to XML draft format that may not be supported until the second stage. A correct interpretation of R68 until XML support is added is "it is an error to submit a draft without a plain text format".
このセクションでは、ツールセットの実装の段階または相を定義します。文字「A」、「B」、または「C」でマークされた三つの連続の段階があります。以前の段階の要件はまだ後の段階で満足しなければなりません。すべての要件は、現段階の状況と、現在実装された機能で解釈し、評価する必要があります。例えば、要求R68は、第一段階に適用されるが、第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.
その他のツールセット機能も投稿ドラフトを使用してテスト可能かもしれません。スクリプトの簡単なペアは、ウェブや電子メールのインターフェイスの基本的な機能をテストするために使用することができます。
Hint: The IESG may require test results before accepting the initial implementation. If automated, the above approach can be used for regression testing as well.
ヒント：IESGは最初の実装を受け入れる前に、テスト結果が必要な場合があります。自動化された場合は、上記のアプローチは、同様に回帰テストのために使用することができます。
Removing humans from the draft submission and posting process (a.k.a. automation) requires adding features to make the Toolset reliable in the presence of denial-of-service (DoS) attacks and attempts to corrupt the draft repository. Ideally, the Toolset needs to resist both premeditated malicious actions and good-intent accidents.
ドラフト提出と投稿プロセス（別称、自動化）から人間を削除すると、破損しているドラフトリポジトリへのサービス拒否（DoS）攻撃と試みの存在下でのツールセットは、信頼性を高めるために機能を追加する必要があります。理想的には、ツールセットは、計画的な悪質な行為と良い意思事故の両方に抵抗する必要があります。
This document contains specific requirements to minimize the impact of DoS attacks (e.g., R97). The requirements are designed with the assumption that it is acceptable for the Toolset to block valid submissions during a DoS attack as long as the Toolset maintainers are notified and already posted drafts are not damaged.
この文書では、DoS攻撃（例えば、R97）の影響を最小化するために特定の要件を含んでいます。要件は、ツールセットは限りツールセットのメンテナが通知され、すでに掲載ドラフトが破損していないとして、DoS攻撃の際、有効な応募をブロックすることが許容されることを前提に設計されています。
This document also contains many specific requirements related to detection of drafts violating IETF posting rules. Those requirements help reduce the number of "bad" drafts posted by mistake but do not offer reliable protection from submitters with malicious intent: Since automated tools do not truly understand drafts (and will not do so in the foreseeable future), it is technically possible to post a rogue draft violating IETF posting rules. For example, a draft may contain abstract text that makes the IETF-approved IPR statements following the abstract meaningless or legally non-binding.
この文書はまた、IETF投稿ルールに違反ドラフトの検出に関連する多くの特定の要件が含まれています。これらの要件が誤って掲載「悪い」草稿の数を減らすのに役立つが、悪意を持った応募者からの信頼性の高い保護を提供しない：自動化ツールは本当にドラフトを理解していない（と予見可能な将来においてそうではないだろう）ので、それは技術的には可能ですIETF投稿ルールに違反する不正なドラフトを投稿します。例えば、ドラフトは抽象無意味または法的拘束力のない、次のIETF承認の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は、実装を評価し、必要に応じて要求を解釈します。
Appendix A. Comparison with Current Procedures
現在の手順で付録A.比較
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ドラフト源（R112を参照）からHTMLドラフト形式を生成してもよいです。現在、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ツールセットは、名前が「ドラフト-ietf-」で始まるドラフトとして「WGN案」を定義します。他のすべてのドラフトは、個々のドラフトとして扱われます。現在、IETF WGは、単一のWGドラフト命名形式に従う必要はありません。したがって、WGは、WGの原案を考えてドラフトの00バージョンは、WGの同意なしにツールセットによって投稿することができます。影響を受けるのWGは、共通の命名形式を使用しない彼らの決定の結果に対処する必要があります。ツールチームは、IETFは、混乱を最小限に抑えるために、単一のフォーマットを使用して自分のドラフトに名前を付けるのWGが必要であることを示唆しています。うまくいけば、「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議長の著者）。現在、事務局は、事実上、このような検証を行いませんが、電子メールの提出インタフェースと提出ループにおける人間の存在が明らかに大規模な自動化された攻撃を防ぐのに十分なされています。変更は、ジャンクで掲示IETFドラフトを上書きするWebインタフェースを使用してから、簡単なスクリプトを防止するために必要とされます。うまくいけば、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を参照）を受け入れることができます。現在、事務局は、ウイルス汚染の懸念のために「ジッパー」のアーカイブを受け付けません。事務局は、まだ彼らは手動ルートを経由して提出された場合に特定の形式を拒否しなければならないことがありながら、ツールセットの適切な実装では、そのような懸念に対処しなければなりません。
Appendix B. Acknowledgements
付録B.謝辞
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).
作者は感謝しハラルド・トバイット・アルベストランド（シスコ）、ブライアンE.カーペンター（IBM）、フランク・Ellermann、ビルフェナー（AT＆T）、バーバラB.フラー（Foretec）、ブルース・リリー、ヘンリックLevkowetz（エリクソン）、ラリーMasinterの貢献を認めて（アドビシステムズ社）、キース・ムーア（テネシー大学）、ペッカSavola（Netcore）、ヘニングSchulzrinneと（コロンビア大学）、およびスタニスラフ・シャルノブ（インターネット2）。
Special thanks to Marshall Rose for his xml2rfc tool.
彼のxml2rfcツールのマーシャルローズに感謝します。
Normative References
引用規格
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用しているRFC"、RFC 2629、1999年6月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979]ブラドナーの、S.、 "IETF技術の知的財産権"、BCP 79、RFC 3979、2005年3月。
[XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, http://www.w3.org/TR/1998/REC-xml-19980210.
[XML]ワールド・ワイド・ウェブ・コンソーシアム、 "拡張マークアップ言語（XML）1.0"、W3C XML、1998年2月、http://www.w3.org/TR/1998/REC-xml-19980210。
Informative References
参考文献
[writing-rfcs] Rose, M., "Writing I-Ds and RFCs using XML (revised)", Work in Progress, April 2004.
[書き込み-RFCは]ローズ、M.は、進捗状況、2004年4月に、仕事を "ライティングI-DSおよびXMLを使用したRFCは（改訂版）"。
[secretariat] "Private communication with the IETF Secretariat", 2004.
[事務局] 2004年「IETF事務局とのプライベート通信」。
[OSD] "The Open Source Definition, version 1.9", Open Source Initiative, 2005, available at http://www.opensource.org/docs/definition.php.
[OSD] "オープンソースの定義、バージョン1.9"、http://www.opensource.org/docs/definition.phpで入手可能なオープンソース・イニシアティブ、2005年。
Author's Address
著者のアドレス
Alex Rousskov The Measurement Factory
アレックスRousskovザ・計測ファクトリー
EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/
電子メール：rousskov@measurement-factory.com URI：http://www.measurement-factory.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.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 Editor機能のための基金は現在、インターネット協会によって提供されます。