Note: This page [http://gtm.vlsm.org/in-rfc.html] is a tribute to the late Dr. Jonathan "--jon." Bruce Postel who occasionally started his email with "Hello." See also [http://gtm.vlsm.org/in-iana.html], RFC-2441, as well as RFC-2468. Do not forget to vote your favorite RFC!.

Hello.

This following is a list of more than 130 interesting (IMHO-lah!) not-so-technical Request For Comments (RFC) citations. It was extracted from http://www.isi.edu/in-notes/rfc-index.txt. Some parts (or the whole) of the abstract or introduction were cited. To get a full text of an RFC, please follow the URL of the related RFC. To get a full list of the Internet Official Protocol Standards, see STD-1 which is (currently) RFC-2600. See also the the RFC editor page.

0. RTFR: an Introduction to the RFC Jungle
1. Read The Fine RFCs -- part I
   • IANA and Jon Postel
   • Organizations in the Internet Standard Process Realm: ISOC, IAB, IESG, IETF, IEPG, and IRTF
   • The RFC-Editor
2. Read The Fine RFCs -- part II
   • General Information
   • DNS, IP Addresses, and Identifiers
3. Read The Fine RFCs -- part III
   • TCP/IP and Email
   • ETC
   • Agreements
4. Read The Fine RFCs -- part IV
   • VIR -- Very Interesting RFCs :-)

General Information

• RFC-1958: Architectural Principles of the Internet.
  B. Carpenter. June 1996. (Format: TXT=17345 bytes) (Status: INFORMATIONAL)

  The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model.
  [... complete text ...]

• RFC-2151: A Primer On Internet and TCP/IP Tools and Utilities .
  G. Kessler, S. Shepard. June 1997. (Format: TXT=114130 bytes) (Obsoletes RFC1739) (Also FYI0030) (Status: INFORMATIONAL)

  This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet.
  [... complete text ...]

• RFC-2150: Humanities and Arts: Sharing Center Stage on the Internet.
  J. Max, W. Stickle. October 1997. (Format: TXT=154037 bytes) (Also FYI0031) (Status: INFORMATIONAL)

  This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet. The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.

  The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure.
  [... complete text ...]

• RFC-1983: Internet Users Glossary.
  G. Malkin. August 1996. (Format: TXT=123008 bytes) (Obsoletes RFC1392) (Also FYI0018) (Status: INFORMATIONAL)

  There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them.
  [... complete text ...]

• RFC-1941: Frequently Asked Questions for Schools.
  J. Sellers & J. Robichaux. May 1996. (Format: TXT=150980 bytes) (Obsoletes RFC1578) (Also FYI0022) (Status: INFORMATIONAL)

  The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. The intended audience is educators who are recently connected to the Internet, who are accessing the Internet by some means other than a direct connection, or who are just beginning to consider Internet access as a resource for their schools. Although the Internet Engineering Task Force is an international organization and this paper will be valuable to educators in many countries, it is limited in focus to internetworking in the United States.
  [... complete text ...]

• RFC-1935: What is the Internet, Anyway?.
  J. Quarterman & S. Carl-Mitchell. April 1996. (Format: TXT=30369 bytes) (Status: INFORMATIONAL)

  We often mention the Internet, and in the press you read about the Internet as the prototype of the Information Highway; as a research tool; as open for business; as not ready for prime time; as a place your children might communicate with (pick one) a. strangers, b. teachers, c. pornographers, d. other children, e. their parents; as bigger than Poland; as smaller than Chicago; as a place to surf; as the biggest hype since Woodstock; as a competitive business tool; as the newest thing since sliced bread.
  [... complete text ...]

• RFC-1855: Netiquette Guidelines.
  S. Hambridge. October 1995. (Format: TXT=46185 bytes) (Also FYI0028) (Status: INFORMATIONAL)

  This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. As such, it is deliberately written in a bulleted format to make adaptation easier and to make any particular item easy (or easier) to find. It also functions as a minimum set of guidelines for individuals, both users and administrators. This memo is the product of the Responsible Use of the Network (RUN) Working Group of the IETF.
  [... complete text ...]

• RFC-1775: To Be "On" the Internet.
  D. Crocker. March 1995. (Format: TXT=8454 bytes) (Status: INFORMATIONAL)

  The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access.
  [... complete text ...]

• RFC-1746: Ways to Define User Expectations.
  B. Manning & D. Perkins. December 1994. (Format: TXT=46164 bytes) (Status: INFORMATIONAL)

  This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet.
  [... complete text ...]

• RFC-2664: FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions.
  R. Plzak, A. Wells, E. Krol. August 1999. (Format: TXT=23640 bytes) (Obsoletes RFC1594) (Also FYI0004) (Status: INFORMATIONAL)

  This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of a more technically sophisticated Internet user. Those desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand the Internet.
  [... complete text ...]

• RFC-1462: FYI on "What is the Internet?".
  E. Krol & E. Hoffman. May 1993. (Format: TXT=27811 bytes) (Also FYI0020) (Status: INFORMATIONAL)

  This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). Containing a modified chapter from Ed Krol's 1992 book, "The Whole Internet User's Guide and Catalog," the paper covers the Internet's definition, history, administration, protocols, financing, and current issues such as growth, commercialization, and privatization.
  [... complete text ...]

• RFC-1402: There is Gold in them thar Networks! or Searching for Treasure in all the Wrong Places.
  J. Martin. January 1993. (Format: TXT=71176 bytes) (Obsoletes RFC1290) (Also FYI0010) (Status: INFORMATIONAL)

  A wealth of information exists on the network. In fact, there is so much information that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be useful.
  [... complete text ...]

• RFC-1207: FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions.
  G.S. Malkin, A.N. Marine, J.K. Reynolds. Feb-01-1991. (Format: TXT=33385 bytes) (Also FYI0007) (Status: INFORMATIONAL)

  This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet.
  [... complete text ...]

• RFC-1192: Commercialization of the Internet summary report.
  B. Kahin. Nov-01-1990. (Format: TXT=35253 bytes) (Status: INFORMATIONAL)

  This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990.
  [... complete text ...]

• RFC-1169: Explaining the role of GOSIP.
  V.G. Cerf, K.L. Mills. Aug-01-1990. (Format: TXT=30255 bytes) (Status: INFORMATIONAL)

  The Federal Networking Council (FNC), the Internet Activities Board (IAB), and the Internet Engineering Task Force (IETF) have a firm commitment to responsible integration of OSI based upon sound network planning. This implies that OSI will be added to the Internet without sacrificing services now available to existing Internet users, and that a multi-protocol environment will exist in the Internet for a prolonged period. Planning is underway within the Internet community to enable integration of OSI, coexistence of OSI with TCP/IP, and interoperability between OSI and TCP/IP.
  [... complete text ...]

• RFC-1087: Ethics and the Internet.
  Defense Advanced Research Projects Agency, Internet Activities Board. Jan-01-1989. (Format: TXT=4582 bytes) (Status: UNKNOWN)

  At great human and economic cost, resources drawn from the U.S. Government, industry and the academic community have been assembled into a collection of interconnected networks called the Internet. Begun as a vehicle for experimental network research in the mid- 1970's, the Internet has become an important national infrastructure supporting an increasingly widespread, multi-disciplinary community of researchers ranging, inter alia, from computer scientists and electrical engineers to mathematicians, physicists, medical researchers, chemists, astronomers and space scientists.
  [... complete text ...]

DNS, IP Addresses, and Identifiers

• RFC-1591: Domain Name System Structure and Delegation.
  J. Postel. March 1994. (Format: TXT=16481 bytes) (Status: INFORMATIONAL)

  This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. The Internet Assigned Numbers Authority (IANA) is the overall authority for the IP Addresses, the Domain Names, and many other parameters, used in the Internet. The day-to-day responsibility for the assignment of IP Addresses, Autonomous System Numbers, and most top and second level Domain Names are handled by the Internet Registry (IR) and regional registries.
  [... complete text ...]

• RFC-2606: Reserved Top Level DNS Names.
  D. Eastlake, A. Panitz. June 1999. (Format: TXT=8008 bytes) (Also RFC2606) (Status: BEST CURRENT PRACTICE)

  To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented

  	(.test, .example, .invalid, .localhost).
  

  [... complete text ...]

• RFC-2050: INTERNET REGISTRY IP ALLOCATION GUIDELINES.
  K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format: TXT=28975 bytes) (Also BCP0012) (Status: BEST CURRENT PRACTICE)

  This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space.

  This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by the IANA. The guidelines and these policies are subject to revision at the direction of the IANA. The registry working group (IRE WG) will be discussing these issues and may provide advice to the IANA about possible revisions.
  [... complete text ...]

• RFC-2101: IPv4 Address Behaviour Today.
  B. Carpenter, J. Crowcroft, Y. Rekhter. February 1997. (Format: TXT=31407 bytes) (Status: INFORMATIONAL)

  The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4.
  [... complete text ...]

• RFC-1886: DNS Extensions to support IP version 6.
  S. Thomson & C. Huitema. December 1995. (Format: TXT=6424 bytes) (Status: PROPOSED STANDARD)

  This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves.
  [... complete text ...]

• RFC-1881: IPv6 Address Allocation Management.
  IAB & IESG. December 1995. (Format: TXT=3215 bytes) (Status: INFORMATIONAL)

  The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries.
  [... complete text ...]

• RFC-2182: Selection and Operation of Secondary DNS Servers.
  R. Elz, R. Bush, S. Bradner, M. Patton. July 1997. (Format: TXT=27456 bytes) (Also BCP0016) (Status: BEST CURRENT PRACTICE)

  The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered.
  [... complete text ...]

• RFC-2181 Clarifications to the DNS Specification.
  R. Elz, R. Bush. July 1997. (Format: TXT=36989 bytes) (Updates RFC1034, RFC1035, RFC1123) (Status: PROPOSED STANDARD)

  This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. Eight separate issues are considered:

  • IP packet header address usage from multi-homed servers,
  • TTLs in sets of records with the same name, class, and type,
  • correct handling of zone cuts,
  • three minor issues concerning SOA records and their use,
  • the precise definition of the Time to Live (TTL)
  • Use of the TC (truncated) header bit
  • the issue of what is an authoritative, or canonical, name,
  • and the issue of what makes a valid DNS label.
  
  [... complete text ...]

• RFC-2317: Classless IN-ADDR.ARPA delegation.
  H. Eidnes, G. de Groot, P. Vixie. March 1998. (Format: TXT=17744 bytes) (Also BCP0020) (Status: BEST CURRENT PRACTICE)

  This document describes a way to do IN-ADDR.ARPA delegation on non- octet boundaries for address spaces covering fewer than 256 addresses. The proposed method should thus remove one of the objections to subnet on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes, without losing the ability to delegate authority for the corresponding IN-ADDR.ARPA mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in STD-13 (RFC-1034), i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups.
  [... complete text ...]

• RFC-2352: A Convention For Using Legal Names as Domain Names.
  O. Vaughan. May 1998. (Format: TXT=16354 bytes) (Obsoletes RFC2240) (Status: INFORMATIONAL)

  The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. The proposed solutions in this document are intended as a framework for development, such that a general consensus will emerge as to the appropriate solution to the problems in each case, leading eventually to the adoption of standards.
  [... complete text ...]

• RFC-2345: Domain Names and Company Name Retrieval.
  J. Klensin, T. Wolf, G. Oglesby. May 1998. (Format: TXT=29707 bytes) (Status: EXPERIMENTAL)

  Location of web information for particular companies based on their names has become an increasingly difficult problem as the Internet and the web grow. The use of a naming convention and the domain name system (DNS) for that purpose has caused complications for the latter while not solving the problem. While there have been several proposals to use contemporary, high-capability, directory service and search protocols to reduce the dependencies on DNS conventions, none of them have been significantly deployed.

  This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed.
  [... complete text ...]

• RFC-2288: Using Existing Bibliographic Identifiers as Uniform Resource Names.
  C. Lynch, C. Preston, R. Daniel. February 1998. (Format: TXT=21628 bytes) (Status: INFORMATIONAL)

  A system for Uniform Resource Names (URNs) must be capable of supporting identifiers from existing widely-used naming systems. This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs.
  [... complete text ...]

• RFC-2146: U.S. Government Internet Domain Names.
  Federal Networking Council. May 1997. (Format: TXT=26564 bytes) (Obsoletes RFC1816) (Status: INFORMATIONAL)

  This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain ".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources.
  [... complete text ...]

• RFC-2071: Network Renumbering Overview: Why would I want it and what is it anyway?.
  P. Ferguson, H. Berkowitz. January 1997. (Format: TXT=33218 bytes) (Status: INFORMATIONAL)

  The PIER [Procedures for Internet/Enterprise Renumbering] working group is compiling a series of documents to assist and instruct organizations in their efforts to renumber. However, it is becoming apparent that, with the increasing number of new Internet Service Providers (ISP's) and organizations getting connected to the Internet for the first time, the concept of network renumbering needs to be further defined. This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so.
  [... complete text ...]

• RFC-2053: The AM (Armenia) Domain.
  E. Der-Danieliantz. October 1996. (Format: TXT=4128 bytes) (Status: INFORMATIONAL)

  The AM Domain is an official Internet top-level domain of Armenia. AM is the ISO-3166 2-letter country code for the Republic of Armenia and thus the AM Domain is established as a top-level domain and registered with the InterNIC the same way other country domains are.
  [... complete text ...]

• RFC-1917: An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA.
  P. Nesser II. February 1996. (Format: TXT=23623 bytes) (Also BCP0004) (Status: BEST CURRENT PRACTICE)

  This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. Similarly an appeal is issued to providers to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment.
  [... complete text ...]

• RFC-1912: Common DNS Operational and Configuration Errors.
  D. Barr. February 1996. (Format: TXT=38252 bytes) (Obsoletes RFC1537) (Status: INFORMATIONAL)

  This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537].
  [... complete text ...]

• RFC-1900: Renumbering Needs Work.
  B. Carpenter & Y. Rekhter. February 1996. (Format: TXT=9528 bytes) (Status: INFORMATIONAL)

  Renumbering, i.e., changes in the IP addressing information of various network components, is likely to become more and more widespread and common. The Internet Architecture Board (IAB) would like to stress the need to develop and deploy solutions that would facilitate such changes.
  [... complete text ...]

• RFC-1814: Unique Addresses are Good.
  E. Gerich. June 1995. (Format: TXT=5936 bytes) (Status: INFORMATIONAL)

  The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider.
  [... complete text ...]

• RFC-1035: Domain names - implementation and specification.
  P.V. Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136, RFC2137, RFC2308) (Status: STANDARD)

  This RFC describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discussed in a companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
  [... complete text ...]

Full Copyright Statement

Based on BCP-9 (currently RFC-2026), RFCs are copyrighted by the Internet Society as following:

Copyright (C) The Internet Society (date). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.