CINXE.COM

<HTML> <HEAD> <TITLE>RFC-Online Project</TITLE> </HEAD> <body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#ff0000"> <center><H1> The RFC-Online Project</h1> </center> <P> <hr> <font color="red">Note: The information on this page is out of date; it is retained for historical reasons. For updated information, please see the</font> <a href="/old/rfc-online-2008.html">Update on the RFC Online Project (2008)</a>. <hr> The <b>RFC Online</b> project is an effort to bring all the early RFCs online. Volunteers type or scan in the text of these RFCS, while the RFC Editor does the final formatting and proof-reading. <p> <ul> <li> <h2> <A HREF="#history">History</A> </h2> <P> <li> <h2> <A HREF="#status">Current status</A> </h2> <P> <li> <h2> <A HREF="#people">Volunteers and Staff</A> </h2> <P> <li> <h2> <A HREF="#rules">Rules</A> </h2> </ul> <P> <P> <hr> <hr> <P> <a name = "history"><H1>History of RFC Online Project</H1></a> <P> The Requests for Comment (RFC) documents form a series of notes started in 1969 by the research community that designed and built the ARPAnet. The RFCs series forms an archive of technical proposals, standards, and ideas about packet-switched networks. The earliest RFCs were produced and distributed on paper, but network distribution began after as the FTP protocol was defined and implemented on the ARPAnet. <P> At some point in the history of the RFCs, when operating systems were changed and links and/or conversions did not work, the files containing the first 600 RFCs were lost. If you <a HREF="https://www.rfc-editor.org/rfc.html">look up an early RFC</a> using the RFC search engine</a> or the RFC index file, you will find <b>"(Not online)"</b> under Format for many early RFCs. Fortunately, the RFC Editor (and a few others) have paper copies of all the RFCs back to the beginning. A few years ago, the RFC Editor Jon Postel initiated a project to restore all the missing RFCs. This is the <b>RFC Online Project</b>. <P> This project depends upon volunteers who type or scan in the missing text. The RFC Editor then edits the documents for content accuracy and style consistency, and finally puts the text online. Any RFC earlier than RFC 600 that <i>is</i> online today is there by grace of the RFC Online project. While the initial scope of the project was thought to be documents in the 1 - 600 range, the project was later expanded to include all missing documents in the 1- 800 range. All RFCs after 800 were already online. <P> <a name = "status"><H1>Current Status</H1></a> <P> With the generous help of the volunteers, over the last 3 years we have made considerable progress. At the present time there are approximately 200 RFCs yet to be put online, out of the first 800. ISI is currently backlogged on editing and proofreading the text; there are approximately 100 RFCs for which we now have nroff sources that we have not yet edited. We are making a strenuous effort to speed up this process, but the RFC Online project must be of lower priority than editing new RFCs. <P> There is also a significant number of RFCs that have been assigned to particular volunteers but received no electronic text after a year. We will be getting in touch with those volunteers and reassigning their RFCs to others who have the time to do finish the job. <P> <a name = "people"><H1>Volunteers and Staff</H1></a> <P> The name of the volunteer who typed in the text is included in a block at the very end of each restored RFC. Among many volunteers, Alex MacKenzie and Mark Blanchet have provided overwhelming support for and interest in the RFC Online Project. Their efforts have resulted in more than 100 re-published RFCs within the 1 - 800 series. <P> Some of the restored RFCs contain ASCII renderings of hand-drawn diagrams and figures that are truly heroic! <P> Within the RFC Editor staff at ISI, the RFC Online project has at various times been supervised by Mary Kennedy, Josh Elliott, Alegre Ramos, Sandy Ginoza, and currently Allison De La Cruz. <P> <A name = "rules"><H1>Rules</H1></a> <P> The rules we use for RFC Online have evolved. Originally the objective was to make the retyped RFC look as much like the original as possible, with some important exceptions (ASCII diagrams replacing hand-drawn figures, single-spacing replacing double-spaced text). However, a simple practice of simply numbering memos and technical notes that were typed in a great variety of styles. A few were hand-written, and many had hand-drawn figures. More recently, the RFC Online project has adopted a different objective: <P> <blockquote> <b> Follow the current RFC standard format, while preserving the contents as strictly as possible </b> </blockquote> <P> More specifically: <P> <OL> <li>We would much prefer to obtain the document in nroff form, according to the examples in RFC 2223 and the following. <P> <li> The following should in general be used as headers and footers: <P> <pre> .ds LF <author last name(s)> .ds RF FORMFEED[Page %] .ds CF .ds LH RFC #### .ds RH <Date as Month Year> .ds CH <Shortened version of title> </pre> <li> The header should be exactly 72 columns wide, right-justified. It should have the modern form: <P> <pre> <---------- 72 columns -------------------------------------------------> Network Working Group <Full author name(s)> Request for Comments: XXXX <Author site> NIC yyyy <date: day month year> </pre> <p> The general principle here is that we should not lose information in the header, but we may reformat it. Exception: we omit author's address if it appeared in the header. We include any Obsoletes, Updates, ... , NIC number and Categories (left margin), if they were present. <P> <li> The restored document is single-spaced. However, if the original was double-spaced, it may sometimes be necessary to add additional blanks lines for clarity to separate paragraphs, tables, etc. <p> <li> In general, the paragraph formatting should be modern, with no indentation of the first line of a paragraph. <p> <li> We generally follow the modern practice of standard indent of 3, with .ti 0 for major headings. <p> <li> Footnotes are generally be put inline or moved to end-notes. <p> <li> We generally suppress underlining. However, there are exceptions. <P> <ul> <li> When underlining is used for emphasis, we may use "_underlined text_" to indicate emphasis. This is a judgment call; if the editor feels the author really _wanted_ that emphasis, use this form. If the author underlined every other word, drop the underlining. <p> <li> When underlining is essential to the meaning (for example, in a computer typescript to show what the computer typed), underline as appropriate with hyphens. </ul> <p> </OL> <p>Questions of problems should be sent to <a href=mailto:rfc-editor@rfc-editor.org>rfc-editor@rfc-editor.org</a> </center> <hr> <ADDRESS> <A HREF="index.html">Go to RFC Editor's home page.</A></ADDRESS> <P> <BR>Last modified 10 February 2010. </BODY> </HTML>