RFC4228 日本語訳
4228 Requirements for an IETF Draft Submission Toolset. A. Rousskov. December 2005. (Format: TXT=76952 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Rousskov Request for Comments: 4228 The Measurement Factory Category: Informational December 2005
Rousskovがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4228 測定工場のカテゴリ: 情報の2005年12月
Requirements for an IETF Draft Submission Toolset
IETF草稿服従ツールセットのための要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.
このドキュメントはIETFツールセットがインターネット草稿服従、合法化、および任命を容易にするという要件を指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Scope ...........................................................2
3. Notation and Terminology ........................................3
4. Status Quo ......................................................4
5. Overall Toolset Operation .......................................6
6. Upload Page .....................................................9
7. Check Action ....................................................9
7.1. Preprocessing .............................................10
7.2. Processing ................................................11
7.3. Storage ...................................................11
7.4. Extraction ................................................12
7.5. Validation ................................................13
7.5.1. Absolute Requirements ..............................14
7.5.2. Desirable Features .................................15
7.5.3. DoS Thresholds .....................................17
7.5.4. WG Approval ........................................17
8. Check Page .....................................................18
8.1. External Meta-Data ........................................19
9. Post Now Action ................................................20
9.1. Receipt Page ..............................................20
10. Adjust Action .................................................21
11. Adjust Page ...................................................21
12. Post Manually Action ..........................................22
13. Receipt Page ..................................................22
1. 序論…2 2. 範囲…2 3. 記法と用語…3 4. 現状…4 5. 総合的なツールセット操作…6 6. ページをアップロードしてください…9 7. 動作をチェックしてください…9 7.1. 前処理します。10 7.2. 処理…11 7.3. 格納…11 7.4. 抽出…12 7.5. 合法化…13 7.5.1. 絶対条件…14 7.5.2. 望ましい特徴…15 7.5.3. DoS敷居…17 7.5.4. WG承認…17 8. ページをチェックしてください…18 8.1. 外部のメタデータ…19 9. 現在、動作を掲示してください…20 9.1. ページを領収書を出させてください…20 10. 動作を調整してください…21 11. ページを調整してください…21 12. 手動で動作を掲示してください…22 13. ページを領収書を出させてください…22
Rousskov Informational [Page 1] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[1ページ]のRFC4228ID服従ツールセット: 要件2005年12月
14. Bypassing the Toolset .........................................22 15. Email Interface ...............................................23 16. Implementation Stages .........................................25 17. Testing .......................................................26 18. Security Considerations .......................................27 19. Compliance ....................................................27 Appendix A. Comparison with Current Procedures ....................28 Appendix B. Acknowledgements ......................................29 Normative References ..............................................30 Informative References ............................................30
14. ツールセットを迂回させます…22 15. インタフェースをメールしてください…23 16. 実現ステージ…25 17. テストします…26 18. セキュリティ問題…27 19. 承諾…27 現在の手順との付録A.比較…28 付録B.承認…29 標準の参照…30 有益な参照…30
1. Introduction
1. 序論
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 Toolsチームは現在のメカニズムの形式化とオートメーションを推薦します。このドキュメントは特定のオートメーション要件を含んでいます。
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関係者がオートメーションの提案者です。 Toolsチームによって解釈されるように、このドキュメントは、彼らの知られている必要性を反映するのを試みて、願われています。
2. Scope
2. 範囲
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.
本書では議論したDraft Submission ToolsetはIETF関係者からIETF草稿倉庫までのインターネット草稿のただ一つの新しいバージョンを得ることに関するものです。 ただ一つの草案バージョンはいくつかの形式を含むかもしれません、そして、それらの形式に対処するのがToolsetのための範囲にあります。 草稿メタ情報(事務局データベースとほかの場所で使用される)の定義と源が範囲にあります。 Submitter認証と服従認可が範囲にあります。
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ドキュメントか手順がToolsetからの追加機能性を必要とするかもしれません。 例えば、ToolsetがプレーンテキストとXML以外の草稿ソース形式を扱わなければならないのは、可能です。
Rousskov Informational [Page 2] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[2ページ]のRFC4228ID服従ツールセット: 要件2005年12月
3. Notation and Terminology
3. 記法と用語
The following terms are to be interpreted according to their definitions below.
以下での彼らの定義に従って、次の用語は解釈されることになっています。
posted draft: A draft accepted into the public IETF draft repository
and, hence, publicly available from the IETF web site. Posting of
a draft does not imply any IETF or IESG review and endorsement.
掲示された草稿: 公共のIETF草稿倉庫に受け入れられてしたがって、IETFウェブサイトから公的に利用可能な草稿。 草稿の任命は少しのIETFやIESGレビューと裏書きも含意しません。
draft version: A meant-to-be-public snapshot of an Internet-Draft
with a meant-to-be-unique version number. Also known as "draft
revision".
草案バージョン: aとのインターネット草稿の意味している未来の公衆スナップ、未来であることを意味する、ユニークである、バージョン番号。 また、「改正案」として、知られています。
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と同様に元の、または、発生しているプレーンテキスト、ポストスクリプト、およびHTML形式を含んでいて。
primary draft format: The first available draft format from the
following list: plain text, PDF, PostScript, or XML.
第一の草稿形式: 以下のリストからの最初の利用可能な草稿形式: プレーンテキスト、PDF、ポストスクリプト、または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によって命名された草稿: Aがどの識別子(通称ファイル名)が知られているかために作成して、始める、「草稿スペシャル、-、」、SPECIALが以下のストリングの1つであるところ: "ietf"、"iab"、"iesg"、「rfc-エディタ」、または"irtf"。 「WGN草稿」が簡略化されています。 例外にもかかわらず、IETFワーキンググループか同様のIETF関連のボディー(逆もまた同様である)によって通常、WGによって命名された草稿は制御されます。 例外を命名するそのようなものの取り扱いがこのドキュメントの範囲の外にあります。
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.
submitter: 合法化か任命のためのインターネット草案バージョンの服従を開始する人間かソフトウェアエージェント。 いくつかの場合、実際の服従をしますが、事務局のスタッフはいつもsubmitterを代表してそうします。 いくつかの場合(他の悪意ある攻撃を含んでいる)、submitterは草稿作者ではありません。
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.
submitterは予想しました: IETFによって認可されるsubmitterは、与えられた草稿を掲示するために統治されます。 これは草稿作者、エディタ(草案文面では、記載されている)、対応するWG議長、またはIESGメンバーを含んでいます。
authorized submitter: An expected submitter authenticated by the
Toolset. Authentication is initially limited to verifying
submitter access to submitter's email address.
認可されたsubmitter: Toolsetによって認証された予想されたsubmitter。 認証は初めは、submitterのEメールアドレスへのsubmitterアクセスについて確かめるのに制限されます。
immediately: Without human interaction or artificial software delays
and within a few seconds.
すぐに: 人間の交流か人工のソフトウェア遅れなしで数秒以内に。
Rousskov Informational [Page 3] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[3ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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.
Toolsetは、1セットの標準の要件を使用することで指定されます。 これらの要件は「(Rnnn/s)」指示で終わるイギリスの句です。(そこでは、"nnn"がユニークな要件番号であり、「s」は実現ステージを要件に指定するただ一つのレター・コード(“a"、「b」、または「c」)です)。 実現ステージはセクション16に記録されます。
This document specifies the interface and functionality of the Toolset, not the details of a Toolset implementation. However, implementation hints or examples are often useful. To avoid mixup with Toolset requirements, such hints and examples are often marked with a "Hint:" prefix. Implementation hints do not carry any normative force, and a different implementation may be the best choice.
このドキュメントはToolset実現の詳細ではなく、Toolsetのインタフェースと機能性を指定します。 しかしながら、実現ヒントか例がしばしば役に立ちます。 Toolsetとの要件、そのようなヒント、および例がしばしばマークされる混乱を避けるために、aは「以下について暗示します」。 前に置きます。 実現ヒントは少しの標準の力も運びません、そして、異なった実現は最も良い選択であるかもしれません。
4. Status Quo
4. 現状
This section summarizes the process for draft submission and posting as it exists at the time of writing.
これを書いている時点で存在していて、このセクションは草稿服従と任命のための過程をまとめます。
To get an Internet-Draft posted on the IETF web site, an IETF participant emails the draft text to the IETF Secretariat, along with an informal note asking the Secretariat to post the draft. Secretariat staff reads the note, reviews the draft according to a checklist, and then approves or rejects the submission. Draft approval triggers the corresponding announcement to be sent to appropriate IETF mailing lists. Every 4 hours, approved drafts are automatically copied to the IETF drafts repository and become available on the IETF web site.
IETFウェブサイトにインターネット草稿を掲示させるために、IETF関係者はIETF事務局に草案文面をメールします、草稿を掲示するように事務局に頼む非公式の注意と共に。 次に、事務局のスタッフは、服従を注意を読むか、チェックリストに従って草稿を見直して、承認するか、または拒絶します。 草稿承認はIETFメーリングリストを当てるために送られる対応する発表の引き金となります。 4時間毎、承認された草稿は、自動的にIETF草稿倉庫にコピーされて、IETFウェブサイトで利用可能になります。
Collectively, IETF participants submit thousands of Internet-Drafts per year (in the year 2000, about 3,000 drafts were submitted; 2002: 5k; 2004: 7k [secretariat]). About 30-50% of posted drafts are WG-named drafts (among some 2,100 drafts, there were about 380 new and 290 updated WGN drafts posted in 2003). While no rejection statistics are available, the vast majority of submitted drafts are approved by the Secretariat for posting.
IETF関係者は1年あたり何千ものインターネット草稿をまとめて、提出します。(2000年の間、およそ3,000の草稿を提出しました;、2002: 5k; 2004: 7k[事務局)。 およそ30-50%の掲示された草稿はWGによって命名された草稿(およそ2,100の草稿のうち新しいおよそ380があります、そして、290は2003年に掲示されたWGN草稿をアップデートした)です。 どんな拒絶統計も利用可能でない間、かなりの大多数の提出された草稿は任命のために事務局によって承認されます。
It usually takes the Secretariat a few minutes to review a given draft. However, since the Secretariat staff does not work 24/7, does not work in all time zones, and has other responsibilities, and since approved drafts are posted in batches every 4 hours, it may take from several hours to several days to get a draft posted. Due to much higher demand and fixed processing capacity, postings during the last weeks before IETF face-to-face meetings take much longer, creating a long queue of unprocessed drafts that are then announced nearly simultaneously.
通常、与えられた草稿を見直すには事務局に数分かかります。 しかしながら、事務局のスタッフが年中無休、24時間働いていなくて、すべての時間帯で働いていなくて、他の責任を持って、承認された草稿が4時間毎にバッチで掲示されるので、それは草稿を掲示させるには数時間から数日までかかるかもしれません。 はるかに高い要求と固定処理容量のため、IETFさしの会談の前の最後の数週間の任命ははるかに長い間、かかります、次にほとんど同時に発表される未加工の草稿の長蛇の列を作成して。
Rousskov Informational [Page 4] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[4ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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.
多くのWorking Groupsが、対処するために遅れを掲示しながら、その場かぎりの解決を提案しました。 例えば、多くの草稿スナップを個人的なウェブサイトで「一時」発行するか、またはグループリストに送ります(完全か一部)。 事実上、公表の代替の手段は公式のIETFインタフェースを取り替えるかもしれません、終わるのがIETFウェブサイトに掲示したほんのいくつかの主要な改正案で。
Informal interfaces for submitting and posting drafts discourage automation. Lack of submission automation increases Secretariat load, complicates automated indexing and cross-referencing of the drafts, and, for some authors, leads to stale drafts not being updated often enough.
草稿を提出して、掲示するための非公式のインタフェースはオートメーションに水をさしています。 何人かの作者のために、服従オートメーションの不足は、事務局荷重を増加させて、草稿の自動化されたインデックスと十字参照箇所を複雑にして、十分しばしばアップデートされるというわけではない聞き古した草稿につながります。
Beyond a short Secretariat checklist, submitted drafts are not checked for compliance with IETF requirements for archival documents, and submitters are not notified of any violations. As a result, the IESG and RFC Editor may have to spend resources (and delay approval) resolving violations with draft authors. Often, these violations can be detected automatically and would have been fixed by draft authors if the authors knew about them before requesting publication of the draft.
短い事務局チェックリストを超えて、提出された草稿は記録保管所のドキュメントのためのIETF要件への承諾がないかどうかチェックされません、そして、submittersはどんな違反についても通知されません。 その結果、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.
認証の不足は深刻な問題として知覚されません、ことによると重大な被害ができる前に重大な改竄が気付きそうであるので。 服従メカニズムの非公式の、そして、手動の本質のために、大規模な自動化された乱用は、短い草稿任命サービスの否定以外の何も引き起こしそうになくて、したがって、防御するたぶん価値がありません。 しかしながら、将来のオートメーションは異なったトレードオフをもたらすかもしれません。
Rousskov Informational [Page 5] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[5ページ]のRFC4228ID服従ツールセット: 要件2005年12月
5. Overall Toolset Operation
5. 総合的なツールセット操作
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.
このセクションはハイレベルの記述を提案されたToolsetに供給します。 記述は総合的な操作と注文を示していることになっています。 各ステップに特定の詳細について他のセクションを参照してください。
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).
典型的なsubmitterは2-4ウェブページと関連動作の系列に直面しています。 ページ数は草稿合法化とメタデータ抽出結果に依存します。 例えば、それを掲示しないで草稿を有効にするのは、2ウェブページと対話するのを必要とします: アップロードして、チェックします。 手動のメタデータ調整なしで有効な草稿を掲示するよくある例は3ウェブページ(アップロード、Check、Receipt)を取ります。
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.
ページをアップロードしてください: submitterのコンピュータからToolset中間準備地域(セクション6)までの草稿をコピーするインタフェース。 複数の形式を受け入れます。 Check動作に草稿を送ります。
Check action: Stores the draft in the Toolset staging area, extracts
draft meta-data, validates the submission (Section 7). Produces
the Check page.
動作をチェックしてください: Toolset中間準備地域の草稿、抽出草稿メタデータを格納して、服従(セクション7)を有効にします。 Checkページを生産します。
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)を作成します。 また、このページで草稿プレビューを与えるかもしれません。 草稿解釈と合法化結果について調査した後に、submitterには、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).
自動化された任命: submitterが、Checkページから自動化された任命を続けると決めるなら、システムは、submitterを認証して、また、submitterが草稿を掲示できるかどうかチェックするかもしれません。 submitterが認可されているなら、草稿は、中間準備地域からすぐに、掲示されていて、削除されています、そして、メールとReceiptページ(セクション9)でsubmitterは結果について通知されます。
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
手動の調整と任命: submitterが、メタデータを調整すると決めるなら、草稿はToolset中間準備地域に残っています、そして、Adjust動作(セクション10)はAdjustページ(セクション11)をsubmitterに与えます。 submitterが調整をして、手動の任命を続けるとき、マニュアルのために格納された草稿とその調整されたメタデータへのポインタを事務局に送ります。
Rousskov Informational [Page 6] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[6ページ]のRFC4228ID服従ツールセット: 要件2005年12月
processing (Section 12). The submitter is notified of the pending
Secretariat request via email and a Receipt page.
(セクション12)を処理します。 メールとReceiptページでsubmitterは未定の事務局要求について通知されます。
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.
キャンセル: submitterが、明らかに服従を中止すると決めるなら、服従状態(草稿を含んでいる)はすぐにToolset中間準備地域から削除されます、そして、適切なReceiptページはさらなる動作なしで発生します。(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.
ページを領収書を出させてください: うまくいっているか失敗した草稿服従の詳細を含んでいて、服従結果に関連する次の適切なステップについてsubmitterに知らせます。
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.
submitterがToolsetである間、何もしないなら、何らかの応答、捨てられている服従時間を予想するのは出かけています。(R124/a)。 タイムアウト値は服従状態に依存します。 ヒント: Toolsetが3番目のパーティー確認(例えば、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.
中間準備地域維持アルゴリズムは、サービスの否定(DoS)があるとき一貫して、正しい状態の領域がにせの差出が様々な段階にある状態で領域を圧倒するのを試みる攻撃であることを保たなければなりません。(R67/a)。 ヒント: 正統のユーザに対するサービスの否定はDoS攻撃状態の下で許容できますが、格納領域の不正は許容できるというわけではありません。
The "web pages" this text is referring to are distinct dialogs that may be visible to the submitter under the same or different URL and that are supported by a single or several server-side programs.
本稿が言及している「ウェブページ」は同じであるか異なったURLの下におけるsubmitterに目に見えるかもしれなくて、シングルか数個のサーバサイドプログラムで支持される異なった対話です。
The Toolset must handle multiple submitters simultaneously submitting the same draft (R72/a) and a single submitter simultaneously submitting two drafts (R73/a). The latter might happen, for example, when the submitter is using several browser windows to submit several
R72/a)とaは同時に2つの草稿を提出するsubmitterを選抜します。Toolsetが同じ草稿を提出しながら同時の複数のsubmittersを扱わなければならない、((R73/a)。 submitterが数個を提出するのにいくつかのブラウザウィンドウを使用しているとき、例えば、後者は起こるかもしれません。
Rousskov Informational [Page 7] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[7ページ]のRFC4228ID服従ツールセット: 要件2005年12月
drafts or is submitting drafts via email interface. The term "simultaneously" means that submission processing times overlap.
メールインタフェースを通した草稿を作成するか、または提出しています。 用語は、「同時、」服従処理回数が重なることを意味します。
Hint: Except for the Upload page, pages contain a submission session identifier to provide actions with access to stored information. The identifier is specific to the submission rather than the draft version or the submitter. While the nature of the web interface allows the session identifier to be invisible to the submitter, email communication would need to identify the session so that the recipient (and Toolset) know the context.
ヒント: Uploadページを除いて、ページは記憶された情報へのアクセスを動作に提供する服従セッション識別子を含んでいます。 識別子は草案バージョンかsubmitterよりむしろ服従に特定です。 ウェブインタフェースの自然が、セッション識別子がsubmitterに目に見えないのを許容している間、メールコミュニケーションは、セッションを特定する必要があるでしょう、したがって、受取人(そして、Toolset)は文脈を知っています。
Hint: A single action may correspond to multiple server-side programs and, vice versa, a single program may implement several actions. This document does not mandate any specific technology (e.g., Common Gateway Interface (CGI), PHP, and/or Java servlets) to implement server-side support. The implementer experience, code reuse across web and email interfaces, and other factors will determine the right technology choice.
ヒント: ただ一つの動作は複数のサーバサイドプログラムに対応するかもしれません、そして、逆もまた同様です、単一のプログラムはいくつかの動作を実行するかもしれません。 このドキュメントはサーバサイドサポートを実行する少しの独自技術(例えば、共通ゲートウェイインターフェイス(CGI)、PHP、そして/または、Javaサーブレット)も強制しません。 implementer経験、ウェブの向こう側のコード再利用、メールインタフェース、および他の要素は正しいテクノロジーの選択を決定するでしょう。
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.
Toolsetを部分的か完全に迂回させる方法はセクション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.
1つの経営陣から別の経営陣までToolsetを移して、ボランティアによる仕事を取り入れて、開発されたコードの公開レビューを考慮するのは可能であるに違いありません。 これらの目標を達成するために、Toolsetソースコードは公的に利用可能であるべきです、そして、(R152/b)バグを報告して、増進を要求するインタフェース(R145/b)があるべきです。 開発は、独占プラットホームかバックエンドとしてロックインを避けるために構造化されるべきです。 Toolsチームは、オープンSource Definition[OSD]に続いて、1つ以上未満のオープンソースが認可するToolsetソースを開発すると手頃な費用でこれらの必要条件を満たす効果的な方法が提供されると信じています。 注意するべきです。選択されたライセンスは、異なったimplementersからのコードが複雑であることを許容します。
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のようなオープンなソースに優しいプロジェクト管理サイトにToolsetソース倉庫をみなすと、コード、ドキュメンテーション、バグレポート、およびディスカッション・フォーラムにアクセスするためにきちんとして、使用するのにおいて準備ができるインタフェースをIETF共同体に提供するでしょう。Toolsetと外部のソフトウェア(例えば、事務局草稿任命スクリプト)との簡単なインタフェースを設立して、記録すると、有用性チェックは容易にされるでしょう。
Rousskov Informational [Page 8] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[8ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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.
Toolsetは取り扱い草稿のための事務局のツールと互換性があることが意味されます。 ヒント: 適切にToolsetを実行するか、またはいくつかの場合、既存の事務局ツールを変更することによって、そのような互換性を獲得できます。
6. Upload Page
6. アップロードページ
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.
草稿をアップロードするために、submitterはIETFウェブサイト(R1/b)の周知のページに行きます。 そこに、HTMLファイルアップロードフォームを使用することで草案文面をアップロードできます。 このフォームは草稿のプレーンテキスト形式をアップロードする野原を供給します。(R2/a)と他のすべての形式がIETFで、草稿公表規則(R3/b)を許容しました。 これを書いている時点で、これらの形式は以下の通りです。 XML[RFC2629]、[書くこと-rfcs)、PDF、およびポストスクリプト。
Submitted forms are handled by the Check action documented in Section 7.
提出されたフォームはセクション7に記録されたCheck動作で扱われます。
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.
また、Uploadページにはaがある、有効にする、-単に、弛んでください、アップロードされた草稿が掲示されてはいけなくて、合法化(R74/b)直後削除されるかもしれないのを示して。 合法化結果にかかわらず、格納された草稿メタデータは、合法化だけ草稿を特定できるようにマークされて、最初に、ごみ収集人によってToolset中間準備地域(R75/b)に削除されます。 草稿がaを中にアップロードした、有効にする、-単に、モードを掲示できません(R76/b)。 彼らが、再びアップロードされる必要があるだろう、有効にする、-単に、旗、およびページで、それ(R77/b)がわかるべきであるという合法化結果。 この旗は、特に大量の草稿処理にオンライン合法化を使用することでツールの役に立ちます。 ヒント: 人間のsubmittersのためにインタフェースを簡素化するために隠されたHTML入力フィールドとしてこの旗を実行しているほうがよいかもしれません。
7. Check Action
7. 動作をチェックしてください。
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).
Check動作は、中間準備地域の提出された草稿(すべての形式)を格納して、次に、抽出メタデータを格納して、服従を前処理して、プレーンテキスト形式(必要であるなら、R70を見る)を発生させて、各形式を有効にします。(R6/a)。 誤りと警告は応答でsubmitterにコンピュータに優しいタグと人間に優しいテキストで示されます。(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について言及しないで、また明らかに自動化された任命を禁止しないものさえ)に適用されます。 自動化された任命が可能でないなら、Toolsetはまだマニュアル合法化と任命のための草稿を送るオプションをsubmitterに与えています。(R114/a)。 各服従が分離して扱われるので、また、submitterには問題を修正して、自動化された任命のための草稿を再提出するオプションがあります。
Rousskov Informational [Page 9] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[9ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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.
手動の合法化と任命ルートは草稿自体で問題を解決するために意味されなかったToolset迂回メカニズム(セクション14を見る)です。 一般に、事務局は提出された草稿を修正しません。 草稿が、submitterの意図を合わせるためにひねる必要があるなら、草稿は、submitterによって修正されて、再提出されるべきです。
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)。 ToolsetがXMLソースからプレーンテキスト形式における草稿を首尾よく発生させる場合にだけ、XMLソースは付随のプレーンテキストなしで許容できます、処理ステップの一部が(R69/b)の下に記録したように。 これらの規則は、PDFかポストスクリプトだけ草稿が自動掲示されているはずがないのを含意します。 そのうえ、手動の事務局かかわり合いさえこれらの草稿を掲示するのに助けることができません、IETF方針がいつもPDFかポストスクリプトに加えたプレーンテキスト形式を必要とすることであるので。 形式が含まなければならないPDFかポストスクリプトを含んでいて、Toolsetがそれを有効にすることができるまで自動掲示されていなくて、それらの内容はプレーンテキスト形式に合っています。その上、草稿、(R143/a)。
The draft format acceptance rules above are meant to decrease the chances that multiple posted draft formats for a single draft contain substantially different documents. With experience, the rules may be simplified so that, for example, only submissions containing nothing but XML or plain text sources can be posted without Secretariat involvement and all other submissions require manual actions to match formats or extract meta-data.
草稿形式承認は、ただ一つの草稿のための複数の掲示された草稿形式が実質的に異なったドキュメントを含んでいるという可能性が上で減少することになっていると裁決します。 経験で、規則が簡素化されるかもしれないので、例えば、事務局かかわり合いなしでXMLだけを含む差出かプレーンテキストソースしか掲示できないで、他のすべての差出が形式を合わせるか、またはメタデータを抜粋するために手動の動きを必要とします。
7.1. Preprocessing
7.1. 前処理
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.
圧縮された草稿を提出するのは、特に遅いか内容を変えたリンクの後ろのsubmittersに、望ましい特徴です。 圧縮された草稿形式を受け入れるかもしれません(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ソース含有は」 …と等しいです」>指示(PIs)は、指示するもの(R8/b)を含むように前処理されます。 このステップが、XMLソースから外部の依存を取り除いて、ツール処理の掲示されたXMLを簡素化するのに必要です。 このドキュメントは「PIsを含んでいます」のようなXMLプロセッサ指示を示します。
The XML preprocessor uses public database(s) to resolve PI references (R85/b). The Toolset documentation specifies what databases are used and how PIs are mapped to database entries (R86/b). The Toolset must
XMLプリプロセッサは、PI参照(R85/b)を決議するのに公共のデータベースを使用します。 Toolsetドキュメンテーションはどんなデータベースが使用されているか、そして、PIsがどのようにデータベースエントリー(R86/b)に写像されるかを指定します。 ツールセットはそうしなければなりません。
Rousskov Informational [Page 10] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[10ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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ソースが服従の前に前処理されるので、PIsの存在(R87/b)を当てにしないか、またはPIsなしで書かれないでしょう。 ヒント: 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ソースは後で掲示されるかもしれません。 インクルードPIsとの一次資料はデフ(未来か一次資料の)のRFC Editorと世代の役に立つかもしれません。 インクルードPIsのない前処理されたソースは公共のXMLが出典を明示する掲示された草稿(R10/b)のデフォルトになります。 Toolsetにおいて知られているインクルードPIsのどれかを扱うことができないなら、誤りは記録されています、そして、(R11/b)submitterが局所的に前処理するよう奨励されます、草稿(R111/b)を提出する前に。
Uncompressed draft formats other than XML are not preprocessed.
XML以外の解凍された草稿形式は前処理されません。
7.2. Processing
7.2. 処理
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ソースが手があいているとき、Toolsetは、提出された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ソースが手があくなら、ToolsetはHTML草稿形式(R112/c)を発生させます。 HTML世代失敗は誤りではなく、警告(R115/c)をもたらすべきです。 Enhancement Stageに達するまで、HTML世代は実行されることになっていません。(R130/a)。 一般に、HTML世代は、HTML草稿は改良された総合的な読み易さとリンクによるプレーンテキスト草稿より通常ナビゲートしやすいので、望ましいです。 どんなEnhancement Stageの特徴としても、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.
ヒント: Toolset implementersは、同じツールで同じソース形式から発生する草稿形式が本質的には同じ内容を持っていると仮定するはずがありません。 世代ツールには、作者が特定の発生している形式に限っている内容を発生させることができるオプションがあるかもしれません。 そのようなオプションは乱用されるかもしれません。
7.3. Storage
7.3. 格納
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).
Check動作は、submitter要求によって後で首尾よく有効にされた草稿が自動掲示するようになるようにすべての草稿形式を格納する必要があります。 動作店はすべて、Toolsetに捧げられた中間準備地域の草稿の形式を提出しました。(R12/a)。 中間準備地域がガーベージコレクションの後に完全であるなら(すなわち、合計の中古のサイズは構成された最大能力に達しました)、submitterと事務局は致命的な誤りについて通知されます。(R13/a)。
Rousskov Informational [Page 11] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[11ページ]のRFC4228ID服従ツールセット: 要件2005年12月
7.4. Extraction
7.4. 抽出
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).
以下からのメタデータが格納したToolset抽出は形式を作成します: プレーンテキスト、(R131/a)、XML(R132/b)、および他の(R133/c。) 抽出はメタデータであるなら失敗して、Toolset記録は誤りです。(R15/a)。 メタデータ抽出が、草稿を有効にして、掲示するのに必要です。 すべての形式からの抽出が、有効にするのにすべてのメタデータがすべての形式(Toolsetと缶が有効にするまた、コンテンツが合っているToolsetの前の)の向こう側に合うのが必要です。
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は上記の要件に関連する非明白な遂行スケジュールを記録します。 形式解釈の部分的なサポートだけが利用可能であるときに、解釈された形式だけが抽出と合法化要件を受けることがあります。 言い換えれば、Toolsetがまだ与えられた形式の解釈を支持していないなら対応する情報を格納して、「そのままで」利用可能にします、実際の内容にかかわらず。
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をふるいの休暇7インチ作成であること」のNo.7。 「必要なら0インチ」でそっと歩いて、通常、数は、2ケタを使用することでレンダリングされます。
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をふるいの休暇7インチ作成であること」の「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ふるいの休暇7インチがそうであるa WG ID」の「ふるい。」 WGによって命名された草稿でない草稿に、WG ID値は空です。
WG flag: True for WGN drafts and false for all other drafts. For
example, "true" for "draft-ietf-sieve-vacation-13". This flag
only influences the further handling of initial (version 00) draft
submissions, as far as the current document is concerned.
WGは弛みます: WGN草稿に本当であって、他のすべての草稿において誤っています。 例えば、「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.
作者: すべての草稿作者のリスト。 各作者の名前とEメールアドレスは抜粋されます。
Rousskov Informational [Page 12] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[12ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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.
サイズ: 草稿の第一の形式におけるページ数と八重奏。 いくつかの形式に、1ページの定義は、形式に依存して、不正確であるか、または任意であるかもしれません。
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.
彼らの草稿が掲示されたことを共著者に通知するのに、それらが不可欠であるので、Toolsetは作者Eメールアドレスを必要とします。 何かそのような通知がなければ、共著者の同意なしで草稿に共著者を加えるsubmitterはしばらく、捕らえられないかもしれません。 そのような「驚き」共同著述業は、過去に起こって、かなり煩わしい場合があります。 しかしながら、Toolsetが有効な草稿を掲示するために共著者の同意に請求しないので(そのような懇願はとにかくメールコントロール検証を越えないでしょう)、悪意があるsubmitterが彼らの知識なしで共著者を加えるのを止めるのは可能ではありません。
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.
他のメタデータ項目のように、上に、草稿創造と有効期限は草稿から抽出されます。 それらの値は実際の服従時間(すなわち、Check動作時)に依存しません。 しかしながら、草稿への外部の現在(すなわち、服従)の時間、IETF草稿満了規則、および他の要素を考慮に入れた後に、合法化手順(セクション7.5を見る)は、どんな抽出された期日も無効であると宣言するかもしれません。
7.5. Validation
7.5. 合法化
Drafts need to be validated to catch broken submissions. Validation also helps educate or warn authors of problems that may become show-stoppers when the draft is sent for IETF Last Call and IESG review. IETF standards have to follow a set of syntax and semantics requirements (see the "ID-NITS" document at <http://www.ietf.org/ID-Checklist.html>. Most of those requirements are not enforced for Internet-Drafts. However, following them may improve draft quality, reduce the IESG load, and increase the chances of the draft being approved as an RFC.
草稿は、中断した差出を捕らえるために有効にされる必要があります。 また、合法化は、草稿がいつIETF Last CallとIESGレビューのために送られるかを名役者になるかもしれない問題の作者に教育するか、または警告するのを助けます。 IETF規格は1セットの構文と意味論要件に従わなければなりません。「ID-夜」が<http://www.ietf.org/ID-Checklist.htmlに>を記録するのを見てください。それらの要件の大部分はインターネット草稿のために実施されません。(しかしながら、それらに続くのは、草稿品質を改良して、IESG荷重を抑えて、RFCとして承認される草稿の可能性を高めるかもしれません。
When validating a given draft, it is important to distinguish between absolute requirements and desirable draft properties. Both categories are checked for, but violations have different effects depending on the category. The two categories are detailed in the following subsections.
与えられた草稿を有効にするとき、絶対条件と望ましい草稿の特性を見分けるのは重要です。 両方のカテゴリがないかどうかチェックされますが、違反はカテゴリによる異なった効果を持っています。 2つのカテゴリが以下の小区分で詳細です。
Rousskov Informational [Page 13] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[13ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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.
有効な草稿が掲示されていて、submitter認可か共著者通知が実行されるとき、合法化結果は、submitterがメタデータ抽出と合法化警告を見ることができるように、メール(R81/b)に含まれるべきです。 これらの結果が有効な草稿しか掲示できないので誤りを含むことができないことに注意してください。
7.5.1. Absolute Requirements
7.5.1. 絶対条件
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)。 手動の任命のために怒っている草稿を修理しなければならないか、または提出しなければならないでしょう、絶対条件が違反される必要がある理由に関する説明で(なぜValidator、誤検出された違反) これらの説明は、事務局任命決定を早くして、事務局がToolset実現を改良するのを助けるかもしれません。
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つ増加しなければなりません。 この要件を満たすために、満期のものを含んでいて、Toolsetは既に掲示された草稿の倉庫に相談しなければならないでしょう。 IETFインフラストラクチャがバージョンを扱うことができないなら、99、Toolsetより大きい数はそれらを拒絶しなければなりません。(R158/a)。
4. An IETF IPR Statement and other boilerplate required for drafts
according to [RFC3978] and [RFC3979] (or successors) must appear
in the draft text (R23/a).
4. [RFC3978]に従って、IETF IPR Statementと他の決まり文句が草稿に必要です、そして、[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. 実際の服従期日の3日以内に草案バージョンの抽出された作成日付はそうであるに違いありません。(R159/a)。 ヒント: Implementersは過去か未来に、あるように見える作成日付を扱うのに慎重であるはずです、可能な時間帯の差のため。 大部分寛大であるか寛大にして、時間帯に関する仮定は十分であるべきです。
Rousskov Informational [Page 14] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[14ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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. IETF草稿(R154/c)に、XMLソース(利用可能であるなら)はXML形式[XML](R153/c)とXML Document Type Definition(DTD)に関して有効です。 最初の2つの実現ステージの間対応する合法化失敗が誤りではなく、警告をもたらすことに注意してください(セクション7.5.2を見てください)。
The XML DTD for IETF drafts is documented in [RFC2629] with recent changes available in [writing-rfcs]. Hint: Bill Fenner's "RFC 2629 validator" at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ (or its derivative) may be useful for XML format and DTD validation.
最近の変化が利用可能な状態でIETF草稿のためのXML DTDは[書くこと-rfcs]に[RFC2629]に記録されます。 ヒント: http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ (または、派生物)のビル・フェナーの「RFC2629validator」は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.
ヒント: 手動の服従のための形式記入に居住するとき、抽出されたメタデータが提出された草稿形式において異なるなら、Toolsetは最も「正式な」形式からのメタデータを使用するはずです。 他方では、ほとんどの抽出されたエントリーがそれほど「正式でない」形式から来るなら、Toolsetは代わりにその形式を選ぶかもしれません。 例えば、プレーンテキスト形式より「正式である」とXMLソースを考えることができます。 また、Toolsetは、どの形式がフォームに居住するのに使用されるべきであるかを指定するためにオプションをsubmitterに提供するかもしれません。 エントリーが複数の形式から抽出した闘争を混ぜて、合うのは、たぶん悪い考えです。 代わりに、フォームかフォームに居住するとき形式が選ばれるべきであるどちらかがいくつかのメタデータ部(各形式あたり1つ)を含むべきです。 エラーメッセージは正確なミスマッチ情報を含むでしょう。
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規則がそれらを禁止しない限り、Toolsetは月の日なしで日付を受け入れるはずです。 日のなしの期日を有効にするとき、Toolsetは最も寛大な/を月の実際の日頃に関する寛大な仮定にするはずです。
7.5.2. Desirable Features
7.5.2. 望ましい特徴
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
以下の要件のどれかに違反するのが自動任命から草稿をより多くのsubmitterに防がない、(警告のR24/a)にもかかわらず、結果、(R160/a)。 各警告は、対応する違反について説明して、どう応じるかに関する(R161/b)アドバイスを提供します。 ヒント: 維持を緩和して、3番目のパーティーアップデート、詳説を奨励するために
Rousskov Informational [Page 15] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[15ページ]のRFC4228ID服従ツールセット: 要件2005年12月
and/or advice may be available as a resource separate from the Toolset.
そして/または、アドバイスはToolsetから別々のリソースとして利用可能であるかもしれません。
1. All automatically testable nits in the "ID-NITS" document at
<http://www.ietf.org/ID-Checklist.html> (R116/b) and
automatically testable guidelines at
<http://www.ietf.org/ietf/1id-guidelines.txt> (R157/b). The
Toolset should use external tools to check these nits and
guidelines rather than embed checking code (R117/a). Hint:
Henrik Levkowetz's idnits tool can be used
(http://tools.ietf.org/tools/idnits/) and other tools can be
written or adopted.
1. 「ID-夜」のすべての自動的に試験できる夜が<http://www.ietf.org/ietf/1id-guidelines.txt>(R157/b)に<http://www.ietf.org/ID-Checklist.htmlに>(R116/b)と自動的に試験できるガイドラインを記録します。 Toolsetは照合コードを埋め込むよりむしろこれらの夜とガイドラインをチェックする外部のツールを使用するはずです。(R117/a)。 ヒント: Henrik Levkowetzのidnitsツールを使用できて( http://tools.ietf.org/tools/idnits/ )、他のツールを書くか、または採用できます。
2. New draft versions are expected (R21/b). For example, version 00
of an individual draft is always expected, while posting a new
version of a draft already under the IESG review should generate
a warning.
2. 新しい草案バージョンは予想されます(R21/b)。 例えば、個々の草稿のバージョン00はいつも予想されて、既にIESGの下に草稿の新しいバージョンを掲示している間、レビューは警告を発生させるべきです。
3. If both XML and plain text formats are submitted, the submitted
plain text matches what can be generated based on submitted XML
(R146/b).
3. XMLとプレーンテキスト形式の両方を提出するなら、提出されたプレーンテキストは提出されたXML(R146/b)に基づいて発生できることに合っています。
4. The previous version, if any, was posted at least 24 hours ago
(R96/b). This warning may prevent some human errors, especially
when multiple authors may post the same draft.
4. もしあれば旧バージョンは少なくとも24時間前(R96/b)に掲示されました。 特に複数の作者が同じ草稿を掲示するとき、この警告はいくつかの人為ミスを防ぐかもしれません。
5. XML sources (if available) are valid with respect to the XML
format (R155/b) and XML DTD for IETF drafts (R156/b). These
requirements become absolute after the second implementation
phase. See Section 7.5.1 for related information.
5. IETF草稿(R156/b)に、XMLソース(利用可能であるなら)は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を満たすために発生していて提出されたプレーンテキスト形式を比較するとき、標準の単語ベースのデフは初期のToolset実現(R147/b)に十分です。 しかしながら、例えば、テキスト形式差を作成するのにおいて当然の誤った警告を最小にするためにカスタムファジー・マッチング機能を開発できます(R148/c)。 違いを検出するとき、別々のページ(R149/c)で警告に加えて完全なデフを提供するかもしれません。
Hint: When comparing generated and submitted plain text formats, the Toolset may try several recent xml2rfc versions for plain text generation, to eliminate warnings due to differences among xml2rfc versions.
ヒント: 発生していて提出されたプレーンテキスト形式を比較するとき、Toolsetは、違いのためxml2rfcバージョンの中で警告を排除するためにプレーンテキスト世代いくつかの最近のxml2rfcバージョンを試みるかもしれません。
Rousskov Informational [Page 16] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[16ページ]のRFC4228ID服従ツールセット: 要件2005年12月
7.5.3. DoS Thresholds
7.5.3. DoS敷居
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 |
+---------------------------------+--------------+-----------+
+---------------------------------+--------------+-----------+ | カテゴリ| バージョン/日| MB/日| +---------------------------------+--------------+-----------+ | 同じ草稿名による草稿| 3 | 5 | | 同じsubmitterとの草稿| 10 | 15 | | 同じWG IDとのWGN草稿| 30 | 45 | | すべての草稿| 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攻撃(例えば、完全なディスクは他のタスクに失敗される)の破壊的な効果を制限して、キャパシティプランニング(Toolsetが必要とする例えば、どのくらいの集積スペース)を考慮するか、そして、掲示されていて(例えば、人はいつ与えられた草稿か与えられたワーキンググループに関する通知を掲示しながら、受信しますか)、「多く過ぎること」の草稿の煩わしい副作用を制限することになっています。 Toolsetは、総差出が何か敷居(R134/b)にアプローチしているかどうかと事務局に警告するはずです。 ヒント: 差出に利用可能な帯域幅は、毎日のサイズ割当てに達するのを(悪意で)難しくするように阻止される(ネットワークサブネットベースで?)必要があるかもしれません。
7.5.4. WG Approval
7.5.4. WG承認
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のために、Toolsetは存在がないかどうかWG承認をチェックします。(R125/a)。 (a) 承認が全く存在していなくて、また(b) Toolsetが「WG承認を待ち」特徴を支持しないなら、Toolsetは誤りを記録します。(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) Toolsetが「WG承認を待ち」特徴を支持して、WG承認が受け取られていても(c) 草稿を掲示できないなら、Toolsetは任命から草稿を防ぐすべての誤りがいったん固定されていると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
(a) 承認が全く存在していなくて、(b) Toolsetが「WG承認を待ち」特徴を支持して、WG承認が受け取られているなら(c) 草稿を掲示できるなら、Toolsetは、submitterに事情を説明して、WGからの明白な承認が請求されるべきであるか、または予想されるべきであるか(R126/b)を尋ねます。 承認がそうするなら、請求されてください、そして、それはそうです。
Rousskov Informational [Page 17] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[17ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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).
ソフトウェアかsubmitterによって請求されます。 適切であるなら、予想された承認が利用可能になるまで(R127/b)、Toolsetは「WG承認を待ち」状態に服従を入れます。 さもなければ、Toolsetは「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承認のための手動の、または、自動化された懇願の詳細があります。 ヒント: 初めは、submitterは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.
このドキュメントの範囲の外に承認のときに服従を再開するメカニズムと同様に承認の録音とアクセスインタフェースの詳細があります。
8. Check Page
8. ページをチェックしてください。
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.
Check動作で作成されたCheckページは抽出された草稿メタデータと合法化結果を表示します。(R25/a)。 ページの目的はsubmitterが格納された草稿と自動的に抽出されたメタデータがsubmitterの意図に合っているかどうか確かめて、合法化問題において知識があるのを許容することです。
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).
submitterはCheckページで、外部のメタデータ(セクション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.
Checkページは草稿プレーンテキスト形式のプレビューを提供します。(掲示されるなら全体の草稿(すべての形式がある)がどのように見えるかを見るリンクがあるR31/a)(R82/b)。 ヒント: Checkページプレビューは、作者に明白な草稿ミスマッチか誤解誤りを検出させることができるくらい長いのですが、ページを支配するのを避けることができるくらい短いはずです。 要約の最終ラインを通って草稿の最初の台詞を表示するのは十分であるかもしれません。
For draft updates, the Check page reports the time and the submitter of the last update (R83/b). This information is especially useful
草稿アップデートのために、Checkページはアップデート(R83/b)の時間とsubmitterを報告します。 この情報は特に役に立ちます。
Rousskov Informational [Page 18] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[18ページ]のRFC4228ID服従ツールセット: 要件2005年12月
when multiple authors are working on the same draft. The page also provides a link to generate a diff against the last posted version (R84/c).
複数の作者が同じ草稿に取り組んでいるとき。 また、ページは、最後に掲示されたバージョン(R84/c)に対してデフを発生させるようにリンクを提供します。
8.1. External Meta-Data
8.1. 外部のメタデータ
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:
Checkページはsubmitterからの以下のメタデータに請求します。 submitterは草稿からそれを抽出できないので、この情報を提供しなければなりません:
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.
Submitter Eメールアドレス、(R32/a)。 submitterが予想されたsubmitter(セクション3を見る)でないときに、自動化された任命は可能ではありません、そして、草稿は事務局(R98)を通らなければなりません。 ヒント: 入力フィールドがある「上記のいずれ」でないチェックボックスに伴う抽出された作者名の横の1セットのチェックボックスは十分でしょう。 この草稿(R33/c)に取り替えられた草稿のリスト。 これは、取り替えられた草稿を目に見えなくするように役に立ちます。 範囲の外に既存の草稿操作があります、そして、そのような動作の安全上の配慮と他の複雑さは別々の仕様で記述されるほうがよいでしょう、したがって、このドキュメントが実際に既存の草稿を取り替えるのに必要な少しの動作も指定しません。 この草稿(R71/b)の議論のための第一のEメールアドレス。 ヒント: ToolsetはWGN草稿のためのWGメーリングリストアドレス、個々の草稿のための(提出)作者アドレス、または草案文面における最初のEメールアドレスさえ勧めることができます。 また、排他的にユーザ入力に依存することの代わりにいくつかのありそうなアドレスを提供すると、誤植の数は減少するでしょう。
Except for the submitter email address, external meta-data is optional (R109/a).
submitterを除いて、Eメールアドレス、外部のメタデータは任意です。(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).
与えられたsubmitter Eメールアドレスが予想されたsubmitter(すなわち、以下のカテゴリの1つに属す)に属すなら、Toolsetが現在ポストの間、submitter認証を実行する、動作、(R19/a)。 さもなければ、誤りは報告されます。(R118/a)。
The following possible expected submitters are identified by the Toolset, without any Secretariat intervention:
以下の可能な予想されたsubmittersは少しも事務局介入なしでToolsetによって特定されます:
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).
草稿、どんなsubmitterのバージョン00、も(R119/a)。 草稿のバージョンN+1、同じ草稿のバージョンNの作者、(R120/a)。 この要件は、NthバージョンがToolsetを使用することで掲示された草稿のために満たされる必要があるだけです。 他の草稿には、作者のリストを確かに得るのに必要である利用可能なメタ情報がないかもしれません。 WGN草稿、対応するWGの議長(R121/b)のために。 どんな草稿、IESGメンバー(R122/c)のためにも。
Rousskov Informational [Page 19] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[19ページ]のRFC4228ID服従ツールセット: 要件2005年12月
9. Post Now Action
9. 現在、動作を掲示してください。
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)、外部のメタデータを有効にする、(submitter Eメールアドレスを含んでいます) (R35/a)、草稿を掲示する、(R36/a)。 submitterは動作進歩と最終的な結果について通知されます。(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).
外部のメタデータはsubmitterのEメールアドレスを含んでいます。 aとして、合法化手順、ポストを離れさせてください、そして、現在、動作はsubmitterを認可します。 初期の動作実現は、submitterがそのアドレスに送られたメールに近づく手段を持っているのをチェックします。(R38/a)。 結局、Toolsetは、弱くて煩わしいメールアクセスチェック(R110/c)を排除するためにIETFによってサインされたクライアント証明書、PGPによってサインされたメール、そして/または、他の形式のクライアントサイド認証を受け入れるはずです。 認証が失敗するsubmitter、服従である、結局と静かである、外の回、(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.
Toolsetがウェブを両方に提供する、(R99/a)とメール(R139/b)は、メールアクセサリーを確認するために連結します。 ヒント: メールするためにsubmitterのアクセスをチェックするために、ツールは推測しにくいクッキーか象徴をsubmitterのアドレスにメールできます。 服従を続行するために、指定されたURLでクッキーを貼るか、象徴を持つURLに行くか、またはsubmitterがメールに応じるよう要求されています。
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).
それは、中間的Receiptページ、Toolset期待について説明して、服従IDをsubmitterに提供します。直後にsubmitter、ポストにメールを送る、現在の動作、発生、(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).
草稿を掲示する直後Toolsetは任命についてすべての作者(知られているEメールアドレスがある)に通知します。(R102/a)。 通知メールは以下で説明された「うまくいっている任命」Receiptページで利用可能な情報を含んでいます。(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) ガーベージコレクションルーチンが結局それを削除するように。
9.1. Receipt Page
9.1. 領収書ページ
A successful Post Now action reports at least the following information on the final Receipt page (R104/a):
うまくいっているポスト、現在、動作が少なくとも最終的なReceiptページの以下の情報を報告する、(R104/a):
o the draft ID and a link to the draft status page.
o 草稿ステータスページへの草稿IDとリンク。
o the draft title, authors, and abstract.
o ドラフトタイトル、作者、および要約。
Rousskov Informational [Page 20] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[20ページ]のRFC4228ID服従ツールセット: 要件2005年12月
o the submission ID.
o 服従ID。
o a link to the draft submission status page (when status queries
are supported, see R140).
o 草稿服従ステータスページ(状態質問が支持されたら、R140を見る)へのリンク。
o the submitter's name and email address.
o submitterの名前とEメールアドレス。
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.
Receiptページの第一の目的は(推定上)彼らの草稿が掲示されたことをすべての草稿作者に知らせることです。 副次目的は作者に出来事の永久的な記録を作成して、任命を障害調査させることです。 草稿(例えば、WGメーリングリストへの)に興味を持っている相手に同じ情報を送るべきですが、このドキュメントの範囲の外に3番目のパーティー通知詳細があります。
10. Adjust Action
10. 動作を調整してください。
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.
Adjust動作はAdjustページを発生させます。(R40/a)、利用可能でそれに居住すると、メタデータと外部のメタデータは抜粋されました、合法化結果とプレビューと同様に。 プレビュー世代の草稿解釈と成功によって、何らかの情報がなくなっているかもしれません。
11. Adjust Page
11. ページを調整してください。
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.
Adjustページは、Checkページと同じ情報を含んでいますが、submitterはすべての抽出された草稿メタデータ(そして、自然に外部のメタデータ)を自由自在に調整します。(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.
調整がなぜ必要であるかを説明しながら、submitterはAdjustページで非公式のコメントに入ることができます、そして、自動化された任命モードは使用できません。(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)。 ポストのManually動作(セクション12)で前者は支持されます。
Rousskov Informational [Page 21] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[21ページ]のRFC4228ID服従ツールセット: 要件2005年12月
12. Post Manually Action
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).
Manually動作が送るポスト紙はマニュアル合法化と任命のためにメタデータと草稿ポインタを事務局に調整しました。(R44/a)。 待つようsubmitterに命令して、領収書ページは発生します。(R45/a)。 草稿がいったん掲示されるか、または拒絶されると、事務局はsubmitterに通知するでしょう。 事務局が草稿を掲示するToolsetを使用しているなら、この通知はToolsetによって送られます。(R46/a)。
13. Receipt Page
13. 領収書ページ
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.
Receiptページは、現在の服従状態とさらなる動きについてsubmitterに知らせるために様々な動作で発生します。 ページのコンテンツは領収書が作られている動作と状態に非常に依存している傾向があります。 このセクションはすべての動作と州に適切な一般的な要件を記録します。
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.
Receiptページは服従のマニュアルトラブルシューティングのために、Uniform Resource Identifier(URI)か事務局が使用できる別の識別子をsubmitterに与えるはずです。(R63/a)。 識別子は永久であるべきです。(関連詳細ですが、R64/a)は結局、失われそうです(例えば、草稿服従データとログはガーベージコレクションルーチンの一部として中間準備地域から削除されます)。 ヒント: ツールは無効のものと古い識別子を区別するはずです。 与えられた識別子が削除されたデータを示しているとき、識別子を受け入れるツールは、特定された服従が認識されますが、関連情報が期限が切れたことを彼らのユーザに知らせるはずです。
The Receipt page should give the submitter a Secretariat point-of-contact to report submission problems (R65/a).
Receiptページは服従問題を報告する事務局連絡先をsubmitterに与えるはずです。(R65/a)。
14. Bypassing the Toolset
14. ツールセットを迂回させます。
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.
バギーのToolset実現か珍しい事情のために、submitterは手動の処理のためにやむを得ず事務局に草稿を提出するかもしれません。 Toolsetによって支えられた「マニュアル任命」ルートを選ぶことによって、これができます。(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
手動の差出を処理するとき、事務局はToolsetを使用できるかもしれません。 デフォルトCheckページと同様のManual Checkページは編集可能なメタデータ野原と「力の任命」動作(R50/b)を認証された事務局のスタッフに提供します。 無理矢理の任命動作は、メタデータ分野が「そのままである」と受け入れて、メールするsubmitterアクセスかWG草稿認可について確かめないで、草稿を掲示します。
Rousskov Informational [Page 22] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[22ページ]のRFC4228ID服従ツールセット: 要件2005年12月
no validation errors were found (R51/b). The Manual Check page should still contain all the errors and warnings identical to those seen by ordinary submitters (R106/b) so that the Secretariat knows what the Toolset is unhappy about (if anything).
(R51/b)はどんな合法化誤りにも見つけられませんでした。 Manual Checkページがまだ普通のsubmitters(R106/b)によって見られたものと同じすべての誤りと警告を含んでいるはずであるので、事務局は、Toolsetが何に関して不幸であるかを(どちらかと言えば)知っています。
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).
手動の処理を使用すると、重要な任命遅れはもたらされるかもしれません。 発生して、服従領収書か通知が予想された処理時間見積りをsubmitterに与えるべきです。(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.
このモードの意図は、submittersが「珍しい」草稿を掲示するために自動化されたメカニズムのバグか限界を迂回させる方法を提供するか、または「珍しい」状況の下での草稿を掲示することです。 1つの例が標準のIETFの決まり文句を含んでいませんが、実験決まり文句で草稿を掲示する特別なIESG許可がある草稿でしょう。 別の例はvalidatorバグによる自動化された合法化テストに失敗する草稿です。
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.
また、(事実上、)迂回モードもToolset実現のTrialステージの間、submittersの大部分によって使用されそうです、わずかなsubmittersしか(または、使用に許容されています)Toolsetに関して知らないとき。
15. Email Interface
15. メールインタフェース
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.
Toolsetには、有効な草稿(R55/b)の自動化された任命のためのメールインタフェースがあるはずです。 メールインタフェースの後ろで実際にはあらゆる記録されたToolsetの機能性を技術的に実行できますが、有効な草稿の任命以外の特徴がメールで実行するか、または使用するために法外に無器用であると信じられています。
The email interface accepts a draft as a set of email part(s) (one per draft format) (R56/b). For example, the plain text format can be submitted in the "body" of the email message, while XML source format can be optionally sent as an "attachment" of the same email message. Each part can either contain the actual format data (R141/b) or a single URL pointing to it (R142/c). In the latter case, the Toolset has to fetch the format data. Details of the URL-fetching option are not documented here, but it is assumed that HTTP URLs are supported (at least), and fetching errors are reported. This document does not specify how the format of each email part is determined, but it is assumed that MIME type and content would need to be analyzed.
メールインタフェースは1セットのメール部分(草稿形式あたり1つ)(R56/b)として手形を引き受けます。 例えば、メールメッセージの「ボディー」でプレーンテキスト形式を提出できます、同じメールメッセージの「付属」として任意にXMLソース形式を送ることができますが。 各部分は実際の形式データ(R141/b)かそれを示すただ一つのURL(R142/c)を含むことができます。 後者の場合では、Toolsetは形式データをとって来なければなりません。 URLを魅惑的なオプションの詳細はここに記録されませんが、HTTP URLが支持されて(少なくとも)、魅惑的な誤りが報告されると思われます。 それはそのMIMEの種類であると思われます、そして、このドキュメントはそれぞれのメール部分の形式がどう決定しているかを指定しませんが、内容は分析される必要があるでしょう。
After accepting the draft, the Toolset uses the sender's email address to select the submitter identity (R57/b), checks the submission (R58/b), and posts the draft if the check is successful (R59/b). The submitter should be notified of the outcome of the draft submission via email (R60/b). Other requirements for the web interface (including requirements on submission preprocessing, draft
草稿を受け入れた後に、Toolsetはsubmitterのアイデンティティ(R57/b)を選択するのに送付者のEメールアドレスを使用して、服従(R58/b)をチェックして、チェックがうまくいくなら(R59/b)、草稿を掲示します。 メール(R60/b)でsubmitterは草稿服従の結果について通知されるべきです。 ウェブのための他の要件が連結する、(服従前処理、草稿に関する要件を含んでいること。
Rousskov Informational [Page 23] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[23ページ]のRFC4228ID服従ツールセット: 要件2005年12月
validation, submitter authentication, draft posting, and notification) apply to the email interface.
合法化、submitter認証、草稿任命、および通知) メールインタフェースに適用してください。
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」は"submitter"のためのものです、そして、「A」は「すべての作者とsubmitter」のためのものです):
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.
草稿形式が草稿形式であることはみなされないとき認識されない部品/付属をメールしてください。 そのような部品はToolset(R107/b)によって無視されます、警告が空白(R108/b)以上を含むそれぞれの認知できない部分に発生するのを除いて。 これらの2つの要件で、インタフェースはsubmitterコントロールの外でメール署名と他の部品があるとき強健になることになっています。
Hint: Toolset actions can be implemented to support email and web interfaces without code duplication.
ヒント: コード複製なしでメールとウェブインタフェースを支持するためにツールセット動作を実行できます。
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:
ウェブとメールインタフェースの両方が有効な草稿の速い任命を考慮しますが、2つのインタフェースの間には、著しい違いがあります。 メールインタフェースの第一の利点は以下の通りです。
off-line mode: A submitter can do all the manual work required to
submit a draft while being disconnected from the network. The
email client actually submits the draft when connectivity is
regained.
オフライン・モード: submitterはネットワークから外されている間、草稿を提出するのに必要であるすべての手仕事ができます。 接続性を取り戻すとき、メールクライアントは実際に草稿を提出します。
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.
不十分な接続性: ネットワークの接続性が高いパケット損害率、トランスミッション遅れ、および他の問題のために不十分であるときに、メールシステムはしばしばメールの自動化されたトランスミッションと再伝達に合うほうがよいです。
Rousskov Informational [Page 24] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[24ページ]のRFC4228ID服従ツールセット: 要件2005年12月
convenience: Some IETFers consider email interfaces as generally
"more convenient".
便利: いくつかのIETFersが、一般に、メールインタフェースが「より便利である」とみなします。
Primary advantages of the web interface are:
ウェブインタフェースの第一の利点は以下の通りです。
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?").
確認: メタデータの自動化された抽出が妥当な結果を生んだことを確かめる機会をsubmitterに与えます。 他の役に立つ確認は可能です(例えば、「あなたは30秒前にあなたの共同作者によってアップデートされた草稿のバージョンを掲示したいのを確信していますか?」)。
validation: A submitter can validate the draft without posting it.
合法化: それを掲示しないで、submitterは草稿を有効にすることができます。
quality: Non-critical warnings may prompt the submitter to postpone
posting to improve draft quality.
品質: 非臨界警告は、submitterが、草稿品質を改良するために掲示するのを延期するようにうながすかもしれません。
manual adjustments: The submitter can adjust extracted meta-data and
ease Secretariat work on manually posting an unusual draft.
手動の調整: 手動で珍しい草稿を掲示するとき、submitterは抽出されたメタデータと容易さ事務局仕事を調整できます。
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.
メタデータ: submitterは任意の外部のメタデータを指定できます(草稿自体からそれを抽出できません)。 例えば、草稿議論のためのEメールアドレスを指定できます。
context help: The web interface makes it easy to provide links to
extra information about input fields, errors, posting options,
deadlines, etc.
コンテキストヘルプ: ウェブインタフェースで、入力フィールド、誤り、任命オプション、締め切りなどに関するその他の情報へのリンクを提供するのは簡単になります。
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).
不透明: ウェブインタフェースを通して提出されたファイルは論証上メールするよりトランジットの様々な変化と誤解に影響されやすくはありません。 メールエージェントはメールをしばしば変異させます(例えば自動化された注意書きが送付者で加えました、そして、余分な改行は受取人で加えました)。
convenience: Some IETFers consider web interfaces as generally "more
convenient".
便利: いくつかのIETFersが、一般に、ウェブインタフェースが「より便利である」とみなします。
16. Implementation Stages
16. 実現ステージ
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".
このセクションはToolset実現ステージかフェーズを定義します。 手紙“a"、「b」、または「c」で示される3つの連続したステージがあります。 後期段階にまだ早期のステージ要件を満たさなければなりません。 すべての要件が、現在のステージと現在実行された特徴の文脈で解釈されて、評価される必要があります。 例えば、要件R68は第一段階に適用しますが、2番目のステージまで支持されないかもしれないXML草稿書式を示します。 R68の正しい解釈によるXMLサポートが加えられるまでの「それはプレーンテキスト形式なしで草稿を提出する誤りです」。
Rousskov Informational [Page 25] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[25ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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.
別の方法で注意されない場合、カバーされる必要はないのを除いて、後期段階にリストアップされた要件は早期のステージでカバーされているかもしれません。いてください。 implementersが、将来のステージから何らかの機能性を加えると決めるなら、彼らはその機能性に関連するすべての要件を満たすのに非常に慎重でなければなりません。 残念ながら、与えられた特徴に関連する「すべての要件」を特定するどんな信頼できて、実践的な方法もありません。
(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) トライアルステージ: 最も一般的な服従ケースを扱うので、基本的な実現に頭文字をつけて、大概念をテストして、事務局を救ってください。 このステージはウェブインタフェースを通してプレーンテキスト草稿提案に焦点を合わせます。 トライアルステージは、終わる(すなわち、すべての記載された要件に従う)ために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) 増進ステージ: Toolsetの総合的な品質を改良する洗練された特徴(例えば、草稿解釈か合法化)に焦点を合わせる果てしないステージ。 このステージは主としてToolsetの総合的な指示を目立たせるように記録されます。 要件はしばしば不正確です、そして、多くが変化することが期待されます。
Implementation experience is likely to result in changes of the Toolset requirements. Such changes should be documented as a part of stage evaluation activities.
実現経験はToolset要件の変化をもたらしそうです。 そのような変化はステージ評価活動の一部として記録されるべきです。
17. Testing
17. テスト
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.
Toolsetが稼動する前に、メタデータ抽出アルゴリズムをテストするのに何千もの掲示された草稿を使用できます。そのようなテストは、メタデータ抽出失敗のために手動の取り扱いのために転送される草稿の数を最小にすることができます。
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.
また、他のToolsetの特徴も、掲示された草稿を使用することで試験できるかもしれません。 ウェブに関する基本機能をテストして、インタフェースをメールするのにスクリプトの純真な組を使用できます。
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は試験の成績を必要とするかもしれません。 自動化されるなら、また、回帰試験に上のアプローチを使用できます。
Rousskov Informational [Page 26] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[26ページ]のRFC4228ID服従ツールセット: 要件2005年12月
18. Security Considerations
18. セキュリティ問題
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.
草稿服従から人間を外して、過程(通称オートメーション)を掲示するのは、Toolsetをサービスの否定(DoS)攻撃があるとき信頼できるようにする特徴を加えるのが必要であり、草稿倉庫を崩壊させるのを試みます。 理想的に、Toolsetは、計画的な悪意がある行為と善意事故の両方に抵抗する必要があります。
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)の影響を最小にするという決められた一定の要求を含んでいます。 Toolset維持装置に通知されて、既に掲示された草稿が破損されていない限り、要件はToolsetが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任命規則に違反する草稿の検出に関連する多くの決められた一定の要求を含んでいます。 それらの要件は、間違って掲示された「悪い」草稿の数を減少させるのを助けますが、submittersから信頼できる保護を悪意で提供しません: 自動化されたツールが本当に、草稿(そして、そう、すぐにしない)を理解していないので、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).
より強いsubmitter認証が、悪意があるsubmittersを思いとどまらせるのに必要であるかもしれません。 記録された認証機構(すなわち、人のメールへのアクセスを読む)はToolsetの最初のバージョンの展開に適切であると考えられます、厳密な事務局監督下で。 ヒント: 十分初期の問題を検出するという可能性を高めるために、あらゆる掲示された服従(Toolsetの初期の展開の間の)について自動的に指定された人間に知らせるのは、名案であるかもしれません。
19. Compliance
19. 承諾
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.
すべての標準の要件(すなわち、"Rnnn"と共にセクション3で定義されるようにマークされた句)を満たすなら、Toolset実現はこの仕様で対応します。 いくつかの要件がいくつかのステージに適用されないとき、コンプライアンスはそれぞれの実現ステージに評価されるべきです。
The IESG evaluates implementations and interprets requirements as necessary.
IESGは、実現を評価して、要件が必要であると解釈します。
Rousskov Informational [Page 27] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[27ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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による現在使用における草稿服従アプローチと提案されたToolsetの主要な違いをまとめます、現在の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 Toolsetは、掲示するのをXMLとPDF草稿形式を許容します。 XML形式は現在事務局によって受け入れられません、そして、事務局によるPDF承認の合法は質問されました。 IETFツールと関係者が生の草稿メタデータと内容に近づく手段を持っているのを可能にするためにXMLソースを受け入れるべきです。 また、それらもRFC Editorの役に立って、したがって、早く「システム」にそれらを有効にして、得るのは、名案です。 後者の議論はまた、PDF草稿に適用されます、最初のToolsetバージョンが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 Toolsetは結局、XML草稿ソースからHTML草稿形式を発生させるかもしれません(R112を見てください)。 現在、IETFはHTML草稿形式を提供しません--事務局はHTMLソースを受け入れません、そして、HTMLは全く引受済み手形ソースから発生しません。 しかしながら、このドキュメントが、Toolsetが結局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 Toolsetが名前が始まる草稿としての「WGN草稿」を定義する、「草稿-ietf、-、」 他のすべての草稿が個々の草稿として扱われます。 現在、IETF WGは形式を命名するただ一つのWG草稿に続く必要はありません。 したがって、ToolsetはWG同意なしでWGがWG草稿であると考える草稿の00バージョンを掲示できます。 影響を受けるWGsは一般的な命名形式を使用しないという彼らの決定の結果に対処しなければならないでしょう。 Toolsチームは、IETFが、WGsが、混乱を最小にするのにただ一つの形式を使用すると彼らの草稿を命名するのを必要とするのを示します。 うまくいけば、彼らの命名された"Ietf"か少なくともいずれも自動ポストの個々の草稿に必要としない人間は全くいません。
o For some drafts, the Toolset verifies that the submitter is
"expected" (e.g., an author of the previous draft version or WG
Chair). Currently, the Secretariat does virtually no such
verification, but an email submission interface and a human
presence in the submission loop have apparently been sufficient to
prevent massive automated attacks. The change is needed to
prevent a simple script from using the web interface to overwrite
posted IETF drafts with junk. Hopefully, the IETF will eventually
have a decent authentication scheme making the submitter checks
simpler, less rigid, and more transparent.
o いくつかの草稿のために、Toolsetは、submitterが「予想されること」を(例えば、前の草案バージョンの作者かWG議長)確かめます。 現在、事務局は実際にはどんなそのような検証もしませんが、メール服従インタフェースと服従輪での人間の存在は、大規模な自動化された攻撃を防ぐために明らかに十分です。 変化が、簡単なスクリプトがくずで掲示されたIETF草稿を上書きするのにウェブインタフェースを使用するのを防ぐのが必要です。 うまくいけば、IETFには、結局、submitterチェックをより簡単で、それほど堅くなくて、より透明にするきちんとした認証計画があるでしょう。
Rousskov Informational [Page 28] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[28ページ]のRFC4228ID服従ツールセット: 要件2005年12月
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 Toolsetは掲示された草稿について自動的に作者に通知するでしょう。 草稿が現在掲示されるとき、submitterも共著者のいずれも明らかに通知されません。 通知は言われて、共著者がそれらの名前が置かれるケースを検出するのを許容するために、一部、作者は許可なしで記載します。 結局、ADs、いす、または評論家などの3番目のパーティーが草稿任命に関する通知のために登録するのを許容する一般的な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 Toolsetは結局、圧縮された草稿を受け入れるかもしれません(R150を見てください)。 現在、事務局はウイルス汚染関心のため「ファスナ」アーカイブを受け入れません。 Toolsetの適切な履行はそのような関心を記述しなければなりません、手動のルートでそれらを提出するなら、事務局が、まだある形式を拒絶する必要があるかもしれませんが。
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).
作者は感謝してハラルドTveit Alvestrand(シスコ)、ブライアンE.Carpenter(IBM)、フランクEllermann、ビル・フェナー(AT&T)、バーバラ・B.フラー(Foretec)、ブルース・リリー、Henrik Levkowetz(エリクソン)、ラリーMasinter(Adobe)、キース・ムーア(テネシー大学)、ペッカSavola(Netcore)、ヘニングSchulzrinne(コロンビア大学)、およびスタニスラフShalunov(Internet2)の貢献を承諾します。
Special thanks to Marshall Rose for his xml2rfc tool.
彼のxml2rfcツールのためのマーシャル・ローズのおかげで、特別です。
Rousskov Informational [Page 29] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[29ページ]のRFC4228ID服従ツールセット: 要件2005年12月
Normative References
引用規格
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
M. [RFC2629]ローズ、RFC2629、「XMLを使用することでI-DsとRFCsに書く」6月1999日
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] ブラドナー、S.、「IETF技術による知的所有権」、BCP79、RFC3979、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インチ、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.
[書くこと-rfcs] ローズと、M.と、「XML(改訂される)を使用する書くことのI-DsとRFCs」は進歩、2004年4月に働いています。
[secretariat] "Private communication with the IETF Secretariat",
2004.
[事務局] 「IETF事務局との私信」、2004。
[OSD] "The Open Source Definition, version 1.9", Open Source
Initiative, 2005, available at
http://www.opensource.org/docs/definition.php.
[OSD]、「オープンSource Definition、バージョン1.9インチ、オープンSource Initiative、利用可能な2005、 http://www.opensource.org/docs/definition.php 、」
Author's Address
作者のアドレス
Alex Rousskov The Measurement Factory
アレックスRousskov測定工場
EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/
メール: rousskov@measurement-factory.com ユリ: http://www.measurement-factory.com/
Rousskov Informational [Page 30] RFC 4228 ID Submission Toolset: Requirements December 2005
Rousskovの情報[30ページ]のRFC4228ID服従ツールセット: 要件2005年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Rousskov Informational [Page 31]
Rousskov情報です。[31ページ]
一覧
スポンサーリンク
