rfc1920
rfc1920
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. The Standardization Process . . . . . . . . . . . . . . . . 3
2. The Request for Comments Documents . . . . . . . . . . . . . 5
3. Other Reference Documents . . . . . . . . . . . . . . . . . 6
3.1. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . 6
3.2. Gateway Requirements . . . . . . . . . . . . . . . . . . . 6
3.3. Host Requirements . . . . . . . . . . . . . . . . . . . . 6
3.4. The MIL-STD Documents . . . . . . . . . . . . . . . . . . 6
4. Explanation of Terms . . . . . . . . . . . . . . . . . . . . 8
4.1. Definitions of Protocol State (Maturity Level) . . . . . . 9
4.1.1. Standard Protocol . . . . . . . . . . . . . . . . . . . 9
4.1.2. Draft Standard Protocol . . . . . . . . . . . . . . . . 9
4.1.3. Proposed Standard Protocol . . . . . . . . . . . . . . . 9
4.1.4. Experimental Protocol . . . . . . . . . . . . . . . . . 9
4.1.5. Informational Protocol . . . . . . . . . . . . . . . . 10
4.1.6. Historic Protocol . . . . . . . . . . . . . . . . . . 10
4.2. Definitions of Protocol Status (Requirement Level) . . . 10
4.2.1. Required Protocol . . . . . . . . . . . . . . . . . . 10
4.2.2. Recommended Protocol . . . . . . . . . . . . . . . . . 10
4.2.3. Elective Protocol . . . . . . . . . . . . . . . . . . 10
4.2.4. Limited Use Protocol . . . . . . . . . . . . . . . . . 10
4.2.5. Not Recommended Protocol . . . . . . . . . . . . . . . 10
5. The Standards Track . . . . . . . . . . . . . . . . . . . 11
5.1. The RFC Processing Decision Table . . . . . . . . . . . 11
5.2. The Standards Track Diagram . . . . . . . . . . . . . . 12
6. The Protocols . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Recent Changes . . . . . . . . . . . . . . . . . . . . . 14
Introduction
The documents called Request for Comments (or RFCs) are the working
notes of the "Network Working Group", that is the Internet research
and development community. A document in this series may be on
essentially any topic related to computer communication, and may be
anything from a meeting report to the specification of a standard.
Notice:
All standards are published as RFCs, but not all RFCs specify
standards.
memo is the reference for determining the correct RFC for the current
specification of each protocol.
The RFCs are available from the INTERNIC, and a number of other
sites. For more information about obtaining RFCs, see Sections 7.4
and 7.5.
Note that these MIL-STD are now somewhat out of date. The
Requirements for IP Version 4 Routers (RFC-1812) and Host
Requirements (RFC-1122, RFC-1123) take precedence over both earlier
RFCs and the MIL-STDs.
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.
4. Explanation of Terms
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"?
These protocols are not recommended for general use. This may be
because of their limited functionality, specialized nature, or
experimental or historic state.
This section discusses in more detail the procedures used by the RFC
Editor and the IESG in making decisions about the labeling and
publishing of protocols as standards.
+==========================================================+
|**************| S O U R C E |
+==========================================================+
| Desired | IAB | IESG | IRSG | Other |
| Status | | | | |
+==========================================================+
| | | | | |
| Standard | Bogus | Publish | Bogus | Bogus |
| or | (2) | (1) | (2) | (2) |
| Draft | | | | |
| Standard | | | | |
+--------------+----------+----------+----------+----------+
| | | | | |
| | Refer | Publish | Refer | Refer |
| Proposed | (3) | (1) | (3) | (3) |
| Standard | | | | |
| | | | | |
+--------------+----------+----------+----------+----------+
| | | | | |
| | Notify | Publish | Notify | Notify |
| Experimental | (4) | (1) | (4) | (4) |
| Protocol | | | | |
| | | | | |
+--------------+----------+----------+----------+----------+
| | | | | |
| Information | Publish | Publish |Discretion|Discretion|
| or Opinion | (1) | (1) | (5) | (5) |
| Paper | | | | |
| | | | | |
+==========================================================+
(1) Publish.
(4) Notify both the IESG and IRSG. If no concerns are raised in
two weeks then do Discretion (5), else RFC Editor to resolve
the concerns or do Refer (3).
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
in response to notifications (4) to the RFC Editor. Documents from
Area Directors or Working Group Chairs may be considered in the same
way as documents from "other".
|
+<----------------------------------------------+
| ^
V 0 | 4
+-----------+ +===========+
| enter |-->----------------+-------------->|experiment |
+-----------+ | +=====+=====+
| |
V 1 |
+-----------+ V
| proposed |-------------->+
+--->+-----+-----+ |
| | |
| V 2 |
+<---+-----+-----+ V
| draft std |-------------->+
+--->+-----+-----+ |
| | |
| V 3 |
+<---+=====+=====+ V
| standard |-------------->+
+=====+=====+ |
|
V 5
+=====+=====+
| historic |
+===========+
The transition from proposed standard (1) to draft standard (2) can
only be by action of the IESG and only after the protocol has been
proposed standard (1) for at least six months.
The transition from draft standard (2) to standard (3) can only be by
action of the IESG and only after the protocol has been draft
standard (2) for at least four months.
Occasionally, the decision may be that the protocol is not ready for
standardization and will be assigned to the experimental state (4).
This is off the standards track, and the protocol may be resubmitted
to enter the standards track after further work. There are other
paths into the experimental and historic states that do not involve
IESG action.
6. The Protocols
Subsection 6.1 lists recent RFCs and other changes. Subsections 6.2
- 6.10 list the standards in groups by protocol state.
This memo.
1915 - Variance for The PPP Connection Control Protocol and The
PPP Encryption Control Protocol
An Experimental protocol.
An Experimental protocol.
An Experimental protocol.
An Experimental protocol.
An Experimental protocol.
1890 - RTP Profile for Audio and Video Conferences with Minimal
Control
An Experimental protocol.
An Experimental protocol.
An Experimental protocol.
1872 - The MIME Multipart/Related Content-type
An Experimental protocol.
Moved to Historic.
Moved to Historic.
Moved to Historic.
Moved to Historic.
Moved to Historic.
Internet Architecture Board Standards Track [Page 19]
Applicability Statements:
Applicability Statements:
Applicability Statements:
[Note: Ele/Req indicates elective for use with IPv4 and required for use
with IPv6.]
Applicability Statements:
For convenience, all the Telnet Options are collected here with both
their state and status.
Some of the protocols listed in this memo are described in RFCs that are
obsoleted by newer RFCs. "Obsolete" or "obsoleted" is not an official
state or status of protocols. This subsection is for information only.
Many obsoleted protocols are of little interest and are dropped from
this memo altogether. Some obsoleted protocols have received enough
recognition that it seems appropriate to list them under their current
status and with the following reference to their current replacement.
7. Contacts
Contacts:
Abel Winerib
Executive Director of the IAB
Intel, JF2-64
2111 NE 25th Avenue
Hillsboro, OR 97124
1-503-696-8972
Brian E. Carpenter
Chair of the IAB
CERN
European Laboratory for Particle Physics
1211 Geneva 23
Switzerland
+41 22 767-4967
Contacts:
Fred Baker
Chair of the IETF
cisco Systems, Inc.
519 Lado Drive
Santa Barbara, CA 93111
1-805-681-0115
Steve Coya
IESG Secretary
Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091
1-703-620-8990
[email protected]
Steve Coya
Executive Director of the IETF
Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091
1-703-620-8990
Contact:
Abel Winerib
Chair of the IRTF
Intel, JF2-64
2111 NE 25th Avenue
Hillsboro, OR 97124
1-503-696-8972
Contact:
Joyce K. Reynolds
Internet Assigned Numbers Authority
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
1-310-822-1511
Contact:
Jon Postel
RFC Editor
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
1-310-822-1511
[email protected]
Documents may be submitted via electronic mail to the RFC Editor for
consideration for publication as RFC. If you are not familiar with
the format or style requirements please request the "Instructions for
RFC Authors". In general, the style of any recent RFC may be used as
a guide.
now available via Gopher. All our collections are WAIS indexed
and can be searched from the Gopher menu.
Contact: [email protected]
help: ways_to_get_rfcs
8. Security Considerations
9. Author's Address
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 310-822-1511
Fax: 310-823-6714
Email: [email protected]