📄 rfc1410.txt
字号:
Another document, Internet Numbers, lists the assigned IP network
numbers, and the autonomous system numbers. Internet Numbers was
most recently issued as RFC-1166.
3.2. Gateway Requirements
This document reviews the specifications that apply to gateways and
supplies guidance and clarification for any ambiguities. Gateway
Requirements is RFC-1009. A working group of the IETF is actively
preparing a revision.
3.3. Host Requirements
This pair of documents reviews and updates the specifications that
apply to hosts, and it supplies guidance and clarification for any
ambiguities. Host Requirements was issued as RFC-1122 and RFC-1123.
3.4. The MIL-STD Documents
The Internet community specifications for IP (RFC-791) and TCP (RFC-
793) and the DoD MIL-STD specifications are intended to describe
exactly the same protocols. Any difference in the protocols
specified by these sets of documents should be reported to DCA and to
Internet Architecture Board [Page 6]
RFC 1410 IAB Standards March 1993
the IAB. The RFCs and the MIL-STDs for IP and TCP differ in style
and level of detail. It is strongly advised that the two sets of
documents be used together, along with RFC-1122 and RFC-1123.
The IAB and the DoD MIL-STD specifications for the FTP, SMTP, and
Telnet protocols are essentially the same documents (RFCs 765, 821,
854). The MIL-STD versions have been edited slightly. Note that the
current Internet specification for FTP is RFC-959 (as modified by
RFC-1123).
Note that these MIL-STD are now somewhat out of date. The Gateway
Requirements (RFC-1009) and Host Requirements (RFC-1122, RFC-1123)
take precedence over both earlier RFCs and the MIL-STDs.
Internet Protocol (IP) MIL-STD-1777
Transmission Control Protocol (TCP) MIL-STD-1778
File Transfer Protocol (FTP) MIL-STD-1780
Simple Mail Transfer Protocol (SMTP) MIL-STD-1781
Telnet Protocol and Options (TELNET) MIL-STD-1782
These documents are available from the Naval Publications and Forms
Center. Requests can be initiated by telephone, telegraph, or mail;
however, it is preferred that private industry use form DD1425, if
possible.
Naval Publications and Forms Center, Code 3015
5801 Tabor Ave
Philadelphia, PA 19120
Phone: 1-215-697-3321 (order tape)
1-215-697-4834 (conversation)
4. Explanation of Terms
There are two independent categorization of protocols. The first is
the "maturity level" or STATE of standardization, one of "standard",
"draft standard", "proposed standard", "experimental",
"informational" or "historic". The second is the "requirement level"
or STATUS of this protocol, one of "required", "recommended",
"elective", "limited use", or "not recommended".
The status or requirement level is difficult to portray in a one word
label. These status labels should be considered only as an
indication, and a further description, or applicability statement,
should be consulted.
When a protocol is advanced to proposed standard or draft standard,
it is labeled with a current status and when possible, the IAB also
notes the status that the protocol is expected to have when it
Internet Architecture Board [Page 7]
RFC 1410 IAB Standards March 1993
reaches the standard state.
At any given time a protocol occupies a cell of the following matrix.
Protocols are likely to be in cells in about the following
proportions (indicated by the relative number of Xs). A new protocol
is most likely to start in the (proposed standard, elective) cell, or
the (experimental, not recommended) cell.
S T A T U S
Req Rec Ele Lim Not
+-----+-----+-----+-----+-----+
Std | X | XXX | XXX | | |
S +-----+-----+-----+-----+-----+
Draft | X | X | XXX | | |
T +-----+-----+-----+-----+-----+
Prop | | X | XXX | | |
A +-----+-----+-----+-----+-----+
Info | | | | | |
T +-----+-----+-----+-----+-----+
Expr | | | | XXX | |
E +-----+-----+-----+-----+-----+
Hist | | | | | XXX |
+-----+-----+-----+-----+-----+
What is a "system"?
Some protocols are particular to hosts and some to gateways; a few
protocols are used in both. The definitions of the terms below
will refer to a "system" which is either a host or a gateway (or
both). It should be clear from the context of the particular
protocol which types of systems are intended.
4.1. Definitions of Protocol State
Every protocol listed in this document is assigned to a "maturity
level" or STATE of standardization: "standard", "draft standard",
"proposed standard", "experimental", or "historic".
4.1.1. Standard Protocol
The IAB has established this as an official standard protocol for
the Internet. These protocols are assigned STD numbers (see RFC-
1311). These are separated into two groups: (1) IP protocol and
above, protocols that apply to the whole Internet; and (2)
network-specific protocols, generally specifications of how to do
IP on particular types of networks.
Internet Architecture Board [Page 8]
RFC 1410 IAB Standards March 1993
4.1.2. Draft Standard Protocol
The IAB is actively considering this protocol as a possible
Standard Protocol. Substantial and widespread testing and comment
are desired. Comments and test results should be submitted to the
IAB. There is a possibility that changes will be made in a Draft
Standard Protocol before it becomes a Standard Protocol.
4.1.3. Proposed Standard Protocol
These are protocol proposals that may be considered by the IAB for
standardization in the future. Implementation and testing by
several groups is desirable. Revision of the protocol
specification is likely.
4.1.4. Experimental Protocol
A system should not implement an experimental protocol unless it
is participating in the experiment and has coordinated its use of
the protocol with the developer of the protocol.
Typically, experimental protocols are those that are developed as
part of an ongoing research project not related to an operational
service offering. While they may be proposed as a service
protocol at a later stage, and thus become proposed standard,
draft standard, and then standard protocols, the designation of a
protocol as experimental may sometimes be meant to suggest that
the protocol, although perhaps mature, is not intended for
operational use.
4.1.5. Informational Protocol
Protocols developed by other standard organizations, or vendors,
or that are for other reasons outside the purview of the IAB, may
be published as RFCs for the convenience of the Internet community
as informational protocols.
4.1.6. Historic Protocol
These are protocols that are unlikely to ever become standards in
the Internet either because they have been superseded by later
developments or due to lack of interest.
4.2. Definitions of Protocol Status
This document lists a "requirement level" or STATUS for each
protocol. The status is one of "required", "recommended",
"elective", "limited use", or "not recommended".
Internet Architecture Board [Page 9]
RFC 1410 IAB Standards March 1993
4.2.1. Required Protocol
A system must implement the required protocols.
4.2.2. Recommended Protocol
A system should implement the recommended protocols.
4.2.3. Elective Protocol
A system may or may not implement an elective protocol. The
general notion is that if you are going to do something like this,
you must do exactly this. There may be several elective protocols
in a general area, for example, there are several electronic mail
protocols, and several routing protocols.
4.2.4. Limited Use Protocol
These protocols are for use in limited circumstances. This may be
because of their experimental state, specialized nature, limited
functionality, or historic state.
4.2.5. Not Recommended Protocol
These protocols are not recommended for general use. This may be
because of their limited functionality, specialized nature, or
experimental or historic state.
5. The Standards Track
This section discusses in more detail the procedures used by the RFC
Editor and the IAB in making decisions about the labeling and
publishing of protocols as standards.
5.1. The RFC Processing Decision Table
Here is the current decision table for processing submissions by the
RFC Editor. The processing depends on who submitted it, and the
status they want it to have.
Internet Architecture Board [Page 10]
RFC 1410 IAB Standards March 1993
+==========================================================+
|**************| S O U R C E |
+==========================================================+
| Desired | IAB | IESG | IRSG | Other |
| Status | | | | |
+==========================================================+
| | | | | |
| Standard | Publish | Vote | Bogus | Bogus |
| or | (1) | (3) | (2) | (2) |
| Draft | | | | |
| Standard | | | | |
+--------------+----------+----------+----------+----------+
| | | | | |
| | Publish | Vote | Refer | Refer |
| Proposed | (1) | (3) | (4) | (4) |
| Standard | | | | |
| | | | | |
+--------------+----------+----------+----------+----------+
| | | | | |
| | Publish | Notify | Notify | Notify |
| Experimental | (1) | (5) | (5) | (5) |
| Protocol | | | | |
| | | | | |
+--------------+----------+----------+----------+----------+
| | | | | |
| Information | Publish |Discretion|Discretion|Discretion|
| or Opinion | (1) | (6) | (6) | (6) |
| Paper | | | | |
| | | | | |
+==========================================================+
(1) Publish.
(2) Bogus. Inform the source of the rules. RFCs specifying
Standard, or Draft Standard must come from the IAB, only.
(3) Vote by the IAB. If approved then do Publish (1), else do
Refer (4).
(4) Refer to an Area Director for review by a WG. Expect to see
the document again only after approval by the IESG and the
IAB.
(5) Notify both the IESG and IRSG. If no concerns are raised in
two weeks then do Discretion (6), else RFC Editor to resolve
the concerns or do Refer (4).
(6) RFC Editor's discretion. The RFC Editor decides if a review
Internet Architecture Board [Page 11]
RFC 1410 IAB Standards March 1993
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -