TOOLS team A. Rousskov
Internet-Draft The Measurement Factory
Expires: April 13, 2005 October 13, 2004
Requirements for IETF Draft Submission Toolset
draft-ietf-tools-draft-submission-04
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 April 13, 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 April 13, 2005 [Page 1]
Internet-Draft Draft Submission Toolset: Requirements October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. State of this draft . . . . . . . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4
5. Status quo . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Overall Toolset operation . . . . . . . . . . . . . . . . . . 6
7. Upload page . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Check action . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Preprocessing . . . . . . . . . . . . . . . . . . . . . . 9
8.2 Processing . . . . . . . . . . . . . . . . . . . . . . . . 10
8.3 Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.4 Extraction . . . . . . . . . . . . . . . . . . . . . . . . 10
8.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . 12
8.5.1 Absolute requirements . . . . . . . . . . . . . . . . 13
8.5.2 Desireable features . . . . . . . . . . . . . . . . . 14
9. Check page . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1 External meta-data . . . . . . . . . . . . . . . . . . . . 15
10. Post Now action . . . . . . . . . . . . . . . . . . . . . . 16
10.1 Receipt page . . . . . . . . . . . . . . . . . . . . . . . 16
11. Adjust action . . . . . . . . . . . . . . . . . . . . . . . 17
12. Adjust page . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Post Manually action . . . . . . . . . . . . . . . . . . . . 17
14. Receipt page . . . . . . . . . . . . . . . . . . . . . . . . 18
15. Bypassing the Toolset . . . . . . . . . . . . . . . . . . . 18
16. E-mail interface . . . . . . . . . . . . . . . . . . . . . . 19
17. Implementation stages . . . . . . . . . . . . . . . . . . . 20
18. Security Considerations . . . . . . . . . . . . . . . . . . 22
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
20. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 23
A. Comparison with current procedures . . . . . . . . . . . . . . 23
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
C. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 31
Rousskov Expires April 13, 2005 [Page 2]
Internet-Draft Draft Submission Toolset: Requirements October 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. The IETF TOOLs team
recommends formalization and automation of the current mechanisms.
This document contains specific automation requirements.
The IETF Secretariat and many IETF participants have long been
proponents of automation. This document attempts to reflect their
known needs and wishes, as interpreted by the TOOLs team.
2. State of this draft
While nothing has been set in stone yet, this draft approaches its
stable state. Text marked with "XXX" usually contains informal
descriptions of known problems the team still needs to solve. These
"XXXs" are uniquely numbered for ease of reference. Only a few
serious XXXs remain.
Please review this draft. Comments on substance and XXX issues are
requested. Editorial comments would be most useful at a later stage,
when most XXXs are resolved and draft text is polished. Please post
comments on tools-discuss@ietf.org mailing list or e-mail them
directly to the author.
RFC Editor Note: Please remove this section for the final publication
of the document. It has been inspired by
draft-rousskov-newtrk-id-state and related NEWTRK WG discussions.
3. Scope
The Draft Submission Toolset discussed in this document is about
getting a single new revision of an Internet-Draft from an IETF
participant to the IETF draft repository. A single draft revision
may include several formats, and dealing with those formats is in
scope for the Toolset. Definition and sources of draft
meta-information (to be used in Secretariat databases and elsewhere)
are in scope. Submitter authentication and submission authorization
are in scope.
Draft posting may result in various notifications sent to interested
parties. While this document recommends a subset of notification
targets, details of notifications are out of scope.
Creation of new drafts or new draft revisions as well as
manipulation, visualization, and interaction with the drafts already
Rousskov Expires April 13, 2005 [Page 3]
Internet-Draft Draft Submission Toolset: Requirements October 2004
in the repository are out of scope. Draft expiration and archiving
of old draft revisions are out of scope.
4. Notation and Terminology
The following terms are to be interpreted according to their
definitions below. [[XXX48: delete unused terms, if any. --Alex]]
posted draft: A draft accepted into public IETF draft repository and,
hence, publicly available on IETF web site. Posting of a draft
does not imply any IETF or IESG review and endorsement.
submitter: A human or software initiating submission of an
Internet-Draft for validation or posting. In some cases, the
Secretariat staff does the actual submission, but always on behalf
of a submitter. In some cases (including but not limited to
malicious attacks), the submitter is not the draft author.
lawful submitter: A submitter that is authorized by IETF rules to
post a given draft. This includes a draft author or editor
(listed in the draft text), a corresponding WG Chair, or an IESG
member.
authorized submitter: A lawful submitter authenticated by the Toolset
as such. Author authentication is initially limited to verifying
author's access to author's e-mail address listed in the draft.
draft version: [[XXX68: Define and check whether version or revision
should be used. --Alex]]
draft format: Any draft source or presentation format, including
original and preprocessed XML, original or generated plain text as
well as PDF, Postscript, and HTML formats. [[XXX67: change "draft
version" to "draft format" where appropriate. --Alex]]
primary draft format: The first available draft format from the
following list: plain text, Postscript, PDF, XML.
immediately: without human interaction or artificial software delays.
The Toolset is specified using a set of normative requirements.
These requirements are English phrases ending with an "(Rnnn)" mark,
where "nnn" is a unique requirement number.
This document specifies interface and functionality of the Toolset,
not details of a Toolset implementation. However, implementation
hints or examples are often useful. To avoid mixup with Toolset
requirements, such hints and examples are often marked with a "Hint:"
Rousskov Expires April 13, 2005 [Page 4]
Internet-Draft Draft Submission Toolset: Requirements October 2004
prefix. Implementation hints do not carry any normative force, and a
different implementation may be the best choice.
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 (in the year 2000, about three thousand drafts were
submitted; 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). While no rejection
statistics is available, 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, 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, Secretariat does not accept Internet-Draft
submissions close to IETF meetings (regardless of whether a draft is
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
"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 IETF web site.
Informal interfaces for submitting and posting drafts discourage
Rousskov Expires April 13, 2005 [Page 5]
Internet-Draft Draft Submission Toolset: Requirements October 2004
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 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.
6. Overall Toolset operation
This section provides a high-level description for the proposed
Toolset. The description is meant to show overall operation and
order; please refer to other sections for details specific to each
step.
A typical submitter goes through a sequence of 2-4 web pages and
associated actions. The number of pages depends on the draft
validation and meta-data extraction results. For example, validating
the draft without posting it requires interacting with two web pages:
Upload and Check. The common case of posting a valid draft without
manual meta-data adjustments takes three web pages (Upload, Check,
Receipt).
Here is a brief overview of pages and actions:
Rousskov Expires April 13, 2005 [Page 6]
Internet-Draft Draft Submission Toolset: Requirements October 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 preview may also be given on this page. After
reviewing 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 checks 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 e-mail and Receipt page (Section 10).
Manual adjustment and posting: If the 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). The submitter is notified of the pending
Secretariat request via e-mail and Receipt page.
Cancellation: If the submitter decides to explicitly cancel the
submission, the draft is deleted from the Toolset staging area and
an appropriate Receipt page is generated with no further actions.
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 diagram illustrates the basic submission logic:
/---> Post Now
/
Upload --> Check -+-----> Adjust ---> Send to Secretariat
\
\---> Cancel
Rousskov Expires April 13, 2005 [Page 7]
Internet-Draft Draft Submission Toolset: Requirements October 2004
If the submitter does not select any explicit action for 1 hour, then
the submission is considered abandoned, and all corresponding state
may be deleted by garbage collection (R66). The staging area
maintenance algorithms must be robust in the presence of DoS attacks
attempting to overwhelm the area with fake submissions in various
stages (R67).
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
supported by a single or several CGI scripts (or even applets).
The Toolset must handle multiple submitters simultaneously submitting
the same draft (R72) and a single submitter simultaneously submitting
two drafts (R73). The latter might happen, for example, when the
submitter is using several browser windows to submit several drafts
or is submitting drafts via e-mail 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 draft version or
the submitter. While the nature of the web interface allows the
session identifier to be invisible to the submitter, e-mail
communication would need to identify the session so that the
recipient (and Toolset) know the context.
Hint: A single action may correspond to multiple programs and, vice
versa, 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
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 15
[[XXX4: Need to add details on how each action interacts with IETF
infrastructure. --Alex]]
7. Upload page
To upload the draft, the submitter goes to a well-known page on the
IETF web site (R1). There, the draft text can be uploaded using an
HTML file input form. This form provides input fields to upload
plain text format of the draft (R2) and all other formats allowed by
IETF draft publication rules (R3). At the time of writing, these
formats are: XML (RFC 2629 and draft-mrose-writing-rfcs),
Rousskov Expires April 13, 2005 [Page 8]
Internet-Draft Draft Submission Toolset: Requirements October 2004
Postscript, and PDF [[XXX66: is XML currently allowed? --Alex]].
Submitted forms are handled by the Check action (R5).
The Toolset should have a Validation page, identical to the Upload
page with the exception of its action. Submitting a draft via the
Validation page causes the draft to be validated exactly like using
Upload page would (R74). Regardless of the validation results, the
stored draft meta-data is marked so that validation-only drafts can
be identified and deleted first by garbage collector for the Toolset
staging area (R75). Drafts uploaded via the Validation page cannot
be be posted (R76); they would need to be uploaded via Upload page
for that, and the validation results page should explain that (R77).
This page, hosted at a well-known location, would be useful for tools
using online validation, especially for bulk draft processing.
8. Check action
The Check action preprocesses XML draft source (if any), generates
plain text format (if needed), stores submitted draft (all formats)
in the staging area, and then extracts meta-data and validates each
format (R6). Errors and warnings are indicated to the submitter in
the response via computer-friendly tag(s) and human-friendly text
(R7).
If any error is found, automated posting becomes impossible (R113),
but the Toolset still gives the submitter an option of sending the
draft for manual validation and posting (R114). Since each
submission is treated in isolation, the submitter also has an option
of correcting the problem and resubmitting for automated posting.
It is an error to submit a draft which has neither plain text nor XML
sources format (R68). XML source is acceptable without accompanying
plain text only if the Toolset successfully generates a draft in
plain text format from the XML source, as a part of the processing
step (R69).
8.1 Preprocessing
XML source containing XML processor <rfc? include="..."> instructions
(PIs) is preprocessed to include references (R8). This step is
needed to remove external dependencies from XML sources and to
simplify tools processing posted XML.
The XML preprocessor uses public database(s) to resolve PI references
(R85). The Toolset documentation specifies what databases are used
and how PIs are mapped to database entries (R86). The Toolset must
not rely on PIs existence (R87) because some XML sources will be
Rousskov Expires April 13, 2005 [Page 9]
Internet-Draft Draft Submission Toolset: Requirements October 2004
preprocessed before the submission or will be written without PIs.
Hint: Local up-to-date copies of Marshall Rose's reference databases
at xml.resource.org can be used.
Both original and preprocessed XML sources may be posted later. The
original source with include PIs may be useful to the RFC Editor and
generation of diffs (against future or past original sources). The
preprocessed version without PIs becomes the default public XML
source of the posted draft (R10). If any of the include PIs known to
the Toolset cannot be handled, an error is recorded (R11), and the
submitter is encouraged to do the preprocessing locally, before
submitting the draft (R111).
Draft formats other than XML are not preprocessed.
8.2 Processing
When no plain text version of the draft is submitted, but XML sources
are available, the Toolset attempts to generate plain text version
from submitted XML sources (R70).
If XML sources are available, the Toolset generates HTML draft format
(R112). HTML generation failures should result in warnings, not
errors (R115).
8.3 Storage
XML source needs to be preprocessed to resolve XML processor
instructions to include references. The action needs to store all
draft formats so that successfully validated drafts can later be
auto-posted at submitter request. The action needs to extract draft
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.
The Check action stores all submitted formats of the draft in a
staging area dedicated to the Toolset (R12). If, after garbage
collection, the staging area is full (i.e., the total used size
reached configured maximum capacity), the submitter and the
Secretariat are notified of a fatal error (R13).
8.4 Extraction
XML source needs to be preprocessed to resolve XML processor
instructions to include references. The action needs to store all
draft formats so that successfully validated drafts can later be
auto-posted at submitter request. The action needs to extract draft
Rousskov Expires April 13, 2005 [Page 10]
Internet-Draft Draft Submission Toolset: Requirements October 2004
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.
Each stored draft format is interpreted to extract draft meta-data
(R14). If a given format is interpreted and meta-data extraction
fails, the Toolset records an error (R15).
Section 17 documents a non-obvious implementation schedule related to
the above two requirements. When only partial support for format
interpretation is available, only interpreted formats are subject to
extraction and validation requirements. In other words, if the
Toolset does not yet support interpretation of a given format, then
the corresponding information is stored and made available "as is",
regardless of the actual content.
The draft interpreter extracts the following meta-data from each
draft format (R16).
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 ID: IETF working group identifier. WG value is empty for
individual drafts not meant to be work items of a known WG and for
non-IETF drafts. For example, "tools" in
"draft-ietf-tools-draft-submission-13" and "opes" in
"draft-rousskov-opes-ocp-00" are both WG IDs.
WG flag: True for IETF WG drafts and false for all other drafts. For
example, "true" for "draft-ietf-tools-draft-submission-13".
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.
Rousskov Expires April 13, 2005 [Page 11]
Internet-Draft Draft Submission Toolset: Requirements October 2004
submission date: Draft submission date.
expiration date: Draft expiration date.
size: The number of pages and octets in primary format of the draft.
The definition of a page depends on the format and may be
imprecise or arbitrary for some formats.
Initially, the Toolset uses draft name to extract WG ID (R88) and to
detect WG drafts (R89). Currently, WG drafts do not have to contain
WG name as a third component. If IETF policy is not changed to
require uniform naming of WG drafts, the Toolset can eventually
consult IETF databases to check WG status of individual-looking
drafts (R90).
If e-mail of an author cannot be extracted, the Toolset reports a
warning (R95). E-mails are essential for notifying co-authors that
their draft has been posted. If there are no such notifications, a
submitter adding a co-author to the draft without co-author consent
may not be caught for a while. Such "surprise" co-authorships has
happened in the past and can be quite annoying. However, since the
Toolset does not solicit co-authors consent to post a valid draft
(and such solicitation would not go beyond e-mail control
verification anyway), it is not possible to stop a malicious
submitter from adding co-authors without their consent. A warning is
usually sufficient for a good-will submitter, while a malicious
submitter can easily circumvent a strict enforcement of the "all
authors must have and control their e-mails" policy by adding a wrong
e-mail address for an unaware co-author.
8.5 Validation
XML source needs to be preprocessed to resolve XML processor
instructions to include references. The action needs to store all
draft formats so that successfully validated drafts can later be
auto-posted at submitter request. The action needs to extract draft
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.
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.
Rousskov Expires April 13, 2005 [Page 12]
Internet-Draft Draft Submission Toolset: Requirements October 2004
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.5.1 Absolute requirements
Violating any of these requirements would prevent a draft to be
automatically posted (R17). 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). These explanations may speedup Secretariat
posting decision and may help help Secretariat to improve Toolset
implementation.
1. All available meta-data entries must match across all submitted
draft formats (R18). 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 (R19).
[[XXX13: move this lower, we do not know the submitter at this
stage --Alex]][[XXX14: Don't forget the co-author, changed
editor, and 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 as a WG draft by the
corresponding Working Group (R20). This approval is usually
relayed before or after the submission of the -00 version of the
draft, by a Chair or Secretary of the corresponding WG. [[XXX58:
Document what the Toolset must do if no approval exists at the
time of the submission. --Alex]]
4. Correct draft ID (including correct revision number with respect
to already published revisions, if any) must appear in the draft
text (R22).
5. An IETF IPR Statement and other boilerplate required for drafts
according to RFC 3667 and 3668 (or successors) must appear in the
draft text (R23).
6. Posting this draft must not result in any Denial of Service
attack threshold to be crossed (R97). "Individual" DoS threshold
for a given draft is 3 revisions per day. "Global" DoS
thresholds for all drafts are 500 submissions and 1GByte worth of
Rousskov Expires April 13, 2005 [Page 13]
Internet-Draft Draft Submission Toolset: Requirements October 2004
data in past 24 hours. 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.
Hint: Bandwidth available for submissions may need to be throttled to
make reaching the daily size quota (with malicious intent) difficult.
Toolset should warn the Secretariat if total submissions are
approaching any global threshold.
8.5.2 Desireable features
Violating any of the following requirements does not prevent the
submitter to auto-post the draft (R24).
1. 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/
2. New draft revisions are expected (R21). For example, revision 00
of an individual draft is always expected, while posting a
revision of a draft already under IESG review should generate a
warning.
3. Last revision was posted at least 24 hours ago (R96). This
warning may prevent some human errors, especially when multiple
authors may post the same draft.
When a valid draft is being posted and submitter authorization or
co-author notification is performed, validation results should be
included in the e-mail (R81) so that the submitter can see meta-data
extraction and validation warnings. Note that the results cannot
include errors since only valid drafts can be posted.
9. Check page
The Check page, created by the Check action displays extracted draft
meta-data and validation results (R25). The purpose of the page is
to allow the submitter to verify whether the stored draft and
automatically 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) (R26). Validation messages include both errors and
warnings. Each validation message should refer to normative
document(s) containing corresponding validation rules (R27).
Rousskov Expires April 13, 2005 [Page 14]
Internet-Draft Draft Submission Toolset: Requirements October 2004
The submitter can also enter external meta-data (Section 9.1), which
is required for automated posting of the draft (R28). If validation
was successful, an "automatically post the draft now" button is
provided (R29). Regardless of validation results, "adjust and post
manually" and "cancel" buttons are provided (R30).
The Check page provides a preview of the draft plain text format
(R31), with a link to see how the entire draft (with all its formats)
would look like if posted (R82). Hint: the Check page preview should
be sufficiently long to let authors detect obvious draft mismatch or
misinterpretation errors but short enough to avoid dominating the
page. Displaying draft image from the first line up to the last line
of the abstract may be sufficient.
For draft updates, the Check page reports the the time and the
submitter of the last update (R83). This information is especially
useful when multiple authors are working on the same draft. The page
also provides a link to generate a diff against the last posted
version (R84).
9.1 External meta-data
The Check page solicits the following meta-data from the submitter.
This information must be supplied by submitter because it cannot be
extracted from the draft:
Submitter e-mail (R32). When submitter is not a lawful submitter
(see Section 4), automated posting is not possible and the draft
has to go through the Secretariat (R98). Hint: A set of
checkboxes next to extracted author names along with a "none of
the above" checkbox with an input field would suffice.
List of drafts obsoleted by this draft (R33). This is useful to
make obsoleted drafts invisible. This document does not specify
any actions necessary to make an existing draft obsolete because
existing draft manipulation is out of scope, and because security
concerns and other complications of such actions would be better
addressed by a separate specification.
Primary e-mail address for discussion of this draft (R71). Hint:
The Toolset can suggest WG mailing list address for WG drafts,
[submitting] author address for individual drafts, or even the
first e-mail address in draft text. Offering a few likely
addresses instead of relying exclusively on user input would also
reduce the number of typos.
Except for the submitter e-mail, external meta-data is optional
(R109).
Rousskov Expires April 13, 2005 [Page 15]
Internet-Draft Draft Submission Toolset: Requirements October 2004
10. Post Now action
The Post Now action checks that the draft has been successfully
validated (R34), validates external meta-data (including submitter
e-mail) (R35), and posts the draft (R36). Submitter is notified of
the action progress and final result (R37).
External meta-data contains submitter e-mail address. As a part of
the validation procedure, the Post Now action authorizes the
submitter. The initial action implementation checks that the
submitter has access to e-mail sent to that address (R38).
Eventually, the Toolset should accept client certificates signed by
IETF, PGP-signed e-mail, and/or other forms of client-side
authentication to eliminate the weak and annoying e-mail access check
(R110). If submitter authentication fails, the submission eventually
and silently times out (R39).
The Toolset provides both e-mail and web interfaces for confirming
e-mail access (R99). Hint: To check submitter's access to e-mail the
tool can e-mail a hard-to-guess cookie or token to the submitter's
address. To continue with the submission, the submitter is requested
to either go to the token-holding URL or respond the the e-mail.
Immediately after sending an e-mail to the submitter, the The Post
Now action generates an intermediate Receipt page that explains
Toolset expectations and provides the submitter with the submission
ID (R100). That number allows the Secretariat to troubleshoot stuck
submissions and can also be used for checking submission status
(R101).
Immediately after posting the draft, the Toolset notifies all authors
(with known e-mail addresses) of the posting (R102). Notification
e-mail contains information available on the "successful posting"
Receipt page described below (R103).
If draft posting is successful, the submission state is marked as
available for deletion (R105) so that the garbage collection routine
eventually deletes it.
10.1 Receipt page
A successful Post Now action reports the following information on the
final Receipt page (R104):
o draft ID and a link to the draft status page;
o draft title, authors, and abstract;
Rousskov Expires April 13, 2005 [Page 16]
Internet-Draft Draft Submission Toolset: Requirements October 2004
o submission ID and a link to the draft submission status page.
o submitter name and e-mail.
The primary purpose of the Receipt page is to inform all draft
authors that [supposedly] their draft has been posted. The secondary
purpose is to let authors create a permanent record of the event and
troubleshoot postings. The same information should be sent to other
parties interested in the draft (e.g., WG mailing list), but 3rd
party notification specifics are out of this draft scope.
11. Adjust action
The Adjust action generates the Adjust page (R40), 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 preview generation
success.
12. Adjust page
The Adjust page includes the same information as the Check page, but
allows the submitter to adjust all extracted draft meta-data (and,
naturally, external meta-data) at will (R41). 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 (R42). Secretariat staff can post drafts
with adjusted meta-data as described in Section 15.
The Adjust page allows the submitter to enter an informal comment
explaining why adjustments are necessary and automated posting mode
cannot be used (R48).
The "post manually" and "cancel" buttons are provided (R43). The
former is backed by the "Post Manually" action (Section 13).
13. Post Manually action
The Post Manually action sends adjusted meta-data and draft pointer
to the Secretariat for manual validation and posting (R44). A
receipt page is generated instruction the submitter to wait (R45).
Secretariat will notify the submitter once the draft is posted or
rejected. This notification is sent by the Toolset if the
Secretariat is using the Toolset to post the draft (R46).
Rousskov Expires April 13, 2005 [Page 17]
Internet-Draft Draft Submission Toolset: Requirements October 2004
14. Receipt page
The Receipt page is generated by various actions to inform the
submitter of current submission status and further actions. The
contents of the page is likely to be highly dependent on the action
and state for which receipt is being generated. This section
documents general requirements applicable to all actions and states.
The Receipt page should give the submitter a URI or another
identifier that can be used by Secretariat for manual troubleshooting
of the submission (R63). The identifier should be perpetual (R64)
even though the associated details are likely to be eventually lost
(e.g., draft submission data and logs are deleted from the staging
area as a part of the garbage collection routine).
The Receipt page should give the submitter a Secretariat
point-of-contact to report submission problems (R65).
15. Bypassing the Toolset
A buggy Toolset implementation or unusual circumstances may force a
submitter to submit a draft to Secretariat for manual processing.
This can be done by choosing the "manual posting" route supported by
the Toolset (R47) 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 Check page similar to the default Check
page provides authenticated Secretariat staff with editable meta-data
fields and a "force posting" action (R50). The forced posting action
accepts meta-data fields "as is", does not verify submitter access to
e-mail or WG draft authorization, and posts the draft as if no
validation errors were found (R51). The Manual Check page should
still contain all the errors and warnings seen by ordinary submitters
(R106) so that the Secretariat knows what the Toolset is unhappy
about (if anything).
Using manual processing may result in significant posting delays.
Generated submission receipts or notifications ought to give the
submitter an expected processing time estimate (R53).
The intent of this mode is to provide a way for submitters to bypass
bugs or limitations of the automated mechanisms in order to post an
"unusual" draft or to post a draft under "unusual" circumstances.
One example would be a draft that does not contain standard IETF
boilerplate but has a special IESG permission to post the draft with
Rousskov Expires April 13, 2005 [Page 18]
Internet-Draft Draft Submission Toolset: Requirements October 2004
the experimental boilerplate. Another example is a draft that fails
automated validation tests due to a validator bug.
The bypass mode is also likely to be used (effectively) by the
majority of submitters during the Beta stage of the Toolset
implementation, when few submitters know about (or are allowed to
use) the Toolset.
16. E-mail interface
The Toolset should have e-mail interface for automated posting of
valid drafts (R55). While virtually every documented Toolset
functionality can, technically, be implemented behind an e-mail
interface, features other than posting of valid drafts are believed
to be prohibitively awkward to implement or use via e-mail.
The e-mail interface accepts a draft as a set of e-mail attachment(s)
(one per draft format) (R56), uses sender's e-mail address to select
submitter's identity (R57), checks the submission (R58), and posts
the draft if the check is successful (R59). The submitter should be
notified of the outcome of the draft submission via e-mail (R60).
Other requirements for web interface (including requirements on draft
validation, submitter authentication, draft posting, and
notification) apply to e-mail interface.
E-mail parts/attachments that are not recognized as draft formats are
not considered as draft formats. Such parts are ignored by the
Toolset (R107), except a warning is generated for each unrecognizable
part containing more than whitespace (R108). These two requirements
are meant to make the interface robust in the presence of e-mail
signatures and other parts outside of the submitter control.
Hint: Toolset actions can be implemented to support e-mail and web
interfaces without code duplication.
While both web and e-mail interfaces allow for fast posting of valid
drafts, there are significant differences between the two interfaces.
Primary advantages of e-mail interface are:
off-line mode: A submitter can do all the manual work required to
submit a draft while being disconnected from the network. The
e-mail client actually submits the draft when connectivity is
regained.
poor connectivity: E-mail systems are often better suited for
automated transmission and re-transmission of e-mails when network
connectivity is poor due to high packet loss ratios, transmission
delays, and other problems.
Rousskov Expires April 13, 2005 [Page 19]
Internet-Draft Draft Submission Toolset: Requirements October 2004
convenience: Some IETFers consider e-mail interfaces as generally
"more convenient".
Primary advantages of web interface are:
confirmation: A submitter is given a chance to verify that automated
extraction of meta-data produced reasonable results. Other useful
confirmations are possible (e.g., "Are you sure you want to post a
revision 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
e-mail for draft discussion can be specified.
context help: Web interface makes it easy to provide links to extra
information about input fields, errors, posting options,
deadlines, etc.
convenience: Some IETFers consider web interfaces as generally "more
convenient".
17. Implementation stages
This section defines an implementation schedule for documented
Toolset requirements. The schedule is divided into three consecutive
phases. Requirements listed in later stages may be covered in
earlier stages, but do not have to be.
Beta Stage: Initial basic implementation to test major concepts and
relieve the Secretariat from handling the most common submission
case. This stage should take a professional about 30 calendar
days to finish (i.e., to comply with all the listed requirements).
1. R14 and R15 for plain text format. Other formats are accepted
but may not be interpreted.
2. R32, R98 (submitter:author mapping).
Rousskov Expires April 13, 2005 [Page 20]
Internet-Draft Draft Submission Toolset: Requirements October 2004
3. R38 (submitter authentication via e-mail access check)
4. R69, R70, and related requirements can be ignored, in which
case plain text version is always required.
5. R88, R89 (WG info extraction from draft name).
6. R97 (DoS prevention).
7. R100 (intermediate receipt page for Post Now).
8. R105 (deleting submission state).
9. R109 (most external meta-data is optional).
10. R113 (errors make auto-posting impossible).
Production Stage: Support for all major features. Once this stage is
completed, the Secretariat should only handle unusual draft
submissions. This stage should take a professional about 90
calendar days to finish.
1. R8, R10, R11, R85 - R87, R111 (
2. R14 and R15 for plain text and XML formats. Other formats are
accepted but may not be interpreted.
3. R21 (warn if draft revision is not expected).
4. R55 - R60, R107 - R108 (basic e-mail interface).
5. R69, R70.
6. R71
7. R74 - R77.
8. R83 (report last update author/timestamp).
9. R95 (warn of a co-author without an e-mail).
10. R96 (warn of small submissions gap).
11. R102 - R104 (posting notification).
12. R50, R51, and R106 (Manual Check page requirements).
13. R114 (whatever the error is, manual posting should be
Rousskov Expires April 13, 2005 [Page 21]
Internet-Draft Draft Submission Toolset: Requirements October 2004
possible).
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.
1. R14 and R15 for all formats.
2. R33 (making an existing draft obsolete).
3. R81 (show warnings to co-authors).
4. R82 (complete draft preview).
5. R84 (a link to generate a diff).
6. R90 (WG info extraction from draft databases).
7. R101 (functionality to check submission status).
8. R110 (submitter authentication via client-side certificates)
9. R112, R115 (HTML generation from XML sources)
Implementation experience is likely to result in changes of the
Toolset requirements. Such changes should be documented as a part of
stage evaluation activities.
18. Security Considerations
Some. TBD: Talk about why authentication and anti-DoS measures
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.
19. IANA Considerations
None.
Rousskov Expires April 13, 2005 [Page 22]
Internet-Draft Draft Submission Toolset: Requirements October 2004
20. Compliance
A Toolset implementation is compliant with this specification if it
satisfies all normative requirements (i.e., the phrases marked with
"Rnnn" as defined in Section 4). Compliance should be evaluated for
each implementation stage as some requirements do not apply to some
stages.
IESG evaluates implementations and interprets requirements as
necessary.
Appendix A. Comparison with current procedures
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 The Toolset allows posting of XML and PDF draft formats. XML
format is not currently accepted by the Secretariat, and legality
of PDF acceptance by the Secretariat has been questioned. XML
sources should be accepted to enable IETF tools and participants
to have access to raw draft meta-data and content. They are also
useful to the RFC Editor and, hence, it is a good idea to validate
and get them "into the system" early. The latter argument applies
to PDF drafts as well, although the first Toolset versions are not
expected to interpret PDF drafts. [[XXX64: Check whether there
are any rules allowing the Secretariat to accept PDF drafts today.
--Alex]]
o The Toolset allows posting of HTML draft formats (in addition to
plain text or another currently allowed format).
o The Toolset will automatically notify authors of posted drafts.
Currently, neither the submitter nor any of the co-authors are
explicitly notified when the draft is posted. Notification is
meant, in part, to allow co-authors detect cases where their name
is put on the authors list without permission. Eventually, there
will be a general IETF mechanism to allow 3rd parties such as ADs,
chairs, or reviewers to register for draft notifications.
Appendix B. Acknowledgments
The author gratefully acknowledges the contributions of Harald Tveit
Alvestrand (Cisco), Brian E. Carpenter (IBM), Barbara B. Fuller
(Foretec), Henrik Levkowetz, Larry Masinter (Adobe), Pekka Savola
(Netcore), and Stanislav Shalunov (Internet2).
Rousskov Expires April 13, 2005 [Page 23]
Internet-Draft Draft Submission Toolset: Requirements October 2004
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.23 2004/10/13
05:51:23 rousskov Exp $
version 04
* In Check action, documented once, early, and explicitly that
errors make auto-posting impossible but should let the
submitter to post manually. Removed references to vague
"action fails" statements (Henrik Levkowetz).
* HTTP error codes should not be used to indicate Check action
errors because doing so would be a layering violation and, in
some cases, may complicate both automated and manual
interpretation of the Toolset responses. Rewrote R7 to require
use of computer-friendly tags in response body instead of HTTP
status codes.
* Split "Preprocessing" subsection into "Preprocessing" and
"Processing". The former deals with XML include PIs while the
latter talks about plain text and HTML generation (Henrik
Levkowetz).
* Removed post-if-valid functionality (R78 - R80). Automation
tools such as the ones that process e-mail-based submissions
would benefit from having the knob, but they cannot use the
Check action "as is", even with the knob, because there are
other differences in the interface (e.g., submitter
identification logic). In other words, more knobs would be
needed, which would defeat the purpose of reusing the same
action. When implementing web and e-mail interfaces, the
Secretariat should still be able to reuse the base action code,
of course.
* Defined compliance.
* Resolved XXX2: inform all authors that their draft was posted.
Documented what information should go into the posting
notification message/page.
* Resolved XXX16 and XXX57: R23 now says that an IETF IPR
Statement and other boilerplate required for drafts according
Rousskov Expires April 13, 2005 [Page 24]
Internet-Draft Draft Submission Toolset: Requirements October 2004
to RFC 3667 and 3668 (or successors) must appear in the draft
text (Henrik Levkowetz).
* Resolved XXX23 and XXX62: Manual Check page and actions used by
secretariat do not verify submitter access to e-mail. Last
resort option should be as flexible and forgiving as possible.
* Resolved XXX26: it should be possible to respond to
do-you-have-access-to-your-email message by e-mail, in addition
to cut-and-pasting a URL.
* Resolved XXX30 and XXX31: R98 now requires that when submitter
is not an author, Secretariat has to be involved.
* Resolved XXX37: E-mail submissions must use attachments, even
if there is only one draft format. This may help to keep the
Toolset simple (no smarts needed to isolate true draft text
from notes in the beginning of the e-mail and signatures).
* Resolved XXX38: do not require special Subject: lines for
e-mail submission to keep the Toolset simple. Since we verify
submitter access to e-mail, no automated spam is likely to
result in a draft submission.
* Resolved XXX43, XXX44, and XXX60: making an existing draft
obsolete is out of this document scope. This complex feature
can be documented and integrated later to satisfy R33.
* Resolved XXX49 and XXX52: the first two implementation stages
should take 30 and 90 days, provided a single full-time person
effort.
* Resolved XXX50: specify approximate effort required to complete
the first two implementation stages. Let IESG and the
Secretariat use our estimates to agree on a specific
implementation schedule/deadlines.
* Resolved XXX53: lack of author e-mail causes a warning, not
error. See R95 for rationale.
* Resolved XXX11: added page count and size of primary draft
format to meta-data because this information is useful to some
humans and tools, and because it is usually much easier and
cheaper to get this information in static form (e.g., some
draft meta-data XML file) than compute it dynamically.
* Resolved XXX15: always allow posting of a new revision but warn
if new revision is not expected. Moved the corresponding R21
Rousskov Expires April 13, 2005 [Page 25]
Internet-Draft Draft Submission Toolset: Requirements October 2004
from absolute to desired requirements.
* Resolved XXX33 and XXX59: prevent DoS attacks (absolute
requirement R97) and warn about too-close submissions (desired
feature R96).
* Defined draft version, format and primary format terms.
2004/10/05
* Resolved XXX9: The Toolset should eventually offer a
Validation-only page.
* Resolved XXX19: The Toolset should eventually provide the
submitter with a way to preview the entire draft, with all
formats.
* Resolved XXX40, XXX41, and XXX56: first use draft name to
extract WG flag and WG name and hope for an IETF policy change.
If IETF policy on naming drafts does not change soon, add code
to query some databases to map individual-looking drafts to WG
names.
* Resolved XXX46 and XXX47: store and make public both original
and preprocessed XML sources. Most tools are likely to use
preprocessed XML format. Humans and some diff tools may prefer
the original.
2004/09/30
* Added requirements R72 and R73 to handle multiple submitters
submitting the same draft and a single submitter submitting two
drafts at the same time, addressing XXX27.
* Resolved XXX7: There seems to be no good reason to support
cut-and-paste mode. Submission via file upload interface
should suffice.
* Semi-resolved XXX53: Toolset should accept PDFs because RFC
Editor does. Still need to check whether the Secretariat
accepts PDFs legally today (XXX64).
2004/09/29
* Clarified and polished the "Scope" section.
* Updated "State of this draft" to document approaching-last-call
state of the draft and to solicit editorial-level feedback.
Rousskov Expires April 13, 2005 [Page 26]
Internet-Draft Draft Submission Toolset: Requirements October 2004
2004/09/27
* Marked formal toolset requirements using a Rnnn notation to (a)
document implementation schedule, and (b) make compliant
implementation and compliance evaluation easier.
* Marked informal implementation hints with a "Hint:" tag, to
avoid possible confusion with formal requirements.
* Started documenting implementation schedule. For example, only
plain text formats are interpreted during the first stage, then
XML support is added, then other formats. Meanwhile,
un-interpreted formats are accepted and posted as is as long as
plain text version validates.
* Added explicit requirements for managing abandoned submissions
(Brian E. Carpenter)
* Plain text or XML formats are always required (Brian E.
Carpenter)
* Added XXX55: Accepting PDFs is a change of current documented
procedures? (Brian E. Carpenter)
* Added an optional "discussion address" to the external
meta-data to help reviewers know where to send comments
(inspired by Brian E. Carpenter suggestion; Brian wanted this
to be a required extractable meta-data)
* Resolved XXX17, XXX28, and XXX29: Today, -00 WG drafts are
approved by the Chair either before and after submission,
depending on several factors. Based on WG chairs feedback we
still need to support both modes. Thus, there is no policy
change to talk about (and more work for the tool implementors
to support both modes). Still need to add specific toolset
requirements in case there is no approval recorded.
* Resolved XXX18, XXX32, and XXX45: We are going to move "request
for publication" functionality to a separate [simple] tool that
works with an existing/posted draft.
* Resolved XXX6: We are going to move the "withdraw this ID"
functionality desired by Secretariat to a separate [simple]
tool that works with an existing/posted draft.
* Added a "comment" field to the Adjust page so that the
submitter can tell Secretariat why manual action is necessary.
This may both save time Secretariat and let them improve the
Rousskov Expires April 13, 2005 [Page 27]
Internet-Draft Draft Submission Toolset: Requirements October 2004
toolset to minimize manual submissions (including fixing
validation/extraction bugs).
* Added the Receipt page to the list of documented pages, for
completeness.
* Emphasized that common sequence of pages to go through is as
short as possible for a given set of features, and that "page"
means "distinct dialog", not necessarily a "distinct URL".
Some reviewers thought "there are too many pages".
2004/09/20
* Added "E-mail Interface" section to document how key toolset
functionality can be accessed via e-mail. Compared e-mail and
web interfaces. (Suggested by Pekka Savola)
* Split "WG ID" meta-data into "WG ID" and "WG Flag". The former
seems to be easy to extract from the draft name. Noted that
the latter (i.e., "this is a working group draft" status)
cannot be inferred from some WG drafts (Pekka Savola).
* Added "List of drafts obsoleted by this draft" external
meta-data item (Pekka Savola), but questioned whether we are
ready to automate that.
* Added more conflicting opinions to XXX15 and proposed a
solution.
* Added "Preprocessing" subsection to reflect the discussion on
how/whether handle include PIs in XML draft sources. Needs
more discussion/work.
* Further clarified how an author can request the draft revision
to be published (i.e., forwarded to IESG or RFC Editor for
review and publication as an RFC or BCP). It's just a checkbox
on the web interface. Raised doubts we can pull this off (see
XXX45).
* Suggested in XXX2 that we would inform all authors but not seek
their consent (except for the submitter) when posting their
draft.
2004/09/09
* Polished high-level page/action summary and replaced text-based
steps diagram with something that looks more like a diagram.
Rousskov Expires April 13, 2005 [Page 28]
Internet-Draft Draft Submission Toolset: Requirements October 2004
* 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
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.
Rousskov Expires April 13, 2005 [Page 29]
Internet-Draft Draft Submission Toolset: Requirements October 2004
Author's Address
Alex Rousskov
The Measurement Factory
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Rousskov Expires April 13, 2005 [Page 30]
Internet-Draft Draft Submission Toolset: Requirements October 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 April 13, 2005 [Page 31]