📄 rfc2223.txt
字号:
Network Working Group J. Postel
Request for Comments: 2223 J. Reynolds
Obsoletes: 1543, 1111, 825 ISI
Category: Informational October 1997
Instructions to RFC Authors
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1997). All Rights Reserved.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3
3. Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4
3a. ASCII Format Rules . . . . . . . . . . . . . . . . . . . . 5
3b. PostScript Format Rules . . . . . . . . . . . . . . . . . . 6
4. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4a. First Page Heading . . . . . . . . . . . . . . . . . . . . 7
4b. Running Header . . . . . . . . . . . . . . . . . . . . . . 8
4c. Running Footer . . . . . . . . . . . . . . . . . . . . . . 8
5. Status Section . . . . . . . . . . . . . . . . . . . . . . . 8
6. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 9
7. Introduction Section . . . . . . . . . . . . . . . . . . . . 9
8. References Section . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations Section . . . . . . . . . . . . . 11
10. Author's Address Section . . . . . . . . . . . . . . . . . 11
11. Copyright Section . . . . . . . . . . . . . . . . . . . . 11
12. Relation to other RFCs . . . . . . . . . . . . . . . . . . 12
13. Protocol Standards Process . . . . . . . . . . . . . . . . 13
14. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Distribution Lists . . . . . . . . . . . . . . . . . . . . 14
16. RFC Index . . . . . . . . . . . . . . . . . . . . . . . . 14
17. Security Considerations . . . . . . . . . . . . . . . . . 14
18. References . . . . . . . . . . . . . . . . . . . . . . . . 14
19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
20. Appendix - RFC "nroff macros" . . . . . . . . . . . . . . 16
21. Full Copyright Statement . . . . . . . . . . . . . . . . . 20
Postel & Reynolds Informational [Page 1]
RFC 2223 Instructions to RFC Authors October 1997
1. Introduction
This Request for Comments (RFC) provides information about the
preparation of RFCs, and certain policies relating to the publication
of RFCs.
The RFC series of notes covers a broad range of interests. The core
topics are the Internet and the TCP/IP protocol suite. However, any
topic related to computer communication may be acceptable at the
discretion of the RFC Editor.
Memos proposed to be RFCs may be submitted by anyone. One large
source of memos that become RFCs is the Internet Engineering Task
Force (IETF). The IETF working groups (WGs) evolve their working
memos (known as Internet Drafts or I-Ds) until they feel they are
ready for publication, then the memos are reviewed by the Internet
Engineering Steering Group (IESG), and if approved sent by the IESG
to the RFC Editor.
Most of the memos submitted to the RFC Editor from independent
sources will be reviewed by the IESG for possible relationship to
work in progress in the IETF Working Groups.
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. This means that the
format of the online files must meet the constraints of a wide
variety of printing and display equipment. (RFCs may also be
returned via e-mail in response to an e-mail query, or RFCs may be
found using information and database searching tools such as Gopher,
Wais, or the World Wide Web (WWW).
RFCs have been traditionally published and continue to be published
in ASCII text.
While the primary RFCs is always an ASCII text file, secondary or
alternative versions of RFC may be provided in PostScript. This
decision is motivated by the desire to include diagrams, drawings,
and such in RFCs. PostScript documents (on paper only, so far) are
visually more appealing and have better readability.
PostScript was chosen for the fancy form of RFC publication over
other possible systems (e.g., impress, interpress, oda) because of
the perceived wide spread availability of PostScript capable
printers.
Postel & Reynolds Informational [Page 2]
RFC 2223 Instructions to RFC Authors October 1997
However, many RFC users read the documents online and use various
text oriented tools (e.g., emacs, grep) to search them. Often, brief
excerpts from RFCs are included in e-mail. These practices are not
yet practical with PostScript files.
PostScript producing systems are less standard than is desirable and
that several of the document production systems that claim to produce
PostScript actually produce nonstandard results.
In the future, it may be necessary to identify a set of document
production systems authorized for use in production of PostScript
RFCs, based on the reasonableness of the output files they generate.
2. Editorial Policy
Documents proposed to be RFCs are reviewed by the RFC Editor and
possibly by other reviewers he selects.
The result of the review may be to suggest to the author some
improvements to the document before publication.
Occasionally, it may be apparent that the topic of a proposed RFC is
also the subject of an IETF Working Group, and that the author could
coordinate with the working group to the advantage of both. The
usual result of this is that a revised memo is produced as a working
group Internet Draft and eventually emerges from the IETF process as
a recommendation from the IESG to the RFC Editor.
In some cases it may be determined that the submitted document is not
appropriate material to be published as an RFC.
In some cases it may be necessary to include in the document a
statement based on the reviews about the ideas in the document. This
may be done in the case that the document suggests relevant but
inappropriate or unsafe ideas, and other situations.
The RFC Editor may make minor changes to the document, especially in
the areas of style and format, but on some occasions also to the
text. Sometimes the RFC Editor will undertake to make more
significant changes, especially when the format rules (see below) are
not followed. However, more often the memo will be returned to the
author for the additional work.
Documents intended to become RFCs specifying standards track
protocols must be approved by the IESG before being sent to the RFC
Editor. The established procedure is that when the IESG completes
work on a document that is to become a standards track RFC the
communication will be from the Secretary of the IESG to the RFC
Postel & Reynolds Informational [Page 3]
RFC 2223 Instructions to RFC Authors October 1997
Editor. Generally, the documents in question are Internet Drafts.
The communication usually cites the exact Internet Draft in question
(by file name). The RFC Editor must assume that only that file is to
be processed to become the RFC. If the authors have small
corrections to the text, they should be sent to the RFC Editor
separately (or as a "diff"), authors should not send a new version of
the document.
In some cases, authors prepare alternate secondary versions of RFCs
in fancy format using PostScript. Since the ASCII text version of
the RFC is the primary version, the PostScript version must match the
text version. The RFC Editor must decide if the PostScript version
is "the same as" the ASCII version before the PostScript version can
be published.
The effect of this is that the RFC Editor first processes the ASCII
version of the memo through to publication as an RFC. If the author
wishes to submit a PostScript version at that point that matches the
ASCII version (and the RFC Editor agrees that it does), then the
PostScript version will be installed in the RFC repositories and
announced to the community.
Due to various time pressures on the RFC Editorial staff, the time
elapsed between submission and publication can vary greatly. It is
always acceptable to query (ping) the RFC Editor about the status of
an RFC during this time (but not more than once a week). The two
weeks preceding an IETF meeting are generally very busy, so RFCs
submitted shortly before an IETF meeting are most likely to be
published after the meeting.
3. 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 to 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 or make minor changes in format or style and
will insert the actual RFC number.
Postel & Reynolds Informational [Page 4]
RFC 2223 Instructions to RFC Authors October 1997
Most of the RFCs are processed by the RFC Editor with the unix
"nroff" program using a very simple set of the formatting commands
(or "requests") from the "ms" macro package (see the Appendix). If a
memo submitted to be an RFC has been prepared by the author using
nroff, it is very helpful to let the RFC Editor know that when it is
submitted.
3a. 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.
Note that the number of pages in a document and the page numbers
on which various sections fall will likely change with
reformatting. Thus cross references in the text by section number
usually are easier to keep consistent than cross references by
page number.
RFCs in ASCII Format may be submitted to the RFC Editor in e-mail
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.
Postel & Reynolds Informational [Page 5]
RFC 2223 Instructions to RFC Authors October 1997
3b. 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.
Note that the number of pages in a document and the page numbers
on which various sections fall will likely differ in the ASCII and
the PostScript versions. Thus cross references in the text by
section number usually are easier to keep consistent than cross
references by page number.
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
e-mail messages (or as online files). If you plan to submit a
document in PostScript please consult the RFC Editor first.
Note that since the ASCII text version of the RFC is the primary
version, the PostScript version must match the text version. The
RFC Editor must decide if the PostScript version is "the same as"
the ASCII version before the PostScript version can be published.
Postel & Reynolds Informational [Page 6]
RFC 2223 Instructions to RFC Authors October 1997
4. Headers and Footers
There is the first page heading, the running headers, and the running
footers.
4a. First Page
Please see the front page of this memo for an example of the front
page heading. On the first page there is no running header. The
top of the first page has the following items:
Network Working Group
The traditional heading for the group that founded the RFC
series. This appears on the first line on the left hand side
of the heading.
Request for Comments: nnnn
Identifies this as a request for comments and specifies the
number. Indicated on the second line on the left side. The
actual number is filled in at the last moment before
publication by the RFC Editor.
Author
The author's name (first initial and last name only) indicated
on the first line on the right side of the heading.
Organization
The author's organization, indicated on the second line on the
right side.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -