The IETF release a lot of documentation in the form of RFCs (Request for Comments), providing the foundation for the standardisation of the Internet. But not all of these are what they seem. Every now again an RFC is released which not only includes the Month and Year of release, but also the Date. These may at first glance appear to be a normal RFC, but read on, and you are taken into a strange, surreal world of the April 1st RFC. This is a world in which data packets are carried by birds, are scenically routed to improve mood, and coffee machines are controlled across the internet. No, wait that last one’s real life now, isn’t it?
History
The RFC was a process started by Steve Crocker, as part of the original ARPAnet project. Initially, they were a series of discussion papers, written on paper and circulated by hand as there was no Internet at this point. Some of the early papers provide an interesting view point on the formation of the Internet, making a great historical resource.
The formation of the InterNIC leads to a more formal process for distribution and discussion of RFCs. Later on, Jon Postel became the RFC Editor, managing the process of releasing RFCs as Best Current Practice (BCP), For Your Information (FYI) (until 2011), or Standards (STD), which are published on a regular cycle.
Example
Indeed, one of the first RFC released in this fashion was RFC 748. It provides a Telnet option to control random losses..
Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features. – RFC748 Motivation
But Telnet runs on top of TCP, which it self should prevent losses. (Although in the early days of the Internet, the stability of hosts might be a shorter time than the life of the TCP connection). The RFC also codes a value which exceeds the defined space, making the option invalid at the protocol level. However, the need for the RFC is still valid, as crashes do occur, although this should be managed via operational, rather than technical issues (to my mind at least).
I will check your understanding of RFC1149 if you’re being interviewed by me, and you profess to know IP.