I would add that the first step in such an effort should probably be to contact the appropriate IETF Area Directors for guidance and for the names of other people who might be interested in helping.
This looks like Applications Area material to me. See http://www.ietf.org/html.charters/wg-dir.html#Applications%20Area
Brian
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter IETF Chair Distinguished Engineer, Internet Standards & Technology, IBM
Bruce Lilly wrote:
Date: 2005-03-14 04:24 From: Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>
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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf