RFC 4228

Requirements for an IETF Draft Submission Toolset

📅 published December 2005, from ietf

RFC 4228: Requirements for an IETF Draft Submission Toolset 🎀

Okay bestie, this one is a total must-read for anyone who's ever wrestled with submitting an Internet-Draft 💅 Here's the title block tea ☕

  • RFC number: 4228
  • Title: Requirements for an IETF Draft Submission Toolset
  • Author: A. Rousskov, The Measurement Factory
  • Series: Network Working Group
  • Category: Informational
  • Date: December 2005
  • Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates

Since it's Informational, it's giving "here's some info," not "this is a binding standard" 🦋

Status of this Memo ✨

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

Copyright (C) The Internet Society (2005).

Abstract 🍓

This document lays out the requirements for an IETF toolset that makes Internet-Draft submission, validation, and posting way smoother 🧚

Table of Contents 📑

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

1. Introduction 💖

Public Internet-Drafts are the main way people in the IETF talk in a structured way 🗣️ The current submission and posting process slows down communication and piles extra work onto the IETF Secretariat 😭 The IETF Tools team is pushing to formalize and automate what's already happening, and this document lists the specific automation requirements ✨

The IETF Secretariat and lots of IETF participants have been automation stans for ages 🤖 This document is the Tools team's take on what they've been asking for 🫶

2. Scope 🎀

The Draft Submission Toolset in this document is all about getting one new version of an Internet-Draft from an IETF participant into the IETF draft repository 📦 A single draft version can come in several formats, and handling those formats is in scope for the Toolset 🌈 Defining draft meta-information, and where it comes from (for Secretariat databases and other places), is also in scope 💅 So are submitter authentication and submission authorization 🔐

Posting a draft can trigger notifications to interested parties. This document recommends a subset of notification targets, but the details of notifications are out of scope 🦋

Creating new drafts or new draft versions is out of scope, and so is manipulating, visualizing, or otherwise interacting with drafts already in the repository 🙈 Draft expiration and archiving of old draft versions are out of scope too 🧹

The requirements here aren't meant to be complete or final 💜 Other IETF documents or procedures might need more from the Toolset. For example, the Toolset may someday have to handle draft source formats beyond plain text and XML 👀

3. Notation and Terminology 📚

The following terms should be read using the definitions below 🤓

  • posted draft: A draft that gets accepted into the public IETF draft repository and is therefore publicly available from the IETF web site 🌸 Posting a draft doesn't mean it's been reviewed or endorsed by the IETF or the IESG 👀
  • draft version: A meant-to-be-public snapshot of an Internet-Draft with a meant-to-be-unique version number 🔢 Also known as "draft revision" 💖
  • draft format: Any draft source or presentation format. That includes original and preprocessed XML, original or generated plain text, and PDF, PostScript, and HTML formats 📄
  • primary draft format: The first available draft format from this list, in order: plain text, PDF, PostScript, or XML 🥇
  • WG-named draft: A draft whose identifier (a.k.a. filename) is known and starts with "draft-SPECIAL-", where SPECIAL is one of these strings: "ietf", "iab", "iesg", "rfc-editor", or "irtf" 🏷️ These are abbreviated as "WGN draft". There are exceptions, but WG-named drafts are usually controlled by IETF working groups or similar IETF-related bodies, and the reverse is usually true too 🌈 How those naming exceptions get handled is outside this document's scope 🙈
  • individual draft: Any draft that isn't a WGN draft 🧍‍♀️
  • submitter: A human or software agent that starts the submission of an Internet-Draft version for validation or posting 🫡 Sometimes the Secretariat staff does the actual submitting, but they're always doing it on behalf of a submitter. Sometimes the submitter isn't the draft author, including (but not limited to) malicious attacks 😭
  • expected submitter: A submitter that IETF rules authorize to post a given draft. That covers a draft author or editor (listed in the draft text), a corresponding WG Chair, or an IESG member 👑
  • authorized submitter: An expected submitter that the Toolset has authenticated. Authentication starts out limited to checking that the submitter has access to their email address 📧
  • immediately: Without human interaction or artificial software delays, and within a few seconds ⚡

The Toolset is specified using a set of normative requirements 🧾 Each requirement is an English phrase ending with an "(Rnnn/s)" marker, where "nnn" is a unique requirement number and "s" is a single-letter code ("a", "b", or "c") for the implementation stage that requirement belongs to. Implementation stages are explained in Section 16 🗓️

This document describes the interface and functionality of the Toolset, not the details of how any particular Toolset implementation works 🛠️ Implementation hints and examples are still often helpful 💡 To avoid mixing them up with Toolset requirements, hints and examples are often marked with a "Hint:" prefix 🏷️ Implementation hints have no normative force at all, and a different implementation might be the better choice 🌸

4. Status Quo ✨

okay so this section is the "how things work right now" tea ☕ before the new Toolset shows up. It's all about how a draft currently gets posted, and honestly it's a little chaotic 💀

To get an Internet-Draft posted on the IETF web site, an IETF participant emails the draft text to the IETF Secretariat, along with an informal note asking the Secretariat to post the draft. Secretariat staff reads the note, reviews the draft according to a checklist, and then approves or rejects the submission. Draft approval triggers the corresponding announcement to be sent to appropriate IETF mailing lists. Every 4 hours, approved drafts are automatically copied to the IETF drafts repository and become available on the IETF web site. 📬

Collectively, IETF participants submit thousands of Internet-Drafts per year (in the year 2000, about 3,000 drafts were submitted; 2002: 5k; 2004: 7k [secretariat]). About 30-50% of posted drafts are WG-named drafts (among some 2,100 drafts, there were about 380 new and 290 updated WGN drafts posted in 2003). While no rejection statistics are available, the vast majority of submitted drafts are approved by the Secretariat for posting. 🌸

It usually takes the Secretariat a few minutes to review a given draft. However, since the Secretariat staff does not work 24/7, does not work in all time zones, and has other responsibilities, and since approved drafts are posted in batches every 4 hours, it may take from several hours to several days to get a draft posted. Due to much higher demand and fixed processing capacity, postings during the last weeks before IETF face-to-face meetings take much longer, creating a long queue of unprocessed drafts that are then announced nearly simultaneously. 🫠

To give IETF face-to-face meeting participants time to review relevant documents, the Secretariat does not accept Internet-Draft submissions close to IETF meetings (regardless of whether a draft is relevant to the upcoming meeting or not). 🎀

Many Working Groups have come up with ad hoc solutions to cope with posting delays. For example, many draft snapshots are "temporarily" published on personal web sites or sent (completely or in part) to the group list. Alternative means of publication may effectively replace official IETF interfaces, with only a few major draft revisions ending up posted on the IETF web site. 🦋

Informal interfaces for submitting and posting drafts discourage automation. Lack of submission automation increases Secretariat load, complicates automated indexing and cross-referencing of the drafts, and, for some authors, leads to stale drafts not being updated often enough. 😭

Beyond a short Secretariat checklist, submitted drafts are not checked for compliance with IETF requirements for archival documents, and submitters are not notified of any violations. As a result, the IESG and RFC Editor may have to spend resources (and delay approval) resolving violations with draft authors. Often, these violations can be detected automatically and would have been fixed by draft authors if the authors knew about them before requesting publication of the draft. 🧚

Technically, anybody and anything can submit a draft to the Secretariat. There is no reliable authentication mechanism in place. Initial submissions of WGN drafts require WG Chair approval, which can be faked just like the submission request itself. No malicious impersonations or fake approvals have been reported to date, however. 👀

Lack of authentication is not perceived as a serious problem, possibly because serious falsification are likely to be noticed before serious damage can be done. Due to the informal and manual nature of the submission mechanism, its massive automated abuse is unlikely to cause anything but a short denial of draft posting service and, hence, is probably not worth defending against. However, future automation may result in a different trade-off. 💅

5. Overall Toolset Operation 👑

This section gives the high-level tour of the proposed Toolset. The description is meant to show overall operation and order; please refer to other sections for details specific to each step. Think of it as the trailer before the movie 🎬

A typical submitter goes through a sequence of 2-4 web pages and associated actions. The number of pages depends on the draft validation and meta-data extraction results. For example, validating the draft without posting it requires interacting with two web pages: Upload and Check. The common case of posting a valid draft without manual meta-data adjustments takes three web pages (Upload, Check, Receipt). ✨

Here is a brief overview of pages and actions:

  • Upload page: The interface to copy a draft from the submitter's computer to the Toolset staging area (Section 6). Multiple formats are accepted. The draft is sent to the Check action.
  • Check action: Stores the draft in the Toolset staging area, extracts draft meta-data, validates the submission (Section 7). Produces the Check page.
  • Check page: Displays draft interpretation and validation results (Section 8). A draft preview may also be given on this page. After reviewing the draft interpretation and validation results, the submitter has four basic choices: (a) auto-post draft "as is" now; (b) make manual corrections and submit the draft to Secretariat for manual posting later; (c) cancel submission; or (d) do nothing. The automated posting option may not be available for drafts with validation errors. 🥹
  • Automated posting: If the submitter decides to proceed with automated posting from the Check page, the system authenticates the submitter and may also check whether the submitter is allowed to post the draft. If the submitter is authorized, the draft is immediately posted, deleted from the staging area, and the submitter is notified of the result via email and a Receipt page (Section 9). 🚀
  • Manual adjustment and posting: If the submitter decides to adjust the meta-data, the draft remains in the Toolset staging area, and the Adjust action (Section 10) presents the submitter with an Adjust page (Section 11). When the submitter makes the adjustments and proceeds with manual posting, a pointer to the stored draft and its adjusted meta-data is sent to the Secretariat for manual processing (Section 12). The submitter is notified of the pending Secretariat request via email and a Receipt page. 🛠️
  • Cancellation: If the submitter decides to explicitly cancel the submission, the submission state (including the draft) is immediately deleted from the Toolset staging area and an appropriate Receipt page is generated without further actions (R123/a). Cancellation of posted drafts is out of this document scope. 🙅‍♀️
  • Receipt page: Contains details of a successful or failed draft submission and informs the submitter of the next appropriate step(s) related to submission result. 🧾

The following informal diagram illustrates the basic submission logic:

                       /---> Post Now
                      /
   Upload --> Check -+-----> Adjust ---> Send to Secretariat
                      \
                       \---> Cancel

If the submitter does nothing while the Toolset is expecting some response, the abandoned submission times out (R124/a). The timeout value depends on the submission state. Hint: A timeout value of one hour is probably large enough unless the Toolset is waiting for some kind of a 3rd party confirmation (e.g., WG Chair approval). Doing nothing is functionally equivalent to explicitly canceling the submission, except that explicit cancellation requires immediate removal of submission state while the state of submissions marked as abandoned is garbage-collected. ⏰

The staging area maintenance algorithms must keep the area in a consistent, correct state in the presence of denial-of-service (DoS) attacks attempting to overwhelm the area with fake submissions in various stages (R67/a). Hint: denial of service to legitimate users is acceptable under DoS attack conditions, but corruption of the storage area is not. Corruption is the real villain here 😤

The "web pages" this text is referring to are distinct dialogs that may be visible to the submitter under the same or different URL and that are supported by a single or several server-side programs.

The Toolset must handle multiple submitters simultaneously submitting the same draft (R72/a) and a single submitter simultaneously submitting two drafts (R73/a). The latter might happen, for example, when the submitter is using several browser windows to submit several drafts or is submitting drafts via email interface. The term "simultaneously" means that submission processing times overlap. 🪟

Hint: Except for the Upload page, pages contain a submission session identifier to provide actions with access to stored information. The identifier is specific to the submission rather than the draft version or the submitter. While the nature of the web interface allows the session identifier to be invisible to the submitter, email communication would need to identify the session so that the recipient (and Toolset) know the context. 🪪

Hint: A single action may correspond to multiple server-side programs and, vice versa, a single program may implement several actions. This document does not mandate any specific technology (e.g., Common Gateway Interface (CGI), PHP, and/or Java servlets) to implement server-side support. The implementer experience, code reuse across web and email interfaces, and other factors will determine the right technology choice. 🧩

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

Ways to partially or completely bypass the Toolset are documented in Section 14.

It must be possible to transfer the Toolset from one management team to another, to incorporate work by volunteers, and to allow for public review of the developed code. To meet these goals, the Toolset source codes should be publicly available (R152/b) and there should be an interface to report bugs and request enhancements (R145/b). Development should be structured to avoid lock-in to proprietary platforms or backends. The Tools team believes that developing the Toolset sources under one or more open source licenses following the Open Source Definition [OSD] would provide an effective way of meeting these requirements at reasonable cost. Care should be taken that the licenses selected allow code from different implementers to be mixed. 🌈

Hint: Placing the Toolset source repository at an open-source-friendly project management site like SourceForge.net would provide the IETF community with a decent, ready-to-use interface to access the code, documentation, bug reports, and discussion forums. Establishing and documenting a simple interface between the Toolset and external software (e.g., the Secretariat draft posting scripts) would facilitate availability checks. 🍓

The Toolset is meant to be compatible with the Secretariat's tools for handling drafts. Hint: Such compatibility can be achieved by appropriately implementing the Toolset or, in some cases, by modifying existing Secretariat tools. 🫶

6. Upload Page 📤

okay so to upload a draft, the submitter goes to a well-known page on the IETF web site (R1/b) 💻 there's an HTML file upload form where the draft text gets uploaded. the form has fields for the plain text format of the draft (R2/a) and for all the other formats the IETF draft publication rules allow (R3/b). at the time of writing, those are: XML ([RFC2629] and [writing-rfcs]), PDF, and PostScript 🎀

submitted forms get handled by the Check action in Section 7 🫶

the Upload page also has a validate-only flag 🚩 which means an uploaded draft must not be posted and may be deleted right after validation (R74/b). no matter what the validation results say, the stored draft meta-data gets marked so validation-only drafts can be spotted and deleted first by the garbage collector for the Toolset staging area (R75/b) 🗑️ drafts uploaded in validate-only mode cannot be posted (R76/b). they'd have to be uploaded again without the flag, and the validation results page should explain that (R77/b) ✨ this flag is super useful for tools doing online validation, especially for bulk draft processing 🤖

💡 hint: it may be better to implement this flag as a hidden HTML input field, so the interface stays simple for human submitters 🙈

7. Check Action 🔍

the Check action preprocesses a submission, generates plain text format (if needed, see R70), stores the submitted draft (all formats) in the staging area, and then extracts meta-data and validates each format (R6/a) 🧠 errors and warnings get shown to the submitter in the response, using computer-friendly tag(s) and human-friendly text (R7/a) 💖

if any error is found, automated posting becomes impossible (R113/a) 💀 this applies to all errors, even ones that don't refer to R113 and don't explicitly ban automated posting. if automated posting isn't possible, the Toolset still gives the submitter an option to send the draft for manual validation and posting (R114/a) 🧚 and since each submission is treated in isolation, the submitter can also fix the problem and resubmit the draft for automated posting 🔁

the manual validation and posting route is a Toolset bypass mechanism (see Section 14) and it's not meant for fixing problems with the draft itself 🙅‍♀️ the Secretariat doesn't generally correct submitted drafts. if the draft needs tweaking to match the submitter's intent, the submitter should correct it and resubmit 💅

it's an error to submit a draft that has neither plain text nor XML source format (R68/a) 😭 XML source is only acceptable without an accompanying plain text file if the Toolset successfully generates a plain text draft from the XML source, as part of the processing step below (R69/b) 🌸 these rules mean PDF- or PostScript-only drafts can't be auto-posted. even manual Secretariat involvement can't help with posting them, because the IETF policy is to always require a plain text format in addition to PDF or PostScript 🙃 and furthermore, drafts containing PDF or PostScript format must not be auto-posted until the Toolset can validate that their content matches the plain text format (R143/a) 🔒

the draft format acceptance rules above are meant to decrease the chances that multiple posted formats of a single draft contain substantially different documents 🎯 with experience, the rules may get simplified so that, for example, only submissions containing nothing but XML or plain text sources can be posted without Secretariat involvement, and all other submissions require manual actions to match formats or extract meta-data 🌈

7.1. Preprocessing 🧼

submitting compressed drafts is a desirable feature, especially for submitters stuck on slow or content-altering links 🐢 compressed draft formats may be accepted (R150/c). any compressed formats, if accepted, must be decompressed during the preprocessing step (R151/c) so other processors don't have to deal with compressed formats 🙌

💡 hint: while this specification doesn't document a list of supported compression standards, it's expected that popular methods like "zip" and "gzip" should be accepted if compression is supported. accepting a collection of draft formats inside a single compressed archive may also be desirable 🎁

XML source containing XML processor <rfc? include="..."> instructions (PIs) gets preprocessed to include references (R8/b) ✨ this step is needed to remove external dependencies from XML sources and to make tools that process posted XML simpler 🛠️ this document calls these XML processor instructions "include PIs" 🏷️

the XML preprocessor uses public database(s) to resolve PI references (R85/b). the Toolset documentation specifies which databases get used and how PIs map to database entries (R86/b) 📚 the Toolset must not rely on PIs' existence (R87/b), because some XML sources will be preprocessed before submission or written without PIs at all 🙈

💡 hint: local up-to-date copies of Marshall Rose's reference databases at xml.resource.org can be used 🫶

both the original and preprocessed XML sources may be posted later 💫 the original source with include PIs may be useful to the RFC Editor and for generating diffs (against future or past original sources) 🔍 the preprocessed source without include PIs becomes the default public XML source of the posted draft (R10/b) 👑 if any of the include PIs known to the Toolset can't be handled, an error gets recorded (R11/b), and the submitter is encouraged to do the preprocessing locally, before submitting the draft (R111/b) 🥺

uncompressed draft formats other than XML are not preprocessed 🙂

7.2. Processing ⚙️

when no plain text format of the draft is submitted, but XML sources are available, the Toolset attempts to generate a plain text format from the submitted XML sources (R70/b) 🪄

if XML sources are available, the Toolset generates an HTML draft format (R112/c) 🌐 HTML generation failures should result in warnings, not errors (R115/c) ⚠️ HTML generation is not meant to be implemented until the Enhancement Stage is reached (R130/a) 🚀 in general, HTML generation is desirable because HTML drafts are usually easier to navigate than plain text drafts, thanks to better readability and links 🥰 and like any Enhancement Stage feature, HTML generation may be dropped or drastically changed to reflect then-current IETF consensus and the experience of the first two implementation stages 🔄

💡 hint: Toolset implementers should not assume that draft formats generated by the same tool from the same source format have essentially the same content. the generation tool may have options that let authors generate content exclusive to a specific generated format, and such options might get abused 👀

7.3. Storage 📦

the Check action needs to store all draft formats, so successfully validated drafts can be auto-posted later at the submitter's request 💖 the action stores all submitted formats of the draft in a staging area dedicated to the Toolset (R12/a) 🏠 if, after garbage collection, the staging area is still full (meaning the total used size has reached the configured maximum capacity), the submitter and the Secretariat get notified of a fatal error (R13/a) 🚨

7.4. Extraction 🕵️‍♀️

the Toolset extracts meta-data from these stored draft formats: plain text (R131/a), XML (R132/b), and other (R133/c) 🧾 if a meta-data extraction fails, the Toolset records an error (R15/a) 😬 meta-data extraction is necessary to validate and post the draft 💅 extraction from all formats is necessary to check that all meta-data matches across all formats (on top of, and before, the Toolset can check that the contents match too) ✅

Section 16 documents a non-obvious implementation schedule related to the requirements above 🗓️ when only partial support for format interpretation is available, only the interpreted formats are subject to extraction and validation requirements. in other words, if the Toolset doesn't yet support interpreting a given format, the corresponding information is stored and made available "as is", no matter what the actual content is 🫠

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

  • identifier: also known as the draft "filename" ✨ for example, "draft-ietf-sieve-vacation-13".
  • version: a non-negative integer representing the draft version number (also known as the draft revision number) 🔢 for example, the number 7 in "draft-ietf-sieve-vacation-07". the number is usually rendered using two digits, padding with "0" if necessary 💜
  • name: the common part of all draft identifiers for all versions of the same draft 🧩 in other words, a draft identifier without the version component. for example, "draft-ietf-sieve-vacation" in "draft-ietf-sieve-vacation-07".
  • WG ID: the Working Group identifier 👯 for example, "sieve" in "draft-ietf-sieve-vacation-07" is a WG ID. the WG ID value is empty for drafts that are not WG-named drafts 🫥
  • WG flag: true for WGN drafts and false for all other drafts 🚩 for example, "true" for "draft-ietf-sieve-vacation-13". this flag only influences the further handling of initial (version 00) draft submissions, as far as this document is concerned 🌱
  • title: a human-friendly draft title 🎀 for example, the title of this document is "Requirements for an IETF Draft Submission Toolset" 🧚
  • authors: a list of all draft authors 👩‍👩‍👧 each author's name and email address are extracted 📧
  • abstract: the draft abstract text 📝
  • creation date: the draft version creation date 📅
  • expiration date: the draft version expiration date ⏳
  • size: the number of pages and octets in the primary format of the draft 📄 the definition of a page depends on the format and may be imprecise or arbitrary for some formats 🤷‍♀️

failing to extract any field results in an error (R95/a) 🚫

the Toolset requires author email addresses because they're essential for notifying co-authors that their draft has been posted 📬 if there are no such notifications, a submitter who adds a co-author without that co-author's consent might not get caught for a while 😤 these "surprise" co-authorships have happened in the past and can be quite annoying 🙄 however, since the Toolset doesn't solicit co-authors' consent to post a valid draft (and such solicitation wouldn't go beyond email control verification anyway), it's not possible to stop a malicious submitter from adding co-authors without their knowledge 💀

like the other meta-data items above, draft creation and expiration dates are extracted from the draft, so their values don't depend on the actual submission time (i.e., the time the Check action starts) ⏰ however, the validation procedure (see Section 7.5) may declare any extracted date invalid after taking into account the current (i.e., submission) time, IETF draft expiration rules, and other factors external to the draft 🫧

7.5. Validation

okay so drafts need to get validated 💅 to catch broken submissions 😭. Validation also helps educate or warn authors about problems that could turn into show-stoppers when the draft goes to IETF Last Call and IESG review 🫶. IETF standards have to follow a set of syntax and semantics requirements (see the "ID-NITS" document at <http://www.ietf.org/ID-Checklist.html>). Most of those requirements aren't enforced for Internet-Drafts, but following them may improve draft quality, reduce the IESG load, and increase the chances of the draft being approved as an RFC ✨🎀.

when you're validating a draft, it's super important to tell apart absolute requirements and desirable draft properties 🔥. Both get checked, but a violation hits differently depending on which category it's in. The two categories are detailed in the following subsections 🦋.

when a valid draft is being posted and the submitter authorization or co-author notification happens, the validation results should be included in the email (R81/b) so the submitter can see the meta-data extraction and validation warnings 💌. Note that these results cannot include errors, since only valid drafts can be posted (it's giving "already passed the vibe check" 💅).

7.5.1. Absolute Requirements

ngl this is the no-negotiation list 💀. Violating any of these requirements would prevent a draft from being automatically posted (R17/a). The offending draft would have to be fixed or submitted for manual posting, with an explanation as to why the absolute requirements need to be violated (or why the Validator mis-detected violations) 🙈. These explanations may speed up the Secretariat posting decision and may help the Secretariat improve the Toolset implementation 🧚.

  1. All available meta-data entries must match across all submitted draft formats (R18/a). For example, if the interpreter managed to extract a draft title from both the plain text and the PDF format, both titles must match. This requirement prevents accidental submission of mismatching formats 🍓.
  2. Version 00 of a Working Group draft has a corresponding Working Group approval (R20/a). This approval can be relayed before or after the first draft submission, by a Chair or Secretary of the WG. See Section 7.5.4 for related requirements 👑.
  3. The draft ID must be correct (R22/a), including the draft version number value and format. Single-digit draft version numbers must be left-padded with "0". Draft version numbers must start with zero and increase by one with every new version. To satisfy this requirement, the Toolset would have to consult the repository of already posted drafts, including expired ones. If the IETF infrastructure cannot handle version numbers greater than 99, the Toolset must reject them (R158/a) 🔢.
  4. An IETF IPR Statement and other boilerplate required for drafts according to [RFC3978] and [RFC3979] (or successors) must appear in the draft text (R23/a) 📜.
  5. The extracted creation date of the draft version must be within 3 days of the actual submission date (R159/a). Hint: Implementers should be careful to handle creation dates that appear to be in the past or in the future, due to possible time zone differences. Making the most forgiving/permissive assumption about the time zone should suffice 🌈.
  6. The draft version expiration date obeys IETF draft expiration rules ⏰.
  7. No IETF submission blackout period applies. Hint: IETF blackouts must be enforced based on submission time, not possible draft creation time 🙅‍♀️.
  8. Posting the draft must not result in any DoS attack threshold to be crossed (R97/a). Specific thresholds are documented in Section 7.5.3 🚨.
  9. XML sources (if available) are valid with respect to the XML format [XML] (R153/c) and XML Document Type Definition (DTD) for IETF drafts (R154/c). Note that during the first two implementation stages, the corresponding validation failures result in warnings and not errors (see Section 7.5.2) 🫧.

The XML DTD for IETF drafts is documented in [RFC2629], with recent changes available in [writing-rfcs]. Hint: Bill Fenner's "RFC 2629 validator" at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ (or its derivative) may be useful for XML format and DTD validation 🛠️.

Hint: If the extracted meta-data differs in the submitted draft formats, the Toolset should use the meta-data from the most "formal" format when populating the form entries for manual submission. On the other hand, if most extracted entries come from a less "formal" format, the Toolset may choose that format instead. For example, XML source can be considered more "formal" than plain text format. The Toolset may also offer the submitter an option to specify which format should be used for populating the form. It is probably a bad idea to mix-and-match the conflicting entries extracted from multiple formats. Instead, either one format should be chosen when populating the form or the form should contain several meta-data sections, one for each format. The error messages will contain the exact mismatch information 🧩.

Hint: The Toolset should accept dates without the day of the month, as long as IETF rules do not prohibit them. The Toolset should make the most forgiving/permissive assumption about the actual day of the month when validating day-less dates 📅.

7.5.2. Desirable Features

these ones are the "pls do this, bestie" list 🥹. Violating any of the following requirements does not prevent the submitter from auto-posting the draft (R24/a), but it results in a warning (R160/a). Each warning explains the corresponding violation and provides advice on how to comply (R161/b). Hint: To ease maintenance and encourage 3rd party updates, detailed explanations and/or advice may be available as a resource separate from the Toolset 📚.

  1. All automatically testable nits in the "ID-NITS" document at <http://www.ietf.org/ID-Checklist.html> (R116/b) and automatically testable guidelines at <http://www.ietf.org/ietf/1id-guidelines.txt> (R157/b). The Toolset should use external tools to check these nits and guidelines rather than embed checking code (R117/a). Hint: Henrik Levkowetz's idnits tool can be used (http://tools.ietf.org/tools/idnits/), and other tools can be written or adopted 🧼.
  2. New draft versions are expected (R21/b). For example, version 00 of an individual draft is always expected, while posting a new version of a draft already under the IESG review should generate a warning 🌸.
  3. If both XML and plain text formats are submitted, the submitted plain text matches what can be generated based on submitted XML (R146/b) 🔍.
  4. The previous version, if any, was posted at least 24 hours ago (R96/b). This warning may prevent some human errors, especially when multiple authors may post the same draft 😅.
  5. XML sources (if available) are valid with respect to the XML format (R155/b) and XML DTD for IETF drafts (R156/b). These requirements become absolute after the second implementation phase. See Section 7.5.1 for related information 💜.

When comparing generated and submitted plain text formats to satisfy R146, a standard word-based diff is sufficient for initial Toolset implementations (R147/b). However, a custom fuzzy matching function can be developed (R148/c) to minimize false warnings due to, for example, draft text formatting differences. When differences are detected, a complete diff may be provided on a separate page (R149/c), in addition to the warning ✨.

Hint: When comparing generated and submitted plain text formats, the Toolset may try several recent xml2rfc versions for plain text generation, to eliminate warnings due to differences among xml2rfc versions 🦋.

7.5.3. DoS Thresholds

this is the "don't flood the place" section 🌊 (lowkey the most dramatic one 😭). The following table documents DoS attack thresholds for various draft categories. Daily limits correspond to all drafts (and all draft formats) within the category. Other thresholds may be introduced, and these initial thresholds may be adjusted as necessary. The thresholds are likely to become more smart/dynamic with experience 📈.

                          DoS attack thresholds:

      +---------------------------------+--------------+-----------+
      | category                        | versions/day |    MB/day |
      +---------------------------------+--------------+-----------+
      | drafts with the same draft name |            3 |         5 |
      | drafts with the same submitter  |           10 |        15 |
      | WGN drafts with the same WG ID  |           30 |        45 |
      | all drafts                      |          400 |       200 |
      +---------------------------------+--------------+-----------+

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

7.5.4. WG Approval

okay the WG approval part is a whole flowchart of vibes 🌈. For version 00 of a WGN draft, the Toolset checks for an existing WG approval (R125/a). If (a) no approval exists, and (b) the Toolset does not support the "waiting for WG approval" feature, the Toolset records an error (R135/a) ❌.

If (a) no approval exists, (b) the Toolset supports the "waiting for WG approval" feature, and (c) the draft cannot be posted even if WG approval is received, then the Toolset records a warning that a WG approval would be required once all errors preventing the draft from posting are fixed (R137/b) 🛑.

If (a) no approval exists, (b) the Toolset supports the "waiting for WG approval" feature, and (c) the draft can be posted if WG approval is received, then the Toolset explains the situation to the submitter and asks whether an explicit approval from the WG should be solicited or expected (R126/b). If the approval should be solicited, it is solicited by the software or the submitter. If appropriate, the Toolset puts the submission into a "waiting for WG approval" state until the expected approval is available (R127/b). Otherwise, the Toolset records a "no WG approval is expected" error (R138/b) 🫠.

The details of manual or automated solicitation for WG approval are outside the scope of this document. Hint: Initially, the submitter will be responsible for soliciting a WG Chair approval, but this process should eventually be automated 🤖.

Details of the approval recording and access interfaces, as well as the mechanism to resume the submission upon approval, are out of this document's scope 💖.

8. Check Page ✨

okay so the Check page 💅 is what the Check action makes, and it shows the extracted draft meta-data and validation results (R25/a). its whole job is helping the submitter confirm that the stored draft and the auto-extracted meta-data actually match what they meant, and letting them know about any validation problems 🔍

Meta-data items from Section 7.4 that failed validation checks must be marked specially (rather than silently omitted or ignored) (R26/b). hint: rendering those items in red, with links to the matching validation errors or warnings, may force authors to pay attention 🔴

Validation messages include both errors and warnings. each one refers to the normative document(s) that hold the matching validation rules (R27/b) 📖

The Check page lets the submitter enter external meta-data (Section 8.1) (R28/a). if validation worked, there's an "automatically post the draft now" button (R29/a). no matter what validation said, you also get "adjust and post manually" and "cancel" buttons (R30/a) 🎀

The page previews the draft in plain text format (R31/a), with a link to see the whole draft in all its formats the way it'd look if posted (R82/b). hint: the preview should be long enough that authors can spot obvious mismatches or misreadings, but short enough that it doesn't take over the page. showing the first line through the last line of the abstract might be enough ✨

For draft updates, the page reports the time and submitter of the last update (R83/b). this is super useful when several authors are working on the same draft 🫶 it also links to a diff against the last posted version (R84/c) 🦋

8.1. External Meta-Data

The Check page asks the submitter for the following meta-data. it has to come from the submitter because it can't be extracted from the draft 🙈

  • Submitter email address (R32/a). if the submitter isn't an expected submitter (see Section 3), automated posting isn't possible and the draft has to go through the Secretariat (R98). Hint: checkboxes next to the extracted author names, plus a "none of the above" checkbox with an input field, would do the job 💖
  • A list of drafts replaced by this draft (R33/c). this is useful for making replaced drafts invisible 👻 this document doesn't specify any actions needed to actually replace an existing draft. existing draft manipulation is out of scope, and security concerns and other complications of such actions would be better handled by a separate specification 🔒
  • Primary email address for discussion of this draft (R71/b). Hint: the Toolset can suggest the WG mailing list address for WGN drafts, the (submitting) author address for individual drafts, or even the first email address in the draft text. offering a few likely addresses instead of relying only on user input would also cut down on typos ⌨️

Except for the submitter email address, external meta-data is optional (R109/a) 🌈

If a given submitter email address belongs to an expected submitter (i.e., belongs to one of the categories below), the Toolset performs submitter authentication during a Post Now action (R19/a). otherwise, an error is reported (R118/a) 🚨

The Toolset identifies the following possible expected submitters on its own, without any Secretariat intervention:

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

9. Post Now Action

The Post Now action checks that the draft was successfully validated (R34/a), validates external meta-data (including the submitter email address) (R35/a), and posts the draft (R36/a). the submitter gets updates on progress and the final result (R37/a) 🚀

The external meta-data includes the submitter's email address. as part of validation, the Post Now action authorizes the submitter. the initial implementation checks that the submitter has access to email sent to that address (R38/a). eventually, the Toolset should accept client certificates signed by IETF, PGP-signed email, and/or other forms of client-side authentication to get rid of the weak and annoying email access check (R110/c) 🙄. if submitter authentication fails, the submission eventually and silently times out (R39/a) ⏳

The Toolset provides both web (R99/a) and email (R139/b) interfaces for confirming email access. Hint: to check the submitter's email access, the tool can email a hard-to-guess cookie or token to the submitter's address. to continue, the submitter pastes the cookie at the specified URL, goes to the token-holding URL, or responds to the email 🍪

Immediately after emailing the submitter, the Post Now action generates an intermediate Receipt page. it explains Toolset expectations and gives the submitter the submission ID (R100/a). that number lets the Secretariat troubleshoot stuck submissions (R101/a), and it can also be used to check submission status without Secretariat involvement (R140/b) 🔢

Immediately after posting the draft, the Toolset notifies all authors (with known email addresses) of the posting (R102/a). the notification email contains the info from the "successful posting" Receipt page described below (R103/a) 📬

If draft posting is successful, the submission is marked as available for deletion (R105/a), so the garbage collection routine eventually deletes it 🗑️

9.1. Receipt Page

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

  • the draft ID and a link to the draft status page.
  • the draft title, authors, and abstract.
  • the submission ID.
  • a link to the draft submission status page (when status queries are supported, see R140).
  • the submitter's name and email address.

The main purpose of the Receipt page is to tell all draft authors that (supposedly) their draft got posted 💌. the secondary purpose is to let authors keep a permanent record of the event and troubleshoot postings 📝. the same information should go to other interested parties (e.g., the WG mailing list), but 3rd-party notification specifics are out of this document's scope 🙅

10. Adjust Action

The Adjust action generates the Adjust page (R40/a). it fills the page with available extracted meta-data and external meta-data, plus validation results and a preview. some info may be missing, depending on how the draft is interpreted and whether the preview generation worked 🧩

11. Adjust Page

The Adjust page includes the same info as the Check page, but lets the submitter adjust all extracted draft meta-data (and external meta-data too, obvi) at will (R41/a) 🛠️. that's needed when automated extraction gets things wrong. to avoid any mismatch between the draft and its meta-data, adjusted drafts can't be posted automatically and need manual validation by the Secretariat (R42/a). Secretariat staff can post drafts with adjusted meta-data as described in Section 14 💼

The Adjust page lets the submitter enter an informal comment explaining why adjustments are necessary and why automated posting mode can't be used (R48/a). those comments can be essential for the Secretariat when they're troubleshooting the problem 🕵️

The "post manually" and "cancel" buttons are provided (R43/a). the former is backed by the Post Manually action (Section 12) 🤝

12. Post Manually Action

The Post Manually action sends the adjusted meta-data and a draft pointer to the Secretariat for manual validation and posting (R44/a). a receipt page is generated that tells the submitter to wait (R45/a). the Secretariat will notify the submitter once the draft is posted or rejected. that notification is sent by the Toolset if the Secretariat is using the Toolset to post the draft (R46/a) 📨

13. Receipt Page

The Receipt page is generated by various actions to tell the submitter the current submission status and what to do next 🧾. its contents are likely to depend heavily on the action and state it's generated for. this section documents general requirements that apply to all actions and states 💜

The Receipt page should give the submitter a Uniform Resource Identifier (URI) or another identifier that the Secretariat can use for manual troubleshooting of the submission (R63/a). the identifier should be perpetual (R64/a), even though the associated details will likely eventually be lost (e.g., draft submission data and logs are deleted from the staging area as a part of the garbage collection routine) 🌸. Hint: tools should tell old identifiers apart from invalid ones. when an identifier refers to deleted data, the tools accepting it should let users know the submission is recognized but the related information has expired 💭

The Receipt page should give the submitter a Secretariat point-of-contact to report submission problems (R65/a) 📞

14. Bypassing the Toolset ✨

okay so sometimes the Toolset just won't cooperate 😭 A buggy Toolset implementation or weird circumstances might force a submitter to send a draft to the Secretariat for manual processing. 💅 They can use the "manual posting" route the Toolset supports (R47/a) or, as a last resort, just email the draft straight to Secretariat. Either way, there has to be an informal "cover letter" tagging along 💌 and it should explain why the automated interface can't be used.

When the Secretariat processes manual submissions, they may be able to use the Toolset too 🛠️ A Manual Check page, kinda like the default Check page, gives authenticated Secretariat staff editable meta-data fields and a "force posting" action (R50/b). The forced posting action accepts meta-data fields "as is", does not verify submitter access to email or WG draft authorization, and posts the draft as if no validation errors were found (R51/b). The Manual Check page should still show all the errors and warnings identical to the ones ordinary submitters see (R106/b), so the Secretariat knows what the Toolset is unhappy about (if anything) 🕵️‍♀️

Using manual processing may result in significant posting delays. ⏳ Generated submission receipts or notifications ought to give the submitter an expected processing time estimate (R53/a).

The whole point of this mode is to let submitters get around bugs or limitations of the automated mechanisms so they can post an "unusual" draft, or post a draft under "unusual" circumstances 🦋 One example would be a draft that doesn't have standard IETF boilerplate but has a special IESG permission to post with the experimental boilerplate. Another is a draft that fails automated validation tests because of a validator bug.

The bypass mode is also likely to be used (effectively) by the majority of submitters during the Trial stage of the Toolset implementation 🌸 That's when few submitters know about the Toolset, or are allowed to use it.

15. Email Interface 📧

The Toolset should have an email interface for automated posting of valid drafts (R55/b). Like, basically every documented Toolset feature could technically sit behind an email interface, but features other than posting valid drafts are believed to be prohibitively awkward to build or use over email 🙈

The email interface accepts a draft as a set of email part(s), one per draft format (R56/b). For example, the plain text format can go in the "body" of the email message, while the XML source format can optionally be sent as an "attachment" of that same message 📎 Each part can either contain the actual format data (R141/b) or a single URL pointing to it (R142/c). In the latter case, the Toolset has to fetch the format data. The details of the URL-fetching option aren't documented here, but it's assumed that HTTP URLs are supported (at least), and fetching errors are reported. This document doesn't specify how the format of each email part gets determined, but it's assumed that MIME type and content would need to be analyzed 🤓

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

So a typical successful submission over email might look like this exchange ("T" is for "Toolset", "S" is for "submitter", and "A" is for "all authors and submitter"):

S-->T: the draft version

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

S-->T: a response to the challenge

A<--T: warnings and the receipt

where the message containing the challenge may include warnings as well.

When draft validation fails, these emails might get exchanged instead:

S-->T: the draft version

S<--T: errors and receipt

Email parts or attachments that aren't recognized as draft formats are not considered draft formats. The Toolset ignores those parts (R107/b), except that a warning is generated for each unrecognizable part containing more than whitespace (R108/b). Both of these requirements exist to keep the interface robust when there are email signatures and other parts outside the submitter's control 🫶

Hint: Toolset actions can be implemented to support email and web interfaces without code duplication. 🧚

Both interfaces allow fast posting of valid drafts, but they're really different, ngl 💜 The main advantages of the email interface are:

  • off-line mode: A submitter can do all the manual work required to submit a draft while disconnected from the network. The email client actually submits the draft once connectivity is back 📴
  • poor connectivity: Email systems are often better suited for automated transmission and re-transmission when network connectivity is poor, with high packet loss ratios, transmission delays, and other problems 📶
  • convenience: Some IETFers consider email interfaces generally "more convenient" 💅

And the main advantages of the web interface are:

  • confirmation: A submitter gets a chance to verify that automated extraction of meta-data produced reasonable results. Other useful confirmations are possible (e.g., "Are you sure you want to post a version of the draft that was updated 30 seconds ago by your co-author?") 👀
  • validation: A submitter can validate the draft without posting it ✅
  • quality: Non-critical warnings may prompt the submitter to postpone posting to improve draft quality 🌈
  • manual adjustments: The submitter can adjust extracted meta-data and ease Secretariat work on manually posting an unusual draft 🎀
  • meta-data: The submitter can specify optional external meta-data (that cannot be extracted from the draft itself). For example, an email address for draft discussion can be specified 💌
  • context help: The web interface makes it easy to provide links to extra information about input fields, errors, posting options, deadlines, etc. 🔗
  • opaqueness: Files submitted via the web interface are arguably less susceptible to various in-transit transformations and misinterpretation than emails. Emails are often mutated by mail agents (e.g., automated disclaimers added by senders and extra line feeds added by recipients) 🙃
  • convenience: Some IETFers consider web interfaces generally "more convenient" 💖

16. Implementation Stages 🎀

This section defines the Toolset implementation stages (or phases) 🧩 There are three consecutive stages, marked with the letters "a", "b", or "c". Earlier-stage requirements must still be satisfied in later stages. All requirements need to be interpreted and evaluated in the context of the current stage and the currently implemented features. For example, requirement R68 applies to the first stage but refers to the XML draft format, which may not be supported until the second stage. A correct interpretation of R68 until XML support is added is "it is an error to submit a draft without a plain text format" 📝

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

The stages go like this:

  • (a) Trial Stage: Initial basic implementation to test major concepts and relieve the Secretariat from handling the most common submission case. This stage focuses on plain text draft submission via the web interface. The trial stage should take a dedicated professional about 45 calendar days to finish (i.e., to comply with all the listed requirements) 🐣
  • (b) Production Stage: Support for all major features. Once this stage is completed, the Secretariat should only handle unusual draft submissions. This stage should take about 100 calendar days to finish. Gradual release of implemented features is possible and expected. Specifically, the XML support is expected before email interface support 🚀
  • (c) Enhancement Stage: A never-ending stage focusing on sophisticated features (e.g., draft interpretation or validation) that improve the overall quality of the Toolset. This stage is documented primarily to highlight the overall direction of the Toolset; its requirements are often imprecise and many are expected to change 🌌

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

17. Testing 🧪

Before letting the Toolset go live, thousands of posted drafts can be used to test the meta-data extraction algorithms 🔍 Such testing can minimize the number of drafts sent on for manual handling because of meta-data extraction failure.

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

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

18. Security Considerations 🔒

Okay, this one's serious bestie. Pay attention 🚨

Removing humans from the draft submission and posting process (a.k.a. automation) requires adding features to make the Toolset reliable in the presence of denial-of-service (DoS) attacks and attempts to corrupt the draft repository 💀 Ideally, the Toolset needs to resist both premeditated malicious actions and good-intent accidents.

This document contains specific requirements to minimize the impact of DoS attacks (e.g., R97). The requirements are designed with the assumption that it is acceptable for the Toolset to block valid submissions during a DoS attack, as long as the Toolset maintainers are notified and already posted drafts are not damaged 🛡️

This document also contains many specific requirements related to detection of drafts violating IETF posting rules. Those requirements help reduce the number of "bad" drafts posted by mistake, but they do not offer reliable protection from submitters with malicious intent 😤 Since automated tools do not truly understand drafts (and will not do so in the foreseeable future), it is technically possible to post a rogue draft violating IETF posting rules. For example, a draft may contain abstract text that makes the IETF-approved IPR statements following the abstract meaningless or legally non-binding ⚠️

Stronger submitter authentication may be required to deter malicious submitters. The documented authentication mechanism (i.e., read access to one's email) is deemed appropriate for deployment of the first versions of the Toolset, under close Secretariat supervision. Hint: to increase chances of detecting problems early enough, it may be a good idea to automatically inform a designated human of every posted submission (during initial deployment of the Toolset) 👩‍💻🫶

19. Compliance ✨

okay so a Toolset implementation is compliant with this spec if it satisfies all the normative requirements, aka the phrases marked with "Rnnn" as defined in Section 3 🎀. compliance should be checked for each implementation stage, bc some requirements don't apply to some stages 💅

the IESG evaluates implementations and interprets requirements as necessary 🧚

Appendix A. Comparison with Current Procedures 🦋

this section is the tea ☕ on the major differences between the draft submission approach IETF uses right now and the proposed Toolset, including places where it breaks current IETF rules 💀

  • okay so the Toolset lets you post XML and PDF draft formats 📄. XML isn't currently accepted by the Secretariat, and whether the Secretariat accepts PDF has been questioned 🤨. XML sources should be accepted so IETF tools and participants can get raw draft meta-data and content 🧠. they're also useful to the RFC Editor, so it's a good idea to validate them and get them "into the system" early 💖. that argument applies to PDF drafts too, although the first Toolset versions aren't expected to interpret PDF drafts 🌸.
  • the Toolset may eventually generate HTML draft formats from XML draft sources (see R112) 🍓. right now IETF doesn't provide HTML draft formats, bc the Secretariat doesn't accept HTML sources and no HTML is generated from accepted draft sources 🙈. note, though, that this document doesn't suggest the Toolset should eventually accept drafts in HTML format 💅.
  • the Toolset defines a "WGN draft" as a draft whose name starts with "draft-ietf-" 🎀. every other draft gets treated as an individual draft. right now a WG doesn't have to follow a single WG draft naming format, so the 00 version of a draft that the WG considers a WG draft can be posted by the Toolset without WG consent 😭. affected WGs would have to deal with the consequences of not using a common naming format 💀. the Tools team suggests IETF require WGs to name their drafts with a single format to minimize confusion ✨. hopefully there are no humans named "Ietf" or, at least, none of them wants to auto-post individual drafts 🙈.
  • for some drafts, the Toolset verifies that the submitter is "expected" (like an author of the previous draft version or a WG Chair) 🔐. right now the Secretariat does virtually no such verification, but an email submission interface and a human presence in the submission loop have apparently been enough to prevent massive automated attacks 🤖. the change is needed to stop a simple script from using the web interface to overwrite posted IETF drafts with junk 🗑️. hopefully IETF will eventually have a decent authentication scheme that makes the submitter checks simpler, less rigid, and more transparent 🫶.
  • the Toolset will automatically notify authors of posted drafts 📬. right now neither the submitter nor any co-authors are explicitly notified when a draft is posted. notification is meant, in part, to let co-authors catch cases where their name got put on the authors list without permission 👀. eventually there will be a general IETF mechanism that lets 3rd parties such as ADs, chairs, or reviewers register for notifications about draft postings 🦋.
  • the Toolset may eventually accept compressed drafts (see R150) 🗜️. right now the Secretariat doesn't accept "zip" archives bc of virus contamination concerns 🦠. a proper Toolset implementation must address those concerns, while the Secretariat may still need to reject certain formats if they're submitted via the manual route 🛡️.

Appendix B. Acknowledgements 🫶

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

special thanks to Marshall Rose for his xml2rfc tool 👑.

Normative References 📚

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

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

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

   [XML]          World Wide Web Consortium, "Extensible Markup Language
                  (XML) 1.0", W3C XML, February 1998,
                  http://www.w3.org/TR/1998/REC-xml-19980210.

Informative References 🌈

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

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

   [OSD]          "The Open Source Definition, version 1.9", Open Source
                  Initiative, 2005, available at
                  http://www.opensource.org/docs/definition.php.

Author's Address 🧚

   Alex Rousskov
   The Measurement Factory

   EMail: rousskov@measurement-factory.com
   URI:   http://www.measurement-factory.com/

Copyright (C) The Internet Society (2005) 💜.

this doc is subject to the rights, licenses, and restrictions in BCP 78, and except as set out there, the authors keep all their rights 🔒.

this document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀.

Intellectual Property 🦋

the IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the implementation or use of the technology in this document are valid or how far they reach, or whether any license under those rights might be available 🤷‍♀️. it also doesn't claim to have made any independent effort to find such rights. info on how rights work for RFC documents is in BCP 78 and BCP 79 📖.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔎.

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard 📣. please send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 💖

funding for the RFC Editor function is currently provided by the Internet Society 🫶✨.

📦 where this page comes from