Have you ever been mystified by RFCs or their kin? Then read on for a full revelation. Although, I was familiar with ANSI and ISO standards before I researched this article, Internet standards were another story. RFCs seemed like secret documents only available to insiders.

• Standards for the Internet
• Forms of Internet Documentation
• Types of RFCs
• Selected RFCs
• Finding the Right RFC
• Acronyms

Questions reg arding this article should be directed to the author at knordby@vnet.ibm.com

Some years ago I was assigned to work on an ISO committee, and I eventually learned about the nomenclature and taxonomy of ISO documents. But when I ran into a reference such as, ``MIME (see RFC 1521) is an extension to mail (see RFC 822),'' I did not know how to interpret the RFC references. What were these RFC documents? How could I get a copy?

The situation became more acute when I started to work on a software project designed to be an application for the World Wide Web. What level of HTTP, HTML and CGI should we adopt? These technologies seemed to be documented in RFCs -- so I had to solve the mystery. I started learning about RFCs.

This article reflects the results of my study. It is tutorial in nature and is intended for Unix developers and others who need to get acquainted with RFCs. I keep this article as a reference for my own use, and my hope is tha t it will also help others to understand RFCs and use them. I hope it helps you!

Standards for the Internet

When our software development team recently wrote a World Wide Web application that generates dynamic Web pages, we discovered that Web pages must start with an HTTP (Hypertext Transfer Protocol) header. One of the values in an HTTP header is the HTTP version -- for example, ``HTTP 1.0''. Is the version number important? Yes, because of functional differences: not only is there a difference between HTTP/0.9 and HTTP/1.0, but a third version appeared in January, 1997 -- HTTP/1.1. Where do HTTP versions come from? Where are the specifications maintained?

HTTP is an example of an Internet protocol in the process of standardization, and documentation for Internet standards is maintained in numbered documents called Request for Comments (RFC).

When new technology is rapidly accepted and implemented, standards are often needed to stabilize growth and pr omote consistency. Standards have played an important role in information technology. For example, the common ASCII characters and code points have been standardized, and the C programming language has become an ANSI (American National Standards Institute) standard. The C++ language, by contrast, illustrates a software technology where ANSI standardization is still in progress. Once information technology is standardized at the national level it often progresses to international standardization through ISO (the International Organization for Standardization).

The growth of the Internet is reflected in the following statistics:

• The number of Internet hosts has increased from 1.3 million in January, 1993 to 16.1 million in January, 1997.
• The number of networks being attached to the Internet is increasing by 30,000+ per month.
• The number of World Wide Web servers has increased from 130 in June, 1993 to 646,162 in January, 1997 (Carolina Computer News, March 1997).

With growth of this magnitude, standardization of Internet protocols is critical to ensure that network software accomplishes its purpose -- to support the flow of information across the network. For example, a software developer needs to be sure that the code that implements FTP on his workstation is compatible with the FTP code running on the file server. The Internet supports a standardization process for network protocols, and in this role it acts as a standards body analogous to ANSI and ISO.

Non-technical RFCs

Internet standards are documented in RFC documents. However, not all RFCs contain standards. In fact, RFCs contain a great variety of information, and not all of it is highly technical. A humorous example of a non-technical RFC is RFC 527 .

Informational RFCs

Some RFC documents are purely informational, such as those that publish tutorial material that helps people understand specific aspects of the Internet. RFC 1865 , which explains how the Internet supports EDI (Electronic Data Interchange), is a good example.

Thus, RFCs provide different services, such as documenting standards, educating users, and even providing humor. In addition, some RFCs contain information of historical interest. The oldest RFC, RFC 1, is dated April 7, 1969, and the approximately 2200 RFCs issued since that time reflect the steady growth of the Internet over many years. Some examples follow.

For History Buffs

1973...

RFC 542 (August, 1973) discusses early development of file transfer technology, and makes the following optimistic assessment:

``The File Transfer protocol should be considered stable at least until February.''

1974...

Another early RFC discusses the need for improved performance when transferring files using t he Multics operating system:

``With the growth of Multics usage in the ARPA Network community, users often need to transfer large amounts of data from Multics to other systems. However, Multics performance in this area has been less than optimal and there clearly exists a need to improve the situation'' (RFC 662, November, 1974).

This RFC reflects an early stage in Internet history, because Multics is the operating system that Ken Thompson and Dennis Ritchie worked on before they started developing Unix.

1975...

An early reference to Unix occurs in RFC 681 (March, 1975), which suggests that Unix might be a promising platform for networking:

``The Unix time-sharing system presents several interesting capabilities as an ARPA network mini-host.''

But the RFC writers felt that Unix was not without its risks:

``As of this writing, network Unix has been running on a full time basis for about fou r weeks. During that period, there were between three and four crashes a day. This is not a valid indicator because many of the failures were due to hardware complications...''

1982...

Is it safe to use the TCP protocol on a LAN? Today, when enterprises are adopting TCP for internal communications over intranets, this question is archaic. But in 1982 the author of RFC 872 found it necessary to defend the use of TCP:

``The sometimes held position that the DoD Standard Transmission Control Protocol (TCP) and Internet Protocol (IP) are inappropriate for use on a Local Area Network (LAN) is shown to be fallacious. The sometimes expressed fear that using TCP on a local net is a bad idea is unfounded.''

Forms of Internet Documentation

RFC documents are a major source of information about the Internet. However, other forms of Internet documentation are also available. The InterNIC, an organization that provides directory, education, registration, and database services for the Internet, lists several categories of electronic documents that relate to the Internet. These include the following:

• IETF documents
• IESG documents
• ISOC documents
• Internet Drafts
• RFC documents
• STD RFC documents
• FYI RFC documents.

What Is the IETF?

The IETF (Internet Engineering Task Force) is one of the groups that cooperate to administer the Internet. IETF's focus is on developing standards for the Internet. The following description is adapted from RFC 1594:

``The Internet has grown to encompass a large number of widely geographically dispersed networks in academic and research communities. It now provides an infrastructure for a broad community with various interests. Moreover, the family of Internet protocols and system components has moved from experimental to commercial d evelopment. To help coordinate the operation, management and evolution of the Internet, the Internet Architecture Board (IAB) established the Internet Engineering Task Force (IETF).''

``The IETF is a large open community of network designers, operators, vendors, and researchers concerned with the Internet and the Internet protocol suite. The activity is performed in a number of working groups organized around a set of several technical areas, each working group has a chair, and each area is managed by a technical area director. The IETF overall is managed by its chair and the Internet Engineering Steering Group (IESG), which is made up of the area directors.''

``The IAB has delegated to the IESG the general responsibility for the resolution of short- and mid-range protocol and architectural issues required to make the Internet function effectively, and the development of Internet standards.''

IETF Documents

Most IETF documents are minutes from meetings of IETF working groups. For example, this sample IETF document reports the minutes of the April, 1997 meeting of the Calendaring and Scheduling working group.

IESG Documents

IESG (Internet Engineering Steering Group) documents primarily consist of minutes from IESG meetings. This sample IESG document contains minutes from a meeting on July 10, 1997.

ISOC documents

The Internet Society (ISOC) was created in 1992 as an umbrella organization with administrative authority over the Internet. ISOC documents include announcements, speeches, frequently asked questions, and press releases. This sample ISOC document , which concerns ethic al use of the Internet, was issued after a 1994 meeting of the Internet Society Board of Trustees.

Internet Drafts

Internet Drafts (IDs) contain proposed Internet documents. They must be updated within six months or they are deleted. After review and approval by IETF members, the IAB (Internet Architecture Board), and the RFC editor, an Internet Draft can be published as an RFC. This index lists representative Internet Drafts.

Types of RFCs

The RFC series includes several different types of documents. The following excerpt from RFC 1594, ``FYI on Questions and Answers,'', gives a general description of RFCs:

``The Request for Comments documents (RFCs) are working notes of 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 s pecification of a standard.''

``Most RFCs are the descriptions of network protocols or services, often giving detailed procedures and formats for their implementation. Other RFCs report on the results of policy studies or summarize the work of technical committees or workshops. All RFCs are considered public domain unless explicitly marked otherwise.''

``While RFCs are not refereed publications, they do receive technical review from either the task forces, individual technical experts, or the RFC Editor, as appropriate. Currently, most standards are published as RFCs, but not all RFCs specify standards.''

``Once a document is assigned an RFC number and published, that RFC is never revised or re-issued with the same number. There is never a question of having the most recent version of a particular RFC. However, a protocol (such as File Transfer Protocol (FTP)) may be improved and re-documented many times in several different RFCs. It is important to verify that you have the most recent RFC on a particular protocol.''

RFC 1543, ``Instructions to RFC Authors,'' indicates that RFCs are primarily intended to discuss topics related to the Internet and its protocols:

``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.''

Although in principle anyone may submit an RFC, most RFCs are created by IETF working groups:

``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 evolve their working memos (known as Internet Drafts or IDs) until they feel they are ready for publication, then the memos are reviewed b y the Internet Engineering Steering Group (IESG), and if approved sent by the IESG to the RFC Editor.''

Based on naming conventions, RFC documents can be divided into four groups:

Best Current Practices (BCP) RFCs

These RFCs describe best current practices for the Internet community. These documents must go through a review process to earn the technical approval of the IETF, but do not become Internet Standards. They carry the BCP label.

For Your Information (FYI) RFCs

These RFCs are informative or explanatory in nature and can address any topic of interest to the Internet community. They carry the FYI label.

Standards (STD) RFCs

These RFCs contain technical information that either has attained the status of Internet Standard or is ``on the track'' toward becoming an Internet Standard. If the material has already been standardized, the RFC carries the STD label.

Other RFCs

This grou p includes all RFCs that are not identified as BCP, FYI, or STD RFCs. These documents are usually technical in nature and usually relate in some way to an Internet protocol.

Some RFCs serve the special purpose of summarizing other RFCs. Beginning with RFC 899, RFCs whose numbers end in ``99'' are reserved for a summary of the preceding 99 RFCs. Thus, RFC 1999 is a summary of RFCs 1900 through 1999. For each summarized RFC, the summary RFC lists the number, author, date, and title, and provides a short description.

RFCs can also be characterized by a Category keyword and Status paragraph, which appear on the first page. The Category can be one of the following:

• Informational
• Standards Track
• Experimental

The Status section, headed ``Status of this Memo,'' is related to the Category keyword. It can contain one of the following paragraphs:

If category is Informational:

``This memo provides information for th e Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.''

If category is 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.''

If category is 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.''

Best Current Practices RFCs

Best Current Practices RFCs represent officially endorsed recommendations regarding Internet practices, but are not as formal as Internet Stand ards. Best Current Practices RFCs are sanctioned in RFC 1818, ``Best Current Practices'':

``This document describes a new series of documents that describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).''

``The current IETF process has two types of RFCs: standards track documents and other RFCs (e.g., informational, experimental, FYIs). The intent of the standards track documents is clear, and culminates in an official Internet Standard. Informational RFCs can be published on a less formal basis, subject to the reasonable constraints of the RFC editor. Informational RFCs are not subject to peer review and carry no significance whatsoever within the IETF process.''

``The IETF currently has no other mechanism or means of publishing relevant technical information which it endorses. This document creates a new subse ries of RFCs, entitled Best Current Practices (BCPs).''

``The BCP process is similar to that for proposed standards. The BCP is submitted to the IESG for review, and the existing review process applies, including a `last call' on the IETF announcement mailing list. However, once the IESG has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical approval of the IETF, but it is not, and cannot become an official Internet Standard.''

Note that BCP RFCs carry a BCP number as well as an RFC number. Here are some examples of BCP titles:

• ``Address Allocation for Private Internets,'' BCP 5 (RFC 1918)
• ``Guidelines for creation, selection, and registration of an Autonomous System,'' BCP 6 (RFC 1930)
• ``Implications of Various Address Allocation Policies for Internet Routing,'' BCP 7 (RFC 2008)
• ``IRTF Research Group Guidelines and Procedures,'' BC P 8 (RFC 2014).

This sample document is an example of a BCP RFC. It defines registration procedures for MIME content types.

For Your Information RFCs

According to RFC 1150, ``F.Y.I. on F.Y.I.,'' FYI RFCs are intended to be less technical than typical RFCs:

``This RFC is the first in a new sub-series of RFCs called FYIs (For Your Information). The FYI series of notes is designed to provide Internet users with a central repository of information about any topics that relate to the Internet. FYI topics may range from historical memos on `Why it was done this way' to answers to commonly asked operational questions. The FYIs are intended for a wide audience. Some FYIs will cater to beginners, while others will discuss more advanced topics. An FYI may be submitted by anyone who has something to contribute and has the time to do so.''

Here are some examples of FYI titles:

• ``A Revised Catalog of Available X.500 Implementations,'' FYI 11 (RFC 1632)
• ``How to Use Anonymous FTP,'' FYI 24 (RFC 1635).
• ``K-12 Internetworking Guidelines,'' FYI 26 (RFC 1709).

RFC 1594 comments about the relationship between FYI numbers and RFC numbers:

``FYI documents are assigned both an FYI number and an RFC number. As RFCs, if an FYI is ever updated, it is issued again with a new RFC number; however, its FYI number remains unchanged. This can be a little confusing at first, but the aim is to help users identify which FYIs are about which topics. For example, FYI 4 will always be FYI 4, even though it may be updated several times and during that process receive different RFC numbers. Thus, you need only to remember the FYI number to find the proper document. Of course, remembering titles often works as well.''

FYI 4 is a useful document for new users of the Internet. This FYI RF C (RFC 1594) is entitled, ``FYI on Questions and Answers: Answers to Commonly asked `New Internet User' Questions.'' It contains short answers to a variety of questions about the Internet, including:

• What is the Internet?
• How do I find someone's electronic mail address?
• What is anonymous FTP?
• How do I get a Netnews feed?

This sample document is an example of an FYI RFC. This RFC is intended to assist Internet users in creating useful names for their computers.

Standards RFCs

Standards RFCs are the subset of RFC documents that contain technical material subject to Internet standardization. According to RFC 1594:

``The newest subseries of RFCs are the STDs (Standards). RFC 1311, which introduces this subseries, states that the intent of STDs is to identify clearly those RFCs that document Internet standards. An STD number wil l be assigned only to those specifications that have completed the full process of standardization in the Internet. Existing Internet standards have been assigned STD numbers; a list of them can be found both in RFC 1311 and in the ``Internet Official Protocol Standards'' RFC. Like FYIs, once a standard has been assigned an STD number, that number will not change, even if the standard is reworked and re-specified and later issued with a new RFC number.''

``It is important to differentiate between a `standard' and `document.' Different RFC documents will always have different RFC numbers. However, sometimes the complete specification for a standard will be contained in more than one RFC document. When this happens, each of the RFC documents that is part of the specification for that standard will carry the same STD number. For example, the Domain Name System (DNS) is specified by the combination of RFC 1034 and RFC 1035; therefore, both of those RFCs are labeled STD 13.''

It is also possible for one Internet Standard to include more than one Internet protocol; for example, Internet Standard 5 includes the IP protocol, the ICMP protocol, and the IGMP protocol.

Where do Internet standards come from? The Internet standardization process is documented in RFC 2200, ``Internet Official Protocol Standards,'' and RFC 2026, ``The Internet Standards Process -- Revision 3.'' The overall process can be summarized in the following steps:

Write specification

Internet specifications are usually created by IETF working groups. External organizations or individuals can also submit new specifications, often working in conjunction with IETF working groups.

Circulate specification as Internet Draft

Draft versions of the document are made available for informal review and comment by placing them in the IETF directory of Internet Drafts . Internet Drafts have no formal status, and are subject to change or removal at any time. Note that Internet Drafts are not RFCs.

Review specification

Time is allowed for technical review by the IESG, the IETF, and the general Internet community. The review period can vary from two weeks to six months.

Publish specification as RFC

If the IESG determines that the specification has sufficient merit to become a proposed standard, the specification is placed on the Internet ``standards track.'' It is removed from the Internet Drafts directory and published as an RFC.

Review/revise specification as Proposed Standard

The specification is designated Proposed Standard and remains at this level for at least six months.

Review/revise specification as Draft Standard

The specification is a designated Draft Standard and remains a t this level for at least four months, or until at least one IETF meeting has occurred.

Publish specification as Internet Standard

The specification is designated Internet Standard. When a specification is adopted as an Internet Standard, it is assigned a standard number; for example, the NetBIOS protocol is Standard 19. The standard number appears on the first page of the document. Note that the document keeps its RFC number and its place in the RFC series.

Because both standardized protocol specifications and miscellaneous types of documents are published as RFCs, there is potential for misunderstanding exactly which RFCs contain Internet standards. RFC 1796, ``Not All RFCs are Standards,'' clarifies the relationship between Internet standards and other kinds of RFCs:

``The `Request for Comments' (RFC) document series is the official publication channel for Internet standards documents and other publications of the IESG, IAB, and Internet community. From time to time... someone questions the rationality of publishing both Internet standards and informational documents as RFCs. The argument is generally that this introduces some confusion between `real standards' and `mere publications.' ''

``It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal.''

``The RFC series includes some documents that are informational by nature and other documents that describe experiences. A problem of perception occurs when such a document `looks like' an official protocol specification. Misguided vendors may claim conformance to it, and misguided clients may actually believe that they are buying an Internet standard.''

This sample d ocument is an example of an STD RFC. This RFC describes the Point-to-Point (PPP) protocol.

Additional Standards Terminology

RFCs on the Internet standards track are sometimes characterized by additional standards-related terms, which are described in the following section.

1. Terms describing content

   A standards RFC can be a Technical Specification (TS) or an Applicability Statement (AS) . According to RFC 1602:

   ``A Technical Specification is any description of a protocol, service, procedure, convention, or format ... an Applicability Statement specifies how, and under what circumstances, one or more TSs are to be applied to support a particular Internet capability ... although TSs and ASs are conceptually separate, in practice a standards-track document may combine an AS and one or more related TSs.''

2. Terms describing levels

   Technical Specifications and Applicability Statements on the Internet stand ards track have one of the following maturity levels:

   • Proposed Standard
   • Draft Standard
   • Internet Standard .

   Technical Specifications and Applicability Statements not on the Internet standards track are labeled with one of the following ``off-track'' maturity levels:

   • Prototype
   • Experimental
   • Informational
   • Historic.

   Prototypes are new protocols that affect core services of the Internet, for which the IESG has requested additional operational experience. An experimental specification is part of some research or development effort. An informational specification is published for the general benefit of the Internet community, and does not represent an Internet consensus or recommendation. A historic specification has been superseded by a more recent specification or is for some other reason considered to be obsolete.

3. Terms describing requirements

   An Applicability Statement may apply one of the following requirement levels to its related Technical Specifications:

   • Required : implementation of the referenced TS is required to achieve minimal conformance
   • Recommended : implementation of the referenced TS is not required for minimal conformance, but vendors are strongly encouraged to include the functions, features, and protocols of the related TS
   • Elective : implementation of the referenced TS is optional within the scope of the related AS.

   Technical Specifications that are not on the standards track can have the following requirement levels:

   • Limited Use : an example of this level would be a non-standards track specification with the maturity level ``Experimental'' that should be used only by persons actively involved in the experimental project
   • Not Recommended : applies to TSs that are considered to be in appropriate for general use.

Selected RFCs

Each of the more than 2200 RFC documents contributes in some way to our understanding of Internet technology. However, not all RFCs address topics of equal interest to Internet users. This section focuses on three groups of RFCs that address topics of general interest -- RFCs describing Internet protocols, RFCs describing World Wide Web protocols, and informative RFCs that can help users learn more about the Internet.

Protocol RFCs

The following table identifies RFCs that specify selected Internet protocols:

Web RFCs

Is there an RFC that ``standardizes the Web?'' Unfortunately for software developers, the Web is too complex to be described in just one RFC. Four main specifications govern the functioning of the Web: URL, HTTP, HTML, and CGI.

URL

URLs (Uniform Resource L ocators) are key components in the operation of the Web because they provide a means of identifying locations in Web space. URLs are described in RFCs 1630, 1737, 1738, and 1808.

RFC 1630
This RFC, published June, 1994, is entitled ``Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web.'' RFC 1630 is categorized as Informational and does not describe an Internet standard. The Introduction states:

``This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet ... A Universal Resource Identifier (URI) is a member of this universal set of names in registered name spaces and addresses referring to registered protocols or name spaces. A Uniform Resource Locator (URL) is a form of URI that expresses an address which maps onto an access algorithm using network protocols ... The Uniform Resou rce Name (URN) debate attempts to define a name space ... for persistent object names.''

RFC 1737
This RFC, dated December, 1994, is entitled ``Functional Requirements for Uniform Resource Names''. RFC 1737 is categorized as Informational and does not describe an Internet standard. The Introduction states:

``This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). URNs fit within a larger Internet information architecture, which in turn is composed of, additionally, Uniform Resource Characteristics (URCs), and Uniform Resource Locators (URLs). URNs are used for identification, URCs for including meta-information, and URLs for locating or finding resources.''

Universal Resource Identifier (URI) and Uniform Resource Name (URN) are concepts related to Uniform Resource Locator (URL), but have not been as widely implemented.

RFC 17 38
This RFC, dated December, 1994, is entitled ``Uniform Resource Locators (URL)''. RFC 1738 is categorized as Standards Track. Its status is Proposed Standard. The Introduction states:

``This document describes the syntax and semantics for a compact string representation for a resource available via the Internet. These strings are called Uniform Resource Locators (URLs). The specification is derived from concepts introduced by the World-Wide Web global information initiative, whose use of such objects dates from 1990 and is described in ``Universal Resource Identifiers in WWW'', RFC 1630.''

RFC 1808
This RFC, dated June, 1995, is entitled ``Relative Uniform Resource Locators''. This RFC discusses relative URLs as distinguished from absolute URLs. RFC 1808 is categorized as Standards Track. Its status is Proposed Standard. The Introduction states:

``This document describes the syntax and semantics for rel ative Uniform Resource Locators (relative URLs): a compact representation of the location of a resource relative to an absolute base URL. It is a companion to RFC 1738, ``Uniform Resource Locators (URL),'' which specifies the syntax and semantics of absolute URLs.''

HTTP

HTTP (Hypertext Transfer Protocol) is the Internet protocol that allows Web messages to be transported over the underlying IP layer. HTTP is described in RFCs 1945 and 2068.

RFC 1945
This RFC, dated May, 1996, is entitled ``Hypertext Transfer Protocol -- HTTP/1.0.'' RFC 1945 is categorized as Informational and does not specify an Internet standard. The Status and Abstract sections state the following:

``The IESG has concerns about this protocol, and expects this document to be replaced relatively soon by a standards track document.''

``The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol that can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.''

RFC 2068
This RFC, dated January, 1997, is entitled ``Hypertext Transfer Protocol --HTTP/1.1.'' RFC 2068 is categorized as Standards Track. Its status is Proposed Standard. The Introduction describes the relationship among HTTP/0.9, HTTP/1.0, and HTTP/1.1:

``HTTP has been in use by the World-Wide Web ... since 1990. The first version of HTTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0 ... improved the protocol by allowing messages to be in the format of MIME-like messages, containing meta information about the data transferred and modifiers on the request-response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, and virtual hosts. In addition, the proliferation of incompletely implemented applications calling themselves `HTTP/1.0' has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.''

HTML

HTML (Hypertext Markup Language) is a document tagging system derived from SGML (Standard Generalized Markup Language) that provides structural and stylistic information about content. HTML documents can be interpreted and rendered by Web browsers. HTML is described in RFCs 1866, 1942, and 1980.

RFC 1866
This RFC, dated November, 1995, is entitled ``Hypertext Markup Language -- 2.0.'' This RFC is characterized as Standards Track. Its status is Proposed Standard. The Abstract section states:

``The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.''

``HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).''

RFCs 1942 and 1980 describe two proposed extensions to HTML: tables and client-side image maps.

RFC 1942
This RFC, dated (May, 1996, is entitled ``HTML Tables.'' RFC 1942 is categorized as Experimental and does not specify an Internet standard. The Abstract states:

``The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, for example, the ability to group table rows into head, body and foot table sections, plus the ability to specify cell alignment compactly for sets of cells according to th e context.''

RFC 1980
This RFC, dated August, 1996, is entitled ``A Proposed Extension to HTML: Client-Side Image Maps.'' RFC 1980 is categorized as Informational and does not specify an Internet standard. The Abstract section states:

``The markup language known as HTML/2.0 provides for image maps. Image maps are document elements that allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the HTTP protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as Client-Side Image Maps, which resolves these limitations.''

In addition to HTML documentation published as RFCs, extensions to the HTML language have been published in other forms . For example, the World Wide Web Consortium has published a reference specification for HTML 3.2. This specification is described as a recommendation rather than a standard and is available at the following URL: http://www.w3.org/pub/WWW/TR/REC-html32.html .

CGI

The Common Gateway Interface (CGI) defines how an HTTP server can communicate with an executable program on the server. CGI enables Web users to invoke server-side executables through the Web browser.

CGI programs are sometimes referred to as CGI scripts because Unix shell scripts and Perl are often used to code them. However, executables compiled from C, C++, and other languages can also serve as CGI programs. CGI programs must be distinguished from other forms of Web-based executables, such as Web server extensions, local proxies, and applets.

Unlike URLs, HTTP, and HTML, CGI is not specified in RFCs. A search of the RFC repos itory on the ds.internic.net host identified several RFCs that refer to the Common Gateway Interface, but these RFCs do not contain the specification of the CGI standard. The CGI specification is available on the Web from the National Center for Supercomputing Applications at the following URL: http://hoohoo.ncsa.uiuc.edu/cgi/interface.html . This specification is for CGI level 1.1.

Informative RFCs

The following RFCs are especially helpful for learning about the Internet:

RFC 1000

``The Request for Comments Reference Guide''

RFC 1011

``Official Internet Protocols''

RFC 1118

``Hitchhikers Guide to the Internet''

RFC 1150

``F.Y.I. on F.Y.I.: Introduction to the F.Y.I. Notes''

RFC 1160

``The Internet Activities Board''

RFC 1180

``A TCP/IP Tutorial''

RFC 1207

``Answers to Commonly Asked "Experienced Internet User" Questions''

RFC 1208

``A Glossary of Networking Terms''

RFC 1311

``Introduction to the STD Notes''

RFC 1462

``FYI on "What is the Internet?"''

RFC 1594

``FYI on Questions and Answers: Answers to Commonly Asked "New Int ernet User" Questions''

RFC 1603

``IETF Working Group Guidelines and Procedures''

RFC 1635

``How to Use Anonymous FTP''

RFC 1718

``The Tao of the IETF: A Guide for New Attendees of the IETF''

RFC 1775

``To Be `On' the Internet''

RFC 1796

``Not All RFCs are Standards''

RFC 1855

``Netiquette Guidelines''

RFC 1935

``What is the Internet Anyway?''

RFC 1958

``Architectural Principles of the I nternet''

RFC 1983

``Internet Users' Glossary''

RFC 2026

``The Internet Standards Process -- Revision 3''

RFC 2028

``The Organizations Involved in the IETF Standards Process''

RFC 2200

``Internet Official Protocol Standards'' (STD 1).

Finding the Right RFC

RFC documents constitute an extensive knowledge base about the Internet, providing information about protocols, network operations, and other aspects of electronic communications. But along with the quantity and diversity of information comes a challenge -- navigating through this body of documents in order to locate RFCs that are relevant for specific tasks. For example, if a software engineer intends to r egister a new MIME data type to be carried in the HTTP protocol, how does he find out which RFC describes the MIME registration process? The best approach is to access an RFC repository that supports keyword search.

RFC documents are stored at several major Internet sites referred to as RFC repositories. These sites offer electronic access to RFC documents, traditionally by FTP or email. Some RFC sites also provide access to RFCs through the World Wide Web.

InterNIC

The InterNIC site, ds.internic.net, is an example of an RFC repository. (Note: www.internic.net and www.ds.internic.net are aliases). The InterNIC is a cooperative activity between the National Science Foundation, AT&T, and Network Solutions, Inc. that provides several Internet services including RFC access. InterNIC allows RFC retrieval by FTP, email, WAIS, gopher, and the Web.

• For FTP access, login with user name ``anonymous'' (or ``ftp'') and en ter your email address as password. After logging in, change directory to rfc and use the Ftp client get command to retrieve RFC files.



• To use email, send an email message to mailserv@ds.internic.net . The message body must contain a command, such as document-by-name rfc nnnn , file /ftp/rfc/rfc nnnn .txt , or simply help .
  
  
• To access RFCs through WAIS, you may use either your local WAIS client or telnet to ds.internic.net and login as wais (no password required) to access a WAIS client. Help information and a tutorial for using WAIS are available online. The WAIS database to search is rfcs .
  
  
• InterNIC documents are also available via Gopher. All collections are wais-index ed and can be searched from the Gopher menu. To access the InterNIC Gopher servers, please connect to internic.net port 70.



• To obtain RFCs through the Web, access InterNIC with the URL http://www.internic.net and click on ``Directory and Database Services.'' Then click on ``Internet Documentation (RFC's, FYI's, etc.) and IETF Information'' and continue following menus to the RFC indexes. An RFC keyword search is provided.

For more information about the InterNIC site contact admin@ds.internic.net .

Additional Repositories

The following sites are additional examples of RFC repositories. This list is not exhaustive.

nis.nsf.net

For FTP access, login with user name ``anonymous'' (or ``ftp'') and password ``guest''. Then change directory to /internet/documents/rfc . The file name is of the form rfcnnnn.txt . For access by email, address the request to nis-info@nis.nsf.net and leave the subject field of the message blank. The first text line of the message must be send rfcnnnn.txt . For information contact rfc-mgr@merit.edu .

nisc.jvnc.net

RFCs can be obtained via FTP with the path name rfc/rfc nnnn .txt . An index can be obtained with the path name rfc/rfc- index.txt . Address email requests to sendrfc@nisc.jvnc.net and in the subject field of the message indicate the RFC number, as in Subject: rfc nnnn . (Note that RFCs whose numbers are less than 1000 need not add a leading 0.) For example, RFC932 is valid. For a complete index to the RFC library enter rfc-index in the subject field, as in Subject: rfc-index . No text in the body of the message is needed. For information contact rfc-admin@nisc.jvnc.net .

ftp.isi.edu

RFCs can be obtained via FTP with the path name in-notes/rfc nnnn .txt . Login with FTP username ``anonymous'' (or ``ftp'') and password ``guest''. For information contact rfc-manager@isi.edu .

wuarchive.wustl.edu

RFCs can be obtained via FTP with the path name info/rfc/rfc nnnn .txt.Z . (Here, ``Z'' indicates that the document is in compressed format.) RFCs are in an archive file system and various archives can be mounted as part of an NFS file system. Contact Chris Myers (chris@wugate.wustl.edu) if you want to mount this file system in your NFS. For information contact chris@wugate.wustl.edu .

src.doc.ic .ac.uk

RFCs can be obtained via FTP with the path name rfc/rfc nnnn .txt.gz or rfc/rfc nnnn .ps.gz . (Trailing .gz indicates that the document is in Gzip compressed format.) Login with FTP username ``anonymous'' (or ``ftp'') and for password use your email address. To obtain the RFC index use the path name rfc/rfc-index.txt.gz . Email service is available for UK sites. Address request to info-server@doc.ic.ac.uk with a subject line of wanted and a message body of request sources topic path rfc/rfc nnnn .txt.gz request end . Multiple requests may be included in the same message by giving multiple topic path commands on separate lines. To request the RFC Index, the command should read topic path rf c/rfc-index.txt.gz . For information contact ukuug-soft@doc.ic.ac.uk .

ftp.ncren.net

To obtain RFCs via FTP, login with username ``anonymous'' (or ``ftp'') and use your Internet email address as password. The RFCs can be found in the directory /rfc , with file names of the form rfc nnnn .txt or rfc nnnn .ps . This repository is also accessible via WAIS and Gopher. For information contact rfc-mgr@ncren.net .

ftp.sesqui.net

RFCs can be obtained via FTP with the path name pub/rfc/rfc nnnn .txt or rfc nnnn .ps . RFCs are in an archive file system and various archives can be mounted as part of an NFS file system. Contact the RFC maintainer at rfc-maint@sesqui.net if you want to mount this file system in your NFS.

nis.garr.it

RFCs can be obtained in the following ways:

FTP

FTP to ftp.nis.garr.it. Login with username ``anonymous'' (or ``ftp'') and password ``guest''. Use path name mirrors/RFC/rfc nnnn .txt .

Gopher

Use gopher.nis.garr.it.

WWW

Use URL: ftp://ftp.nis.garr.it/mirrors/RFC.

Email

Send email to dbserv@nis.garr.it . Message should contain the command get mirrors/RFC/rfc nnnn .txt,ps . For example, to get RFC1004, the command should be get mirrors/RFC/rfc1004.txt . Put the get command either in the Subject or as a line in the mail message body.

The precedin g list of RFC repositories is adapted from a document entitled ``ways_to_get_rfcs'' available from the Information Sciences Institute at the University of Southern California (ISI). To obtain a copy of this document, send an email message to rfc-info@isi.edu with help: ways_to_get_rfcs as the text of the message.

RFC-INFO

Another way to obtain RFCs is the RFC-INFO service, which is an email-based service to help in locating and retrieving RFCs provided by ISI. Users can ask for lists of RFCs having certain values for attributes such as number, title, author, issuing organization, and date. Once an RFC is identified it can be retrieved. To use this service, send email to rfc-info@isi.edu with your requests as the text of the message. The subject field can contain any value, and input is not case dependent.

The following table shows examples of requests using the RFC-INFO servi ce:

The RFC-INFO service supports several keywords including author, doc-ID, and organization . A good way to start using the RFC-INFO service is to obtain the main help document with the request help: help.

Acronyms

ANSI

American National Standards Institute

ARPA

Advanced Research Projects Agency

AS

Applicability Statement

ASCII

Amer ican Standard Code for Information Interchange

BCD

Binary Coded Decimal

CALS

Computer Aided Acquisition & Logistics Support

CERN

Conseil Europeen pour la Recherche Nucleaire (European organization for nuclear research)

CGI

Common Gateway Interface

DARPA

Defense Advanced Research Projects Agency

DDN

US Defense Data Network

DES

Data Encryption Standard

DNS

Domain Name System

EDI

Electronic Data Interchange

FTP

File Transfer Protocol

FYI

For Your Information

GIF

Graphics Interchange Format

HTTP

Hypertext Transfer Protocol

HTML

Hypertext Markup Language

IAB

Internet Architecture Board

IANA

Internet Assigned Numbers Authority

ICMP

Internet Control Message Protocol

ID

Internet Draft

IESG

Internet Engineering Steering Group

IETF

Internet Engineering Task Force

IGMP

Internet Group Multicast Protocol

IMAP

Interactive Mail A ccess Protocol

IP

Internetworking Protocol

IRTF

Internet Research Task Force

ISI

Information Sciences Institute

ISO

International Organization for Standardization

ISOC

Internet Society

LAN

Local Area Network

MIME

Multipurpose Internet Mail Extensions

MPEG

Motion Picture Experts Group

NCSA

National Center for Supercomputing Applications

NFS

Network File System

NNTP

Network News Transport Protocol

NTP

Network Time Protocol

PEM

Privacy Enhanced Mail

POP

Post Office Protocol

PPP

Point-to-Point Protocol

RFC

Request For Comments

RSA

Rivest-Shamir-Adleman algorithm

RTP

Real Time Protocol

SGML

Standard Generalized Markup Language

SLIP

Serial Line Internetworking Protocol

SMTP

Simple Mail Transfer Protocol

SNMP

Simple Network Management Protocol

STD

Standard

TCP

Transmission Control Protocol

TS

Te chnical Specification

UDP

User Datagram Protocol

UK

United Kingdom

URC

Uniform Resource Characteristics

URI

Universal Resource Identifier

URL

Uniform Resource Locator

URN

Uniform Resource Name

UUCP

Unix-to-Unix Copy

WAIS

Wide Area Information Server

WWW

World Wide Web

Author Biography

Ken Nordby is a programmer in Cary, North Carolina. In between trips to the beach (2 hours east) and the mountains (4 hours west), Ken writes software in C, C++, and Java for IBM.