1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc1111.txt b/doc/rfc/rfc1111.txt
new file mode 100644
index 0000000..66f0353
--- /dev/null
+++ b/doc/rfc/rfc1111.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 1111                                           ISI
+Obsoletes: 825                                               August 1989
+
+
+              Request for Comments on Request for Comments
+
+                      Instructions to RFC Authors
+
+Status of this Memo
+
+   This RFC specifies a standard for the Internet community.  Authors of
+   RFCs are expected to adopt and implement this standard.  Distribution
+   of this memo is unlimited.
+
+1.  Introduction
+
+   RFCs are distributed online by being stored as public access files,
+   and a short message is sent to the distribution list indicating the
+   availability of the memo.
+
+   The online files are copied by the interested people and printed or
+   displayed at their site on their equipment.  (An RFC may also be
+   returned via email in response to an email query.)  This means that
+   the format of the online files must meet the constraints of a wide
+   variety of printing and display equipment.
+
+2.  Format Rules
+
+   To meet the distribution constraints the following rules are
+   established for the two allowed formats for RFCs:  ASCII and
+   PostScript.
+
+   The RFC Editor attempts to ensure a consistent RFC style.  To do this
+   the RFC Editor may choose reformat the RFC submitted.  It is much
+   easier to do this if the submission matches the style of the most
+   recent RFCs.  Please do look at some recent RFCs and prepare yours in
+   the same style.
+
+   You must submit an editable online document to the RFC Editor.  The
+   RFC Editor may require minor changes in format or style and will
+   insert the actual RFC number.
+
+   2a.  ASCII Format Rules:
+
+      The character codes are ASCII.
+
+      Each page must be limited to 58 lines followed by a form feed on a
+
+
+
+Postel                                                          [Page 1]
+
+RFC 1111                    RFC Instructions                 August 1989
+
+
+      line by itself.
+
+      Each line must be limited to 72 characters followed by carriage
+      return and line feed.
+
+      No overstriking (or underlining) is allowed.
+
+      These "height" and "width" constraints include any headers,
+      footers, page numbers, or left side indenting.
+
+      Do not fill the text with extra spaces to provide a straight right
+      margin.
+
+      Do not do hyphenation of words at the right margin.
+
+      Do not use footnotes.  If such notes are necessary, put them at
+      the end of a section, or at the end of the document.
+
+      Use single spaced text within a paragraph, and one blank line
+      between paragraphs.
+
+      RFCs in ASCII Format may be submitted to the RFC Editor in email
+      messages (or as online files) in either the finished publication
+      format or in NROFF.  If you plan to submit a document in NROFF,
+      please consult the RFC Editor first.
+
+   2b.  PostScript Format Rules
+
+   Standard page size is 8 1/2 by 11 inches.
+
+      Margin of 1 inch on all sides (top, bottom, left, and right).
+
+      Main text should have a point size of no less than 10 points with
+      a line spacing of 12 points.
+
+      Footnotes and graph notations no smaller than 8 points with a line
+      spacing of 9.6 points.
+
+      Three fonts are acceptable: Helvetica, Times Roman and Courier
+      Plus their bold-face and italic versions.  These are the three
+      standard fonts on most PostScript printers.
+
+      Prepare diagrams and images based on lowest common denominator
+      PostScript.  Consider common PostScript printer functionality and
+      memory requirements.
+
+      The following PostScript commands should not be used:
+      initgraphics, erasepage, copypage, grestoreall, initmatrix,
+
+
+
+Postel                                                          [Page 2]
+
+RFC 1111                    RFC Instructions                 August 1989
+
+
+      initclip, banddevice, framedevice, nulldevice and renderbands.
+
+      These PostScript rules are likely to changed and expanded as
+      experience is gained.
+
+      RFCs in PostScript Format may be submitted to the RFC Editor in
+      email messages (or as online files).  Since PostScript is not
+      editable, an editable source version of the document must also be
+      submitted.  If you plan to submit a document in PostScript, please
+      consult the RFC Editor first.
+
+3.  Status Statement
+
+   Each RFC must include on its first page the "Status of this Memo"
+   section which contains a paragraph describing the intention of the
+   RFC.  This section is meant to convey the status granted by the RFC
+   Editor and the Internet Activities Board (IAB).  There are several
+   reasons for publishing a memo as an RFC, for example, to make
+   available some information for interested people, or to begin or
+   continue a discussion of an interesting idea, or to make available
+   the specification of a protocol.
+
+      The following sample paragraphs may be used to satisfy this
+      requirement:
+
+         Proposed Protocol
+
+            This RFC suggests a proposed protocol for the Internet
+            community, and requests discussion and suggestions for
+            improvements.
+
+         Specification
+
+            This RFC specifies a standard for the Internet community.
+            Hosts on the Internet are expected to adopt and implement
+            this standard.
+
+         Discussion
+
+            The purpose of this RFC is to focus discussion on particular
+            problems in the Internet and possible methods of solution.
+            No proposed solutions this document are intended as
+            standards for the Internet.  Rather, it is hoped that a
+            general consensus will emerge as to the appropriate solution
+            to such problems, leading eventually to the adoption of
+            standards.
+
+
+
+
+
+Postel                                                          [Page 3]
+
+RFC 1111                    RFC Instructions                 August 1989
+
+
+         Information
+
+            This RFC is being distributed to members of the Internet
+            community in order to solicit their reactions to the
+            proposals contained in it.  While the issues discussed may
+            not be directly relevant to the research problems of the
+            Internet, they may be interesting to a number of researchers
+            and implementers.
+
+         Status
+
+            In response to the need for maintenance of current
+            information about the status and progress of various
+            projects in the Internet community, this RFC is issued for
+            the benefit of community members.  The information contained
+            in this document is accurate as of the date of publication,
+            but is subject to change.  Subsequent RFCs will reflect such
+            changes.
+
+      These paragraphs need not be followed word for word, but the
+      general intent of the RFC must be made clear.
+
+4.  Distribution Statement
+
+   Each RFC is to also include a "distribution statement".  In general,
+   RFCs have unlimited distribution.  There may be a few cases in which
+   it is appropriate to restrict the distribution in some way.
+
+   Typically, the distribution statement will simply be the sentence
+   "Distribution of this memo is unlimited." appended to the "Status of
+   this Memo" section.
+
+5.  Author's Address
+
+   Each RFC must have at the very end a section giving the author's
+   address, including the name and postal address, the telephone number,
+   and the Internet email address.
+
+6.  Relation to other RFCs
+
+   Sometimes an RFC adds information on a topic discussed in a previous
+   RFC or completely replaces an earlier RFC.  There are two terms used
+   for these cases respectively, UPDATES and OBSOLETES.  A document that
+   obsoletes an earlier document can stand on its own.  A document that
+   merely updates an earlier document cannot stand on its own; it is
+   something that must be added to or inserted into the existing
+   document, and has limited usefulness independently.  The terms
+   SUPERSEDES and REPLACES are no longer used.
+
+
+
+Postel                                                          [Page 4]
+
+RFC 1111                    RFC Instructions                 August 1989
+
+
+   UPDATES
+
+      To be used as a reference from a new item that cannot be used
+      alone (i.e., one that supplements a previous document), to refer
+      to the previous document.  The newer publication is a part that
+      will supplement or be added on to the existing document; e.g., an
+      addendum, or separate, extra information that is to be added to
+      the original document.
+
+   OBSOLETES
+
+      To be used to refer to an earlier document that is replaced by
+      this document.  This document contains either revised information,
+      or else all of the same information plus some new information,
+      however extensive or brief that new information is; i.e., this
+      document can be used alone, without reference to the older
+      document.
+
+      For example:
+
+         On the Assigned Numbers RFCs, the term OBSOLETES should be used
+         since the new document actually incorporates new information
+         (however brief) into the text of existing information and is
+         more up-to-date than the older document, and hence, replaces it
+         and makes it OBSOLETE.
+
+   In lists of RFCs or the RFC-Index (but not on the RFCs themselves),
+   the following may be used with early documents to point to later
+   documents.
+
+   OBSOLETED-BY
+
+      To be used to refer to the newer document that replaces the older
+      document.
+
+   UPDATED-BY
+
+      To be used to refer to the newer document that adds information to
+      the existing, still useful, document.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [Page 5]
+
+RFC 1111                    RFC Instructions                 August 1989
+
+
+7. The RFC Editor
+
+   The RFC Editor is Jon Postel.
+
+8.  The RFC Announcement List
+
+   New RFCs are announced to the RFC distribution list maintained by the
+   SRI Network Information Center (NIC).  Contact the SRI-NIC to be
+   added or deleted from this mailing list by sending an email message
+   to RFC-REQUEST@NIC.DDN.MIL.
+
+9.  Obtaining RFCs
+
+   RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
+   RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC).
+   Login with FTP, username ANONYMOUS and password GUEST.
+
+   The NIC also provides an automatic mail service for those sites which
+   cannot use FTP.  Address the request to SERVICE@NIC.DDN.MIL and in
+   the subject field of the message indicate the RFC number, as in
+   "Subject: RFC nnnn".
+
+   Requests for special distribution (for example, hardcopy) should be
+   addressed to either the author of the RFC in question, or to
+   NIC@NIC.DDN.MIL.
+
+   Unless specifically noted otherwise on the RFC itself, all RFCs are
+   for unlimited distribution.
+
+   The RFCs may also be obtained from other information centers,
+   including the CSNET Information Center (INFO@SH.CS.NET), the NSFNET
+   Information Service (INFO@NIS.NSF.NET).
+
+Author's Address
+
+   Jon Postel
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, California  90292-6695
+
+   Phone:  213-822-1511
+
+   EMail:  POSTEL@ISI.EDU
+
+
+
+
+
+
+
+
+Postel                                                          [Page 6]
+