Article #39-2 | Gutenberg Articles

Excerpt

Excerpt from Hitchhiker's Guide to the Internet, by Ed Krol

RFCs

The internal workings of the Internet are defined by a set
of documents called RFCs (Request for Comments). The general
process for creating an RFC is for someone wanting something
formalized to write a document describing the issue and mailing
it to Jon Postel (postel@isi.edu). He acts as a referee for
the proposal. It is then commented upon by all those wishing
to take part in the discussion (electronically of course).
It may go through multiple revisions. Should it be generally
accepted as a good idea, it will be assigned a number and
filed with the RFCs.

The RFCs can be divided into five groups: required, suggested,
directional, informational and obsolete. Required RFC's (e.g.
RFC-791, The Internet Protocol) must be implemented on any host
connected to the Internet. Suggested RFCs are generally
implemented by network hosts. Lack of them does not preclude
access to the Internet, but may impact its usability. RFC-793
(Transmission Control Protocol) is a suggested RFC. Directional
RFCs were discussed and agreed to, but their application has never
come into wide use. This may be due to the lack of wide need for
the specific application (RFC-937 The Post Office Protocol) or
that, although technically superior, ran against other pervasive
approaches (RFC-891 Hello). It is suggested that should the
facility be required by a particular site, animplementation
be done in accordance with the RFC. This insures that, should
the idea be one whose time has come, the implementation will be
in accordance with some standard and will be generally usable.
Informational RFCs contain factual information about the
Internet and its operation (RFC-990, Assigned Numbers).
Finally, as the Internet and technology have grown, some
RFCs have become unnecessary. These obsolete RFCs cannot
be ignored, however. Frequently when a change is made to
some RFC that causes a new one to be issued obsoleting others,
the new RFC only contains explanations and motivations for the
change. Understanding the model on which the whole facility
is based may involve reading the original and subsequent RFCs
on the topic.

Explanation

**Detailed Explanation of the Excerpt from The Hitchhiker’s Guide to the Internet by Ed Krol**

This excerpt explains the Request for Comments (RFC) process, a foundational system for documenting and standardizing the technical and operational aspects of the Internet. Written in 1987 (with updates in later editions), The Hitchhiker’s Guide to the Internet was one of the first accessible introductions to the Internet for a general audience. Ed Krol, a computer scientist at the University of Illinois, wrote it to demystify the Internet’s infrastructure, which was still largely confined to academic, military, and research institutions at the time.

The passage focuses on how RFCs—the formal documents that define Internet protocols, policies, and best practices—are created, categorized, and maintained. Below is a breakdown of the text’s key elements, themes, and literary techniques, with an emphasis on close reading.

1. Context & Purpose of the Excerpt

Historical Context:
- The Internet in the 1980s was transitioning from ARPANET (a U.S. Department of Defense project) to a more decentralized, global network.
- RFCs had been in use since 1969 (starting with RFC 1, which described the basic principles of host software). By the 1980s, they were the primary way to propose, debate, and standardize Internet protocols.
- Jon Postel (mentioned in the text) was a key figure in Internet governance, serving as the RFC Editor and later as the director of the Internet Assigned Numbers Authority (IANA).
Purpose of the Passage:
- To explain how the Internet’s technical standards are developed collaboratively and transparently.
- To categorize RFCs by their functional role (required, suggested, etc.).
- To emphasize that RFCs are living documents—subject to revision, obsolescence, and historical context.

2. Thematic Analysis

The excerpt touches on several key themes:

A. Decentralization & Collaborative Governance

The Internet’s standards are not dictated by a single authority but emerge from open discussion and consensus.
The process described:
1. Someone proposes an idea by writing a draft.
2. It is sent to Jon Postel (acting as a referee, not a dictator).
3. The broader community debates and revises it electronically.
4. If accepted, it is assigned an RFC number and archived.
This reflects the bottom-up, meritocratic ethos of early Internet culture, where technical excellence and practical utility determined adoption rather than institutional power.

B. Evolution & Obsolescence in Technology

The text acknowledges that not all RFCs remain relevant forever.
- Some become obsolete as technology advances (e.g., replaced by newer protocols).
- Others are directional—technically sound but never widely adopted (e.g., RFC 891 "Hello", a network monitoring protocol that lost out to ICMP).
The Internet is portrayed as a dynamic system, where standards must adapt to changing needs.

C. Practicality Over Perfection

Some RFCs are required (e.g., RFC 791, Internet Protocol), meaning they are essential for interoperability.
Others are suggested (e.g., RFC 793, TCP), meaning they improve functionality but aren’t strictly mandatory.
The text suggests that real-world usage often determines an RFC’s fate—even if a protocol is technically superior (like RFC 891 "Hello"), it may fail if a simpler or more entrenched alternative exists.

D. The Importance of Historical Knowledge

The passage warns that obsolete RFCs cannot be ignored because:
- New RFCs often reference or modify older ones.
- Understanding the evolution of a protocol may require studying its predecessors.
This reflects a historical consciousness in engineering—knowing why things were designed a certain way helps in troubleshooting and innovation.

3. Literary & Rhetorical Devices

Krol’s writing is technical yet accessible, using several devices to clarify complex ideas:

A. Classification & Taxonomy

The RFCs are divided into five clear categories:
1. Required (must be implemented)
2. Suggested (widely used but not mandatory)
3. Directional (agreed upon but rarely used)
4. Informational (factual reference, e.g., assigned numbers)
5. Obsolete (replaced but still relevant for history)
This taxonomic structure helps readers grasp the hierarchy of importance in Internet standards.

B. Examples & Concrete References

Krol names specific RFCs to illustrate each category:
- RFC 791 (IP) → Required
- RFC 793 (TCP) → Suggested
- RFC 937 (POP, Post Office Protocol) → Directional (not widely adopted at the time)
- RFC 891 ("Hello") → Directional (technically good but overshadowed)
- RFC 990 (Assigned Numbers) → Informational
These real-world examples ground the explanation in practical reality, making abstract concepts tangible.

C. Conditional & Hypothetical Language

The text uses modal verbs ("may," "should," "could") to describe possibilities rather than absolutes:
- "It may go through multiple revisions."
- "Should it be generally accepted as a good idea..."
- "This insures that, should the idea be one whose time has come..."
This reflects the provisional nature of RFCs—they are proposals, not decrees.

D. Metaphor & Analogy (Implied)

While not overtly poetic, the process described implies a scientific/legal metaphor:
- RFCs are like peer-reviewed papers (submitted, debated, revised).
- Jon Postel acts as a referee (like in academia or sports).
- Obsolete RFCs are like historical legal precedents—no longer in force but still relevant for interpretation.

E. Passive Voice for Neutrality

The text frequently uses passive constructions to emphasize the process over individuals:
- "It is then commented upon by all those wishing to take part."
- "Should it be generally accepted as a good idea..."
This reinforces the collective, impersonal nature of Internet standardization.

4. Significance of the Passage

A. Historical Significance

This excerpt captures the early Internet’s collaborative, non-hierarchical ethos, which contrasts with later commercialization and corporate control.
It documents a time when technical merit and community consensus drove standards, rather than market dominance (e.g., today’s battles between proprietary protocols like those of Google, Apple, or Microsoft).

B. Technical Significance

The RFC process described here remains largely unchanged today.
Understanding RFCs is still essential for network engineers, software developers, and policymakers who work with Internet protocols.

C. Philosophical Significance

The passage embodies open-source principles before the term was widely used:
- Transparency (anyone can propose an RFC).
- Meritocracy (the best ideas win, not the most powerful proponents).
- Iterative improvement (standards evolve through debate and testing).

D. Pedagogical Value

Krol’s explanation is a model of technical writing:
- Clear categorization helps readers navigate complexity.
- Examples make abstract concepts concrete.
- Neutral tone avoids bias, presenting the process as objective.

5. Close Reading of Key Lines

Let’s examine a few lines in detail:

"He acts as a referee for the proposal. It is then commented upon by all those wishing to take part in the discussion (electronically of course)."

"Referee" implies fair judgment, not authoritarian control.
"Electronically of course" is a subtle nod to the digital nature of the process—even in the 1980s, this was a given.

"Directional RFCs were discussed and agreed to, but their application has never come into wide use. This may be due to the lack of wide need for the specific application (RFC-937 The Post Office Protocol) or that, although technically superior, ran against other pervasive approaches (RFC-891 Hello)."

This highlights two reasons for failure:
1. No demand (POP wasn’t widely needed yet—though it later became crucial for email).
2. Competition from entrenched alternatives ("Hello" lost to ICMP).
The phrase "technically superior" suggests that engineering quality alone doesn’t guarantee adoption—a recurring theme in tech history.

"Understanding the model on which the whole facility is based may involve reading the original and subsequent RFCs on the topic."

"Whole facility" is an interesting phrase—it treats the Internet as a public utility, not just a network.
This line underscores the importance of historical literacy in engineering—you can’t fully grasp TCP/IP without knowing its predecessors.

6. Connection to Broader Internet Culture

This excerpt reflects several enduring aspects of Internet culture:

Open Standards vs. Proprietary Systems: The RFC process embodies the open, interoperable Internet, in contrast to walled gardens (e.g., AOL in the 1990s, modern app ecosystems).
The Role of Individuals in Collective Systems: Jon Postel’s role as RFC Editor was pivotal yet unassuming—he facilitated discussion but didn’t impose decisions. (Postel’s famous adage: "We reject kings, presidents, and voting. We believe in rough consensus and running code.")
The Internet as a "Work in Progress": The acknowledgment that RFCs can become obsolete or revised mirrors the Internet’s constant evolution.

7. Potential Criticisms or Limitations

While the passage is clear and informative, a few nuances could be explored further:

Who Gets to Participate? The text implies anyone can comment, but in practice, technical expertise and access were (and are) barriers.
Power Dynamics: While RFCs are collaborative, institutional influence (e.g., DARPA, later IETF) still shapes outcomes.
The "Tyranny of the Default": Some RFCs become de facto standards not because they’re best, but because they were first or most widely implemented (e.g., SMTP for email).

8. Conclusion: Why This Matters

This excerpt is more than a technical explanation—it’s a snapshot of Internet philosophy:

It shows how decentralized, consensus-driven processes can create global infrastructure.
It demonstrates that standards are not fixed but evolve through debate, testing, and real-world use.
It serves as a reminder of the Internet’s origins as a collaborative, open system—a contrast to today’s more commercialized and fragmented web.

For modern readers, understanding RFCs is not just about networking—it’s about how complex systems can be governed fairly, transparently, and adaptively. The principles described here influence everything from open-source software to blockchain governance to AI ethics debates.

In short, this passage is a microcosm of how the Internet was built—and how it continues to function.

Questions

Question 1

The passage’s description of the RFC process most strongly implies which of the following about the nature of technological standardisation?

A. It is inherently resistant to obsolescence because of its iterative revision mechanism.
B. It reflects a tension between technical merit and the pragmatic realities of adoption.
C. It privileges the authority of central figures like Jon Postel over community consensus.
D. It assumes that all participants in the discussion possess equal technical expertise.
E. It is primarily driven by market forces rather than collaborative debate.

Question 2

The phrase "although technically superior, ran against other pervasive approaches" (in reference to RFC-891) serves to illustrate which broader principle?

A. The inevitability of technological progress rendering older standards obsolete.
B. The discrepancy between theoretical excellence and real-world implementation.
C. The tendency for RFCs to be revised until they achieve universal acceptance.
D. The role of government regulation in determining which protocols succeed.
E. The superiority of open-source models over proprietary alternatives.

Question 3

The passage’s categorisation of RFCs into five groups (required, suggested, directional, informational, obsolete) primarily serves to:

A. demonstrate the hierarchical nature of Internet governance.
B. highlight the arbitrary distinctions between different types of standards.
C. argue for the elimination of obsolete RFCs to streamline the system.
D. illustrate the functional diversity and conditional applicability of standards.
E. suggest that only required RFCs have lasting technical significance.

Question 4

Which of the following best describes the rhetorical effect of the phrase "electronically of course" in the context of the passage?

A. It subtly reinforces the taken-for-granted digital medium of the RFC process.
B. It introduces an ironic tone by highlighting the impracticality of non-digital discussion.
C. It serves as a parenthetical dismissal of alternative methods of collaboration.
D. It underscores the exclusivity of the process to those with technical access.
E. It implies that electronic communication is inherently more democratic than in-person debate.

Question 5

The passage’s treatment of obsolete RFCs suggests that their continued relevance lies primarily in their role as:

A. cautionary examples of failed technological experiments.
B. historical artifacts that contextualise the evolution of current standards.
C. legal precedents for resolving disputes over protocol ownership.
D. templates for reviving outdated but theoretically sound ideas.
E. evidence of the Internet’s shift from academic to commercial control.

Solutions and Explanations

1) Correct answer: B

Why B is most correct: The passage explicitly notes that some RFCs (e.g., RFC-891 "Hello") were "technically superior" yet failed due to competition from "pervasive approaches." This juxtaposition of technical merit (superiority) and pragmatic adoption (pervasiveness) underscores a tension between ideal design and real-world usage. The RFC process itself accommodates this tension by allowing directional RFCs to persist despite limited adoption, acknowledging that utility often trumps pure technical excellence.