📄 rfc1250.txt
字号:
3.3. 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.4. 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.5. 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 Activities Board [Page 6]
RFC 1250 IAB Standards August 1991
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. These five documents are included in the 1985 DDN Protocol
Handbook (available from the Network Information Center, see Section
7.4).
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 STATE of standardization, one of "standard", "draft standard",
"proposed standard", "experimental", "informational" or "historic".
The second is the STATUS (requirement level or applicability) 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,
Internet Activities Board [Page 7]
RFC 1250 IAB Standards August 1991
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
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 | X | |
A +-----+-----+-----+-----+-----+
Info | | X | XXX | X | X |
T +-----+-----+-----+-----+-----+
Expr | | | X | XXX | X |
E +-----+-----+-----+-----+-----+
Hist | | | | X | 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 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 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 Activities Board [Page 8]
RFC 1250 IAB Standards August 1991
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. Such protocols may in some cases also
be recommended for use in the Internet by the IAB.
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.
Internet Activities Board [Page 9]
RFC 1250 IAB Standards August 1991
4.2. Definitions of Protocol Status
This document lists a STATUS (requirement level or applicability)
for each protocol. The status is one of "required",
"recommended", "elective", "limited use", or "not recommended".
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 Activities Board [Page 10]
RFC 1250 IAB Standards August 1991
+==========================================================+
|**************| S O U R C E |
+==========================================================+
| Desired | IAB | IESG | IRSG | Other |
| Status | | | or RG | |
+==========================================================+
| | | | | |
| 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 Activities Board [Page 11]
RFC 1250 IAB Standards August 1991
is needed and if so by whom. RFC Editor decides to publish or
not.
Of course, in all cases the RFC Editor can request or make minor
changes for style, format, and presentation purposes.
The IESG has designated the IESG Secretary as its agent for
forwarding documents with IESG approval and for registering concerns
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -