Re: RFC - 2229 / Dictionary Server Protocol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]