GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1111

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1111.txt · Last modified: 1989/08/09 16:38 (external edit)