Date: 2005-03-14 04:24
From: Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Looking again into 2026 I'm still not sure how Gaurav
could handle this if the authors don't answer.
Anybody can write an Internet-Draft (getting IETF community consensus
is another matter). In the case of a revision of a document created
by others, it would be appropriate to acknowledge the contribution
of the original authors in a Contributors or Acknowledgments section.
Regarding mechanics of an update, if one is at all familiar with
troff/nroff/groff, see RFC 2223 and draft-lilly-using-troff (update
expected imminently). Cutting and pasting from the original RFC
(ignore boilerplate and TOC) or editing a copy of the original to
remove boilerplate and TOC and to add directives should take no more
than 45 minutes for a novice, less than half that for an experienced
person.
Then come the difficult parts:
the EBNF in the original has to be converted (manually) to ABNF
you'll need a good understanding of the intent of the original
EBNF and a working knowledge of RFC 2234 as amended by errata
(http://www.rfc-editor.org/cgi-bin/errata.pl)
references need to be updated (see the rfc-ref.txt document made
available by the RFC Editor) and checked against the referring
text -- references are supposed to be categorized as either
normative or informative, so a decision needs to be made for
each reference. You'll want to update the reference to RFC
1122 to 2119 (normative), for example.
desired changes can be made (keep track of what is changed; the
question will be asked -- put a list of changes in an Appendix
to head off the question); make absolutely sure to pay careful
attention to backwards compatibility (generation of "new" URIs
should not be such that an existing (2229-based) parser will
break or cause illegal content to be handed to some other
protocol (in that respect, the mailto draft is the wrong
document to use as a reference))
don't forget to include a suggestion for a discussion mailing
list in the Abstract
Then it gets easy again:
format the document to generate text with up-to-date boilerplate,
TOC, and references
check with Henrik Levkowetz' idnits program, and revise until
there are no nits (http://ietf.levkowetz.com/tools/idnits/)
submit the formatted and checked text as an Internet-Draft as
described in the guidelines (see http://www.ietf.org/ID.html)
subscribe to the I-D-announce mailing list: when the draft is
announced, notify the discussion mailing list (if the Secretariat
didn't copy that list in the announcement)
after a suitable discussion period (min. two weeks), revise the
draft according to comments from the discussion and repeat to
produce the next draft version
when the draft is stable (no additional comments during discussion),
ask the appropriate Area Director(s) (Applications Area, in this
case) to submit the draft to the IESG for approval as an
(Informational or Proposed Standard) RFC
subscribe to the IETF-announce mailing list; if the IESG approves,
a Last Call will be issued on the draft, with discussion taking
place on the IETF discussion (that's this list) or IESG mailing
lists -- Last Call for an individual submission runs a minimum
of four weeks
if there are substantive comments during Last Call, revise the draft
again and repeat the cycle
if/when the draft is stable and passes Last Call with no serious
objections, the IESG may approve it as an RFC; then you work
with the RFC Editor to generate a published RFC (should be
quick and painless if you use groff and macros as mentioned above);
there is a final (nominally) 48-hour author review where you're
supposed to carefully review the document to ensure that
everything is the way you want it
if the IESG decided to publish as a Proposed Standard, you can
then set about collecting information to proceed to Draft
Standard (minimum of two independent and fully interoperable
implementations need to be documented).
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf