[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4228

TOOLS team                                                   A. Rousskov
Internet-Draft                                   The Measurement Factory
Expires: March 21, 2005                               September 20, 2004


             Requirements for IETF Draft Submission Toolset
                  draft-ietf-tools-draft-submission-01

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 21, 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 21, 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Status quo . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Overall toolset operation  . . . . . . . . . . . . . . . . . .  5
   7.  Upload page  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Check action . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1   Preprocessing  . . . . . . . . . . . . . . . . . . . . . .  8
     8.2   Storage  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.3   Extraction . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.4   Validation . . . . . . . . . . . . . . . . . . . . . . . . 10
       8.4.1   Absolute requirements  . . . . . . . . . . . . . . . . 10
       8.4.2   Desireable features  . . . . . . . . . . . . . . . . . 11
   9.  Check page . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1   External meta-data . . . . . . . . . . . . . . . . . . . . 12
   10.   Post Now action  . . . . . . . . . . . . . . . . . . . . . . 13
   11.   Adjust action  . . . . . . . . . . . . . . . . . . . . . . . 14
   12.   Adjust page  . . . . . . . . . . . . . . . . . . . . . . . . 14
   13.   Post Manually action . . . . . . . . . . . . . . . . . . . . 14
   14.   Bypassing the toolset  . . . . . . . . . . . . . . . . . . . 14
   15.   E-mail interface . . . . . . . . . . . . . . . . . . . . . . 15
   16.   Implementation stages  . . . . . . . . . . . . . . . . . . . 16
   17.   Security Considerations  . . . . . . . . . . . . . . . . . . 16
   18.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 17
   19.   Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 17
   A.  Comparison with current procedures . . . . . . . . . . . . . . 17
   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   C.  Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 21


















Rousskov                 Expires March 21, 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.  Text marked with "XXX" usually contains
   informal descriptions of known problems the team needs to solve.
   These "XXXs" are uniquely numbered for ease of reference.

   Please provide an early high-level review of this draft.  Is the
   overall scope and functionality of the toolset appropriate? Are there
   any key 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.






Rousskov                 Expires March 21, 2005                 [Page 3]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


4.  Terminology

   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 (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 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, 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



Rousskov                 Expires March 21, 2005                 [Page 4]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


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



Rousskov                 Expires March 21, 2005                 [Page 5]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


   web pages and actions:

   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



Rousskov                 Expires March 21, 2005                 [Page 6]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


   session identifier is invisible to the submitter.

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




Rousskov                 Expires March 21, 2005                 [Page 7]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


   [[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
   to human submitter as well? Perhaps as a "Validate Only" button? Or
   should we KISS? --Alex]].

8.  Check action

   The Check action preprocesses XML draft source (if any), 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.

   XML source needs to be preprocessed to resolve XML processor
   instructions to include references.  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  Preprocessing

   XML source, if any, is preprocessed in an attempt to resolve all
   <rfc? include="..."> XML processor instructions (PIs), using [a copy
   of] Marshall Rose's reference database at xml.resource.org.  Both
   pre-processed and post-processed XML sources may be stored later.
   The pre-processed source with include PIs may be useful to the RFC
   Editor and must not be made public.  The post-processed version
   without PIs becomes the public XML source of the posted draft.  If
   any of the include PIs cannot be handled, the action fails.

   [[XXX46: There is no TOOLs team consensus on whether the toolset
   should store preprocessed XML.  There seems to be consensus that
   publicly available XML sources must not have PIs.  There are still
   several serious unaddressed issues here.  First, include PIs seem to
   be undocumented in RFC 2629 and in draft-mrose-writing-rfcs.  Second,
   they are just PIs and, AFAIK, ignoring PIs should not cause fatal
   errors in XML world.  It seems that the current approach with include
   PIs brings XML sources out of XML world into some pre-XML state,
   where DTD/schema/etc.  validation is not applicable.  --Alex]]

   [[XXX47: Does the RFC Editor actually care much about include PIs?
   References (i.e., things those PIs point to) contain all the
   information in the PI and more...  --Alex]]




Rousskov                 Expires March 21, 2005                 [Page 8]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


   Draft formats other than XML are not preprocessed.

8.2  Storage

   The Check action 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 action fails.

8.3  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 ID: IETF working group identifier.  WG value is empty for
      individual drafts not meant to be related to 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".  [[XXX42: Is it possible that an
      individual draft without a WG name component in its name is
      adopted as a WG draft without changing draft name? See also "WG
      flag" concerns.  --Alex]]

   WG flag: True for IETF WG drafts and false for all other drafts.  For
      example, "true" for "draft-ietf-tools-draft-submission-13".
      [[XXX40: Currently, there is no reliable way to extract WG ID from
      the draft, because some WGs (e.g., OSPF) tell the Secretariat that
      a draft-surname-wg-foo-05 draft is actually a WG document.  I
      would encourage a policy change to require this-is-a-WG-draft
      information to be embedded in WG drafts.  --Pekka Savola]][[XXX41:
      A simple policy would be the best, but, in theory, the toolset can
      also consult some IETF database to see if a
      draft-surname-wg-foo-05 draft is actually a WG draft.  --Alex]]



Rousskov                 Expires March 21, 2005                 [Page 9]

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.4  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.4.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 21, 2005                [Page 10]

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, Harald, and Pekka 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.  Pekka: In practice, revisions are allowed in any
       state; don't try to solve a process knowledge problem (the I-D
       author should not submit new versions) using a technical means.
       Need further clarification.  If no clarification, always allow
       until approved, but issue a warning when draft is under IESG
       control.  --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.4.2  Desireable features

   Violating any of the following requirements would NOT prevent a draft
   to be automatically posted except for the draft revision that
   submitter explicitly marks as 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]]



Rousskov                 Expires March 21, 2005                [Page 11]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


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
   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)? The author would tick a corresponding checkbox on the
      web interface to set the "publication requested" flag.  [[XXX32:
      clarify that for-publication submissions may be subjected to more
      mandatory checks than other drafts.  --Alex]][[XXX45: Currently,



Rousskov                 Expires March 21, 2005                [Page 12]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


      it is the WG Chair that submits "for publication" drafts to the
      AD.  This meta-data flag would let authors do it.  The intent is
      to enable more strict checks before the submission, to improve the
      quality of the drafts submitted for IESG review.  Bad idea?
      --Alex]]

      List of drafts obsoleted by this draft.  This is useful to make
      obsoleted drafts invisible.  [[XXX43: Can non -00 draft obsolete
      other drafts? Or is this reserved for -00 versions for some
      reason? Is this reserved for WG drafts only? --Alex]].  [[XXX44:
      This may open a bigger can of worms than we want to deal with, as
      it allows anybody to "kill" any other draft.  The toolset would
      probably need a manual check by Secretariat and/or approvals from
      both(?) WG Chairs.  A lot of work for something relatively rare?
      --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),
   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 inform all authors that their
   draft is being posted (since the draft says they all made an IPR
   statement)? Default answer: yes.  Obtaining consent from all authors
   seems impractical.  --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]].






Rousskov                 Expires March 21, 2005                [Page 13]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


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

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



Rousskov                 Expires March 21, 2005                [Page 14]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


   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.  E-mail interface

   The toolset should have e-mail interface for automated posting of
   valid drafts.  While virtually every documented toolset functionality
   can, technically, be implemented behind an e-mail interface, other
   features are believed to be prohibitively awkward to implement or use
   via e-mail.

   E-mail interface accepts a draft as a set of e-mail attachment(s)
   (one per draft format), uses sender's e-mail address to select
   submitters identity, checks the submission, and post the draft if the
   check is successful.  The submitter should be notified of the outcome
   of the draft submission.  Notification includes detected errors and
   warnings (if any).

   Toolset actions should be implemented to support e-mail and web
   interfaces without code duplication.

   [[XXX37: If there is only one draft format, can e-mail body be used
   for submission? --Alex]]

   [[XXX38: To easily filter out spam and reduce human errors, should we
   require a special keyword in the subject or body of the submission
   e-mail? For example, we can require and check that the subject starts
   with "Please post" --Alex]]

   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.  E-mail
      client actually submits the draft when connectivity is regained.
      [[XXX39: This advantage would be significantly reduced if we



Rousskov                 Expires March 21, 2005                [Page 15]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


      require submitter e-mail verification for each draft submission.
      Such verification would mean that valid drafts cannot be posted
      automatically when connectivity is regained -- sending an e-mail
      just starts the process.  --Alex]]

   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.

   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.

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


16.  Implementation stages

   TBD: Come up with a simple way to identify distinct toolset elements/
   features and suggest implementation order.

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



Rousskov                 Expires March 21, 2005                [Page 16]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


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

18.  IANA Considerations

   None.

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


Appendix B.  Acknowledgments

   The author gratefully acknowledges the contributions of Harald Tveit
   Alvestrand (Cisco), Barbara B.  Fuller (Foretec), Henrik Levkowetz,
   Larry Masinter (Adobe), Pekka Savola (Netcore), and Stanislav



Rousskov                 Expires March 21, 2005                [Page 17]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


   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.13 2004/09/21
   06:30:53 rousskov Exp $

   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 March 21, 2005                [Page 18]

Internet-Draft    Draft Submission Toolset: Requirements  September 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 March 21, 2005                [Page 19]

Internet-Draft    Draft Submission Toolset: Requirements  September 2004


Author's Address

   Alex Rousskov
   The Measurement Factory

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












































Rousskov                 Expires March 21, 2005                [Page 20]

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 21, 2005                [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/