RFC1111 - Request for comments on Request for Comments: Inst

　　 
　　Network Working Group J. Postel
Request for Comments: 1111 ISI
Obsoletes: 825 August 1989

Request for Comments on Request for Comments

Instructions to RFCAuthors

Status of this Memo

This RFCspecifies 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 aclearcase/" target="_blank" >ccess 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 RFCmay 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 RFCEditor attempts to ensure a consistent RFCstyle. To do this
the RFCEditor may choose reformat the RFCsubmitted. 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 RFCEditor. The
RFCEditor may require minor changes in format or style and will
insert the actual RFCnumber.

2a. ASCII Format Rules:

The character codes are ASCII.

Each page must be limited to 58 lines followed by a form feed on a

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 RFCEditor 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 RFCEditor 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,

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 RFCEditor 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 RFCEditor first.

3. Status Statement

Each RFCmust 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 RFCsuggests a proposed protocol for the Internet
community, and requests discussion and suggestions for
improvements.

Specification

This RFCspecifies a standard for the Internet community.
Hosts on the Internet are expected to adopt and implement
this standard.

Discussion

The purpose of this RFCis 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.

Information

This RFCis 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 RFCis 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 RFCmust be made clear.

4. Distribution Statement

Each RFCis 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 RFCmust 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 RFCadds information on a topic discussed in a previous
RFCor 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.

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.

7. The RFCEditor

The RFCEditor is Jon Postel.

8. The RFCAnnouncement List

New RFCs are announced to the RFCdistribution 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 RFCnumber, as in
"Subject: RFCnnnn".

Requests for special distribution (for example, hardcopy) should be
addressed to either the author of the RFCin question, or to
NIC@NIC.DDN.MIL.

Unless specifically noted otherwise on the RFCitself, 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

原文转自：http://www.ltesting.net