idnits 2.17.1 draft-ietf-tools-draft-submission-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2000. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 12, 2005) is 6917 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Tools team A. Rousskov 3 Internet-Draft The Measurement Factory 4 Expires: November 13, 2005 May 12, 2005 6 Requirements for an IETF Draft Submission Toolset 7 draft-ietf-tools-draft-submission-09 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 13, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document specifies requirements for an IETF toolset to 41 facilitate Internet-Draft submission, validation, and posting. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. State of this draft . . . . . . . . . . . . . . . . . . . . . 3 47 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 4. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4 49 5. Status quo . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 6. Overall Toolset operation . . . . . . . . . . . . . . . . . . 7 51 7. Upload page . . . . . . . . . . . . . . . . . . . . . . . . . 10 52 8. Check action . . . . . . . . . . . . . . . . . . . . . . . . . 10 53 8.1 Preprocessing . . . . . . . . . . . . . . . . . . . . . . 11 54 8.2 Processing . . . . . . . . . . . . . . . . . . . . . . . . 12 55 8.3 Storage . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 8.4 Extraction . . . . . . . . . . . . . . . . . . . . . . . . 12 57 8.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . 14 58 8.5.1 Absolute requirements . . . . . . . . . . . . . . . . 15 59 8.5.2 Desirable features . . . . . . . . . . . . . . . . . . 16 60 8.5.3 DoS thresholds . . . . . . . . . . . . . . . . . . . . 17 61 8.5.4 WG approval . . . . . . . . . . . . . . . . . . . . . 18 62 9. Check page . . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 9.1 External meta-data . . . . . . . . . . . . . . . . . . . . 19 64 10. Post Now action . . . . . . . . . . . . . . . . . . . . . . 21 65 10.1 Receipt page . . . . . . . . . . . . . . . . . . . . . . . 21 66 11. Adjust action . . . . . . . . . . . . . . . . . . . . . . . 22 67 12. Adjust page . . . . . . . . . . . . . . . . . . . . . . . . 22 68 13. Post Manually action . . . . . . . . . . . . . . . . . . . . 22 69 14. Receipt page . . . . . . . . . . . . . . . . . . . . . . . . 23 70 15. Bypassing the Toolset . . . . . . . . . . . . . . . . . . . 23 71 16. Email interface . . . . . . . . . . . . . . . . . . . . . . 24 72 17. Implementation stages . . . . . . . . . . . . . . . . . . . 26 73 18. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 19. Security Considerations . . . . . . . . . . . . . . . . . . 27 75 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 76 21. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 A. Comparison with current procedures . . . . . . . . . . . . . . 28 78 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 79 C. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 30 80 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 81 22.1 Normative References . . . . . . . . . . . . . . . . . . . 41 82 22.2 Informative References . . . . . . . . . . . . . . . . . . 42 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 42 84 Intellectual Property and Copyright Statements . . . . . . . . 43 86 1. Introduction 88 Public Internet-Drafts are the primary means of structured 89 communication within the IETF. Current Internet-Draft submission and 90 posting mechanisms hinder efficient and timely communication while 91 creating an unnecessary load on the IETF Secretariat. The IETF Tools 92 team recommends formalization and automation of the current 93 mechanisms. This document contains specific automation requirements. 95 The IETF Secretariat and many IETF participants have long been 96 proponents of automation. This document attempts to reflect their 97 known needs and wishes, as interpreted by the Tools team. 99 2. State of this draft 101 This draft version attempts to resolve all known issues and address 102 all Last Call comments received by 2005/04/12 as well as AD comments 103 received after the Last Call. The Tools team expects IESG to review 104 this version. 106 If you decide to review the draft at this late stage, please limit 107 your comments to critical issues. Please check the Change log in 108 Appendix C before proposing changes as it is possible that your idea 109 has already been discussed. Please post comments on the 110 tools-discuss@ietf.org mailing list or email them directly to the 111 author. 113 RFC Editor Note: Please remove this section for the final publication 114 of the document. It has been inspired by 115 draft-rousskov-newtrk-id-state and related NEWTRK WG discussions. 117 3. Scope 119 The Draft Submission Toolset discussed in this document is about 120 getting a single new version of an Internet-Draft from an IETF 121 participant to the IETF draft repository. A single draft version may 122 include several formats, and dealing with those formats is in scope 123 for the Toolset. Definition and sources of draft meta-information 124 (to be used in Secretariat databases and elsewhere) are in scope. 125 Submitter authentication and submission authorization are in scope. 127 Draft posting may result in various notifications sent to interested 128 parties. While this document recommends a subset of notification 129 targets, details of notifications are out of scope. 131 Creation of new drafts or new draft versions as well as manipulation, 132 visualization, and interaction with the drafts already in the 133 repository are out of scope. Draft expiration and archiving of old 134 draft versions are out of scope. 136 The set of requirements in this document is not meant to be 137 comprehensive or final. Other IETF documents or procedures may 138 require additional functionality from the Toolset. For example, it 139 is possible that the Toolset will be required to handle draft source 140 formats other than plain text and XML. 142 4. Notation and Terminology 144 The following terms are to be interpreted according to their 145 definitions below. 147 posted draft: A draft accepted into the public IETF draft repository 148 and, hence, publicly available from the IETF web site. Posting of 149 a draft does not imply any IETF or IESG review and endorsement. 151 draft version: A meant-to-be-public snapshot of an Internet-Draft 152 with a meant-to-be-unique version number. Also known as "draft 153 revision". 155 draft format: Any draft source or presentation format, including 156 original and preprocessed XML, original or generated plain text as 157 well as PDF, PostScript, and HTML formats. 159 primary draft format: The first available draft format from the 160 following list: plain text, PDF, PostScript, or XML. 162 WG-named draft: A draft for which identifier (a.k.a. filename) is 163 known and starts with "draft-SPECIAL-", where SPECIAL is one of 164 the following strings: "ietf", "iab", "iesg", "rfc-editor", or 165 "irtf". Abbreviated as "WGN draft". Exceptions notwithstanding, 166 WG-named drafts are usually controlled by IETF working groups or 167 similar IETF-related bodies (and vice versa). The handling of 168 such naming exceptions is outside of this document scope. 170 individual draft: A draft other than a WGN draft. 172 submitter: A human or software agent initiating submission of an 173 Internet-Draft version for validation or posting. In some cases, 174 the Secretariat staff does the actual submission, but always on 175 behalf of a submitter. In some cases (including but not limited 176 to malicious attacks), the submitter is not the draft author. 178 expected submitter: A submitter that is authorized by IETF rules to 179 post a given draft. This includes a draft author or editor 180 (listed in the draft text), a corresponding WG Chair, or an IESG 181 member. 183 authorized submitter: An expected submitter authenticated by the 184 Toolset. Authentication is initially limited to verifying 185 submitter access to submitter's email address. 187 immediately: Without human interaction or artificial software delays 188 and within a few seconds. 190 The Toolset is specified using a set of normative requirements. 191 These requirements are English phrases ending with an "(Rnnn/s)" 192 indication, where "nnn" is a unique requirement number, and "s" is a 193 single letter code ("a", "b", or "c") specifying the implementation 194 stage for the requirement. Implementation stages are documented in 195 Section 17. 197 This document specifies the interface and functionality of the 198 Toolset, not the details of a Toolset implementation. However, 199 implementation hints or examples are often useful. To avoid mixup 200 with Toolset requirements, such hints and examples are often marked 201 with a "Hint:" prefix. Implementation hints do not carry any 202 normative force, and a different implementation may be the best 203 choice. 205 5. Status quo 207 This section summarizes the process for draft submission and posting 208 as it exists at the time of writing. 210 To get an Internet-Draft posted on the IETF web site, an IETF 211 participant emails the draft text to the IETF Secretariat, along with 212 an informal note asking the Secretariat to post the draft. 213 Secretariat staff reads the note, reviews the draft according to a 214 checklist, and then approves or rejects the submission. Draft 215 approval triggers the corresponding announcement to be sent to 216 appropriate IETF mailing lists. Every 4 hours, approved drafts are 217 automatically copied to the IETF drafts repository and become 218 available on the IETF web site. 220 Collectively, IETF participants submit thousands of Internet-Drafts 221 per year (in the year 2000, about three thousand drafts were 222 submitted; 2002: 5k; 2004: 7k [secretariat]). About 30-50% of posted 223 drafts are WG-named drafts (among some 2,100 drafts, there were about 224 380 new and 290 updated WGN drafts posted in 2003). While no 225 rejection statistics is available, the vast majority of submitted 226 drafts are approved by the Secretariat for posting. 228 It usually takes the Secretariat a few minutes to review a given 229 draft. However, since the Secretariat staff does not work 24/7, does 230 not work in all time zones, has other responsibilities, and since 231 approved drafts are posted in batches every 4 hours, it may take from 232 several hours to several days to get a draft posted. Due to much 233 higher demand and fixed processing capacity, postings during the last 234 weeks before IETF face-to-face meetings take much longer, creating a 235 long queue of unprocessed drafts that are then announced nearly 236 simultaneously. 238 To give IETF face-to-face meeting participants time to review 239 relevant documents, the Secretariat does not accept Internet-Draft 240 submissions close to IETF meetings (regardless of whether a draft is 241 relevant to the upcoming meeting or not). 243 Many Working Groups have come up with ad hoc solutions to cope with 244 posting delays. For example, many draft snapshots are "temporarily" 245 published on personal web sites or sent (completely or in part) to 246 the group list. Alternative means of publication may effectively 247 replace official IETF interfaces, with only a few major draft 248 revisions ending up posted on the IETF web site. 250 Informal interfaces for submitting and posting drafts discourage 251 automation. Lack of submission automation increases Secretariat 252 load, complicates automated indexing and cross-referencing of the 253 drafts, and, for some authors, leads to stale drafts not being 254 updated often enough. 256 Beyond a short Secretariat checklist, submitted drafts are not 257 checked for compliance with IETF requirements for archival documents, 258 and submitters are not notified of any violations. As a result, the 259 IESG and RFC Editor may have to spend resources (and delay approval) 260 resolving violations with draft authors. Often, these violations can 261 be detected automatically and would have been fixed by draft authors 262 if the authors knew about them before requesting publication of the 263 draft. 265 Technically, anybody and anything can submit a draft to the 266 Secretariat. There is no reliable authentication mechanism in place. 267 Initial submissions of WGN drafts require WG Chair approval, which 268 can be faked just like the submission request itself. No malicious 269 impersonations or fake approvals have been reported to date however. 271 Lack of authentication is not perceived as a serious problem, 272 possibly because serious falsification are likely to be noticed 273 before serious damage can be done. Due to the informal and manual 274 nature of the submission mechanism, its massive automated abuse is 275 unlikely to cause anything but a short denial of draft posting 276 service and, hence, is probably not worth defending against. 277 However, future automation may result in a different trade-off. 279 6. Overall Toolset operation 281 This section provides a high-level description for the proposed 282 Toolset. The description is meant to show overall operation and 283 order; please refer to other sections for details specific to each 284 step. 286 A typical submitter goes through a sequence of 2-4 web pages and 287 associated actions. The number of pages depends on the draft 288 validation and meta-data extraction results. For example, validating 289 the draft without posting it requires interacting with two web pages: 290 Upload and Check. The common case of posting a valid draft without 291 manual meta-data adjustments takes three web pages (Upload, Check, 292 Receipt). 294 Here is a brief overview of pages and actions: 296 Upload page: The interface to copy a draft from the submitter's 297 computer to the Toolset staging area (Section 7). Multiple 298 formats are accepted. The draft is sent to the Check action. 300 Check action: Stores the draft in the Toolset staging area, extracts 301 draft meta-data, validates the submission (Section 8). Produces 302 the Check page. 304 Check page: Displays draft interpretation and validation results 305 (Section 9). A draft preview may also be given on this page. 306 After reviewing the draft interpretation and validation results, 307 the submitter has four basic choices (a) auto-post draft "as is" 308 now; (b) make manual corrections and submit the draft to 309 Secretariat for manual posting later; (c) cancel submission; or 310 (d) do nothing. The automated posting option may not be available 311 for drafts with validation errors. 313 Automated posting: If the submitter decides to proceed with automated 314 posting from the Check page, the system authenticates the 315 submitter and may also check whether the submitter is allowed to 316 post the draft. If the submitter is authorized, the draft is 317 immediately posted, deleted from the staging area, and the 318 submitter is notified of the result via email and a Receipt page 319 (Section 10). 321 Manual adjustment and posting: If the submitter decides to adjust the 322 meta-data, the draft remains in the Toolset staging area, and the 323 Adjust action (Section 11) presents the submitter with an Adjust 324 page (Section 12). When the submitter makes the adjustments and 325 proceeds with manual posting, a pointer to the stored draft and 326 its adjusted meta-data is sent to the secretariat for manual 327 processing (Section 13). The submitter is notified of the pending 328 Secretariat request via email and a Receipt page. 330 Cancellation: If the submitter decides to explicitly cancel the 331 submission, the submission state (including the draft) is 332 immediately deleted from the Toolset staging area and an 333 appropriate Receipt page is generated without further actions 334 (R123/a). Cancellation of posted drafts is out of this document 335 scope. 337 Receipt page: Contains details of a successful or failed draft 338 submission and informs the submitter of the next appropriate 339 step(s) related to submission result. 341 The following informal diagram illustrates the basic submission 342 logic: 344 /---> Post Now 345 / 346 Upload --> Check -+-----> Adjust ---> Send to Secretariat 347 \ 348 \---> Cancel 350 If the submitter does nothing while the Toolset is expecting some 351 response, the abandoned submission times out (R124/a). The timeout 352 value depends on the submission state. Hint: A timeout value of one 353 hour is probably large enough unless the Toolset is waiting for some 354 kind of a 3rd party confirmation (e.g., WG chair approval). Doing 355 nothing is functionally equivalent to explicitly canceling the 356 submission, except that explicit cancellation requires immediate 357 removal of submission state while the state of submissions marked as 358 abandoned is garbage-collected. 360 The staging area maintenance algorithms must keep the area in a 361 consistent, correct state in the presence of DoS attacks attempting 362 to overwhelm the area with fake submissions in various stages 363 (R67/a). Hint: denial of service to legitimate users is acceptable 364 under DoS attack conditions, but corruption of the storage area is 365 not. 367 The "web pages" this text is referring to are distinct dialogs, that 368 may be visible to the submitter under the same or different URL, and 369 supported by a single or several server-side programs. 371 The Toolset must handle multiple submitters simultaneously submitting 372 the same draft (R72/a) and a single submitter simultaneously 373 submitting two drafts (R73/a). The latter might happen, for example, 374 when the submitter is using several browser windows to submit several 375 drafts or is submitting drafts via email interface. The term 376 "simultaneously" means that submission processing times overlap. 378 Hint: Except for the Upload page, pages contain a submission session 379 identifier to provide actions with access to stored information. The 380 identifier is specific to the submission rather than the draft 381 version or the submitter. While the nature of the web interface 382 allows the session identifier to be invisible to the submitter, email 383 communication would need to identify the session so that the 384 recipient (and Toolset) know the context. 386 Hint: A single action may correspond to multiple server-side programs 387 and, vice versa, a single program may implement several actions. 388 This document does not mandate any specific technology (e.g., CGI, 389 PHP, and/or Java servlets) to implement server-side support. The 390 implementer experience, code reuse across web and email interfaces, 391 and other factors will determine the right technology choice. 393 Hint: Actions preserve and exchange state by storing it along with 394 the draft. Grouping all submission-specific information in one 395 subdirectory named using the session identifier may increase 396 robustness and simplify debugging. Session creation and destruction 397 can then be logged in a global index. 399 Ways to partially or completely bypass the Toolset are documented in 400 Section 15 402 The Toolset sources should be publicly available (R152/b) under a 403 license certified by the Open Source Initiative [OSI] (R144/a), with 404 an interface to report bugs and request enhancements (R145/b). These 405 requirements are meant to enable the Toolset transfer from one 406 management team to another and to allow for public review and 407 contribution. To meaningfully satisfy these availability 408 requirements, the Toolset has to implement the required functionality 409 without relying on software with different availability conditions. 411 Hint: Placing the Toolset source repository at an open-source- 412 friendly project management site like SourceForge.net would provide 413 the IETF community with a decent, ready-to-use interface to access 414 the code, documentation, bug reports, and discussion forums. 415 Establishing and documenting a simple interface between the Toolset 416 and external software (e.g., the Secretariat draft posting scripts) 417 would facilitate availability checks. 419 The Toolset is meant to be compatible with the Secretariat's tools 420 for handling drafts. Hint: Such compatibility can be achieved by 421 appropriately implementing the Toolset or, in some cases, by 422 modifying existing Secretariat tools. 424 7. Upload page 426 To upload a draft, the submitter goes to a well-known page on the 427 IETF web site (R1/b). There, the draft text can be uploaded using an 428 HTML file upload form. This form provides fields to upload the plain 429 text format of the draft (R2/a) and all other formats allowed by IETF 430 draft publication rules (R3/b). At the time of writing, these 431 formats are: XML ([RFC2629] and [I-D.mrose-writing-rfcs]), PDF, and 432 PostScript. 434 Submitted forms are handled by the Check action documented in 435 Section 8. 437 The Upload page also has a validate-only flag, indicating that an 438 uploaded draft must not be posted and may be deleted immediately 439 after the validation (R74/b). Regardless of the validation results, 440 the stored draft meta-data is marked so that validation-only drafts 441 can be identified and deleted first by garbage collector for the 442 Toolset staging area (R75/b). Drafts uploaded in a validate-only 443 mode cannot be posted (R76/b); they would need to be uploaded again, 444 without the validate-only flag, and the validation results page 445 should explain that (R77/b). This flag is useful for tools using 446 online validation, especially for bulk draft processing. Hint: it 447 may be better to implement this flag as a hidden HTML input field to 448 simplify the interface for human submitters. 450 8. Check action 452 The Check action preprocesses a submission, generates plain text 453 format (if needed, see R70), stores the submitted draft (all formats) 454 in the staging area, and then extracts meta-data and validates each 455 format (R6/a). Errors and warnings are indicated to the submitter in 456 the response via computer-friendly tag(s) and human-friendly text 457 (R7/a). 459 If any error is found, automated posting becomes impossible (R113/a). 460 This rule applies to all errors, even those that do not refer to R113 461 and do not explicitly prohibit automated posting. If automated 462 posting is not possible, the Toolset still gives the submitter an 463 option of sending the draft for manual validation and posting 464 (R114/a). Since each submission is treated in isolation, the 465 submitter also has an option of correcting the problem and 466 resubmitting the draft for automated posting. 468 The manual validation and posting route is a Toolset bypass mechanism 469 (see Section 15) not meant for fixing problems with the draft itself. 470 The Secretariat does not generally correct submitted drafts. If the 471 draft needs tweaking to match submitter's intent, then the draft 472 should be corrected by the submitter and resubmitted. 474 It is an error to submit a draft which has neither plain text nor XML 475 source format (R68/a). XML source is acceptable without accompanying 476 plain text only if the Toolset successfully generates a draft in 477 plain text format from the XML source, as a part of the processing 478 step documented below (R69/b). These rules imply that PDF- or 479 PostScript-only drafts cannot be auto-posted. Moreover, even manual 480 Secretariat involvement cannot help with posting these drafts, as the 481 IETF policy is to always require a plain text format in addition to 482 PDF or PostScript. Furthermore, drafts containing PDF or Postscript 483 format must not be auto-posted until the Toolset can validate that 484 their content matches the plain text format (R143/a). 486 The draft format acceptance rules above are meant to decrease the 487 chances that multiple posted draft formats for a single draft contain 488 substantially different documents. With experience, the rules may be 489 simplified so that, for example, only submissions containing nothing 490 but XML or plain text sources can be posted without Secretariat 491 involvement and all other submissions require manual actions to match 492 formats or extract meta-data. 494 8.1 Preprocessing 496 Submitting compressed drafts is a desirable feature, especially for 497 submitters behind slow or content-altering links. Compressed draft 498 formats may be accepted (R150/c). Compressed formats, if any, must 499 be decompressed during the preprocessing step (R151/c) so that other 500 processors do not have to deal with compressed formats. Hint: While 501 this specification does not document a list of supported compression 502 standards, it is expected that such popular methods as "zip" and 503 "gzip" should be accepted if compression is supported. Accepting a 504 collection of draft formats within a single compressed archive may 505 also be desirable. 507 XML source containing XML processor instructions 508 (PIs) is preprocessed to include references (R8/b). This step is 509 needed to remove external dependencies from XML sources and to 510 simplify tools processing posted XML. This document refers to such 511 XML processor instructions as "include PIs". 513 The XML preprocessor uses public database(s) to resolve PI references 514 (R85/b). The Toolset documentation specifies what databases are used 515 and how PIs are mapped to database entries (R86/b). The Toolset must 516 not rely on PIs existence (R87/b) because some XML sources will be 517 preprocessed before the submission or will be written without PIs. 518 Hint: Local up-to-date copies of Marshall Rose's reference databases 519 at xml.resource.org can be used. 521 Both original and preprocessed XML sources may be posted later. The 522 original source with include PIs may be useful to the RFC Editor and 523 generation of diffs (against future or past original sources). The 524 preprocessed source without include PIs becomes the default public 525 XML source of the posted draft (R10/b). If any of the include PIs 526 known to the Toolset cannot be handled, an error is recorded (R11/b), 527 and the submitter is encouraged to do the preprocessing locally, 528 before submitting the draft (R111/b). 530 Uncompressed draft formats other than XML are not preprocessed. 532 8.2 Processing 534 When no plain text format of the draft is submitted, but XML sources 535 are available, the Toolset attempts to generate plain text format 536 from submitted XML sources (R70/b). 538 If XML sources are available, the Toolset generates HTML draft format 539 (R112/c). HTML generation failures should result in warnings, not 540 errors (R115/c). HTML generation is not meant to be implemented 541 until the Enhancement stage is reached (R130/a). In general, HTML 542 generation is desirable because HTML drafts are usually easier to 543 navigate than plain text drafts due to improved overall readability 544 and links. As any Enhancement Stage feature, HTML generation may be 545 dropped or drastically changed to reflect then-current IETF consensus 546 and the experience of the first two implementation stages. 548 Hint: The Toolset implementers should not assume that draft formats 549 generated by the same tool from the same source format have 550 essentially the same content. The generation tool may have options 551 that allow authors to generate content exclusive to a specific 552 generated format. Such options might be abused. 554 8.3 Storage 556 The Check action needs to store all draft formats so that 557 successfully validated drafts can later be auto-posted at submitter 558 request. The action stores all submitted formats of the draft in a 559 staging area dedicated to the Toolset (R12/a). If, after garbage 560 collection, the staging area is full (i.e., the total used size has 561 reached the configured maximum capacity), the submitter and the 562 Secretariat are notified of a fatal error (R13/a). 564 8.4 Extraction 566 The Toolset extracts meta-data from the following stored draft 567 formats: plain text (R131/a), XML (R132/b), and other (R133/c). If a 568 meta-data extraction fails, the Toolset records an error (R15/a). 570 Meta-data extraction is necessary to validate and post the draft. 571 Extraction from all formats is necessary to validate that all meta- 572 data matches across all formats (in addition to and before the 573 Toolset can validate that the contents matches as well). 575 Section 17 documents a non-obvious implementation schedule related to 576 the above requirements. When only partial support for format 577 interpretation is available, only interpreted formats are subject to 578 extraction and validation requirements. In other words, if the 579 Toolset does not yet support interpretation of a given format, then 580 the corresponding information is stored and made available "as is", 581 regardless of the actual content. 583 The draft interpreter extracts the following meta-data from each 584 draft format (R16/a): 586 identifier: Also known as draft "filename". For example, 587 draft-ietf-sieve-vacation-13 . 589 version: A non-negative integer number representing draft version 590 number (also known as draft revision number). For example, the 591 number seven in draft-ietf-sieve-vacation-07. The number is 592 usually rendered using two digits, padding with "0" if necessary. 594 name: The common part of all draft identifiers for all versions of 595 the same draft. In other words, a draft identifier without the 596 version component. For example, draft-ietf-sieve-vacation in 597 draft-ietf-sieve-vacation-07. 599 WG ID: Working Group identifier. For example, "sieve" in 600 "draft-ietf-sieve-vacation-07" is a WG ID. The WG ID value is 601 empty for drafts that are not WG-named drafts. 603 WG flag: True for WGN drafts and false for all other drafts. For 604 example, "true" for "draft-ietf-sieve-vacation-13". This flag 605 only influences the further handling of initial (version 00) draft 606 submissions, as far as the current document is concerned. 608 title: A human-friendly draft title. For example, the title of this 609 document is "Requirements for an IETF Draft Submission Toolset" 611 authors: A list of all draft authors. For each author, their name 612 and email address are extracted. 614 abstract: The draft abstract text. 616 creation date: The draft version creation date. 618 expiration date: The draft version expiration date. 620 size: The number of pages and octets in the primary format of the 621 draft. The definition of a page depends on the format and may be 622 imprecise or arbitrary for some formats. 624 Failure to extract any field results in error (R95/a). 626 The Toolset requires author email addresses because they are 627 essential for notifying co-authors that their draft has been posted. 628 If there are no such notifications, a submitter adding a co-author to 629 the draft without the co-author's consent may not be caught for a 630 while. Such "surprise" co-authorships have happened in the past and 631 can be quite annoying. However, since the Toolset does not solicit 632 co-authors' consent to post a valid draft (and such solicitation 633 would not go beyond email control verification anyway), it is not 634 possible to stop a malicious submitter from adding co-authors without 635 their knowledge. 637 Like other meta-data items above, draft creation and expiration dates 638 are extracted from the draft; their values do not depend on the 639 actual submission time (i.e., the time the Check action starts). 640 However, the validation procedure (see Section 8.5) may declare any 641 extracted date invalid after taking into consideration current (i.e., 642 submission) time, IETF draft expiration rules, and other factors 643 external to the draft. 645 8.5 Validation 647 Drafts need to be validated to catch broken submissions. Validation 648 also helps educate or warn authors of problems that may become show- 649 stoppers when the draft is sent for IETF Last Call and IESG review. 650 IETF standards have to follow a set of syntax and semantics 651 requirements (see the "ID-NITS" document at 652 . Most of those requirements 653 are not enforced for Internet-Drafts. However, following them may 654 improve draft quality, reduce the IESG load, and increase the chances 655 of the draft being approved as an RFC. 657 When validating a given draft, it is important to distinguish between 658 absolute requirements and desirable draft properties. Both 659 categories are checked for, but violations have different effects 660 depending on the category. The two categories are detailed in the 661 following subsections. 663 When a valid draft is being posted and submitter authorization or co- 664 author notification is performed, validation results should be 665 included in the email (R81/b) so that the submitter can see meta-data 666 extraction and validation warnings. Note that these results cannot 667 include errors since only valid drafts can be posted. 669 8.5.1 Absolute requirements 671 Violating any of these requirements would prevent a draft to be 672 automatically posted (R17/a). The offending draft would have to be 673 fixed or submitted for manual posting, with an explanation why the 674 absolute requirements need to be violated (or why the Validator mis- 675 detected violations). These explanations may speed up Secretariat 676 posting decision and may help Secretariat to improve the Toolset 677 implementation. 679 1. All available meta-data entries must match across all submitted 680 draft formats (R18/a). For example, if the interpreter managed 681 to extract a draft title from both the plain text and the PDF 682 format, both titles must match. This requirement prevents 683 accidental submission of mismatching formats. 685 2. Version 00 of a Working Group draft has a corresponding Working 686 Group approval (R20/a). This approval can be relayed before or 687 after the first draft submission, by a Chair or Secretary of the 688 WG. See Section 8.5.4 for related requirements. 690 3. The draft ID must be correct (R22/a), including the draft version 691 number value and format. Single-digit draft version numbers must 692 be left-padded with "0". Draft version numbers must start with 693 zero and increase by one with every new version. To satisfy this 694 requirement, the Toolset would have to consult the repository of 695 already posted drafts, including expired ones. If the IETF 696 infrastructure cannot handle version numbers greater than 99, the 697 Toolset must reject them (R158/a). 699 4. An IETF IPR Statement and other boilerplate required for drafts 700 according to [RFC3978] and [RFC3979] (or successors) must appear 701 in the draft text (R23/a). 703 5. The extracted creation date of the draft version must be within 3 704 days of the actual submission date (R159/a). Hint: Implementers 705 should be careful to handle creation dates that appear to be in 706 the past or in the future, due to possible time zone differences. 707 Making the most forgiving/permissive assumption about the time 708 zone should suffice. 710 6. The draft version expiration date obeys IETF draft expiration 711 rules. 713 7. No IETF submission blackout period applies. Hint: IETF 714 blackouts must be enforced based on submission time, not possible 715 draft creation time. 717 8. Posting the draft must not result in any Denial of Service (DoS) 718 attack threshold to be crossed (R97/a). Specific thresholds are 719 documented in Section 8.5.3. 721 9. XML sources (if available) are valid with respect to the XML 722 format [XML] (R153/c) and XML Document Type Definition (DTD) for 723 IETF drafts (R154/c). Note that during the first two 724 implementation stages, the corresponding validation failures 725 result in warnings and not errors (see Section 8.5.2). 727 The XML DTD for IETF drafts is documented in [RFC2629] with recent 728 changes available in [I-D.mrose-writing-rfcs]. Hint: Bill Fenner's 729 "RFC 2629 validator" at 730 http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ (or its derivative) 731 may be useful for XML format and DTD validation. 733 Hint: If the extracted meta-data differs in the submitted draft 734 formats, the Toolset should use the meta-data from the most "formal" 735 format when populating the form entries for manual submission. On 736 the other hand, if most extracted entries come from a less "formal" 737 format, the Toolset may choose that format instead. For example, XML 738 source can be considered more "formal" than plain text format. The 739 Toolset may also offer the submitter an option to specify which 740 format should be used for populating the form. It is probably a bad 741 idea to mix-and-match the conflicting entries extracted from multiple 742 formats. Instead, either one format should be chosen when populating 743 the form or the form should contain several meta-data sections, one 744 for each format. The error messages will contain the exact mismatch 745 information. 747 Hint: The Toolset should accept dates without the day of the month, 748 as long as IETF rules do not prohibit them. The Toolset should make 749 the most forgiving/permissive assumption about the actual day of the 750 month when validating day-less dates. 752 8.5.2 Desirable features 754 Violating any of the following requirements does not prevent the 755 submitter from auto-posting the draft (R24/a) but results in a 756 warning (R160/a). Each warning explains the corresponding violation 757 and provides advice on how to comply (R161/b). Hint: To ease 758 maintenance and encourage 3rd party updates, detailed explanations 759 and/or advice may be available as a resource separate from the 760 Toolset. 762 1. All automatically testable nits in the "ID-NITS" document at 763 (R116/b) and 764 automatically testable guidelines at 765 (R157/b). The 766 Toolset should use external tools to check these nits and 767 guidelines rather than embed checking code (R117/a). Hint: 768 Henrik Levkowetz' idnits tool can be used 769 (http://ietf.levkowetz.com/tools/idnits/) and other tools can be 770 written or adopted. 772 2. New draft versions are expected (R21/b). For example, version 00 773 of an individual draft is always expected, while posting a new 774 version of a draft already under the IESG review should generate 775 a warning. 777 3. If both XML and plain text formats are submitted, the submitted 778 plain text matches what can be generated based on submitted XML 779 (R146/b). 781 4. The previous version, if any, was posted at least 24 hours ago 782 (R96/b). This warning may prevent some human errors, especially 783 when multiple authors may post the same draft. 785 5. XML sources (if available) are valid with respect to the XML 786 format (R155/b) and XML DTD for IETF drafts (R156/b). These 787 requirements become absolute after the second implementation 788 phase. See Section 8.5.1 for related information. 790 When comparing generated and submitted plain text formats to satisfy 791 R146, a standard word-based diff is sufficient for initial Toolset 792 implementations (R147/b). However, a custom fuzzy matching function 793 can be developed (R148/c) to minimize false warnings due to, for 794 example, draft text formatting differences. When differences are 795 detected, a complete diff may be provided on a separate page 796 (R149/c), in addition to the warning. 798 Hint: When comparing generated and submitted plain text formats, the 799 Toolset may try several recent xml2rfc versions for plain text 800 generation, to eliminate warnings due to differences among xml2rfc 801 versions. 803 8.5.3 DoS thresholds 805 The following table documents DoS attack thresholds for various draft 806 categories. Daily limits correspond to all drafts (and all draft 807 formats) within the category. Other thresholds may be introduced and 808 these initial thresholds may be adjusted as necessary. The 809 thresholds are likely to become more smart/dynamic with experience. 811 DoS attack thresholds: 813 +----------------------------------------+--------------+-----------+ 814 | category | versions/day | MB/day | 815 +----------------------------------------+--------------+-----------+ 816 | drafts with the same draft name | 3 | 5 | 817 | drafts with the same submitter | 10 | 15 | 818 | WGN drafts with the same WG ID | 30 | 45 | 819 | all drafts | 400 | 200 | 820 +----------------------------------------+--------------+-----------+ 822 The thresholds are meant to limit destructive effects of DoS attacks 823 (e.g., full disks cause other tasks to fail), allow for capacity 824 planning (e.g., how much storage space the Toolset needs), and limit 825 annoying side-effects of "too many" drafts being posted (e.g., when a 826 person receives posting notifications about a given draft or a given 827 working group). The Toolset should warn the Secretariat if total 828 submissions are approaching any threshold (R134/b). Hint: Bandwidth 829 available for submissions may need to be throttled (on a network 830 subnet basis?) to make reaching the daily size quota (with malicious 831 intent) difficult. 833 8.5.4 WG approval 835 For version 00 of a WGN draft, the Toolset checks for an existing WG 836 approval (R125/a). If (a) no approval exists, and (b) the Toolset 837 does not support the "waiting for WG approval" feature, the Toolset 838 records an error (R135/a). 840 If (a) no approval exists, (b) the Toolset supports the "waiting for 841 WG approval" feature, and (c) the draft cannot be posted even if WG 842 approval is received, then the Toolset records a warning that a WG 843 approval would be required once all errors preventing draft from 844 posting are fixed (R137/b). 846 If (a) no approval exists, (b) the Toolset supports the "waiting for 847 WG approval" feature, and (c) the draft can be posted if WG approval 848 is received, then the Toolset explains the situation to the submitter 849 and asks whether an explicit approval from the WG should be solicited 850 or expected (R126/b). If the approval should be solicited, it is 851 solicited by the software or the submitter. If appropriate, the 852 Toolset puts the submission into a "waiting for WG approval" state 853 until the expected approval is available (R127/b). Otherwise, the 854 Toolset records a "no WG approval is expected" error (R138/b). 856 The details of manual or automated solicitation for WG approval is 857 outside the scope of this document. Hint: Initially, the submitter 858 will be responsible for soliciting a WG Chair approval, but this 859 process should eventually be automated. 861 Details of the approval recording and access interfaces as well as 862 the mechanism to resume the submission upon approval are out of this 863 document scope. 865 9. Check page 867 The Check page, created by the Check action, displays extracted draft 868 meta-data and validation results (R25/a). The purpose of the page is 869 to allow the submitter to verify whether the stored draft and 870 automatically extracted meta-data match the submitter's intent and to 871 be informed of validation problems. 873 Meta-data items specified in Section 8.4 that failed validation 874 checks must be marked specially (rather than silently omitted or 875 ignored) (R26/b). Hint: rendering those items in red, with links to 876 corresponding validation errors or warnings, may force authors to pay 877 attention. 879 Validation messages include both errors and warnings. Each 880 validation message refers to normative document(s) containing the 881 corresponding validation rules (R27/b). 883 The Check page allows the submitter to enter external meta-data 884 (Section 9.1) (R28/a). If validation was successful, an 885 "automatically post the draft now" button is provided (R29/a). 886 Regardless of validation results, "adjust and post manually" and 887 "cancel" buttons are provided (R30/a). 889 The Check page provides a preview of the draft plain text format 890 (R31/a), with a link to see how the entire draft (with all its 891 formats) would look like if posted (R82/b). Hint: the Check page 892 preview should be sufficiently long to let authors detect obvious 893 draft mismatch or misinterpretation errors but short enough to avoid 894 dominating the page. Displaying the first line of the draft through 895 the last line of the abstract may be sufficient. 897 For draft updates, the Check page reports the time and the submitter 898 of the last update (R83/b). This information is especially useful 899 when multiple authors are working on the same draft. The page also 900 provides a link to generate a diff against the last posted version 901 (R84/c). 903 9.1 External meta-data 905 The Check page solicits the following meta-data from the submitter. 906 This information must be supplied by submitter because it cannot be 907 extracted from the draft: 909 Submitter email address (R32/a). When submitter is not an 910 expected submitter (see Section 4), automated posting is not 911 possible and the draft has to go through the Secretariat (R98). 912 Hint: A set of checkboxes next to extracted author names along 913 with a "none of the above" checkbox with an input field would 914 suffice. 916 A list of drafts replaced by this draft (R33/c). This is useful 917 to make replaced drafts invisible. This document does not specify 918 any actions necessary to actually replace an existing draft 919 because existing draft manipulation is out of scope, and because 920 security concerns and other complications of such actions would be 921 better addressed by a separate specification. 923 Primary email address for discussion of this draft (R71/b). Hint: 924 The Toolset can suggest the WG mailing list address for WGN 925 drafts, (submitting) author address for individual drafts, or even 926 the first email address in draft text. Offering a few likely 927 addresses instead of relying exclusively on user input would also 928 reduce the number of typos. 930 Except for the submitter email address, external meta-data is 931 optional (R109/a). 933 If a given submitter email address belongs to an expected submitter 934 (i.e., belongs to one of the categories below), the Toolset performs 935 submitter authentication during a Post Now action (R19/a). 936 Otherwise, an error is reported (R118/a). 938 The following possible expected submitters are identified by the 939 Toolset, without any Secretariat intervention: 941 For version 00 of a draft, any submitter (R119/a). 943 For version N+1 of a draft, an author of version N of the same 944 draft (R120/a). This requirement only needs to be satisfied for 945 drafts for which Nth version was posted using the Toolset; other 946 drafts may not have the meta-information available which is 947 required to reliably get a list of authors. 949 For a WGN draft, a Chair of the corresponding WG (R121/b). 951 For any draft, an IESG member (R122/c). 953 10. Post Now action 955 The Post Now action checks that the draft has been successfully 956 validated (R34/a), validates external meta-data (including submitter 957 email address) (R35/a), and posts the draft (R36/a). The submitter 958 is notified of the action progress and the final result (R37/a). 960 The external meta-data contains the submitter's email address. As a 961 part of the validation procedure, the Post Now action authorizes the 962 submitter. The initial action implementation checks that the 963 submitter has access to email sent to that address (R38/a). 964 Eventually, the Toolset should accept client certificates signed by 965 IETF, PGP-signed email, and/or other forms of client-side 966 authentication to eliminate the weak and annoying email access check 967 (R110/c). If submitter authentication fails, the submission 968 eventually and silently times out (R39/a). 970 The Toolset provides both web (R99/a) and email (R139/b) interfaces 971 for confirming email access. Hint: To check submitter's access to 972 email, the tool can email a hard-to-guess cookie or token to the 973 submitter's address. To continue with the submission, the submitter 974 is requested to paste the cookie at the specified URL, go to the 975 token-holding URL, or respond to the email. 977 Immediately after sending an email to the submitter, the The Post Now 978 action generates an intermediate Receipt page that explains Toolset 979 expectations and provides the submitter with the submission ID 980 (R100/a). That number allows the Secretariat to troubleshoot stuck 981 submissions (R101/a) and can also be used for checking submission 982 status without Secretariat involvement (R140/b). 984 Immediately after posting the draft, the Toolset notifies all authors 985 (with known email addresses) of the posting (R102/a). The 986 notification email contains the information available on the 987 "successful posting" Receipt page described below (R103/a). 989 If draft posting is successful, the submission state is marked as 990 available for deletion (R105/a) so that the garbage collection 991 routine eventually deletes it. 993 10.1 Receipt page 995 A successful Post Now action reports at least the following 996 information on the final Receipt page (R104/a): 998 o the draft ID and a link to the draft status page; 999 o the draft title, authors, and abstract; 1001 o the submission ID 1003 o a link to the draft submission status page (when status queries 1004 are supported, see R140). 1006 o the submitter's name and email address. 1008 The primary purpose of the Receipt page is to inform all draft 1009 authors that (supposedly) their draft has been posted. The secondary 1010 purpose is to let authors create a permanent record of the event and 1011 troubleshoot postings. The same information should be sent to other 1012 parties interested in the draft (e.g., to the WG mailing list), but 1013 3rd party notification specifics are out of this document's scope. 1015 11. Adjust action 1017 The Adjust action generates the Adjust page (R40/a), populating it 1018 with available extracted meta-data and external meta-data, as well as 1019 validation results and a preview. Some information may be missing, 1020 depending on draft interpretation and the success of preview 1021 generation. 1023 12. Adjust page 1025 The Adjust page includes the same information as the Check page, but 1026 allows the submitter to adjust all extracted draft meta-data (and, 1027 naturally, external meta-data) at will (R41/a). Such adjustment is 1028 necessary when automated extraction failed to extract correct 1029 information. To avoid any mismatch between draft and its meta-data, 1030 adjusted drafts cannot be automatically posted and require manual 1031 validation by the Secretariat (R42/a). Secretariat staff can post 1032 drafts with adjusted meta-data as described in Section 15. 1034 The Adjust page allows the submitter to enter an informal comment 1035 explaining why adjustments are necessary and automated posting mode 1036 cannot be used (R48/a). Such comments may be essential for the 1037 Secretariat in their efforts to troubleshoot the problem. 1039 The "post manually" and "cancel" buttons are provided (R43/a). The 1040 former is backed by the "Post Manually" action (Section 13). 1042 13. Post Manually action 1044 The Post Manually action sends adjusted meta-data and a draft pointer 1045 to the Secretariat for manual validation and posting (R44/a). A 1046 receipt page is generated, instructing the submitter to wait (R45/a). 1048 The Secretariat will notify the submitter once the draft is posted or 1049 rejected. This notification is sent by the Toolset if the 1050 Secretariat is using the Toolset to post the draft (R46/a). 1052 14. Receipt page 1054 The Receipt page is generated by various actions to inform the 1055 submitter of the current submission status and further actions. The 1056 contents of the page is likely to be highly dependent on the action 1057 and state for which receipt is being generated. This section 1058 documents general requirements applicable to all actions and states. 1060 The Receipt page should give the submitter a URI or another 1061 identifier that can be used by Secretariat for manual troubleshooting 1062 of the submission (R63/a). The identifier should be perpetual 1063 (R64/a) even though the associated details are likely to be 1064 eventually lost (e.g., draft submission data and logs are deleted 1065 from the staging area as a part of the garbage collection routine). 1066 Hint: Tools should distinguish old identifiers from invalid ones; 1067 when a given identifier is referring to deleted data, the tools 1068 accepting the identifier should inform their users that the 1069 identified submission is recognized, but the related information has 1070 expired. 1072 The Receipt page should give the submitter a Secretariat point-of- 1073 contact to report submission problems (R65/a). 1075 15. Bypassing the Toolset 1077 A buggy Toolset implementation or unusual circumstances may force a 1078 submitter to submit a draft to the Secretariat for manual processing. 1079 This can be done by choosing the "manual posting" route supported by 1080 the Toolset (R47/a) or, as a last resort, by emailing the draft 1081 directly to Secretariat. In either case, an informal "cover letter" 1082 has to accompany the draft. The letter should explain why the 1083 automated interface cannot be used. 1085 When processing manual submissions, the Secretariat may be able to 1086 use the Toolset. A Manual Check page similar to the default Check 1087 page provides authenticated Secretariat staff with editable meta-data 1088 fields and a "force posting" action (R50/b). The forced posting 1089 action accepts meta-data fields "as is", does not verify submitter 1090 access to email or WG draft authorization, and posts the draft as if 1091 no validation errors were found (R51/b). The Manual Check page 1092 should still contain all the errors and warnings identical to those 1093 seen by ordinary submitters (R106/b) so that the Secretariat knows 1094 what the Toolset is unhappy about (if anything). 1096 Using manual processing may result in significant posting delays. 1097 Generated submission receipts or notifications ought to give the 1098 submitter an expected processing time estimate (R53/a). 1100 The intent of this mode is to provide a way for submitters to bypass 1101 bugs or limitations of the automated mechanisms in order to post an 1102 "unusual" draft or to post a draft under "unusual" circumstances. 1103 One example would be a draft that does not contain standard IETF 1104 boilerplate but has a special IESG permission to post the draft with 1105 the experimental boilerplate. Another example is a draft that fails 1106 automated validation tests due to a validator bug. 1108 The bypass mode is also likely to be used (effectively) by the 1109 majority of submitters during the Trial stage of the Toolset 1110 implementation, when few submitters know about (or are allowed to 1111 use) the Toolset. 1113 16. Email interface 1115 The Toolset should have an email interface for automated posting of 1116 valid drafts (R55/b). While virtually every documented Toolset 1117 functionality can, technically, be implemented behind an email 1118 interface, features other than posting of valid drafts are believed 1119 to be prohibitively awkward to implement or use via email. 1121 The email interface accepts a draft as a set of email part(s) (one 1122 per draft format) (R56/b). For example, the plain text format can be 1123 submitted in the "body" of the email message, while XML source format 1124 can be optionally sent as an "attachment" of the same email message. 1125 Each part can either contain the actual format data (R141/b) or a 1126 single URL pointing to it (R142/c). In the latter case, the Toolset 1127 has to fetch the format data. Details of URL-fetching option are not 1128 documented here, but it is assumed that HTTP URLs are supported (at 1129 least), and fetching errors are reported. This document does not 1130 specify how the format of each email part is determined, but it is 1131 assumed that MIME type and content would need to be analyzed. 1133 After accepting the draft, the Toolset uses the sender's email 1134 address to select the submitter identity (R57/b), checks the 1135 submission (R58/b), and posts the draft if the check is successful 1136 (R59/b). The submitter should be notified of the outcome of the 1137 draft submission via email (R60/b). Other requirements for the web 1138 interface (including requirements on submission preprocessing, draft 1139 validation, submitter authentication, draft posting, and 1140 notification) apply to the email interface. 1142 Therefore, a typical successful submission via email interface may 1143 result in the following exchange of messages ("T" is for "Toolset", 1144 "S" is for "submitter", and "A" is for "all authors and submitter"): 1146 S-->T: the draft version 1148 S<--T: a challenge to verify email access 1150 S-->T: a response to the challenge 1152 A<--T: warnings and the receipt 1154 where the message containing the challenge may include warnings as 1155 well. 1157 When draft validation fails, the following emails may be exchanged: 1159 S-->T: the draft version 1161 S<--T: errors and receipt 1163 Email parts/attachments that are not recognized as draft formats are 1164 not considered as draft formats. Such parts are ignored by the 1165 Toolset (R107/b), except that a warning is generated for each 1166 unrecognizable part containing more than whitespace (R108/b). These 1167 two requirements are meant to make the interface robust in the 1168 presence of email signatures and other parts outside of the submitter 1169 control. 1171 Hint: Toolset actions can be implemented to support email and web 1172 interfaces without code duplication. 1174 While both web and email interfaces allow for fast posting of valid 1175 drafts, there are significant differences between the two interfaces. 1176 Primary advantages of the email interface are: 1178 off-line mode: A submitter can do all the manual work required to 1179 submit a draft while being disconnected from the network. The 1180 email client actually submits the draft when connectivity is 1181 regained. 1183 poor connectivity: Email systems are often better suited for 1184 automated transmission and re-transmission of emails when network 1185 connectivity is poor due to high packet loss ratios, transmission 1186 delays, and other problems. 1188 convenience: Some IETFers consider email interfaces as generally 1189 "more convenient". 1191 Primary advantages of the web interface are: 1193 confirmation: A submitter is given a chance to verify that automated 1194 extraction of meta-data produced reasonable results. Other useful 1195 confirmations are possible (e.g., "Are you sure you want to post a 1196 version of the draft that was updated 30 seconds ago by your co- 1197 author?"). 1199 validation: A submitter can validate the draft without posting it. 1201 quality: Non-critical warnings may prompt the submitter to postpone 1202 posting to improve draft quality. 1204 manual adjustments: The submitter can adjust extracted meta-data and 1205 ease Secretariat work on manually posting an unusual draft. 1207 meta-data: The submitter can specify optional external meta-data 1208 (that cannot be extracted from the draft itself). For example, an 1209 email address for draft discussion can be specified. 1211 context help: The web interface makes it easy to provide links to 1212 extra information about input fields, errors, posting options, 1213 deadlines, etc. 1215 opaqueness: Files submitted via the web interface are arguably less 1216 susceptible to various in-transit transformations and 1217 misinterpretation than emails. Emails are often mutated by mail 1218 agents (e.g., automated disclaimers added by senders and extra 1219 line feeds added by recipients). 1221 convenience: Some IETFers consider web interfaces as generally "more 1222 convenient". 1224 17. Implementation stages 1226 This section defines the Toolset implementation stages or phases. 1227 There are three consecutive stages, marked with letters "a", "b", or 1228 "c". Earlier stage requirements must still be satisfied in later 1229 stages. All requirements need to be interpreted and evaluated in the 1230 context of the current stage and the currently implemented features. 1231 For example, requirement R68 applies to the first stage but refers to 1232 XML draft format that may not be supported until the second stage. A 1233 correct interpretation of R68 until XML support is added is "it is an 1234 error to submit a draft without a plain text format". 1236 Unless otherwise noted, requirements listed in later stages may be 1237 covered in earlier stages, but do not have to be. If the 1238 implementers decide to add some functionality from a future stage, 1239 they has to be very careful to satisfy all requirements related to 1240 that functionality. Unfortunately, there is no reliable, pragmatic 1241 way to identify "all requirements" related to a given feature. 1243 (a) Trial Stage: Initial basic implementation to test major concepts 1244 and relieve the Secretariat from handling the most common 1245 submission case. This stage focuses on plain text draft 1246 submission via the web interface. The trial stage should take a 1247 dedicated professional about 45 calendar days to finish (i.e., to 1248 comply with all the listed requirements). 1250 (b) Production Stage: Support for all major features. Once this 1251 stage is completed, the Secretariat should only handle unusual 1252 draft submissions. This stage should take about 100 calendar days 1253 to finish. Gradual release of implemented features is possible 1254 and expected. Specifically, the XML support is expected before 1255 email interface support. 1257 (c) Enhancement Stage: A never-ending stage focusing on sophisticated 1258 features (e.g., draft interpretation or validation) that improve 1259 the overall quality of the Toolset. This stage is documented 1260 primarily to highlight the overall direction of the Toolset; its 1261 requirements are often imprecise and many are expected to change. 1263 Implementation experience is likely to result in changes of the 1264 Toolset requirements. Such changes should be documented as a part of 1265 stage evaluation activities. 1267 18. Testing 1269 Before letting the Toolset go live, thousands of posted drafts can be 1270 used to test the meta-data extraction algorithms. Such testing can 1271 minimize the number of drafts being sent on for manual handling 1272 because of meta-data extraction failure. 1274 Other Toolset features may also be testable using posted drafts. A 1275 simple pair of scripts can be used to test basic functionality of the 1276 web and email interfaces. 1278 Hint: The IESG may require test results before accepting the initial 1279 implementation. If automated, the above approach can be used for 1280 regression testing as well. 1282 19. Security Considerations 1284 Removing humans from the draft submission and posting process (a.k.a. 1285 automation) requires adding features to make the Toolset reliable in 1286 the presence of denial of service (DoS) attacks and attempts to 1287 corrupt the draft repository. Ideally, the Toolset needs to resist 1288 both premeditated malicious actions and good-intent accidents. 1290 This document contains specific requirements to minimize the impact 1291 of DoS attacks (e.g., R97). The requirements are designed with the 1292 assumption that it is acceptable for the Toolset to block valid 1293 submissions during a DoS attack as long as the Toolset maintainers 1294 are notified and already posted drafts are not damaged. 1296 This document also contains many specific requirements related to 1297 detection of drafts violating IETF posting rules. Those requirements 1298 help reduce the number of "bad" drafts posted by mistake but do not 1299 offer reliable protection from submitters with malicious intent: 1300 Since automated tools do not truly understand drafts (and will not do 1301 so in the foreseeable future), it is technically possible to post a 1302 rogue draft violating IETF posting rules. For example, a draft may 1303 contain abstract text that makes the IETF-approved IPR statements 1304 following the abstract meaningless or legally non-binding. 1306 Stronger submitter authentication may be required to deter malicious 1307 submitters. The documented authentication mechanism (i.e., read 1308 access to one's email) is deemed appropriate for deployment of the 1309 first versions of the Toolset, under close Secretariat supervision. 1310 Hint: to increase chances of detecting problems early enough, it may 1311 be a good idea to automatically inform a designated human of every 1312 posted submission (during initial deployment of the Toolset). 1314 20. IANA Considerations 1316 None. 1318 21. Compliance 1320 A Toolset implementation is compliant with this specification if it 1321 satisfies all normative requirements (i.e., the phrases marked with 1322 "Rnnn" as defined in Section 4). Compliance should be evaluated for 1323 each implementation stage as some requirements do not apply to some 1324 stages. 1326 The IESG evaluates implementations and interprets requirements as 1327 necessary. 1329 Appendix A. Comparison with current procedures 1331 This section summarizes major differences between the draft 1332 submission approach currently in use by IETF and the proposed 1333 Toolset, including violations of the current IETF rules. 1335 o The Toolset allows posting of XML and PDF draft formats. The XML 1336 format is not currently accepted by the Secretariat, and legality 1337 of PDF acceptance by the Secretariat has been questioned. XML 1338 sources should be accepted to enable IETF tools and participants 1339 to have access to raw draft meta-data and content. They are also 1340 useful to the RFC Editor and, hence, it is a good idea to validate 1341 and get them "into the system" early. The latter argument applies 1342 to PDF drafts as well, although the first Toolset versions are not 1343 expected to interpret PDF drafts. 1345 o The Toolset may eventually generate HTML draft formats from XML 1346 draft sources (see R112). Currently, IETF does not provide HTML 1347 draft formats -- the Secretariat does not accept HTML sources and 1348 no HTML is generated from accepted draft sources. Note, however, 1349 that this document does not suggest that the Toolset should 1350 eventually accept drafts in HTML format. 1352 o The Toolset defines "WGN draft" as a draft which name starts with 1353 "draft-ietf-". All other drafts are treated as individual drafts. 1354 Currently, an IETF WG does not have to follow a single WG draft 1355 naming format. Thus, the 00 version of a draft that the WG 1356 considers a WG draft can be posted by the Toolset without WG 1357 consent. Affected WGs would have to deal with the consequences of 1358 their decision not to use a common naming format. The Tools team 1359 suggests that IETF requires WGs to name their drafts using a 1360 single format to minimize confusion. Hopefully, there are no 1361 humans named "Ietf" or, at least, none of them wants to auto-post 1362 individual drafts. 1364 o For some drafts, the Toolset verifies that the submitter is 1365 "expected" (e.g., an author of the previous draft version or WG 1366 Chair). Currently, the Secretariat does virtually no such 1367 verification, but an email submission interface and a human 1368 presence in the submission loop have apparently been sufficient to 1369 prevent massive automated attacks. The change is needed to 1370 prevent a simple script from using the web interface to overwrite 1371 posted IETF drafts with junk. Hopefully, the IETF will eventually 1372 have a decent authentication scheme making the submitter checks 1373 simpler, less rigid, and more transparent. 1375 o The Toolset will automatically notify authors of posted drafts. 1376 Currently, neither the submitter nor any of the co-authors are 1377 explicitly notified when the draft is posted. Notification is 1378 meant, in part, to allow co-authors to detect cases where their 1379 name is put on the authors list without permission. Eventually, 1380 there will be a general IETF mechanism to allow 3rd parties such 1381 as ADs, chairs, or reviewers to register for notifications about 1382 draft postings. 1384 o The Toolset may eventually accept compressed drafts (see R150). 1385 Currently, the Secretariat does not accept "zip" archives due to 1386 virus contamination concerns. A proper implementation of the 1387 Toolset must address such concerns, while the Secretariat may 1388 still need to reject certain formats if they are submitted via the 1389 manual route. 1391 Appendix B. Acknowledgments 1393 The author gratefully acknowledges the contributions of Harald Tveit 1394 Alvestrand (Cisco), Brian E. Carpenter (IBM), Frank Ellermann, Bill 1395 Fenner (AT&T), Barbara B. Fuller (Foretec), Bruce Lilly, Henrik 1396 Levkowetz (Ericsson), Larry Masinter (Adobe), Keith Moore (University 1397 of Tennessee), Pekka Savola (Netcore), Henning Schulzrinne (Columbia 1398 University), and Stanislav Shalunov (Internet2). 1400 Special thanks to Marshall Rose for his xml2rfc tool. 1402 Appendix C. Change log 1404 RFC Editor Note: This section is to be removed during the final 1405 publication of the document. 1407 Internal WG revision control ID: $Id: id.xml,v 1.39 2005/04/20 1408 04:25:38 rousskov Exp $ 1410 version 09 1412 * Added R157 to check automatically testable guidelines at 1413 (Brian E. 1414 Carpenter) 1416 * Added R158: If the IETF infrastructure cannot handle version 1417 numbers greater than 99, the Toolset must reject them. 1419 * Added R159: The extracted creation date of the draft version 1420 must be within 3 days of the actual submission date. This rule 1421 replaces a less strict and number-less rule requiring the 1422 creation date to be 48 hours or less before the submission 1423 time. 1425 * Added R160 and R161 to clarify that violating "desirable" 1426 validation requirements results in warnings. 1428 * To prevent impersonations, the initial versions of IAB, IESG, 1429 RFC Editor, and IRTF drafts need approval of the corresponding 1430 "IETF-related body", just like WG drafts. To protect those 1431 special bodies, extended the definition of WG-named draft: A 1432 draft for which identifier (a.k.a. filename) is known and 1433 starts with "draft-SPECIAL-", where SPECIAL is one of the 1434 following strings: "ietf", "iab", "iesg", "rfc-editor", or 1435 "irtf". 1437 * Raised DoS thresholds (Brian E. Carpenter) 1439 * Added hints regarding populating forms for manual submission 1440 when extracted meta-data does not match across all supported 1441 draft formats. Most formal (or most complete) format should be 1442 used. One (or all) formats should be used. 1444 * Hinted that The Toolset should accept dates without the day of 1445 the month, as long as IETF rules do not prohibit them. 1447 * Polished WG approval solicitation blob to make it more clear 1448 that the details of manual or automated solicitation for WG 1449 approval is outside the scope of this document. Hinted that 1450 initially, the submitter will be responsible for soliciting a 1451 WG Chair approval, but this process should eventually be 1452 automated. 1454 * Noted that a draft version number is usually rendered using two 1455 digits, padding with "0" if necessary. Explicitly mentioned 1456 that format when talking about "draft ID" validation. 1458 * Noted that XML support is expected before email interface 1459 support. Both are still scheduled for the second stage. We 1460 already note that features may be implemented ahead of the 1461 proposed schedule and that multiple releases for the second 1462 stage are expected. Some folks wanted to move email interface 1463 support to the third stage. While the Tools team may agree 1464 that email interface is not essential, no scheduling changes 1465 were done during this revision because we felt it would go 1466 against the IETF Last Call procedures (the comments came after 1467 the Last Call was closed, and many earlier comments considered 1468 email interface essential). The Tools team encourages the IESG 1469 to review whether email interface support should be moved from 1470 the second to the third stage and would be happy to make those 1471 changes at the IESG request. 1473 * Minor text polishing touches. 1475 version 08 1477 * Clarified that the secretariat does not intend to correct 1478 drafts submitted for manual posting. If the draft needs 1479 tweaking to match submitter's intent, then the draft should be 1480 corrected and re-submitted. 1482 * Renamed "lawful submitter" to "expected submitter" to avoid an 1483 incorrect implication that some kind of new legal checks are 1484 involved. Without an email interface and the Secretariat in 1485 the loop, the submitter must still be "expected" and 1486 authenticated to avoid script kiddies from overwriting posted 1487 IETF drafts with junk. 1489 * Clarified that R68 and other multi-stage requirements with 1490 multi-stage features are to be interpreted by ignoring features 1491 that will be implemented at a later stage. For example, "text 1492 or XML" means just "text" until XML support is added. 1494 * Meta-data extraction: Explicitly explained why meta-data 1495 extraction from all draft formats is necessary. 1497 * Meta-data extraction: be even more explicit that the validation 1498 procedure described in the following section may declare an 1499 extracted date invalid after taking into consideration current 1500 (i.e., submission) time, IETF draft expiration rules, and other 1501 factors external to the draft. The validation section already 1502 has the necessary formal rules. 1504 * Added R152 to require public availability of sources instead of 1505 just hinting at it (Henrik Levkowetz). Explained that to 1506 meaningfully satisfy availability requirements, the Toolset 1507 cannot rely on unavailable software. 1509 * Validation: added R153-R156 to require XML format and RFC 2629+ 1510 DTD validation. During the first two implementation stages 1511 validation failures result in warnings (not fatal submission 1512 errors) to give IETFers (and IETF tools) enough time to get 1513 accustomed to the necessity of obeying XML standards. This 1514 addition documents Tools team consensus reached in December 1515 2004. It should have been documented earlier. 1517 * Polished SourceForge "hosting" hint to clarify that we are 1518 suggesting to place Toolset sources there and not suggesting 1519 that the Toolset runs from SF servers. 1521 * Added Testing section with a hint: use existing drafts (Brian 1522 E. Carpenter) 1524 * Terminology: replaced "WG draft" with "WG-named draft" or "WGN 1525 draft" because not all WG-named drafts are WG drafts and we do 1526 not want to deal with the difference or to answer questions 1527 about the "wrong" terminology. 1529 * Overall operation: explicitly stated that the Toolset has to be 1530 compatible with the Secretariat's tools for handling drafts 1531 with a hint that such compatibility can be achieved by 1532 appropriately implementing the Toolset or, in some cases, by 1533 modifying existing tools. 1535 * Scope: Addressed concern that "there should also be provision 1536 for those who prefer to use troff/nroff" by explicitly stating 1537 that the set of requirements in this document is not 1538 comprehensive and other documents may add more requirements, 1539 including those related to other source formats. The Tools 1540 team in not interested in adding troff/nroff support to the 1541 Toolset, especially in this document. 1543 * Applied Last Call comments by Frank Ellermann. 1545 * Added a hint: The Toolset implementers should not assume that 1546 draft formats generated by the same tool from the same source 1547 format have essentially the same content (Keith Moore). 1549 * Updated Acknowledgments section. 1551 * Did numerous minor language corrections (Henrik Levkowetz). 1553 version 07 1555 * Added R146, a requirement to generate a warning (and, 1556 eventually, a complete diff) when the produced plain text does 1557 not match the submitted one (even if meta-data matches). 1559 * Added a stage-c suggestion R148 to add a smart fuzzy match 1560 function to compare submitted and generated-from-XML texts. 1561 Hinted at using multiple xml2rfc versions to avoid warnings 1562 based on minor xml2rfc differences alone. 1564 * Added R150 to eventually support submission of compressed 1565 drafts (via both web and email interfaces). Noted that the 1566 Secretariat currently does not accept "zip" archives. 1568 * Be explicit that CGI is not somehow mandated for server-side 1569 implementations. The implementor will pick the right 1570 technology given all the factors, including her experience and 1571 available tools (Henning Schulzrinne). 1573 * Added "opaqueness" to the list of web interface advantages, 1574 inspired by the number of folks complaining about their drafts 1575 being mutated by the mail system while in-transit to the draft 1576 archive. 1578 version 06 1580 * Instead of using a special section to map requirements to 1581 Toolset implementation stages, encode the stage with each 1582 requirement. The reader now knows requirement "urgency" when 1583 reading the requirement itself, instead of having to search for 1584 the requirement code in the "Implementation stages" section. 1585 Also, this makes it much easier to make sure that all 1586 requirements are "staged". 1588 * Reflected Tools team concerns about HTML generation by placing 1589 that feature in the Enhancement implementation stage and 1590 explicitly mentioning that the feature may be gone before its 1591 implemented. 1593 * Added R143/a to avoid mismatching formats: Drafts containing 1594 PDF or Postscript format must not be auto-posted until the 1595 Toolset can validate that their content matches plain text 1596 format. Documented rationale and future direction for format 1597 acceptance rules. 1599 * Defined "WG draft" as a draft which name starts with 1600 "draft-ietf-". All other drafts are treated as individual 1601 drafts. 1603 * Support (eventually) fetching draft data using an email- 1604 embedded URL (Stanislav Shalunov). 1606 * Re-Resolved XXX37: support submitting drafts in main email 1607 "body", not just attachments (Stanislav Shalunov). 1609 * Renamed draft submission date into draft version creation date 1610 and documented how creation and expiration dates are validated 1611 and the fact that they do not depend on submission time. 1613 * Required implementation to be open-source (see R144/a). 1615 version 05 1617 * Changed draft status to solicit editorial comments and indicate 1618 close-to-be-last-called state. 1620 * Wrote "Security Considerations" section. 1622 * Refer to ID-NITS document as an list of nits the Toolset should 1623 check for in R116. Hinted that Henrik's idnits tool can be 1624 used for actual checks. More checking tools can be added 1625 eventually. 1627 * Added more submission cancellation details. Covered both 1628 explicit (via submitter action) and implicit (via timeout) 1629 cancellations (Stanislav Shalunov). 1631 * Adjusted "Global" DoS threshold from 500 to 300 and added a 1632 "WG" DoS threshold of 30 draft versions per day (inspired by 1633 Stanislav Shalunov). 1635 * Illustrated what emails may be exchanged when email interface 1636 is in use (Stanislav Shalunov). 1638 * Replaced Validation page with validate-only flag on the Upload 1639 page. This helps avoid multiple well-known locations for 1640 similar tools and might simplify the implementation. 1642 * Resolved XXX12: Simply refer to the ID-NITS document for now. 1644 * Resolved XXX13, XXX14: Placed "lawful submitter" check into the 1645 "External meta-data" section. Documented what submitters the 1646 Toolset has to identify as lawful submitters (R119 - R122). 1647 Others would require manual checks by the Secretariat. 1649 * Resolved XXX58: Documented what the Toolset must do if no 1650 approval exists at the time of the WG draft submission (R123, 1651 R124). 1653 * Removed XXX64: PDF drafts are currently allowed to be posted; 1654 why they are allowed is not really important. 1656 * Resolved XXX66: XML draft sources are currently not allowed to 1657 be posted. 1659 * Resolved XXX68: use draft "version" instead of "revision". 1660 Guidelines to Authors of Internet-Drafts document uses both. 1661 RFC 2026 uses "version", which is also a more popular and 1662 arguably more precise term. 1664 version 04 1666 * In Check action, documented once, early, and explicitly that 1667 errors make auto-posting impossible but should let the 1668 submitter to post manually. Removed references to vague 1669 "action fails" statements (Henrik Levkowetz). 1671 * HTTP error codes should not be used to indicate Check action 1672 errors because doing so would be a layering violation and, in 1673 some cases, may complicate both automated and manual 1674 interpretation of the Toolset responses. Rewrote R7 to require 1675 use of computer-friendly tags in response body instead of HTTP 1676 status codes. 1678 * Split "Preprocessing" subsection into "Preprocessing" and 1679 "Processing". The former deals with XML include PIs while the 1680 latter talks about plain text and HTML generation (Henrik 1681 Levkowetz). 1683 * Removed post-if-valid functionality (R78 - R80). Automation 1684 tools such as the ones that process e-mail-based submissions 1685 would benefit from having the knob, but they cannot use the 1686 Check action "as is", even with the knob, because there are 1687 other differences in the interface (e.g., submitter 1688 identification logic). In other words, more knobs would be 1689 needed, which would defeat the purpose of reusing the same 1690 action. When implementing web and e-mail interfaces, the 1691 Secretariat should still be able to reuse the base action code, 1692 of course. 1694 * Defined compliance. 1696 * Resolved XXX2: inform all authors that their draft was posted. 1697 Documented what information should go into the posting 1698 notification message/page. 1700 * Resolved XXX16 and XXX57: R23 now says that an IETF IPR 1701 Statement and other boilerplate required for drafts according 1702 to RFC 3667 and 3668 (or successors) must appear in the draft 1703 text (Henrik Levkowetz). 1705 * Resolved XXX23 and XXX62: Manual Check page and actions used by 1706 secretariat do not verify submitter access to e-mail. Last 1707 resort option should be as flexible and forgiving as possible. 1709 * Resolved XXX26: it should be possible to respond to do-you- 1710 have-access-to-your-email message by e-mail, in addition to 1711 cut-and-pasting a URL. 1713 * Resolved XXX30 and XXX31: R98 now requires that when submitter 1714 is not an author, Secretariat has to be involved. 1716 * Resolved XXX37: E-mail submissions must use attachments, even 1717 if there is only one draft format. This may help to keep the 1718 Toolset simple (no smarts needed to isolate true draft text 1719 from notes in the beginning of the e-mail and signatures). 1721 * Resolved XXX38: do not require special Subject: lines for 1722 e-mail submission to keep the Toolset simple. Since we verify 1723 submitter access to e-mail, no automated spam is likely to 1724 result in a draft submission. 1726 * Resolved XXX43, XXX44, and XXX60: making an existing draft 1727 obsolete is out of this document scope. This complex feature 1728 can be documented and integrated later to satisfy R33. 1730 * Resolved XXX49 and XXX52: the first two implementation stages 1731 should take 30 and 90 days, provided a single full-time person 1732 effort. 1734 * Resolved XXX50: specify approximate effort required to complete 1735 the first two implementation stages. Let the IESG and the 1736 Secretariat use our estimates to agree on a specific 1737 implementation schedule/deadlines. 1739 * Resolved XXX53: lack of author e-mail causes a warning, not 1740 error. See R95 for rationale. 1742 * Resolved XXX11: added page count and size of primary draft 1743 format to meta-data because this information is useful to some 1744 humans and tools, and because it is usually much easier and 1745 cheaper to get this information in static form (e.g., some 1746 draft meta-data XML file) than compute it dynamically. 1748 * Resolved XXX15: always allow posting of a new revision but warn 1749 if new revision is not expected. Moved the corresponding R21 1750 from absolute to desired requirements. 1752 * Resolved XXX33 and XXX59: prevent DoS attacks (absolute 1753 requirement R97) and warn about too-close submissions (desired 1754 feature R96). 1756 * Defined draft version, format and primary format terms. 1758 2004/10/05 1760 * Resolved XXX9: The Toolset should eventually offer a 1761 Validation-only page. 1763 * Resolved XXX19: The Toolset should eventually provide the 1764 submitter with a way to preview the entire draft, with all 1765 formats. 1767 * Resolved XXX40, XXX41, and XXX56: first use draft name to 1768 extract WG flag and WG name and hope for an IETF policy change. 1769 If IETF policy on naming drafts does not change soon, add code 1770 to query some databases to map individual-looking drafts to WG 1771 names. 1773 * Resolved XXX46 and XXX47: store and make public both original 1774 and preprocessed XML sources. Most tools are likely to use 1775 preprocessed XML format. Humans and some diff tools may prefer 1776 the original. 1778 2004/09/30 1780 * Added requirements R72 and R73 to handle multiple submitters 1781 submitting the same draft and a single submitter submitting two 1782 drafts at the same time, addressing XXX27. 1784 * Resolved XXX7: There seems to be no good reason to support cut- 1785 and-paste mode. Submission via file upload interface should 1786 suffice. 1788 * Semi-resolved XXX53: Toolset should accept PDFs because RFC 1789 Editor does. Still need to check whether the Secretariat 1790 accepts PDFs legally today (XXX64). 1792 2004/09/29 1794 * Clarified and polished the "Scope" section. 1796 * Updated "State of this draft" to document approaching-last-call 1797 state of the draft and to solicit editorial-level feedback. 1799 2004/09/27 1801 * Marked formal toolset requirements using a Rnnn notation to (a) 1802 document implementation schedule, and (b) make compliant 1803 implementation and compliance evaluation easier. 1805 * Marked informal implementation hints with a "Hint:" tag, to 1806 avoid possible confusion with formal requirements. 1808 * Started documenting implementation schedule. For example, only 1809 plain text formats are interpreted during the first stage, then 1810 XML support is added, then other formats. Meanwhile, un- 1811 interpreted formats are accepted and posted as is as long as 1812 plain text version validates. 1814 * Added explicit requirements for managing abandoned submissions 1815 (Brian E. Carpenter) 1817 * Plain text or XML formats are always required (Brian E. 1818 Carpenter) 1820 * Added XXX55: Accepting PDFs is a change of current documented 1821 procedures? (Brian E. Carpenter) 1823 * Added an optional "discussion address" to the external meta- 1824 data to help reviewers know where to send comments (inspired by 1825 Brian E. Carpenter suggestion; Brian wanted this to be a 1826 required extractable meta-data) 1828 * Resolved XXX17, XXX28, and XXX29: Today, -00 WG drafts are 1829 approved by the Chair either before and after submission, 1830 depending on several factors. Based on WG chairs feedback we 1831 still need to support both modes. Thus, there is no policy 1832 change to talk about (and more work for the tool implementors 1833 to support both modes). Still need to add specific toolset 1834 requirements in case there is no approval recorded. 1836 * Resolved XXX18, XXX32, and XXX45: We are going to move "request 1837 for publication" functionality to a separate [simple] tool that 1838 works with an existing/posted draft. 1840 * Resolved XXX6: We are going to move the "withdraw this ID" 1841 functionality desired by Secretariat to a separate [simple] 1842 tool that works with an existing/posted draft. 1844 * Added a "comment" field to the Adjust page so that the 1845 submitter can tell Secretariat why manual action is necessary. 1846 This may both save time Secretariat and let them improve the 1847 toolset to minimize manual submissions (including fixing 1848 validation/extraction bugs). 1850 * Added the Receipt page to the list of documented pages, for 1851 completeness. 1853 * Emphasized that common sequence of pages to go through is as 1854 short as possible for a given set of features, and that "page" 1855 means "distinct dialog", not necessarily a "distinct URL". 1856 Some reviewers thought "there are too many pages". 1858 2004/09/20 1860 * Added "E-mail Interface" section to document how key toolset 1861 functionality can be accessed via e-mail. Compared e-mail and 1862 web interfaces. (Suggested by Pekka Savola) 1864 * Split "WG ID" meta-data into "WG ID" and "WG Flag". The former 1865 seems to be easy to extract from the draft name. Noted that 1866 the latter (i.e., "this is a working group draft" status) 1867 cannot be inferred from some WG drafts (Pekka Savola). 1869 * Added "List of drafts obsoleted by this draft" external meta- 1870 data item (Pekka Savola), but questioned whether we are ready 1871 to automate that. 1873 * Added more conflicting opinions to XXX15 and proposed a 1874 solution. 1876 * Added "Preprocessing" subsection to reflect the discussion on 1877 how/whether handle include PIs in XML draft sources. Needs 1878 more discussion/work. 1880 * Further clarified how an author can request the draft revision 1881 to be published (i.e., forwarded to the IESG or RFC Editor for 1882 review and publication as an RFC or BCP). It's just a checkbox 1883 on the web interface. Raised doubts we can pull this off (see 1884 XXX45). 1886 * Suggested in XXX2 that we would inform all authors but not seek 1887 their consent (except for the submitter) when posting their 1888 draft. 1890 2004/09/09 1892 * Polished high-level page/action summary and replaced text-based 1893 steps diagram with something that looks more like a diagram. 1895 * Added "Comparison with current procedures" section placeholder 1896 for summarizing what this draft improves/changes/violates. 1898 * Frequent draft updates is not always a good thing (Henrik 1899 Levkowetz) 1901 * Added ideas regarding frequent draft updates warnings 1902 (Stanislav Shalunov) 1904 * Added "State of this draft" section to encourage review. 1906 2004/09/02 1908 * Documented all major toolset pages and corresponding actions. 1910 2004/09/01 1912 * Deleted all primary modes except for what used to be called 1913 "Posting Automation". Focus on the latter and mention other 1914 modes as exceptions or side-effects. 1916 * Changed draft outline and depth to describe specific submission 1917 steps and corresponding web pages rather than more general 1918 ideas/requirements. 1920 * Assume, for now, that Chair authorization of WG draft work must 1921 exist for WG draft to be published. This needs to be 1922 documented and perhaps relaxed to allow post-submission 1923 approvals. 1925 2004/08/30 1927 * Use "toolset" instead of a less accurate "interfaces" in the 1928 draft title and throughout the text (Henrik Levkowetz) 1930 * Use "post" instead of "publish"" in the draft title and 1931 throughout the text (Barbara B. Fuller and Larry Masinter) 1933 * Nits, clarifications, data-points (Harald Tveit Alvestrand, 1934 Henrik Levkowetz, Larry Masinter, and Barbara B. Fuller for the 1935 Secretariat) 1937 2004/08/25 1939 * Initial revision. 1941 22. References 1943 22.1 Normative References 1945 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1946 June 1999. 1948 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 1949 RFC 3978, March 2005. 1951 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1952 Technology", BCP 79, RFC 3979, March 2005. 1954 [XML] World Wide Web Consortium, "Extensible Markup Language 1955 (XML) 1.0", W3C XML, February 1998, 1956 . 1958 22.2 Informative References 1960 [I-D.mrose-writing-rfcs] 1961 Rose, M., "Writing I-Ds and RFCs using XML (revised)", 1962 draft-mrose-writing-rfcs (work in progress), April 2004. 1964 [secretariat] 1965 "Private communication with the IETF Secretariat", 2004. 1967 [OSI] "Open Source Licenses Approved by the Open Source 1968 Initiative", 2004. 1970 Author's Address 1972 Alex Rousskov 1973 The Measurement Factory 1975 Email: rousskov@measurement-factory.com 1976 URI: http://www.measurement-factory.com/ 1978 Intellectual Property Statement 1980 The IETF takes no position regarding the validity or scope of any 1981 Intellectual Property Rights or other rights that might be claimed to 1982 pertain to the implementation or use of the technology described in 1983 this document or the extent to which any license under such rights 1984 might or might not be available; nor does it represent that it has 1985 made any independent effort to identify any such rights. Information 1986 on the procedures with respect to rights in RFC documents can be 1987 found in BCP 78 and BCP 79. 1989 Copies of IPR disclosures made to the IETF Secretariat and any 1990 assurances of licenses to be made available, or the result of an 1991 attempt made to obtain a general license or permission for the use of 1992 such proprietary rights by implementers or users of this 1993 specification can be obtained from the IETF on-line IPR repository at 1994 http://www.ietf.org/ipr. 1996 The IETF invites any interested party to bring to its attention any 1997 copyrights, patents or patent applications, or other proprietary 1998 rights that may cover technology that may be required to implement 1999 this standard. Please address the information to the IETF at 2000 ietf-ipr@ietf.org. 2002 Disclaimer of Validity 2004 This document and the information contained herein are provided on an 2005 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2006 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2007 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2008 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2009 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2010 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2012 Copyright Statement 2014 Copyright (C) The Internet Society (2005). This document is subject 2015 to the rights, licenses and restrictions contained in BCP 78, and 2016 except as set forth therein, the authors retain all their rights. 2018 Acknowledgment 2020 Funding for the RFC Editor function is currently provided by the 2021 Internet Society.