TOOLS team A. Rousskov Internet-Draft The Measurement Factory Expires: March 10, 2005 September 9, 2004 Requirements for IETF Draft Submission Toolset draft-ietf-tools-draft-submission-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document specifies requirements for an IETF toolset facilitating Internet-Draft submission, validation, and posting. Rousskov Expires March 10, 2005 [Page 1] Internet-Draft Draft Submission Toolset: Requirements September 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. State of this draft . . . . . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Status quo . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Overall toolset operation . . . . . . . . . . . . . . . . . . 5 7. Upload page . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Check action . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Storage . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.2 Extraction . . . . . . . . . . . . . . . . . . . . . . . . 8 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . 9 8.3.1 Absolute requirements . . . . . . . . . . . . . . . . 9 8.3.2 Desireable features . . . . . . . . . . . . . . . . . 10 9. Check page . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 External meta-data . . . . . . . . . . . . . . . . . . . . 11 10. Post Now action . . . . . . . . . . . . . . . . . . . . . . 11 11. Adjust action . . . . . . . . . . . . . . . . . . . . . . . 12 12. Adjust page . . . . . . . . . . . . . . . . . . . . . . . . 12 13. Post Manually action . . . . . . . . . . . . . . . . . . . . 13 14. Bypassing the toolset . . . . . . . . . . . . . . . . . . . 13 15. Implementation stages . . . . . . . . . . . . . . . . . . . 13 16. Security Considerations . . . . . . . . . . . . . . . . . . 13 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 18. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 14 A. Comparison with current procedures . . . . . . . . . . . . . . 14 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 C. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Rousskov Expires March 10, 2005 [Page 2] Internet-Draft Draft Submission Toolset: Requirements September 2004 1. Introduction Public Internet-Drafts are primary means of structured communication within IETF. Current Internet-Draft submission and posting mechanisms hinder efficient and timely communication while creating unnecessary load on the IETF Secretariat. IETF TOOLs team recommends formalization and automation of the current mechanisms. This document contains specific automation requirements. IETF Secretariat and many IETF participants have long been proponents of automation. This document attempts to reflect their known needs and wishes, as interpreted by the TOOLs team. [[XXX1: Secretariat and participant feedback has not yet been fully relayed to TOOLs team. --Alex]] 2. State of this draft Nothing has been set in stone. The TOOLs team has not yet reached consensus on draft details. Questions marked with "XXX" are some of the known problems the team needs to solve. Please provide an early high-level review of this draft. Is the overall scope and functionality of the toolset appropriate? Are there any key big pieces missing? We need to move fast with these recommendations, so please do not delay your comments. Please ignore language and style bugs for now, unless you find a bug that may result in misinterpretation of the text. RFC Editor Note: This section is to be removed during the final publication of the document. [[XXX36: This section has been inspired by draft-rousskov-newtrk-id-state and related NEWTRK WG discussions. --Alex]] 3. Scope TBD: In scope are interface(s) to submit the draft and requirements on submitted draft review, approval/rejection, and posting. Definition and sources of draft meta-information (to be used in Secretariat databases and elsewhere) are also in scope. Out of scope are things like linking related drafts, draft persistency/archiving, or providing a "monitor this draft" service. If IETF TOOLs team defines a general IETF authentication interface, specifics of authenticating draft submissions become out of this document scope. 4. Terminology Rousskov Expires March 10, 2005 [Page 3] Internet-Draft Draft Submission Toolset: Requirements September 2004 Posted draft: A draft accepted into public IETF draft repository and, hence, publicly available on IETF web site. Posting (a.k.a., publication) of a draft does not imply any IETF or IESG review and endorsement. Submitter: A human or software submitting an Internet-Draft for validation or posting. Authorized Submitter: Any of the draft authors or editors listed in the draft text and any member of IETF Secretariat staff. Immediately: without artificial software delays or human interaction. 5. Status quo This section summarizes the process for draft submission and posting as it exists at the time of writing. To get an Internet-Draft posted on IETF web site, an IETF participant e-mails draft text to the IETF Secretariat, along with an informal note asking 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 IETF web site. Collectively, IETF participants submit thousands of Internet-Drafts per year (about three thousand drafts submitted in the year 2000; 2002: 5K; 2004: 7K). About 30-50% of posted drafts are Working Group drafts (among some 2,100 drafts, there were about 380 new and 290 updated WG drafts posted in 2003). No statistics is available, but the vast majority of submitted drafts are approved by 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 since approved drafts are posted in batches every 4 hours, it may take from several hours to a couple of 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, Secretariat does not accept Internet-Draft submissions close to IETF meetings (regardless of whether a draft is Rousskov Expires March 10, 2005 [Page 4] Internet-Draft Draft Submission Toolset: Requirements September 2004 relevant to the upcoming meeting). Many Working Groups have come up with ad hoc solutions to cope with posting delays. For example, many draft subversions are "temporary" 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 end up being posted on 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, IESG and RFC Editor may have to spend resources (and delay standard approval) resolving violations with draft authors. Often, these violations can be detected automatically and would have been fixed by draft authors if authors knew about them before requesting to publish the draft as a standard. Technically, anybody and anything can submit a draft to the Secretariat. There is no reliable authentication mechanism in place. Initial submissions of WG 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 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. 6. Overall toolset operation This section provides high-level description for the proposed toolset. The description is meant to show overall operation and order; please refer to other sections for details specific to each step. To post a draft, the submitter goes through the following sequence of web pages and actions: Rousskov Expires March 10, 2005 [Page 5] Internet-Draft Draft Submission Toolset: Requirements September 2004 Upload page: Interface to copy draft from submitters computer into the toolset staging area (Section 7). 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 8). Produces the Check page. Check page: Displays draft interpretation and validation results (Section 9). Draft rendering preview may also be given on this page. After reviewing draft interpretation and validation results, the submitter selects one of the following three actions (a) auto-post draft "as is" now; (b) correct extracted meta-data and submit draft to Secretariat for manual posting later; or (c) cancel submission. Automated posting option may not be available for drafts that failed validation. Automated posting: If submitter decides to proceed with automated posting from the Check page, the system authenticates the submitter and checks whether the submitter is allowed to post the draft. If submitter is authorized, the draft is immediately posted, deleted from the staging area, and the submitter is notified of the result (Section 10). Manual adjustment and posting: If submitter decides to adjust meta-data, the draft remains in the toolset staging area, and the Adjust action (Section 11) presents the submitter with an Adjust page (Section 12). When 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 13). Cancellation: If submitter decides to cancel the submission, the draft is deleted from the toolset staging area with no further actions. The following diagram illustrates basic submission logic: /---> Post Now / Upload --> Check --+-----> Adjust ---> Send to Secretariat \ \---> Cancel Except for the Upload page, pages contain submission session identifier to provide actions with access to stored information. The session identifier is invisible to the submitter. A single action may correspond to multiple programs and, vice versa, Rousskov Expires March 10, 2005 [Page 6] Internet-Draft Draft Submission Toolset: Requirements September 2004 a single CGI program may implement several actions. Actions preserve and exchange state by storing it along with draft. Grouping all submission-specific information in one subdirectory named using 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 [[XXX4: need to add details on how each action interacts with IETF infrastructure --Alex]] [[XXX5: add more details about error handling (generation of error pages). Or is it obvious enough? --Alex]] [[XXX6: Secretariat wants to automate "withdraw this ID" action, which seems out of this toolset scope. --Alex]] [[XXX27: Mention that the system must handle (somehow) multiple submitters submitting the same draft. For example, the state should not be per-draft but per-submit-session. --Alex]] 7. Upload page To upload the draft, the submitter goes to a well-known URL on IETF web site. There, two exclusive options are available. First, the draft text can be uploaded using HTML file input form. This form provides input fields to upload plain text format of the draft and all other formats allowed by IETF draft publication rules. At the time of writing, these formats are: XML (RFC 2629), Postscript, and PDF. Second, the draft text can be cut-and-pasted into the form. Only plain text version of the draft can be submitted this way. [[XXX7: do we really need this option? Are there any popular browsers or web libraries that support POST requests but do not support file uploads? --Alex]] Submitted forms are handled by the Check action. [[XXX8: specify that automated submitters can use a post-if-valid hidden form option to bypass explicit confirmation after the successful validation step --Alex]]. [[XXX9: specify that automated submitters can use a validate-only hidden form option to let validator delete drafts from the staging area after validation. Or should this be a visible option, available Rousskov Expires March 10, 2005 [Page 7] Internet-Draft Draft Submission Toolset: Requirements September 2004 to human submitter as well? Perhaps as a "Validate Only" button? Or should we KISS? --Alex]]. 8. Check action The Check action stores submitted draft (all formats) in the staging area, and then extracts meta-data and validates each format. Failure of each operation results in action failure, indicated to submitter via a non-successful HTTP response status code with a human-friendly explanation in the response body. The action needs to store the draft so that successfully validated drafts can later be auto-posted at submitter request. The action needs to extract meta-data to perform validation and posting. Drafts need to be validated to catch broken submissions and to block automated submissions of malformed final draft versions for IETF Last Call and IESG review. 8.1 Storage Validator stores all submitted formats of the draft in a staging area dedicated to the Toolset. If, after garbage collection, the staging area is full (i.e., the total used size reached configured maximum capacity), the operation fails. 8.2 Extraction Each stored draft format is interpreted to extract draft meta-data. [[XXX10: mention somewhere that initially, some formats will not be fully or at all interpreted, but eventually either the format needs to be interpreted or it should not be accepted for automated posting --Alex]]. The following meta-data is extracted by the draft interpreter. identifier: Also known as draft "filename". For example, draft-ietf-tools-draft-submission-13. revision: A non-negative integer also known as draft version. For example, 13 in draft-ietf-tools-draft-submission-13. name: Common part of all draft identifiers for all revisions of the same draft. For example, draft-ietf-tools-draft-submission in draft-ietf-tools-draft-submission-13. WG: IETF working group identifier. WG value is empty for individual drafts or non-IETF drafts. For example, "tools" in draft-ietf-tools-draft-submission-13. Rousskov Expires March 10, 2005 [Page 8] Internet-Draft Draft Submission Toolset: Requirements September 2004 title: A human-friendly draft title. For example, the title of this draft is "Requirements for IETF Draft Submission Toolset" authors: A list of all draft authors. For each author, their first name, last name, and e-mail are extracted. abstract: Draft abstract text. submission date: Draft submission date. expiration date: Draft expiration date. [[XXX11: number of pages and size would depend on format version; they probably should not (do not need to) be specified manually; do we need to extract them at this stage? --Alex]]. 8.3 Validation IETF standards have to follow a set of syntax and semantics requirements [[XXX12: provide references to the nits document and IP policies --Alex]]. Most of those requirements are not enforced for Internet-Drafts. However, following them may improve draft quality, reduce IESG load, and increase the chances of the draft being approved as an RFC. When validating a given draft, it is important to distinguish between absolute requirements and desirable draft properties. Both categories are checked for, but violations have different effects depending on the category. The two categories are detailed in the following subsections. 8.3.1 Absolute requirements Violating any of these requirements would prevent a draft to be automatically posted. The offending draft would have to be fixed or submitted for manual posting, with an explanation why the absolute requirements need to be violated (or why Validator mis-detected violations). 1. All available meta-data entries must match across all submitted draft formats. For example, if the interpreter managed to extract draft title from plain text and PDF version, both titles must match. This requirement prevents accidental submission of mismatching formats. 2. A draft must be submitted by an authorized submitter. [[XXX13: move this lower, we do not know the submitter at this stage --Alex]][[XXX14: Don't forget the co-author, changed editor, and Rousskov Expires March 10, 2005 [Page 9] Internet-Draft Draft Submission Toolset: Requirements September 2004 drafts being posted anonymously (secretariat needs to know who submitter is, but name doesn't necessarily appear on draft) --Harald]] 3. A Working Group draft must be approved by the corresponding working group. 4. Current draft state must allow new revisions to be posted. [[XXX15: document IESG review states when new revisions are allowed. Secretariat and Harald opinions seem to differ here. Secretariat: No revisions are allowed in any state except for "I-D exists", "AD watching", or an explicit IESG request for a new revision. Harald: no revisions once submitted for publication. Need further clarification --Alex]]. 5. Correct draft ID (including correct revision number with respect to already published revisions, if any) must appear in the draft text. 6. An IETF IPR statement must appear in the draft text. [[XXX16: add the applicable parts of RFC 2026, 3667 and 3668 - this is mostly a matter of checking the presence of boilerplate text. --Henrik]] [[XXX17: Today, -00 WG drafts are approved by the Chair after submission, not prior to submission. See "Comparison with current procedures" section. --Alex]] 8.3.2 Desireable features Violating any of the following requirements would NOT prevent a draft to be automatically posted except for draft revision designated for "publication requested" state (i.e., IETF Last Call and IESG review). [[XXX18: should we be that strict with last revisions? --Alex]] TBD: list testable nits here or refer to the nits document. Henrik's idnits tool is a starting point: http://ietf.levkowetz.com/tools/idnits/ [[XXX33: What to do when two versions are submitted with a suspiciously small gap? How small should the gap be to warrant warnings/actions? --Stanislav]] 9. Check page The Check page, created by the Check action displays extracted draft meta-data and validation results. The purpose of the page is to allow the submitter to verify whether stored draft and automatically Rousskov Expires March 10, 2005 [Page 10] Internet-Draft Draft Submission Toolset: Requirements September 2004 extracted meta-data match submitter's intent and to be informed of validation problems. Extracted meta-data items that were not successfully extracted or that failed validation checks must be marked specially (rather than silently omitted). Validation results include errors and warnings, with references to normative documents containing corresponding validation rules. The submitter can also enter external meta-data (Section 9.1), which is required for automated posting of the draft. If validation was successful, an "automatically post the draft now" button is provided. Regardless of validation results, "adjust and post manually" and "cancel" buttons are provided. Finally, a preview of the draft is provided. [[XXX19: should the entire draft be rendered, especially when submission does not include plain text format? --Alex]] [[XXX34: Report the time of the last update. Especially useful when multiple authors might update. --Stanislav]] [[XXX35: How about providing a link to generate a nice diff against the last posted version?. --Alex]] 9.1 External meta-data TBD: Input fields for meta-data that must be supplied by submitter and cannot be extracted from the draft: Which author is the submitter? [[XXX30: with the exception for Secretariat manual submission? No. Secretariat submits on behalf of one of the authors. --Alex]][[XXX31: are there any situations when a draft is submitted by somebody other than author and not on explicit authors behalf? What happens to IPR "by submitting this draft I ..." statement then? --Alex]]; Does the author request this submission to be published? (i.e., forwarded to IESG or RFC Editor for review and publication as an RFC or BCP) [[XXX32: clarify that for-publication submissions may be subjected to more mandatory checks than other drafts. --Alex]]. 10. Post Now action The Post Now action checks that the draft has been successfully validated, validates external meta-data (including submitter e-mail), Rousskov Expires March 10, 2005 [Page 11] Internet-Draft Draft Submission Toolset: Requirements September 2004 and posts the draft. Submitter is notified of the action progress and final result. External data contains submitter e-mail address. As a part of the validation procedure, the Post Now action checks that the submitter has access to e-mail sent to that address. The check is performed by e-mailing a hard-to-guess cookie or token. The submitter is requested to cut-and-paste the token or go to the token-holding URL to continue with the submission. If the submitter does not continue, the submission will eventually timeout. This intermediate dialog requires storing additional state and generating a token-accepting web page. [[XXX2: should the posting program obtain all authors consent? --Alex]][[XXX26: should responding to e-mail be also supported (as an alternative to going back to the web page to cut-and-paste the token)? --Alex]] If draft posting is successful, toolset state information may be deleted from the toolset storage area [[XXX21: on-demand garbage collection may be better from debugging point of view; what may seem like a successful post may not be that successful --Alex]]. 11. Adjust action The Adjust action generates the Adjust page, populating it with available extracted meta-data and external meta-data as well as validation results and preview. Some or all of the information may be missing, depending on draft interpretation and rendering success. 12. Adjust page The Adjust page allows the submitter to adjust all extracted draft meta-data (and, naturally, external meta-data) at will. Such adjustment is necessary when automated extraction failed to extract [correct] information. To avoid mismatch between draft and its meta-data, adjusted drafts cannot be automatically posted and require manual validation by Secretariat. Secretariat staff can post drafts with adjusted meta-data as described in Section 14. In addition to editable meta-data, the page provides read-only validation results and preview, if available. The "post manually" and "cancel" buttons are provided. The former is backed by the "Post Manually" action (Section 13). Rousskov Expires March 10, 2005 [Page 12] Internet-Draft Draft Submission Toolset: Requirements September 2004 13. Post Manually action The Post Manually action sends adjusted meta-data and draft pointer to the Secretariat for manual validation and posting. A receipt page is generated instruction the submitter to wait. Secretariat will notify the submitter once the draft is posted or rejected. 14. Bypassing the toolset A buggy toolset or unusual circumstances may force a submitter to submit draft to Secretariat for manual processing. This can be done by choosing the "manual posting" route supported by the toolset or, as a last resort, by e-mailing the draft directly to Secretariat. In either case, an informal "cover letter" has to accompany the draft. The letter should explain why the automated interface cannot be used. When processing manual submissions, the Secretariat may be able to use the toolset. A Manual Validation page similar to the default Validation page provides authenticated Secretariat staff with editable meta-data fields and a "force posting" action. The forced posting action accepts meta-data fields "as is" and proceeds with the regular posting algorithm [[XXX22: Should we document the details even though this page is for internal Secretariat use? --Alex]][[XXX23: Should forced posting script obtain authors consent or do we want to be able to bypass that as well? --Alex]] Using manual processing may result in significant posting delays. The intent of this mode is to provide a way for submitters to bypass bugs or limitations of automated mechanisms in order to post an "unusual" draft or to post a draft under "unusual" circumstances. One example would be a draft that does not contain standard IETF boilerplate but has a special IESG permission to post the draft with the experimental boilerplate. Another example is a draft that fails automated validation tests due to a validator bug. [[XXX24: mention that sometimes submitter is not the author or chair so default authentication may not work -- unless we provide an interface to authorize "other" submitters? --Alex]] 15. Implementation stages TBD: Come up with a simple way to identify distinct toolset elements/ features and suggest implementation order. 16. Security Considerations Some. TBD: Talk about why authentication and anti-DoS measures Rousskov Expires March 10, 2005 [Page 13] Internet-Draft Draft Submission Toolset: Requirements September 2004 become important once things become automated. When everybody is using an informal e-mail interface, an automated attack will last only until the interface is changed. The informal interface can be changed very quickly. Only the attacker would be suffering from the change, since others do not automate and, hence, are flexible. Once things are automated and interfaces are documented, substantially changing an interface would require rewriting many software agents that use current interfaces. [[XXX25: do we need an explicit IESG approval to require stronger-then-current submitter authentication? --Alex]] 17. IANA Considerations None. 18. Compliance TBD: What does it mean to be compliant with (to satisfy) our requirements? The definition must be usable in the context of IESG evaluation of Secretariat work on implementing the proposed toolset. Appendix A. Comparison with current procedures TBD: This section summarizes major differences between draft submission approach currently in use by IETF and the proposed toolset, including violations of the current IETF rules. o Approval for version -00 of a WG draft. [[XXX28: Clearly point out that we propose to require that working group chairs post an approval *before* a -00 is submitted - there is no option to submit a -00 draft and have it sit and wait for the Chair's approval. This is a change from current procedure, and may need approval from outside the tools team. --Henrik]][[XXX29: I am not sure the current procedure is required by IETF rules. The order does not seem to be codified anywhere so changing current practice should not be that difficult. The key is to convince IETF that the change is worth it long-term. --Alex]] o The toolset allows posting of draft renderings additional to plain text as well as XML draft sources. Currently, the Secretariat only accepts plain text submissions of drafts. o TBD Rousskov Expires March 10, 2005 [Page 14] Internet-Draft Draft Submission Toolset: Requirements September 2004 Appendix B. Acknowledgments The author gratefully acknowledges the contributions of Harald Tveit Alvestrand (Cisco), Barbara B. Fuller (Foretec), Henrik Levkowetz, Larry Masinter (Adobe), and Stanislav Shalunov (Internet2). Special thanks to Marshall Rose for his xml2rfc tool. Appendix C. Change log RFC Editor Note: This section is to be removed during the final publication of the document. Internal WG revision control ID: $Id: id.xml,v 1.12 2004/09/09 21:11:43 rousskov Exp $ 2004/09/09 * Polished high-level page/action summary and replaced text-based steps diagram with something that looks more like a diagram. * Added "Comparison with current procedures" section placeholder for summarizing what this draft improves/changes/violates. * Frequent draft updates is not always a good thing (Henrik Levkowetz) * Added ideas regarding frequent draft updates warnings (Stanislav Shalunov) * Added "State of this draft" section to encourage review. 2004/09/02 * Documented all major toolset pages and corresponding actions. 2004/09/01 * Deleted all primary modes except for what used to be called "Posting Automation". Focus on the latter and mention other modes as exceptions or side-effects. * Changed draft outline and depth to describe specific submission steps and corresponding web pages rather than more general ideas/requirements. * Assume, for now, that Chair authorization of WG draft work must exist for WG draft to be published. This needs to be Rousskov Expires March 10, 2005 [Page 15] Internet-Draft Draft Submission Toolset: Requirements September 2004 documented and perhaps relaxed to allow post-submission approvals. 2004/08/30 * Use "toolset" instead of a less accurate "interfaces" in the draft title and throughout the text (Henrik Levkowetz) * Use "post" instead of "publish"" in the draft title and throughout the text (Barbara B. Fuller and Larry Masinter) * Nits, clarifications, datapoints (Harald Tveit Alvestrand, Henrik Levkowetz, Larry Masinter, and Barbara B. Fuller for the Secretariat) 2004/08/25 * Initial revision. Author's Address Alex Rousskov The Measurement Factory EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/ Rousskov Expires March 10, 2005 [Page 16] Internet-Draft Draft Submission Toolset: Requirements September 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rousskov Expires March 10, 2005 [Page 17]