...making Linux just a little more fun!
By Amber Pawar
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.
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
Based on their contents the RFC’s can be broadly classified in the following categories.
These documents either specify an Internet standard or a draft of it. These include the official standards for the Internet protocols, defined by the IETF.
These documents describe the Best Current Practices for the Internet Community. They are guidelines and recommendations, but not standards, from the IETF.
The informational RFC’s or the FYIs (For Your Information) documents are a series of the RFC’s that are of particular interest to Internet users.
These are former standards that have been actively deprecated or they are obsolete.
Every year (since 1978) on 1st of April (Fools day), one or more unusual sort of RFC is published. They are amongst the most interesting ones. They are humorous documents sometimes written in very formal way, which makes it hard to differentiate them from the serious stuff. The next section of this article includes a brief description of some of these 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.
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.
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.”
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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