TCP/IP, RFC and a few laughs along the way
For those of us who are constantly studying to keep up to date with technological advances or going on re-fresher courses to remind ourselves of things we thought we knew well, but had actually forgotten bits and pieces, it is the daunting amount of information to be read and absorbed that can be off-putting at times. For example, I am currently on a re-fresher for TCP/IP (Transmission Control Protocol/Internet Protocol - TCP/IP_model) and just one of the documents I am reading runs to over 700 pages long. TCP/IP sounds very boring (and to most it probably is).
Given that the nitty-gritty of TCP/IP also appears technically demanding to understand (perhaps a bit like rocket science) one needs a sense of humour working in this arena if one is not to go ‘bonkers’ or become a total ‘anorak’ on the subject. Whilst reading the commentary on the standardisation bodies structure responsible for the creation of RFC (Request for Comments) IP Standards and proposals for RFC standards I was came across a couple of gems, which I found quite humorous. To fully appreciate the humour, one needs first to have an appreciation of the aura of formality and control engendered around understanding standardisation and the bodies that assist in their creation.
As a very brief overview, because of the openness and perpetual renewal of TCP/IP, which is popular with developers and users alike, there is no overall governing body to issue directives and regulations for the Internet. Control is mostly based on mutual co-operation. The Internet community is said to be organised and managed by the Internet Architecture Board (IAB). The IAB itself relies on the Internet Engineering Task Force (IETF) for issuing new Standards (RFCs) and the Internet Assigned Numbers Authority (IANA) for co-ordinating values shared among multiple protocols. RFC standards can be proposed by anyone; but the RFC Editor is responsible for reviewing and publishing new standards documents. The IETF itself is governed by the
Internet Engineering Steering Group (
IESG) and is further organised in the form of Areas and Working Groups where new specifications are discussed and new standards are proposed.
In order to have a new IP protocol approved as a standard, applicants have to submit a proposed specification to the IESG where it will be discussed and reviewed for technical merit and feasibility and also published as an Internet draft document. For Internet Protocol suite to evolve through the mechanism of Request for Comments (RFC) new protocols (mostly application protocols) are designed and implemented by researchers, and are brought to the attention of the Internet community identified in standard categories:
Draft standard: There is a possibility that changes will be made in a draft protocol before it becomes a standard.
Proposed standard: Revision of the protocol is likely.
Experimental: A system should not implement an experimental protocol unless it is participating in the experiment and has co-ordinated its use.
Informational: Protocols developed by other standard organisations, or vendors, or that are for other reasons outside the purview of the IAB may be published as RFCs
Historic: These are protocols that are unlikely to ever become standards, because they have been superseded by later developments or due to lack of interest.
Required: A system must implement the required protocols.
Recommended: A system should implement the recommended protocol.
Elective: A system may or may not implement an elective protocol. The general notion is that if you are going to do something like this, you must do exactly this.
Limited use: These protocols are for use in limited circumstances. This may be because of their experimental state, specialised nature, limited functionality, or historic state.
Not recommended: These protocols are not recommended for general use. This may be because of their limited functionality, specialised nature, or experimental or historic state.
The overall picture one gets, having glimpsed at this highly defined and controlled standardisation structure, is one of individuals feverishly working away solving technical conundrums with little room for levity. Well, apparently not. It was with a grinning surprise I found, amid all this rocket science, that some ‘techies’ have been allowed to let their imaginations run riot – presumably to defeat creeping techmadness, maybe? Two protocols identified by the RFC Editor, and dated April 1st that are described at best as “impractical”:
RFC 1149 (dated 1990 April 1 - rfc1149) describes: A standard for the transmission of IP datagrams by avian carrier (carrier pigeon)
RFC 1437 (dated 1993 April 1 - rfc1437) describes: The Extension of MIME Content-Types to a New Medium (transmission of people by electronic mail).
Are these two impractical or just ahead of their time?
