Table of Contents Future - High-Speed Networking

1.5 Request For Comments (RFC)

The Internet protocol suite is still evolving through the mechanism of Request For Comments (RFC). New protocols (mostly application protocols) are being designed and implemented by researchers, and are brought to the attention of the Internet community in the form of an RFC. (0)The RFC mechanism is overseen by the Internet Architecture Board (IAB). The largest source of RFCs is the Internet Engineering Task Force (IETF) which is a subsidiary of the IAB. However, anyone may submit a memo proposed as an RFC to the RFC Editor. There are a set of rules which RFC authors must follow in order for an RFC to be accepted. These rules are themselves described in an RFC (RFC 1543) which also indicates how to submit a proposal for an RFC.

Once an RFC has been published, all revisions and replacements are published as new RFCs. A new RFC which revises or replaces an existing RFC is said to ``update'' or to ``obsolete'' that RFC. The existing RFC is said to be ``updated by'' or ``obsoleted by'' the new one. For example RFC 1521 which describes the MIME protocol is a ``second edition'', being a revision of RFC 1341 and RFC 1590 is an amendment to RFC 1521. RFC 1521 is therefore labelled like this: ``Obsoletes RFC 1341; Updated by RFC 1590''. Consequently, there is never any confusion over whether two people are referring to different versions of an RFC, since there are never different versions.

Some RFCs are described as information documents while others describe Internet protocols. The Internet Architecture Board (IAB) maintains a list of the RFCs that describe the protocol suite. Each of these is assigned a state and a status.

An Internet protocol can have one of the following states:

Standard

The IAB has established this as an official protocol for the Internet. These are separated in two groups:

1. IP protocol and above, protocols that apply to the whole Internet.
2. Network-specific protocols, generally specifications of how to do IP on particular types of networks.

Draft standard

The IAB is actively considering this protocol as a possible standard protocol. Substantial and widespread testing and comments are desired. Comments and test results should be submitted to the IAB. There is a possibility that changes will be made in a draft protocol before it becomes a standard.

Proposed standard

These are protocol proposals that may be considered by the IAB for standardization in the future. Implementations and testing by several groups are desirable. Revision of the protocol is likely.

Experimental

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.

Informational

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 on the Internet by the IAB.

Historic

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.

Definitions of protocol status:

Required

A system must implement the required protocols.

Recommended

A system should implement the recommended protocol.

Elective

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.

Limited use

These protocols are for use in limited circumstances. This may be because of their experimental state, specialized nature, limited functionality, or historic state.

Not recommended

These protocols are not recommended for general use. This may be because of their limited functionality, specialized nature, or experimental or historic state.

1.5.1 Internet Standards

Proposed standard, draft standard and standard protocols are described as being on the Internet Standards Track. The standards track is controlled by the Internet Engineering Steering Group (IESG) of the IETF. When a protocol reaches the standard state it is assigned a standard number (STD). The purpose of STD numbers is to clearly indicate which RFCs describe Internet standards. STD numbers reference multiple RFCs when the specification of a standard is spread across multiple documents. Unlike RFCs, where the number refers to a specific document, STD numbers do not change when a standard is updated. STD numbers do not, however, have version numbers since all updates are made via RFCs and the RFC numbers are unique. Thus to unambiguously specify which version of a standard one is referring to, the standard number and all of the RFCs which it includes should be stated. For instance, the Domain Name System (DNS) is STD 13 and is described in RFCs 1034 and 1035. To reference the standard, a form like ``STD-13/RFC-1034/RFC-1035'' should be used. For a description of the Standards Process, see RFC 1602 -- The Internet Standards Process - Revision 2.

For some standards track RFCs the status category does not always contain enough information to be useful. It is therefore supplemented, notably for routing protocols by an applicability statement which is given either in STD 1 or in a separate RFC.

References to the RFCs and to STD numbers will be made throughout this book, since they form the basis of all TCP/IP protocol implementations.

Four Internet standards are of particular importance:

STD 1 - Internet Official Protocol Standards

This standard gives the state and status of each Internet protocol or standard, and defines the meanings attributed to each different state or status. It is issued by the IAB approximately quarterly. At the time of writing this standard is in RFC 1780 (March 1995).

STD 2 - Assigned Internet Numbers

This standard lists currently assigned numbers and other protocol parameters in the Internet protocol suite. It is issued by the Internet Assigned Numbers Authority (IANA). The current edition at the time of writing is RFC 1700 (October 1994).

STD 3 - Host Requirements

This standard defines the requirements for Internet host software (often by reference to the relevant RFCs). The standard comes in two parts: RFC 1122 - Requirements for Internet hosts - communications layer and RFC 1123 - Requirements for Internet hosts - application and support.

STD 4 - Gateway Requirements

This standard defines the requirements for Internet gateway (router) software. It is RFC 1009.

1.5.2 For Your Information (FYI)

A number of RFCs which are intended to be of wide interest to Internet users are classified as For Your Information (FYI) documents. They frequently contain introductory or other helpful information. Like STD numbers, an FYI number is not changed when a revised RFC is issued. Unlike STDs, FYIs correspond to a single RFC document. For example, FYI 4 -- FYI on Questions and Answers - Answers to Commonly asked ``New Internet User'' Questions is currently in its fourth edition. The RFC numbers are 1177, 1206, 1325 and 1594.

1.5.3 Obtaining RFCs

All RFCs are available publicly, both in printed and electronic form from the Internet Network Information Center or InterNIC (internic.net). Prior to 1993, the NIC function was performed by the DDN NIC (nic.ddn.mil). See RFC 1400 for more information about the transition.

• RFCs can be obtained in printed form from:
  Network Solutions, Inc.
  Attn: InterNIC Registration Service
  505 Huntmar Park Drive
  Herndon, VA 22070
  
  Help Desk Telephone Number:
  703-742-4777
  
  FAX Number 703-742-4811
  
  
• To get the electronic form, users may use anonymous FTP to ds.internic.net (198.49.45.10) and retrieve files from the directory rfc, or Gopher to internic.net (198.41.0.5).
• For information on other methods of accessing RFCs by E-mail or FTP, send an E-mail message to ``rfc-info@ISI.EDU'' with the message body ``help: ways_to_get_rfcs''. For example:

  To: rfc-info@ISI.EDU
  Subject: getting rfcs
  
  help: ways_to_get_rfcs
  

• If you have World Wide Web access, there are many sites that maintain RFC archives. One that you might try is the MAGIC Document Archive at http://www.msci.magic.net/docs/rfc/rfc_by_num.html.
• RFCs can also be obtained through the IBM VNET network using the following command:

  EXEC TOOLS SENDTO ALMVMA ARCNET RFC GET RFCnnnn TXT *
  

  Where nnnn refers to the number of the RFC.

  To obtain the list of all the RFCs (and to know if they are available in TXT format or in PostScript format), use the command:

  EXEC TOOLS SENDTO ALMVMA ARCNET RFC GET RFCINDEX TXT *
  

1.5.4 Major Internet Protocols

To give an idea of the importance of the major protocols, we list some of them together with their current state and status and STD number where applicable in Table - The Current state and status and STD numbers of Important Internet protocols. The complete list can be found in RFC 1780 - Internet Official Protocol Standards. Legend:
State: Std. = Standard; Draft = Draft Standard; Prop. = Proposed Standard; Info. = Informational; Hist. = Historic
Status: Req. = Required; Rec. = Recommended; Ele. = Elective; Not = Not Recommended


Table: The Current state and status and STD numbers of Important Internet protocols

At the time of writing there is no RFC associated with the HyperText Transfer Protocol used in World Wide Web implementations. However, the document HyperText Transfer Protocol (HTTP) written by Tim Berners-Lee may be obtained at ftp://info.cern.ch/pub/www/doc/http-spec.text.

In addition, the following RFCs describe the Uniform Resource Locator (URL) and associated concepts:

• RFC 1630 - Universal Resource Identifiers in WWW
• RFC 1737 - Functional Requirements for Uniform Resource Names
• RFC 1738 - Uniform Resource Locators (URL)

Table of Contents Architecture and Protocols