drafts with adjusted meta-data as described in Section 14.
The Adjust page allows the submitter to enter an informal comment
explaining why adjustments are necessary and automated posting mode
cannot be used (R48/a). Such comments may be essential for the
Secretariat in their efforts to troubleshoot the problem.
The "post manually" and "cancel" buttons are provided (R43/a). The
former is backed by the Post Manually action (Section 12).
12. Post Manually Action
The Post Manually action sends adjusted meta-data and a draft pointer
to the Secretariat for manual validation and posting (R44/a). A
receipt page is generated, instructing the submitter to wait (R45/a).
The 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/a).
13. Receipt Page
The Receipt page is generated by various actions to inform the
submitter of the 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 Uniform Resource
Identifier (URI) or another identifier that can be used by
Secretariat for manual troubleshooting of the submission (R63/a).
The identifier should be perpetual (R64/a) 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). Hint: Tools should distinguish old identifiers
from invalid ones; when a given identifier is referring to deleted
data, the tools accepting the identifier should inform their users
that the identified submission is recognized, but the related
information has expired.
The Receipt page should give the submitter a Secretariat
point-of-contact to report submission problems (R65/a).
14. Bypassing the Toolset
A buggy Toolset implementation or unusual circumstances may force a
submitter to submit a draft to the Secretariat for manual processing.
This can be done by choosing the "manual posting" route supported by
the Toolset (R47/a) or, as a last resort, by emailing 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/b). The forced posting
action accepts meta-data fields "as is", does not verify submitter
access to email or WG draft authorization, and posts the draft as if
no validation errors were found (R51/b). The Manual Check page
should still contain all the errors and warnings identical to those
seen by ordinary submitters (R106/b) 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/a).
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
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 Trial stage of the Toolset
implementation, when few submitters know about (or are allowed to
use) the Toolset.
15. Email Interface
The Toolset should have an email interface for automated posting of
valid drafts (R55/b). While virtually every documented Toolset
functionality can, technically, be implemented behind an email
interface, features other than posting of valid drafts are believed
to be prohibitively awkward to implement or use via email.
The email interface accepts a draft as a set of email part(s) (one
per draft format) (R56/b). For example, the plain text format can be
submitted in the "body" of the email message, while XML source format
can be optionally sent as an "attachment" of the same email message.
Each part can either contain the actual format data (R141/b) or a
single URL pointing to it (R142/c). In the latter case, the Toolset
has to fetch the format data. Details of the URL-fetching option are
not documented here, but it is assumed that HTTP URLs are supported
(at least), and fetching errors are reported. This document does not
specify how the format of each email part is determined, but it is
assumed that MIME type and content would need to be analyzed.
After accepting the draft, the Toolset uses the sender’s email
address to select the submitter identity (R57/b), checks the
submission (R58/b), and posts the draft if the check is successful
(R59/b). The submitter should be notified of the outcome of the
draft submission via email (R60/b). Other requirements for the web
interface (including requirements on submission preprocessing, draft
validation, submitter authentication, draft posting, and
notification) apply to the email interface.
Therefore, a typical successful submission via email interface may
result in the following exchange of messages ("T" is for "Toolset",
"S" is for "submitter", and "A" is for "all authors and submitter"):
S-->T: the draft version
S<--T: a challenge to verify email access
S-->T: a response to the challenge
A<--T: warnings and the receipt
where the message containing the challenge may include warnings as
well.
When draft validation fails, the following emails may be exchanged:
S-->T: the draft version
S<--T: errors and receipt
Email parts/attachments that are not recognized as draft formats are
not considered as draft formats. Such parts are ignored by the
Toolset (R107/b), except that a warning is generated for each
unrecognizable part containing more than whitespace (R108/b). These
two requirements are meant to make the interface robust in the
presence of email signatures and other parts outside of the submitter
control.
Hint: Toolset actions can be implemented to support email and web
interfaces without code duplication.
While both web and email interfaces allow for fast posting of valid
drafts, there are significant differences between the two interfaces.
Primary advantages of the email 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
email client actually submits the draft when connectivity is
regained.
poor connectivity: Email systems are often better suited for
automated transmission and re-transmission of emails when network
connectivity is poor due to high packet loss ratios, transmission
delays, and other problems.
convenience: Some IETFers consider email interfaces as generally
"more convenient".
Primary advantages of the 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
version of the draft that was updated 30 seconds ago by your co-
author?").
validation: A submitter can validate the draft without posting it.
quality: Non-critical warnings may prompt the submitter to postpone
posting to improve draft quality.
manual adjustments: The submitter can adjust extracted meta-data and
ease Secretariat work on manually posting an unusual draft.
meta-data: The submitter can specify optional external meta-data
(that cannot be extracted from the draft itself). For example, an
email address for draft discussion can be specified.
context help: The web interface makes it easy to provide links to
extra information about input fields, errors, posting options,
deadlines, etc.
opaqueness: Files submitted via the web interface are arguably less
susceptible to various in-transit transformations and
misinterpretation than emails. Emails are often mutated by mail
agents (e.g., automated disclaimers added by senders and extra
line feeds added by recipients).
convenience: Some IETFers consider web interfaces as generally "more
convenient".
16. Implementation Stages
This section defines the Toolset implementation stages or phases.
There are three consecutive stages, marked with letters "a", "b", or
"c". Earlier-stage requirements must still be satisfied in later
stages. All requirements need to be interpreted and evaluated in the
context of the current stage and the currently implemented features.
For example, requirement R68 applies to the first stage but refers to
XML draft format that may not be supported until the second stage. A
correct interpretation of R68 until XML support is added is "it is an
error to submit a draft without a plain text format".
Unless otherwise noted, requirements listed in later stages may be
covered in earlier stages, but do not have to be. If the
implementers decide to add some functionality from a future stage,
they have to be very careful to satisfy all requirements related to
that functionality. Unfortunately, there is no reliable, pragmatic
way to identify "all requirements" related to a given feature.
(a) Trial Stage: Initial basic implementation to test major concepts
and relieve the Secretariat from handling the most common
submission case. This stage focuses on plain text draft
submission via the web interface. The trial stage should take a
dedicated professional about 45 calendar days to finish (i.e., to
comply with all the listed requirements).
(b) Production Stage: Support for all major features. Once this
stage is completed, the Secretariat should only handle unusual
draft submissions. This stage should take about 100 calendar days
to finish. Gradual release of implemented features is possible
and expected. Specifically, the XML support is expected before
email interface support.
(c) Enhancement Stage: A never-ending stage focusing on sophisticated
features (e.g., draft interpretation or validation) that improve
the overall quality of the Toolset. This stage is documented
primarily to highlight the overall direction of the Toolset; its
requirements are often imprecise and many are expected to change.
Implementation experience is likely to result in changes of the
Toolset requirements. Such changes should be documented as a part of
stage evaluation activities.
17. Testing
Before letting the Toolset go live, thousands of posted drafts can be
used to test the meta-data extraction algorithms. Such testing can
minimize the number of drafts being sent on for manual handling
because of meta-data extraction failure.
Other Toolset features may also be testable using posted drafts. A
simple pair of scripts can be used to test basic functionality of the
web and email interfaces.
Hint: The IESG may require test results before accepting the initial
implementation. If automated, the above approach can be used for
regression testing as well.
18. Security Considerations
Removing humans from the draft submission and posting process (a.k.a.
automation) requires adding features to make the Toolset reliable in
the presence of denial-of-service (DoS) attacks and attempts to
corrupt the draft repository. Ideally, the Toolset needs to resist
both premeditated malicious actions and good-intent accidents.
This document contains specific requirements to minimize the impact
of DoS attacks (e.g., R97). The requirements are designed with the
assumption that it is acceptable for the Toolset to block valid
submissions during a DoS attack as long as the Toolset maintainers
are notified and already posted drafts are not damaged.
This document also contains many specific requirements related to
detection of drafts violating IETF posting rules. Those requirements
help reduce the number of "bad" drafts posted by mistake but do not
offer reliable protection from submitters with malicious intent:
Since automated tools do not truly understand drafts (and will not do
so in the foreseeable future), it is technically possible to post a
rogue draft violating IETF posting rules. For example, a draft may
contain abstract text that makes the IETF-approved IPR statements
following the abstract meaningless or legally non-binding.
Stronger submitter authentication may be required to deter malicious
submitters. The documented authentication mechanism (i.e., read
access to one’s email) is deemed appropriate for deployment of the
first versions of the Toolset, under close Secretariat supervision.
Hint: to increase chances of detecting problems early enough, it may
be a good idea to automatically inform a designated human of every
posted submission (during initial deployment of the Toolset).
19. Compliance
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 3). Compliance should be evaluated for
each implementation stage as some requirements do not apply to some
stages.
The IESG evaluates implementations and interprets requirements as
necessary.
Appendix A. Comparison with Current Procedures
This section summarizes major differences between the 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. The 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.
o The Toolset may eventually generate HTML draft formats from XML
draft sources (see R112). Currently, IETF does not provide HTML
draft formats -- the Secretariat does not accept HTML sources and
no HTML is generated from accepted draft sources. Note, however,
that this document does not suggest that the Toolset should
eventually accept drafts in HTML format.
o The Toolset defines "WGN draft" as a draft whose name starts with
"draft-ietf-". All other drafts are treated as individual drafts.
Currently, an IETF WG does not have to follow a single WG draft
naming format. Thus, the 00 version of a draft that the WG
considers a WG draft can be posted by the Toolset without WG
consent. Affected WGs would have to deal with the consequences of
their decision not to use a common naming format. The Tools team
suggests that IETF requires WGs to name their drafts using a
single format to minimize confusion. Hopefully, there are no
humans named "Ietf" or, at least, none of them wants to auto-post
individual drafts.
o For some drafts, the Toolset verifies that the submitter is
"expected" (e.g., an author of the previous draft version or WG
Chair). Currently, the Secretariat does virtually no such
verification, but an email submission interface and a human
presence in the submission loop have apparently been sufficient to
prevent massive automated attacks. The change is needed to
prevent a simple script from using the web interface to overwrite
posted IETF drafts with junk. Hopefully, the IETF will eventually
have a decent authentication scheme making the submitter checks
simpler, less rigid, and more transparent.
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 to 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 notifications about
draft postings.
o The Toolset may eventually accept compressed drafts (see R150).
Currently, the Secretariat does not accept "zip" archives due to
virus contamination concerns. A proper implementation of the
Toolset must address such concerns, while the Secretariat may
still need to reject certain formats if they are submitted via the
manual route.
Appendix B. Acknowledgements
The author gratefully acknowledges the contributions of Harald Tveit
Alvestrand (Cisco), Brian E. Carpenter (IBM), Frank Ellermann, Bill
Fenner (AT&T), Barbara B. Fuller (Foretec), Bruce Lilly, Henrik
Levkowetz (Ericsson), Larry Masinter (Adobe), Keith Moore (University
of Tennessee), Pekka Savola (Netcore), Henning Schulzrinne (Columbia
University), and Stanislav Shalunov (Internet2).
Special thanks to Marshall Rose for his xml2rfc tool.
Normative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
Informative References
[writing-rfcs] Rose, M., "Writing I-Ds and RFCs using XML (revised)",
Work in Progress, April 2004.
[secretariat] "Private communication with the IETF Secretariat",
2004.
[OSD] "The Open Source Definition, version 1.9", Open Source
Initiative, 2005, available at
http://www.opensource.org/docs/definition.php.
Author’s Address
Alex Rousskov
The Measurement Factory
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.