Network Working Group                                        A. Rousskov
Request for Comments: 4228                       The Measurement Factory
Category: Informational                                    December 2005
Network Working Group                                        A. Rousskov
Request for Comments: 4228                       The Measurement Factory
Category: Informational                                    December 2005

Requirements for an IETF Draft Submission Toolset


Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2005).




This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.


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. Introduction ....................................................2
   2. Scope ...........................................................2
   3. Notation and Terminology ........................................3
   4. Status Quo ......................................................4
   5. Overall Toolset Operation .......................................6
   6. Upload Page .....................................................9
   7. Check Action ....................................................9
      7.1. Preprocessing .............................................10
      7.2. Processing ................................................11
      7.3. Storage ...................................................11
      7.4. Extraction ................................................12
      7.5. Validation ................................................13
           7.5.1. Absolute Requirements ..............................14
           7.5.2. Desirable Features .................................15
           7.5.3. DoS Thresholds .....................................17
           7.5.4. WG Approval ........................................17
   8. Check Page .....................................................18
      8.1. External Meta-Data ........................................19
   9. Post Now Action ................................................20
      9.1. Receipt Page ..............................................20
   10. Adjust Action .................................................21
   11. Adjust Page ...................................................21
   12. Post Manually Action ..........................................22
   13. Receipt Page ..................................................22
   14. Bypassing the Toolset .........................................22
   15. Email Interface ...............................................23
   16. Implementation Stages .........................................25
   17. Testing .......................................................26
   18. Security Considerations .......................................27
   19. Compliance ....................................................27
   Appendix A. Comparison with Current Procedures ....................28
   Appendix B. Acknowledgements ......................................29
   Normative References ..............................................30
   Informative References ............................................30
   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
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.


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.


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 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.


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.


draft version: A meant-to-be-public snapshot of an Internet-Draft with a meant-to-be-unique version number. Also known as "draft revision".


draft format: Any draft source or presentation format, including original and preprocessed XML, original or generated plain text as well as PDF, PostScript, and HTML formats.


primary draft format: The first available draft format from the following list: plain text, PDF, PostScript, or 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.


individual draft: A draft other than a WGN draft.


submitter: A human or software agent initiating submission of an Internet-Draft version for validation or posting. In some cases, the Secretariat staff does the actual submission, but always on behalf of a submitter. In some cases (including but not limited to malicious attacks), the submitter is not the draft author.


expected submitter: A submitter that is authorized by IETF rules to post a given draft. This includes a draft author or editor (listed in the draft text), a corresponding WG Chair, or an IESG member.


authorized submitter: An expected submitter authenticated by the Toolset. Authentication is initially limited to verifying submitter access to submitter's email address.


immediately: Without human interaction or artificial software delays and within a few seconds.


The Toolset is specified using a set of normative requirements. These requirements are English phrases ending with an "(Rnnn/s)" indication, where "nnn" is a unique requirement number, and "s" is a single-letter code ("a", "b", or "c") specifying the implementation stage for the requirement. Implementation stages are documented in Section 16.


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.


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.


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.


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.


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).


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.


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.


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.


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.


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.


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).


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.


Check action: Stores the draft in the Toolset staging area, extracts draft meta-data, validates the submission (Section 7). Produces the Check page.


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节)。本页还可提供预览草稿。在审查草案的解释和验证结果后,提交人有四个基本选择:(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).


Manual adjustment and posting: If the submitter decides to adjust the meta-data, the draft remains in the Toolset staging area, and the Adjust action (Section 10) presents the submitter with an Adjust page (Section 11). When the submitter makes the adjustments and proceeds with manual posting, a pointer to the stored draft and its adjusted meta-data is sent to the Secretariat for manual


processing (Section 12). The submitter is notified of the pending Secretariat request via email and a Receipt page.


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.


Receipt page: Contains details of a successful or failed draft submission and informs the submitter of the next appropriate step(s) related to submission result.


The following informal diagram illustrates the basic submission logic:


                       /---> Post Now
   Upload --> Check -+-----> Adjust ---> Send to Secretariat
                       \---> Cancel
                       /---> 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.


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.


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.


The Toolset must handle multiple submitters simultaneously submitting the same draft (R72/a) and a single submitter simultaneously submitting two drafts (R73/a). The latter might happen, for example, when the submitter is using several browser windows to submit several


drafts or is submitting drafts via email interface. The term "simultaneously" means that submission processing times overlap.


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.


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 servlet)来实现服务器端支持。实现者经验、跨web和电子邮件接口的代码重用以及其他因素将决定正确的技术选择。

Hint: Actions preserve and exchange state by storing it along with the draft. Grouping all submission-specific information in one subdirectory named using the session identifier may increase robustness and simplify debugging. Session creation and destruction can then be logged in a global index.


Ways to partially or completely bypass the Toolset are documented in Section 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.


Hint: Placing the Toolset source repository at an open-source-friendly project management site like 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.


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.


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.

为了上传草稿,提交人进入IETF网站(R1/b)上的知名页面。在那里,可以使用HTML文件上传表单上传草稿文本。此表单提供了用于上传草案纯文本格式(R2/a)和IETF草案发布规则(R3/b)允许的所有其他格式的字段。在撰写本文时,这些格式是:XML([RFC2629]和[writing RFC])、PDF和PostScript。

Submitted forms are handled by the Check action documented in Section 7.


The Upload page also has a validate-only flag, indicating that an uploaded draft must not be posted and may be deleted immediately after the validation (R74/b). Regardless of the validation results, the stored draft meta-data is marked so that validation-only drafts can be identified and deleted first by garbage collector for the Toolset staging area (R75/b). Drafts uploaded in a validate-only mode cannot be posted (R76/b); they would need to be uploaded again, without the validate-only flag, and the validation results page should explain that (R77/b). This flag is useful for tools using online validation, especially for bulk draft processing. Hint: it may be better to implement this flag as a hidden HTML input field to simplify the interface for human submitters.

上传页面还有一个仅验证标志,表示上传的草稿不得发布,并可在验证后立即删除(R74/b)。不管验证结果如何,存储的草稿元数据都会被标记,以便工具集暂存区域(R75/b)的垃圾收集器可以首先识别和删除仅验证草稿。以仅验证模式上载的草稿无法发布(R76/b);它们需要再次上传,没有validate only标志,validation results页面应该对此进行解释(R77/b)。此标志对于使用在线验证的工具非常有用,特别是对于批量草稿处理。提示:最好将此标志实现为隐藏的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).


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.


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.


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).


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.


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.


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".


The XML preprocessor uses public database(s) to resolve PI references (R85/b). The Toolset documentation specifies what databases are used and how PIs are mapped to database entries (R86/b). The Toolset must


not rely on PIs' existence (R87/b) because some XML sources will be preprocessed before the submission or will be written without PIs. Hint: Local up-to-date copies of Marshall Rose's reference databases at can be used.

不要依赖PIs的存在(R87/b),因为一些XML源将在提交之前进行预处理,或者在没有PIs的情况下编写。提示:可以使用xml.resource.org上Marshall Rose参考数据库的本地最新副本。

Both original and preprocessed XML sources may be posted later. The original source with include PIs may be useful to the RFC Editor and generation of diffs (against future or past original sources). The preprocessed source without include PIs becomes the default public XML source of the posted draft (R10/b). If any of the include PIs known to the Toolset cannot be handled, an error is recorded (R11/b), and the submitter is encouraged to do the preprocessing locally, before submitting the draft (R111/b).

原始和预处理的XML源都可能在以后发布。包含PI的原始源可能对RFC编辑器和差异生成(针对未来或过去的原始源)有用。未包含PIs的预处理源将成为已发布草稿(R10/b)的默认公共XML源。如果工具集已知的任何include PI无法处理,则会记录错误(R11/b),并鼓励提交者在提交草稿(R111/b)之前在本地进行预处理。

Uncompressed draft formats other than XML are not preprocessed.


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).


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.


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.


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).


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).


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.


The draft interpreter extracts the following meta-data from each draft format (R16/a):


identifier: Also known as draft "filename". For example, "draft-ietf-sieve-vacation-13".


version: A non-negative integer number representing draft version number (also known as draft revision number). For example, the number 7 in "draft-ietf-sieve-vacation-07". The number is usually rendered using two digits, padding with "0" if necessary.


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".


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 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.


title: A human-friendly draft title. For example, the title of this document is "Requirements for an IETF Draft Submission Toolset".


authors: A list of all draft authors. Each author's name and email address are extracted.


abstract: The draft abstract text.


creation date: The draft version creation date.


expiration date: The draft version expiration date.


size: The number of pages and octets in the primary format of the draft. The definition of a page depends on the format and may be imprecise or arbitrary for some formats.


Failure to extract any field results in error (R95/a).


The Toolset requires author email addresses because they are essential for notifying co-authors that their draft has been posted. If there are no such notifications, a submitter adding a co-author to the draft without the co-author's consent may not be caught for a while. Such "surprise" co-authorships have happened in the past and can be quite annoying. However, since the Toolset does not solicit co-authors' consent to post a valid draft (and such solicitation would not go beyond email control verification anyway), it is not possible to stop a malicious submitter from adding co-authors without their knowledge.


Like other meta-data items above, draft creation and expiration dates are extracted from the draft; their values do not depend on the actual submission time (i.e., the time the Check action starts). However, the validation procedure (see Section 7.5) may declare any extracted date invalid after taking into consideration current (i.e., submission) time, IETF draft expiration rules, and other factors external to the draft.


7.5. 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 <>. 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.


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.


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.


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.


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)。该批准可在提交初稿之前或之后由工作组主席或秘书转达。相关要求见第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”填充。草稿版本号必须从零开始,每增加一个新版本,就增加一个。为了满足这一要求,工具集必须查阅已经发布的草稿(包括过期的草稿)的存储库。如果IETF基础设施无法处理大于99的版本号,则工具集必须拒绝它们(R158/a)。

4. An IETF IPR Statement and other boilerplate required for drafts according to [RFC3978] and [RFC3979] (or successors) must appear in the draft text (R23/a).

4. 根据[RFC3978]和[RFC3979](或后续文件)起草的草案所需的IETF IPR声明和其他样板必须出现在草案文本(R23/a)中。

5. The extracted creation date of the draft version must be within 3 days of the actual submission date (R159/a). Hint: Implementers should be careful to handle creation dates that appear to be in the past or in the future, due to possible time zone differences. Making the most forgiving/permissive assumption about the time zone should suffice.

5. 草稿版本的提取创建日期必须在实际提交日期(R159/a)后3天内。提示:由于可能的时区差异,实现者应该小心处理似乎在过去或将来的创建日期。对时区做出最宽容/宽容的假设就足够了。

6. The draft version expiration date obeys IETF draft expiration rules.

6. 草稿版本的到期日期遵循IETF草稿到期规则。

7. No IETF submission blackout period applies. Hint: IETF blackouts must be enforced based on submission time, not possible draft creation time.

7. 不适用IETF提交中断期。提示:IETF断电必须基于提交时间,而不是可能的草稿创建时间。

8. Posting the draft must not result in any DoS attack threshold to be crossed (R97/a). Specific thresholds are documented in Section 7.5.3.

8. 发布草稿不得导致超过任何DoS攻击阈值(R97/a)。具体阈值记录在第7.5.3节中。

9. XML sources (if available) are valid with respect to the XML format [XML] (R153/c) and XML Document Type Definition (DTD) for IETF drafts (R154/c). Note that during the first two implementation stages, the corresponding validation failures result in warnings and not errors (see Section 7.5.2).

9. XML源(如果可用)对于IETF草案(R154/c)的XML格式[XML](R153/c)和XML文档类型定义(DTD)是有效的。请注意,在前两个实施阶段,相应的验证失败会导致警告而不是错误(参见第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 (or its derivative) may be useful for XML format and DTD validation.

IETF草案的XML DTD记录在[RFC2629]中,最近的更改可在[writing RFC]中获得。提示:Bill Fenner的“RFC 2629验证器”位于 valid/(或其衍生物)可能对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.


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.


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


and/or advice may be available as a resource separate from the Toolset.


1. All automatically testable nits in the "ID-NITS" document at <> (R116/b) and automatically testable guidelines at <> (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 ( and other tools can be written or adopted.

1. 位于“ID-nits”文档中的所有自动可测试NIT<>(R116/b)和自动测试指南<>(R157/b)。工具集应该使用外部工具来检查这些NIT和指南,而不是嵌入检查代码(R117/a)。提示:可以使用Henrik Levkowetz的idnits工具(可以编写或采用其他工具。

2. New draft versions are expected (R21/b). For example, version 00 of an individual draft is always expected, while posting a new version of a draft already under the IESG review should generate a warning.

2. 预计会有新的草案版本(R21/b)。例如,个人草稿的版本00总是预期的,而发布已在IESG审查中的草稿的新版本时,应生成警告。

3. If both XML and plain text formats are submitted, the submitted plain text matches what can be generated based on submitted XML (R146/b).

3. 如果提交了XML和纯文本格式,则提交的纯文本与基于提交的XML(R146/b)生成的内容相匹配。

4. The previous version, if any, was posted at least 24 hours ago (R96/b). This warning may prevent some human errors, especially when multiple authors may post the same draft.

4. 以前的版本(如有)至少在24小时前发布(R96/b)。此警告可能会防止某些人为错误,尤其是当多个作者可能发布同一草稿时。

5. XML sources (if available) are valid with respect to the XML format (R155/b) and XML DTD for IETF drafts (R156/b). These requirements become absolute after the second implementation phase. See Section 7.5.1 for related information.

5. XML源(如果可用)对于XML格式(R155/b)和IETF草案的XML DTD(R156/b)是有效的。在第二个实施阶段之后,这些要求变得绝对。有关信息,请参见第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.


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.


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 attack thresholds:


      | 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 |
      | category                        | versions/day |    MB/day |
      | drafts with the same draft name |            3 |         5 |
      | drafts with the same submitter  |           10 |        15 |
      | WGN drafts with the same WG ID  |           30 |        45 |
      | all drafts                      |          400 |       200 |

The thresholds are meant to limit destructive effects of DoS attacks (e.g., full disks cause other tasks to fail), allow for capacity planning (e.g., how much storage space the Toolset needs), and limit annoying side effects of "too many" drafts being posted (e.g., when a person receives posting notifications about a given draft or a given working group). The Toolset should warn the Secretariat if total submissions are approaching any threshold (R134/b). Hint: Bandwidth available for submissions may need to be throttled (on a network subnet basis?) to make reaching the daily size quota (with malicious intent) difficult.


7.5.4. WG Approval
7.5.4. 工作组批准

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).


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).


If (a) no approval exists, (b) the Toolset supports the "waiting for WG approval" feature, and (c) the draft can be posted if WG approval is received, then the Toolset explains the situation to the submitter and asks whether an explicit approval from the WG should be solicited or expected (R126/b). If the approval should be solicited, it is


solicited by the software or the submitter. If appropriate, the Toolset puts the submission into a "waiting for WG approval" state until the expected approval is available (R127/b). Otherwise, the Toolset records a "no WG approval is expected" error (R138/b).


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.


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.


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.


Validation messages include both errors and warnings. Each validation message refers to normative document(s) containing the corresponding validation rules (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).


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.


For draft updates, the Check page reports the time and the submitter of the last update (R83/b). This information is especially useful


when multiple authors are working on the same draft. The page also provides a link to generate a diff against the last posted version (R84/c).


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:


Submitter email address (R32/a). When submitter is not an expected submitter (see Section 3), automated posting is not possible and the draft has to go through the Secretariat (R98). Hint: A set of checkboxes next to extracted author names along with a "none of the above" checkbox with an input field would suffice. A list of drafts replaced by this draft (R33/c). This is useful to make replaced drafts invisible. This document does not specify any actions necessary to actually replace an existing draft because existing draft manipulation is out of scope, and because security concerns and other complications of such actions would be better addressed by a separate specification. Primary email address for discussion of this draft (R71/b). Hint: The Toolset can suggest the WG mailing list address for WGN drafts, (submitting) author address for individual drafts, or even the first email address in draft text. Offering a few likely addresses instead of relying exclusively on user input would also reduce the number of typos.

提交人电子邮件地址(R32/a)。如果提交人不是预期的提交人(见第3节),则不可能自动过账,草案必须通过秘书处(R98)。提示:在提取的作者姓名旁边有一组复选框,再加上一个带有输入字段的“none of the Over”复选框就足够了。由本草案(R33/c)替换的草案列表。这有助于使替换的草稿不可见。本文件未规定实际替换现有草案所需的任何行动,因为现有草案操纵超出范围,并且此类行动的安全问题和其他复杂问题最好通过单独的规范解决。讨论本草案的主要电子邮件地址(R71/b)。提示:该工具集可以建议WGN草稿的工作组邮件列表地址,个人草稿的作者地址,甚至草稿文本中的第一个电子邮件地址。提供一些可能的地址,而不是完全依赖用户输入,也可以减少打字错误的数量。

Except for the submitter email address, external meta-data is optional (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).


The following possible expected submitters are identified by the Toolset, without any Secretariat intervention:


For version 00 of a draft, any submitter (R119/a). For version N+1 of a draft, an author of version N of the same draft (R120/a). This requirement only needs to be satisfied for drafts for which Nth version was posted using the Toolset; other drafts may not have the meta-information available that is required to reliably get a list of authors. For a WGN draft, a Chair of the corresponding WG (R121/b). For any draft, an IESG member (R122/c).


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).


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).


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.


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).


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).


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.


9.1. Receipt Page
9.1. 收据页

A successful Post Now action reports at least the following information on the final Receipt page (R104/a):


o the draft ID and a link to the draft status page.

o 草稿ID和指向草稿状态页面的链接。

o the draft title, authors, and abstract.

o 标题草案、作者和摘要。

o the submission ID.

o 提交ID。

o a link to the draft submission status page (when status queries are supported, see R140).

o 指向草稿提交状态页面的链接(支持状态查询时,请参阅R140)。

o the submitter's name and email address.

o 提交者的姓名和电子邮件地址。

The primary purpose of the Receipt page is to inform all draft authors that (supposedly) their draft has been posted. The secondary purpose is to let authors create a permanent record of the event and troubleshoot postings. The same information should be sent to other parties interested in the draft (e.g., to the WG mailing list), but 3rd-party notification specifics are out of this document's scope.


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.


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.


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.


The "post manually" and "cancel" buttons are provided (R43/a). The former is backed by the Post Manually action (Section 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).


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.


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.


The Receipt page should give the submitter a Secretariat point-of-contact to report submission problems (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.


When processing manual submissions, the Secretariat may be able to use the Toolset. A Manual Check page similar to the default Check page provides authenticated Secretariat staff with editable meta-data fields and a "force posting" action (R50/b). The forced posting action accepts meta-data fields "as is", does not verify submitter access to email or WG draft authorization, and posts the draft as if


no validation errors were found (R51/b). The Manual Check page should still contain all the errors and warnings identical to those seen by ordinary submitters (R106/b) so that the Secretariat knows what the Toolset is unhappy about (if anything).


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).


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.


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.


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.


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.

电子邮件接口将草稿作为一组电子邮件部分(每个草稿格式一个)(R56/b)接受。例如,纯文本格式可以在电子邮件的“正文”中提交,而XML源格式可以选择性地作为同一电子邮件的“附件”发送。每个部分可以包含实际格式数据(R141/b)或指向它的单个URL(R142/c)。在后一种情况下,工具集必须获取格式数据。此处未记录URL抓取选项的详细信息,但假定支持(至少)HTTP URL,并报告抓取错误。本文档未指定如何确定每个电子邮件部分的格式,但假定需要分析MIME类型和内容。

After accepting the draft, the Toolset uses the sender's email address to select the submitter identity (R57/b), checks the submission (R58/b), and posts the draft if the check is successful (R59/b). The submitter should be notified of the outcome of the draft submission via email (R60/b). Other requirements for the web interface (including requirements on submission preprocessing, draft


validation, submitter authentication, draft posting, and notification) apply to the email interface.


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"):


S-->T: the draft version


S<--T: a challenge to verify email access


S-->T: a response to the challenge


A<--T: warnings and the receipt


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: errors and receipt


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.


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:


off-line mode: A submitter can do all the manual work required to submit a draft while being disconnected from the network. The email client actually submits the draft when connectivity is regained.


poor connectivity: Email systems are often better suited for automated transmission and re-transmission of emails when network connectivity is poor due to high packet loss ratios, transmission delays, and other problems.


convenience: Some IETFers consider email interfaces as generally "more convenient".


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?").


validation: A submitter can validate the draft without posting it.


quality: Non-critical warnings may prompt the submitter to postpone posting to improve draft quality.


manual adjustments: The submitter can adjust extracted meta-data and ease Secretariat work on manually posting an unusual draft.


meta-data: The submitter can specify optional external meta-data (that cannot be extracted from the draft itself). For example, an email address for draft discussion can be specified.


context help: The web interface makes it easy to provide links to extra information about input fields, errors, posting options, deadlines, etc.


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".


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".


Unless otherwise noted, requirements listed in later stages may be covered in earlier stages, but do not have to be. If the implementers decide to add some functionality from a future stage, they have to be very careful to satisfy all requirements related to that functionality. Unfortunately, there is no reliable, pragmatic way to identify "all requirements" related to a given feature.


(a) Trial Stage: Initial basic implementation to test major concepts and relieve the Secretariat from handling the most common submission case. This stage focuses on plain text draft submission via the web interface. The trial stage should take a dedicated professional about 45 calendar days to finish (i.e., to comply with all the listed requirements).

(a) 试验阶段:初步基本实施,以测试主要概念,并使秘书处不再处理最常见的提交案件。此阶段的重点是通过web界面提交纯文本草稿。试验阶段需要一名专业人员约45个日历日完成(即,遵守所有列出的要求)。

(b) Production Stage: Support for all major features. Once this stage is completed, the Secretariat should only handle unusual draft submissions. This stage should take about 100 calendar days to finish. Gradual release of implemented features is possible and expected. Specifically, the XML support is expected before email interface support.

(b) 生产阶段:支持所有主要功能。一旦这一阶段完成,秘书处应只处理不寻常的提交草稿。这一阶段需要大约100个日历日才能完成。逐步发布已实现的特性是可能的,也是预期的。具体地说,XML支持应该先于电子邮件接口支持。

(c) Enhancement Stage: A never-ending stage focusing on sophisticated features (e.g., draft interpretation or validation) that improve the overall quality of the Toolset. This stage is documented primarily to highlight the overall direction of the Toolset; its requirements are often imprecise and many are expected to change.

(c) 增强阶段:一个永无止境的阶段,专注于提高工具集整体质量的复杂功能(例如,草稿解释或验证)。记录此阶段主要是为了突出工具集的总体方向;它的要求往往不精确,许多要求可能会改变。

Implementation experience is likely to result in changes of the Toolset requirements. Such changes should be documented as a part of stage evaluation activities.


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.


Other Toolset features may also be testable using posted drafts. A simple pair of scripts can be used to test basic functionality of the web and email interfaces.


Hint: The IESG may require test results before accepting the initial implementation. If automated, the above approach can be used for regression testing as well.


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.


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.


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.


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).


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.


The IESG evaluates implementations and interprets requirements as necessary.


Appendix A. Comparison with Current Procedures

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.


o The Toolset allows posting of XML and PDF draft formats. The XML format is not currently accepted by the Secretariat, and legality of PDF acceptance by the Secretariat has been questioned. XML sources should be accepted to enable IETF tools and participants to have access to raw draft meta-data and content. They are also useful to the RFC Editor and, hence, it is a good idea to validate and get them "into the system" early. The latter argument applies to PDF drafts as well, although the first Toolset versions are not expected to interpret PDF drafts.

o 该工具集允许发布XML和PDF草稿格式。秘书处目前不接受XML格式,秘书处接受PDF格式的合法性受到质疑。应接受XML源,以使IETF工具和参与者能够访问原始草案元数据和内容。它们对RFC编辑器也很有用,因此,尽早验证并“进入系统”是一个好主意。后一个参数也适用于PDF草稿,尽管第一个工具集版本预计不会解释PDF草稿。

o The Toolset may eventually generate HTML draft formats from XML draft sources (see R112). Currently, IETF does not provide HTML draft formats -- the Secretariat does not accept HTML sources and no HTML is generated from accepted draft sources. Note, however, that this document does not suggest that the Toolset should eventually accept drafts in HTML format.

o 该工具集最终可能会从XML草稿源生成HTML草稿格式(请参见R112)。目前,IETF不提供HTML草稿格式——秘书处不接受HTML源,也不从接受的草稿源生成HTML。但是,请注意,本文档并不建议工具集最终接受HTML格式的草稿。

o The Toolset defines "WGN draft" as a draft whose name starts with "draft-ietf-". All other drafts are treated as individual drafts. Currently, an IETF WG does not have to follow a single WG draft naming format. Thus, the 00 version of a draft that the WG considers a WG draft can be posted by the Toolset without WG consent. Affected WGs would have to deal with the consequences of their decision not to use a common naming format. The Tools team suggests that IETF requires WGs to name their drafts using a single format to minimize confusion. Hopefully, there are no humans named "Ietf" or, at least, none of them wants to auto-post individual drafts.

o 该工具集将“WGN草稿”定义为名称以“草稿ietf-”开头的草稿。所有其他汇票均视为单独汇票。目前,IETF工作组不必遵循单一的工作组草案命名格式。因此,工作组认为是工作组草案的草案的00版本可以在没有工作组同意的情况下由工具集发布。受影响的工作组必须处理其决定不使用通用命名格式的后果。工具团队建议IETF要求工作组使用单一格式命名其草稿,以尽量减少混淆。希望没有人叫“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 对于某些草稿,该工具集验证提交人是否“预期”(例如,先前草稿版本的作者或工作组主席)。目前,秘书处几乎不进行这种核查,但电子邮件提交界面和提交循环中的人员存在显然足以防止大规模自动攻击。需要进行更改,以防止简单脚本使用web界面用垃圾邮件覆盖已发布的IETF草稿。希望IETF最终会有一个像样的身份验证方案,使提交者检查更简单、更不严格、更透明。

o The Toolset will automatically notify authors of posted drafts. Currently, neither the submitter nor any of the co-authors are explicitly notified when the draft is posted. Notification is meant, in part, to allow co-authors to detect cases where their name is put on the authors list without permission. Eventually, there will be a general IETF mechanism to allow 3rd parties such as ADs, chairs, or reviewers to register for notifications about draft postings.

o 该工具集将自动通知提交草稿的作者。目前,无论是提交人还是任何合著者都没有在草稿发布时得到明确通知。在某种程度上,通知的意思是允许共同作者发现其姓名未经许可而被列入作者名单的情况。最终,将有一个通用的IETF机制,允许第三方(如广告、主席或评审员)注册关于草稿发布的通知。

o The Toolset may eventually accept compressed drafts (see R150). Currently, the Secretariat does not accept "zip" archives due to virus contamination concerns. A proper implementation of the Toolset must address such concerns, while the Secretariat may still need to reject certain formats if they are submitted via the manual route.

o 该工具集最终可能接受压缩草稿(请参见R150)。目前,由于病毒污染问题,秘书处不接受“zip”档案。工具集的适当实施必须解决这些问题,而秘书处可能仍然需要拒绝通过人工方式提交的某些格式。

Appendix B. Acknowledgements

The author gratefully acknowledges the contributions of Harald Tveit Alvestrand (Cisco), Brian E. Carpenter (IBM), Frank Ellermann, Bill Fenner (AT&T), Barbara B. Fuller (Foretec), Bruce Lilly, Henrik Levkowetz (Ericsson), Larry Masinter (Adobe), Keith Moore (University of Tennessee), Pekka Savola (Netcore), Henning Schulzrinne (Columbia University), and Stanislav Shalunov (Internet2).

作者感谢Harald Tveit Alvestrand(Cisco)、Brian E.Carpenter(IBM)、Frank Ellermann、Bill Fenner(AT&T)、Barbara B.Fuller(Foretec)、Bruce Lilly、Henrik Levkowetz(爱立信)、Larry Masinter(Adobe)、Keith Moore(田纳西大学)、Pekka Savola(Netcore)、Henning Schulzrinne的贡献(哥伦比亚大学)和Stanislav Shalunov(互联网2)。

Special thanks to Marshall Rose for his xml2rfc tool.

特别感谢Marshall Rose提供的xml2rfc工具。

Normative References


[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.

[RFC2629]Rose,M.,“使用XML编写I-D和RFC”,RFC 26292999年6月。

[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.

[RFC3978]Bradner,S.,“IETF在贡献中的权利”,BCP 78,RFC 3978,2005年3月。

[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.

[RFC3979]Bradner,S.,“IETF技术中的知识产权”,BCP 79,RFC 3979,2005年3月。

[XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998,

[XML]万维网联盟,“可扩展标记语言(XML)1.0”,W3C XML,1998年2月,

Informative References


[writing-rfcs] Rose, M., "Writing I-Ds and RFCs using XML (revised)", Work in Progress, April 2004.


[secretariat] "Private communication with the IETF Secretariat", 2004.


[OSD] "The Open Source Definition, version 1.9", Open Source Initiative, 2005, available at


Author's Address


Alex Rousskov The Measurement Factory



Full Copyright Statement


Copyright (C) The Internet Society (2005).


This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


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




Funding for the RFC Editor function is currently provided by the Internet Society.