Comments on RFC

Introduction

Anyone who studies the Internet or ‘Computer Networks’ in general comes across some of the RFC’s, which describes the networking protocols and the standards. Many people think that the RFC’s are amongst the most boring documents to read. I know a person who uses RFC’s as a substitute for sleeping pills.

This article is an attempt to change this deadly-boring image of the RFC’s. In this article I give a brief definition of the RFC, followed by an informal classification of the RFC’s. Then the major section contains comments on some of the most interesting RFC’s that I have found. You will find that this article is about the lighter side of the RFC’s.

What is an RFC?

RFC’s (an acronym for Request For Comments) are the working notes of the Internet research and development community. They contain the description of protocols, systems, and procedures for Internet, or simply reviews, experiments, or information on some topic. All the Internet’s standard protocols are written up as RFC’s.

The RFC’s are in the form of a series of documents, each identified by a unique number. The first RFC was written in 1969. Now there are well over 3800 RFC’s today, and the number is growing. An RFC is for forever. Once published, they can never be changed or modified in anyway. If there is an error in the RFC, then a revised RFC is published that obsoletes the one with the error.

An RFC can be submitted by anyone, Eventually, if it gains enough interest, it may evolve into a standard.

The home page for all RFC’s is here: http://www.ietf.org/rfc.html

Some of the more interesting RFC’s

Here’s a brief description of some of the interesting RFC’s that I discovered. This include poetries, facts, recommendations, and April 1st RFC’s.

RFC 3092 – Etymology of “foo”

Many of us have been using foo, bar, and foobar as names of absolutely anything, without thinking much about where these names came from. Many of the code samples that we see have filenames or functions named foo, bar or foobar. Over 200 RFC’s have used these words without properly defining them.

A look at the RFC 3092 will tell you the Etymology of “foo”. The RFC reveals half a dozen definitions of the word foo. The RFC gives many traces of origin of word foobar, including comic strips. It reveals that the word foobar is generally traced back to World War II era Army slang, FUBAR, which it seems, was itself derived from German word furchtbar meaning terrible.

RFC 1178 – Choosing a name for your computer

Yes, this RFC gives some nice tips on how to better name your Computer. It’s not exactly like the books on choosing names for your babies. The RFC describes in detail what makes a name good or bad, and what things you should consider before naming your computer. The tips include the appropriate length and spelling of name. This RFC is fun to read. The line that caught my eye was the line before the conclusion: “I could go on but it would be easier just to forget this guideline exists.”

RFC 1149 - Standard for the transmission of IP datagrams on avian carriers

This RFC describes the standard for transmission of data on avian carriers, aka birds (pigeons to be specific); although the RFC never uses the latter words. The RFC very formally describes the whole process, from printing the data on paper, to wrapping the piece of paper around the bird’s leg with a duct tape, to removing it at the receiver end. The RFC also mentions that the carrier has got intrinsic collision avoidance system. This is a good RFC to read when you want to know the extreme limits of people's thinking.

RFC 2549 - IP over Avian Carriers with Quality of Service

This RFC amends the above RFC (1149). It is far more technical in content in comparison to RFC 1149. It goes a step further and explains how the quality of transmission depends on the carrier used. It suggests the use of Ostriches for bulk data transfers, which have a small limitation that they need a real bridge between the domains. With nice ASCII art figure of a bird on scale, it tells that even Weighted Fair Queuing (WFQ) can be implemented. This RFC even defines its own MIB.

RFC 3514 - The Security Flag in the IPv4 Header

This is an April 1st RFC. This RFC defines a security flag, known as the “evil” bit in the IPv4 header. This “evil” bit is to be used to distinguish good packets from the packets with the evil-intent. The RFC describes that the programs should set the “evil” bit to 1 when the packet has evil intent, otherwise the bit should be set to 0.

RFC 1605 - SONET to Sonnet Translation

Another April 1st RFC, this one reveals literary aspect of data transmission technology. It talks about translation of a SONET (Synchronous Optical NETwork) packets to SONNET (SONET Over Novel English Translation). This RFC describes how a 9x90 bytes SONET OC1 frames can be translated to fourteen line decasyllabic English sonnets. Coincidently this RFC’s author shares his name with one of the world's most read authors, William Shakespeare.

RFC 2550 - Y10K and Beyond

Everyone is well aware of the Y2K bug that haunted many COBOL programmers for a long time. The Y2K bug came because of the shortsightedness of the programmers who wrote programs that would fail in the year 2000. The fixes for the Y2K problem were again shortsighted. These programs are again written to fail, this time in the year 10,000. This RFC provides a solution to the Y10K problem. Y10K is also known as the “YAK” problem, as the hex equivalent of 10 is A, or the “YXK” problem, as X is the Roman numeral for 10.

RFC 1925 - The Twelve Networking Truths

If you think you know a lot (if not everything) about the Networking, then you may like to verify these twelve Networking truths. These truths seems to be very illuminating and enlightening, most especially the one which talks about the flying pigs.

Some people might feel that truth number 2's corollary and truth number 3 are a bit contradictory. But if you read carefully, you will realize that truth number 2 is all about time and speed, whereas truth number 3 has nothing to do with the speed or time. If you don’t understand what I am talking about then go and read the RFC 1925.

POEMS

There have been several RFC’s that reveals the literary aspects of computing. The following four are the ones which illustrate the poetic aspect of computing.

RFC 1121 - Act one - the poems

This one is a collection of poems that were presented at “Act One”, a symposium held partially in celebration of the 20th anniversary of ARPANET. My favorite among the ones here is “THE BIG BANG” (or the birth of the ARPANET) by Leonard Kleinrock.

RFC 968 - Twas the Night Before Start-up

This is nice poem by Vint Cerf, published in 1985, exposes the dangers of the off-by-one index error in programming. It discusses the problems that may arise and debugging technique used in bringing a new network into operation.

RFC 1882 - The 12-Days of Technology Before Christmas

You must have heard the Christmas song, "The Twelve Days of Christmas". Our tech people have released a new and improved version of it. They call it “The 12-Days of Technology Before Christmas”. So don’t forget to update yourself with this new song by reading this RFC.

RFC 1300 - Remembrances of Things Past

A brilliant work by Stanley R. Greenfield, this RFC makes us think about the origin of words that we take for granted in the computing world. Words like bus, net, port, bridge, and menu that people have associated with computing are though of entirely differently by non-geeks.

So, how do I publish an RFC ?

An RFC can be submitted by anyone, but before you publish it as an RFC, you need to publish it as an Internet Draft (I-D). The I-D is made available for informal review and comment by placing them in the IETF’s “Internet-Drafts” directory, which is accessible through number of other hosts also. Once it gets approved, it is published as an RFC. You may refer to RFC 2223 - Instructions to RFC Authors.

How can I submit an April 1st RFC?

April 1st submissions are the only RFC’s-to-be which do not need to be published as an internet-draft. These entries should be sent directly to the RFC Editor. If they find it interesting enough, it will be published as an RFC on April 1st.

More interesting RFC’s

In this article I have given a short description of some of the interesting RFC’s that I found. There are many other interesting RFC’s out there. When you actually start reading them, you will find that most of them are very interesting and lively. Go ahead read them and learn some of the protocols, best practices, reviews, experiments, and information on some topic. That’s what an RFC is supposed to contain. Don’t they?

Well, following is list of some more interesting RFC’s.

RFC 602 - The Stockings Were Hung by the Chimney with Care
RFC 1217 - Memo from the Consortium for Slow Commotion Research (CSCR)
RFC 1313 - Today's Programming for KRFC AM 1313 - Internet Talk Radio
RFC 1402 - There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places
RFC 1438 - IETF Statements of Boredom (SOBs)
RFC 1606 - A Historical Perspective On The Usage Of IP Version 9
RFC 1607 - A VIEW FROM THE 21ST CENTURY
RFC 1776 - The Address is the Message
RFC 1924 - A Compact Representation of IPv6 Addresses
RFC 2322 - Management of IP numbers by peg-dhcp
RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
RFC 2325 - Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
RFC 2795 -The Infinite Monkey Protocol Suite
RFC 3251 - Electricity over IP

[BIO] Amber Pawar is a software engineer working with an MNC. He is an alumnus of 'National Center for Software Technology' (NCST). He likes reading and listens to all kinds of music except the sort which he better refers to as noise. One thing that he misses the most these days is the home-cooked food. His interest involves Linux L10N and Data Structures.

Published in Issue 106 of Linux Gazette, September 2004

<-- prev | next -->