Network Working Group J. Postel
Request for Comments: 2223 J. Reynolds
Obsoletes: 1543, 1111, 825 ISI
Category: Informational October 1997
Network Working Group J. Postel
Request for Comments: 2223 J. Reynolds
Obsoletes: 1543, 1111, 825 ISI
Category: Informational October 1997
Instructions to RFC Authors
RFC作者须知
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.
版权所有（C）互联网协会（1997年）。版权所有。
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
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
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs.
本征求意见书（RFC）提供了有关RFC编制的信息，以及与RFC发布相关的某些政策。
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.
RFC系列票据涵盖广泛的利益。核心主题是Internet和TCP/IP协议套件。但是，RFC编辑可自行决定是否接受与计算机通信相关的任何主题。
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.
拟提交RFC的备忘录可由任何人提交。成为RFC的备忘录的一大来源是互联网工程任务组（IETF）。IETF工作组（WG）不断完善其工作备忘录（称为互联网草稿或I-D），直到他们认为可以发布，然后由互联网工程指导小组（IESG）审查这些备忘录，如果IESG批准，则将其发送给RFC编辑。
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.
IESG将审查从独立来源提交给RFC编辑的大部分备忘录，以确定与IETF工作组中正在进行的工作的可能关系。
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.
RFC通过存储为公共访问文件在线分发，并向分发列表发送一条短消息，指示备忘录的可用性。
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).
在线文件由感兴趣的人复制，并打印或显示在他们的设备上。这意味着在线文件的格式必须满足各种打印和显示设备的限制。（RFC也可以通过电子邮件返回以响应电子邮件查询，或者可以使用信息和数据库搜索工具（如Gopher、Wais或万维网）查找RFC。
RFCs have been traditionally published and continue to be published in ASCII text.
RFC传统上以ASCII文本发布，并将继续以ASCII文本发布。
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.
虽然主RFC始终是ASCII文本文件，但可以在PostScript中提供RFC的辅助或替代版本。这一决定的动机是希望在RFC中包括图表、图纸等。PostScript文档（目前仅限于纸面文档）在视觉上更具吸引力，可读性更好。
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.
选择PostScript是因为它比其他可能的系统（如impress、interpress、oda）更适合RFC出版物的奇特形式，因为人们认为支持PostScript的打印机广泛可用。
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.
然而，许多RFC用户在线阅读文档，并使用各种面向文本的工具（如emacs、grep）进行搜索。通常，电子邮件中包含RFC的简短摘录。这些做法在PostScript文件中还不实用。
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.
PostScript生成系统不如理想的标准，而且一些声称生成PostScript的文档生成系统实际上生成了非标准结果。
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.
将来，可能需要根据PostScript RFC生成的输出文件的合理性，确定一组授权用于PostScript RFC生产的文档生产系统。
Documents proposed to be RFCs are reviewed by the RFC Editor and possibly by other reviewers he selects.
拟作为RFC的文件由RFC编辑审查，也可能由他选择的其他审查人审查。
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.
有时，很明显，提议的RFC的主题也是IETF工作组的主题，并且作者可以与工作组进行协调，这对双方都有利。通常的结果是，修订后的备忘录作为工作组互联网草案产生，并最终作为IESG向RFC编辑提出的建议从IETF过程中产生。
In some cases it may be determined that the submitted document is not appropriate material to be published as an RFC.
在某些情况下，可能会确定提交的文件不适合作为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.
RFC编辑器可能会对文档进行微小更改，特别是在样式和格式方面，但在某些情况下也会对文本进行更改。有时，RFC编辑器会做出更重要的更改，尤其是在不遵守格式规则（见下文）的情况下。然而，更多的时候，备忘录将返回给作者，以便进行额外的工作。
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
指定标准跟踪协议的RFC文件必须在发送至RFC编辑器之前获得IESG的批准。既定程序是，当IESG完成将成为标准跟踪RFC的文件工作时，IESG秘书将与RFC进行沟通
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.
编辑一般来说，所讨论的文件是互联网草稿。通信通常引用所讨论的确切互联网草案（按文件名）。RFC编辑器必须假定只有该文件被处理才能成为RFC。如果作者对文本有小的修改，则应单独发送给RFC编辑器（或作为“差异”），作者不应发送新版本的文档。
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.
在某些情况下，作者使用PostScript以奇特的格式准备RFCs的备用二级版本。由于RFC的ASCII文本版本是主版本，因此PostScript版本必须与文本版本匹配。在发布PostScript版本之前，RFC编辑器必须确定PostScript版本是否与ASCII版本“相同”。
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.
其效果是RFC编辑器首先处理备忘录的ASCII版本，直到将其作为RFC发布。如果作者希望在该点提交与ASCII版本匹配的PostScript版本（并且RFC编辑器同意），则PostScript版本将安装在RFC存储库中并向社区公布。
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.
由于RFC编辑人员面临各种时间压力，从提交到出版的时间可能会有很大差异。在这段时间（但每周不超过一次）向RFC编辑器查询（ping）RFC的状态始终是可以接受的。IETF会议前的两周通常非常繁忙，因此IETF会议前不久提交的RFC最有可能在会议后发布。
To meet the distribution constraints, the following rules are established for the two allowed formats for RFCs: ASCII and PostScript.
为了满足分布约束，为RFC的两种允许格式建立了以下规则：ASCII和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.
RFC编辑器尝试确保RFC样式一致。为此，RFC编辑器可以选择重新格式化提交的RFC。如果提交内容与最新RFC的样式相匹配，则执行此操作会容易得多。请务必查看一些最近的RFC，并以相同的样式准备您的RFC。
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.
您必须向RFC编辑器提交可编辑的在线文档。RFC编辑器可能需要或对格式或样式进行微小更改，并将插入实际的RFC编号。
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.
大多数RFC由RFC编辑器使用unix“nroff”程序处理，使用“ms”宏包（见附录）中的一组非常简单的格式化命令（或“请求”）。如果提交给RFC的备忘录是作者使用nroff编写的，那么在提交时让RFC编辑知道这一点非常有用。
3a. ASCII Format Rules
3a。ASCII格式规则
The character codes are ASCII.
字符代码是ASCII码。
Each page must be limited to 58 lines followed by a form feed on a line by itself.
每个页面必须限制为58行，然后在一行上单独添加一个表单提要。
Each line must be limited to 72 characters followed by carriage return and line feed.
每行必须限制为72个字符，后跟回车符和换行符。
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.
ASCII格式的RFC可通过电子邮件（或在线文件）以完成的出版物格式或nroff格式提交给RFC编辑器。如果您计划在nroff中提交文档，请先咨询RFC编辑器。
3b. PostScript Format Rules
3b。PostScript格式规则
Standard page size is 8 1/2 by 11 inches.
标准页面大小为8 1/2乘11英寸。
Margin of 1 inch on all sides (top, bottom, left, and right).
所有侧面（顶部、底部、左侧和右侧）的边距均为1英寸。
Main text should have a point size of no less than 10 points with a line spacing of 12 points.
正文的点大小应不小于10点，行距为12点。
Footnotes and graph notations no smaller than 8 points with a line spacing of 9.6 points.
脚注和图表符号不小于8点，行距为9.6点。
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.
可以使用三种字体：Helvetica、Times Roman和Courier。加上他们的粗体和斜体版本。这是大多数PostScript打印机上的三种标准字体。
Prepare diagrams and images based on lowest common denominator PostScript. Consider common PostScript printer functionality and memory requirements.
根据最低公分母PostScript准备图表和图像。考虑常见的PASScript打印机功能和内存要求。
The following PostScript commands should not be used: initgraphics, erasepage, copypage, grestoreall, initmatrix, initclip, banddevice, framedevice, nulldevice and renderbands.
不应使用以下PostScript命令：initgraphics、橡皮擦页面、copypage、grestoreall、initmatrix、initclip、banddevice、framedevice、nulldevice和RenderBand。
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.
请注意，在ASCII和PostScript版本中，文档中的页数和各节所在的页码可能会有所不同。因此，文本中按章节编号的交叉引用通常比按页码的交叉引用更容易保持一致。
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.
PostScript格式的RFC可以通过电子邮件（或在线文件）提交给RFC编辑器。如果您计划在PostScript中提交文档，请先咨询RFC编辑器。
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.
请注意，由于RFC的ASCII文本版本是主版本，因此PostScript版本必须与文本版本匹配。在发布PostScript版本之前，RFC编辑器必须确定PostScript版本是否与ASCII版本“相同”。
There is the first page heading, the running headers, and the running footers.
有第一个页面标题、正在运行的标题和正在运行的页脚。
4a. First Page
4a。首页
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.
创立RFC系列的集团的传统领导。这将出现在标题左侧的第一行。
Request for Comments: nnnn
征求意见：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.
将此标识为注释请求并指定编号。显示在左侧的第二行。实际数字由RFC编辑在发布前的最后一刻填写。
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.
作者的组织，如右侧第二行所示。
Date
日期
This is the Month and Year of the RFC Publication. Indicated on the third line on the right side.
这是RFC出版物的月份和年份。显示在右侧的第三行。
Updates or Obsoletes
更新或淘汰
If this RFC Updates or Obsoletes another RFC, this is indicated as third line on the left side of the heading.
如果此RFC更新或淘汰了另一个RFC，则在标题左侧的第三行显示。
Category
类别
The category of this RFC, one of: Standards Track, Best Current Practice, Informational, or Experimental. This is indicated on the third (if there is no Updates or Obsoletes indication) or fourth line of the left side.
此RFC的类别，包括：标准跟踪、当前最佳实践、信息性或实验性。这显示在左侧的第三行（如果没有更新或淘汰指示）或第四行。
Other Numbers
其他数字
Other numbers in the RFC series of notes include the subseries of FYI (For Your Information) [4], BCP (Best Current Practice) [5], and STD (Standard) [6]. These are placed on the left side.
RFC系列注释中的其他数字包括FYI（供参考）[4]、BCP（最佳实践）[5]和STD（标准）[6]的子系列。这些放在左侧。
Title
标题
The title appears, centered, below the rest of the heading. Periods or "dots" in the titles are not allowed.
标题将居中显示在标题其余部分的下方。标题中不允许有句号或“点”。
If there are multiple authors and if the multiple authors are from multiple organizations the right side heading may have additional lines to accommodate them and to associate the authors with the organizations properly.
如果有多个作者，并且如果多个作者来自多个组织，则右侧标题可能有额外的行以容纳他们，并将作者与组织正确关联。
4b. Running Headers
4b。运行标题
The running header in one line (on page 2 and all subsequent pages) has the RFC number on the left (RFC NNNN), the (possibly nshortened form) title centered, and the date (Month Year) on the right.
一行（第2页和所有后续页面）中的运行标题左侧为RFC编号（RFC NNNN），中间为标题（可能为非排序形式），右侧为日期（月-年）。
4c. Running Footers
4c。运行页脚
The running footer in one line (on all pages) has the author's last name on the left, category centered, and the page number on the right ([Page N]).
一行（在所有页面上）的运行页脚左边是作者的姓氏，以类别为中心，右边是页码（[第N页]）。
Each RFC must include on its first page the "Status of this Memo" section which contains two elements: (1) a paragraph describing the type of the RFC, and (2) the distribution statement.
每个RFC必须在其首页包含“本备忘录的状态”部分，该部分包含两个要素：（1）描述RFC类型的段落，以及（2）分发声明。
The content of this section will be one of the four following statements.
本节的内容将是以下四个陈述之一。
Standards Track
标准轨道
"This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited."
“本文档为Internet社区指定了Internet标准跟踪协议，并要求讨论和提出改进建议。有关此协议的标准化状态和状态，请参阅当前版本的“Internet官方协议标准”（STD 1）。本备忘录的分发不限。”
Best Current Practice
当前最好惯例
"This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited."
此文档为Internet社区指定了Internet最佳当前做法，并要求讨论和提出改进建议。此备忘录的分发不受限制
Experimental
实验的
"This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited."
“此备忘录为Internet社区定义了一个实验协议。此备忘录未指定任何类型的Internet标准。需要讨论和改进建议。此备忘录的分发不受限制。”
Informational
信息的
"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."
“此备忘录为Internet社区提供信息。此备忘录未指定任何类型的Internet标准。此备忘录的分发不受限制。”
Immediately following the Status section the statement, "Copyright (C) The Internet Society (date). All Rights Reserved." is placed. Also, see Section 11 for the full statement that must appear at the end of the document.
紧接着状态部分，声明“版权（C）互联网协会（日期）。保留所有权利。”被放置。此外，有关必须出现在文档末尾的完整语句，请参见第11节。
Each RFC should have an Introduction section that (among other things) explains the motivation for the RFC and (if appropriate) describes the applicability of the protocol described.
每个RFC应有一个介绍部分（除其他外）解释RFC的动机，并（如适用）描述所述协议的适用性。
Normally, this will be the "abstract" section from the Internet Draft. If the RFC is not based on an I-D, other possibilities are:
通常，这将是互联网草案中的“摘要”部分。如果RFC不是基于I-D，则其他可能性为：
Protocol
协议
This protocol is intended to provide the bla-bla service, and be used between clients and servers on host computers. Typically the clients are on workstation hosts and the servers on mainframe hosts.
此协议旨在提供bla bla服务，并在主机上的客户端和服务器之间使用。通常，客户端位于工作站主机上，服务器位于大型机主机上。
or
或
This protocol is intended to provide the bla-bla service, and be used between special purpose units such as terminal servers or routers and a monitoring host.
该协议旨在提供bla bla服务，并在终端服务器或路由器等特殊用途单元与监控主机之间使用。
Discussion
讨论
The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in 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.
本RFC的目的是集中讨论互联网中的特定问题和可能的解决方法。本文件中的任何拟议解决方案均不作为互联网标准。相反，希望就这些问题的适当解决办法达成普遍共识，最终通过标准。
Interest
兴趣
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.
该RFC正在分发给互联网社区的成员，以征求他们对其中所含建议的反应。虽然讨论的问题可能与互联网的研究问题没有直接关系，但许多研究人员和实施者可能对这些问题感兴趣。
Status Report
状态报告
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.
为了满足维护互联网社区中各种项目状态和进度的最新信息的需要，发布本RFC是为了社区成员的利益。本文件中包含的信息在发布之日是准确的，但可能会发生更改。后续RFC将反映此类变更。
These paragraphs need not be followed word for word, but the general intent of the RFC must be made clear.
这些段落无需逐字逐句，但必须明确RFC的总体意图。
Nearly all RFCs contain citations to other documents, and these are listed in a References section near the end of the RFC. There are many styles for references, and the RFCs have one of their own. Please follow the reference style used in recent RFCs. See the reference section of this RFC for an example. Please note that for protocols that have been assigned STD numbers, the STD number must be included in the reference.
几乎所有的RFC都包含对其他文件的引用，这些都列在RFC末尾附近的参考资料部分。有许多样式可供参考，RFC也有自己的样式。请遵循最近RFC中使用的参考样式。有关示例，请参阅本RFC的参考部分。请注意，对于已分配STD编号的协议，参考文件中必须包含STD编号。
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. BCP 14, RFC 2119 [3], defines these words as they should be interpreted in IETF documents.
在许多标准跟踪文件中，使用几个词来表示规范中的要求。这些词通常大写。BCP 14，RFC 2119[3]定义了这些词，因为它们应该在IETF文件中解释。
All RFCs must contain a section near the end of the document that discusses the security considerations of the protocol or procedures that are the main topic of the RFC.
所有RFC必须在文件末尾附近包含一节，讨论RFC主要主题的协议或程序的安全注意事项。
Each RFC must have at the very end a section giving the author's address, including the name and postal address, the telephone number, (optional: a FAX number) and the Internet email address.
每个RFC的末尾必须有一个部分，给出作者的地址，包括姓名和邮政地址、电话号码（可选：传真号码）和互联网电子邮件地址。
Per BCP 9, RFC 2026 [2], "The following copyright notice and disclaimer shall be included in all ISOC standards-related documentation." The following statement should be placed on the last page of the RFC, as the "Full Copyright Statement".
根据BCP 9，RFC 2026[2]，“以下版权声明和免责声明应包含在所有ISOC标准相关文件中。”以下声明应作为“完整版权声明”放在RFC的最后一页。
"Copyright (C) The Internet Society (date). All Rights Reserved.
“版权所有（C）互联网协会（日期）。保留所有权利。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成
languages other than English.
英语以外的语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 previously existing document, and has limited usefulness independently. The terms Supercedes and Replaces are no longer used.
有时，RFC会添加有关先前RFC中讨论的主题的信息，或完全替代先前的RFC。有两个术语分别用于这些情况，更新和淘汰。淘汰早期文档的文档可以独立存在。仅更新早期文档的文档不能独立存在；它是必须添加到或插入到以前存在的文档中的内容，并且独立使用的功能有限。取代和替换的术语不再使用。
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.
用作不能单独使用的新项目（即补充先前文件的项目）的参考，参考先前文件。较新的出版物是对现有文件进行补充或添加的一部分；e、 例如，将添加到原始文件中的附录或单独的额外信息。
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.
用于指由本文档替换的早期文档。本文件包含修订后的信息，或所有相同信息加上一些新信息，无论新信息多么广泛或简短；i、 例如，本文件可单独使用，无需参考旧文件。
For example:
例如：
On the Assigned Numbers RFCs the term Obsoletes should be used since the new document actually incorporate 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 Obsoletes.
在指定编号的RFC上，应使用术语“作废”，因为新文件实际上将新信息（无论多么简短）纳入现有信息的文本中，并且比旧文件更为更新，因此，取代旧文件并使其作废。
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.
在RFC列表或RFC索引（但不在RFC本身上）中，以下内容可与早期文档一起使用，以指向后期文档。
Obsoleted-by
被淘汰
To be used to refer to the newer document(s) that replaces the older document.
用于引用替换旧文档的较新文档。
Updated-by
更新人
To be used to refer to the newer section(s) which are to be added to the existing, still used, document.
用于指要添加到现有的、仍在使用的文档中的较新部分。
See the current "Internet Official Protocol Standards" (STD 1) memo for the definitive statement on protocol standards and their publication [1].
有关协议标准及其出版物的最终声明，请参见当前的“互联网官方协议标准”（STD 1）备忘录[1]。
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 Editor. Generally, the documents in question are Internet Drafts. The communication usually cites the exact Internet Draft (by file name) in question. 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"), do not send a new version of the document.
既定程序是，当IESG完成将成为标准跟踪RFC的文件工作时，IESG秘书将与RFC编辑进行沟通。一般来说，所讨论的文件是互联网草稿。通信通常引用所讨论的确切互联网草案（按文件名）。RFC编辑器必须假定只有该文件被处理才能成为RFC。如果作者对文本有小的修改，应单独发送给RFC编辑器（或作为“差异”），不要发送文档的新版本。
To contact the RFC Editor send an email message to:
要联系RFC编辑器，请发送电子邮件至：
"rfc-editor@isi.edu".
“rfc-editor@isi.edu".
The RFC announcements are distributed via two mailing lists: the "IETF-Announce" list, and the "RFC-DIST" list. You don't want to be on both lists.
RFC公告通过两个邮件列表分发：“IETF公告”列表和“RFC-DIST”列表。你不想同时出现在两个名单上。
To join (or quit) the IETF-Announce list send a message to ietf-request@ietf.org.
要加入（或退出）IETF公告列表，请向IETF发送消息-request@ietf.org.
To join (or quit) the RFC-DIST list send a message to rfc-dist-request@isi.edu.
要加入（或退出）RFC-DIST列表，请向RFC DIST发送消息-request@isi.edu.
Several organizations maintain RFC Index files, generally using the file name "rfc-index.txt". The contents of such a file copied from one site may not be identical to that copied from another site.
一些组织维护RFC索引文件，通常使用文件名“RFC Index.txt”。从一个站点复制的文件内容可能与从另一个站点复制的文件内容不同。
This RFC raises no security issues (however, see Section 9).
此RFC不会引起任何安全问题（但是，请参见第9节）。
[1] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 2200, June 1997.
[1] Postel，J.，编辑，“互联网官方协议标准”，STD 1，RFC 2200，1997年6月。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I Introduction to the F.Y.I. Notes", FYI 1, RFC 1150, March 1990.
[4] Malkin，G.和J.Reynolds，“F.Y.I.关于F.Y.I.的F.Y.I.注释介绍”，FYI 1，RFC 1150，1990年3月。
[5] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", BCP 1, RFC 1818, August 1995.
[5] Postel，J.，Li，T.，和Y.Rekhter，“当前最佳实践”，BCP 1，RFC 18181995年8月。
[6] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311, March 1992.
[6] Postel，J.，编辑，“标准注释介绍”，RFC 13111992年3月。
Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
Jon Postel USC/信息科学研究所4676金钟路Marina del Rey，加利福尼亚州90292
Phone: +1 310-822-1511
Fax: +1 310-823-6714
EMail: Postel@ISI.EDU
Phone: +1 310-822-1511
Fax: +1 310-823-6714
EMail: Postel@ISI.EDU
Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
Joyce K.Reynolds USC/信息科学研究所4676金钟路Marina del Rey，加利福尼亚州90292
Phone: +1 310-822-1511
Fax: +1 310-823-6714
EMail: jkrey@isi.edu
Phone: +1 310-822-1511
Fax: +1 310-823-6714
EMail: jkrey@isi.edu
Generally, we use the very simplest nroff features. We use the "ms" macros. So, "nroff -ms input-file > output-file". However, we could not get nroff to do the right thing about putting a form feed after the last visible line on a page and no extra line feeds before the first visible line of the next page. We want:
通常，我们使用最简单的nroff特性。我们使用“ms”宏。所以，“nroff-ms输入文件>输出文件”。但是，我们无法让nroff做正确的事情，将表单提要放在页面上最后一行之后，而在下一页的第一行之前没有额外的换行。我们希望：
last visible line on page i ^L first visible line on page i+1
第i页的最后一行^L第i+1页的第一行可见
So, we invented a hack to fix this. We use a perl script called "fix.pl". So the command to process the file becomes:
所以，我们发明了一个黑客来解决这个问题。我们使用一个名为“fix.pl”的perl脚本。因此，处理文件的命令变为：
nroff -ms input-file | fix.pl > output-file
nroff-ms输入文件| fix.pl>输出文件
The actual perl script is:
实际的perl脚本是：
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /local/bin/perl
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /local/bin/perl
# fix.pl 17-Nov-93 Craig Milo Rogers at USC/ISI
#
# The style guide for RFCs calls for pages to be delimited by the
# sequence <last-non-blank-line><formfeed-line><first-non-blank-line>.
# Unfortunately, NROFF is reluctant to produce output that conforms to
# this convention. This script fixes RFC-style documents by searching
# for the token "FORMFEED[Page", replacing "FORMFEED" with spaces,
# appending a formfeed line, and deleting white space up to the next
# non-white space character.
#
# There is one difference between this script's output and that of
# the "fix.sh" and "pg" programs it replaces: this script includes a
# newline after the formfeed after the last page in a file, whereas the
# earlier programs left a bare formfeed as the last character in the
# file. To obtain bare formfeeds, uncomment the second substitution
# command below. To strip the final formfeed, uncomment the third
# substitution command below.
#
# This script is intended to run as a filter, as in:
#
# nroff -ms input-file | fix.pl > output-file
#
# When porting this script, please observe the following points:
#
# 1) ISI keeps perl in "/local/bin/perl"; your system may keep it
# fix.pl 17-Nov-93 Craig Milo Rogers at USC/ISI
#
# The style guide for RFCs calls for pages to be delimited by the
# sequence <last-non-blank-line><formfeed-line><first-non-blank-line>.
# Unfortunately, NROFF is reluctant to produce output that conforms to
# this convention. This script fixes RFC-style documents by searching
# for the token "FORMFEED[Page", replacing "FORMFEED" with spaces,
# appending a formfeed line, and deleting white space up to the next
# non-white space character.
#
# There is one difference between this script's output and that of
# the "fix.sh" and "pg" programs it replaces: this script includes a
# newline after the formfeed after the last page in a file, whereas the
# earlier programs left a bare formfeed as the last character in the
# file. To obtain bare formfeeds, uncomment the second substitution
# command below. To strip the final formfeed, uncomment the third
# substitution command below.
#
# This script is intended to run as a filter, as in:
#
# nroff -ms input-file | fix.pl > output-file
#
# When porting this script, please observe the following points:
#
# 1) ISI keeps perl in "/local/bin/perl"; your system may keep it
# elsewhere. # 2) On systems with a CRLF end-of-line convention, the "\n"s below # may have to be replaced with "\r\n"s.
#其他地方2） 在具有CRLF线端约定的系统上，以下的“\n”可能必须替换为“\r\n”s。
$* = 1; # Enable multiline patterns. undef $/; # Read whole files in a single # gulp.
$* = 1; # 启用多行模式。未定义$/#一口气读完整个文件。
while (<>) { # Read the entire input file.
s/FORMFEED(\[Page\s+\d+\])\s+/ \1\n\f\n/g;
# Rewrite the end-of-pages.
# s/\f\n$/\f/; # Want bare formfeed at end?
# s/\f\n$//; # Want no formfeed at end?
print; # Print the resultant file.
}
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
while (<>) { # Read the entire input file.
s/FORMFEED(\[Page\s+\d+\])\s+/ \1\n\f\n/g;
# Rewrite the end-of-pages.
# s/\f\n$/\f/; # Want bare formfeed at end?
# s/\f\n$//; # Want no formfeed at end?
print; # Print the resultant file.
}
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc-
editor/fix.pl
This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc-
editor/fix.pl
Now as to the nroff features we actually use, following is a sample memo, prepared in RFC style.
现在，关于我们实际使用的nroff特性，下面是一个样本备忘录，以RFC风格编写。
.pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Waitzman .ds RF PUTFFHERE[Page %] .ds CF .ds LH RFC 1149 .ds RH 1 April 1990 .ds CH IP Datagrams on Avian Carriers .hy 0 .ad l .in 0 Network Working Group D. Waitzman Request for Comments: 1149 BBN STC 1 April 1990
.pl 10.0i.po 0.ll 7.2i.lt 7.2i.nr ll 7.2i.nr lt 7.2i.ds LF Waitzman.ds RF putfhere[第%页].ds CF.ds LH RFC 1149.ds RH 1990年4月1日.ds CH鸟类携带者IP数据报.hy 0.ad l.in 0网络工作组D.Waitzman征求意见：1149 BBN STC 1990年4月1日
.ce A Standard for the Transmission of IP Datagrams on Avian Carriers
.ce在鸟类载体上传输IP数据报的标准
.ti 0 Status of this Memo
.ti 0此备忘录的状态
.fi .in 3 This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. Distribution of this memo is unlimited.
.fi.在3中，本备忘录描述了在鸟类载体中封装IP数据报的实验方法。本规范主要适用于城域网。这是一个实验性的标准，不是推荐的标准。本备忘录的分发不受限制。
.ti 0 Overview and Rational
.ti 0概述和Rational
Avian carriers can provide high delay, low throughput, and low altitude service. The connection topology is limited to a single point-to-point path for each carrier, used with standard carriers, but many carriers can be used without significant interference with each other, outside of early spring. This is because of the 3D ether space available to the carriers, in contrast to the 1D ether used by IEEE802.3. The carriers have an intrinsic collision avoidance system, which increases availability. Unlike some network technologies, such as packet radio, communication is not limited to line-of-sight distance. Connection oriented service is available in some cities, usually based upon a central hub topology.
鸟类载体可以提供高延迟、低吞吐量和低空服务。连接拓扑被限制为每个载波的单点对点路径，与标准载波一起使用，但在早春之外，许多载波可以在彼此之间没有明显干扰的情况下使用。这是因为与IEEE802.3使用的1D以太相比，运营商可以使用3D以太空间。运营商有一个固有的防撞系统，提高了可用性。与某些网络技术（如分组无线电）不同，通信不限于视线距离。在某些城市，面向连接的服务是可用的，通常基于中心枢纽拓扑。
.ti 0 Frame Format
.ti0帧格式
The IP datagram is printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram's edges. The bandwidth is limited to the leg length. The MTU is variable, and paradoxically, generally increases with increased carrier age. A typical MTU is 256 milligrams. Some datagram padding may be needed.
IP数据报以十六进制打印在一张小纸卷上，每个八位字节由白色和黑色分隔。纸卷轴缠绕在鸟类载体的一条腿上。一条管道胶带用于固定数据报的边缘。带宽受限于支腿长度。MTU是可变的，矛盾的是，通常随着携带者年龄的增加而增加。典型的MTU为256毫克。可能需要一些数据报填充。
Upon receipt, the duct tape is removed and the paper copy of the datagram is optically scanned into a electronically transmittable form.
收到后，移除管道胶带，并对数据报的纸质副本进行光学扫描，形成电子传输形式。
.ti 0 Discussion
.ti 0讨论
Multiple types of service can be provided with a prioritized pecking order. An additional property is built-in worm detection and eradication. Because IP only guarantees best effort delivery, loss of a carrier can be tolerated. With time, the carriers are self-regenerating. While broadcasting is not specified, storms can cause data loss. There is persistent delivery retry, until the carrier drops. Audit trails are automatically generated, and can often be found on logs and cable trays.
可以按优先顺序提供多种类型的服务。另一个特性是内置的蠕虫检测和根除。因为IP只保证尽最大努力交付，所以可以容忍承运人的损失。随着时间的推移，载体会自我再生。虽然未指定广播，但风暴可能导致数据丢失。在运营商退出之前，会有持续的交付重试。审计跟踪是自动生成的，通常可以在日志和电缆桥架上找到。
.ti 0 Security Considerations
.0安全注意事项
.in 3 Security is not generally a problem in normal operation, but special measures must be taken (such as data encryption) when avian carriers are used in a tactical environment.
。在正常操作中，安全通常不是问题，但在战术环境中使用鸟类载体时，必须采取特殊措施（如数据加密）。
.ti 0 Author's Address
.ti 0作者地址
.nf David Waitzman BBN Systems and Technologies Corporation BBN Labs Division 10 Moulton Street Cambridge, MA 02238
nf David Waitzman BBN系统和技术公司BBN实验室分部马萨诸塞州剑桥莫尔顿街10号02238
Phone: (617) 873-4323
电话：（617）873-4323
EMail: dwaitzman@BBN.COM
EMail: dwaitzman@BBN.COM
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。”