Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
A study on the relative relevance of RFCs

By cribeiro in Internet
Tue Oct 22, 2002 at 09:51:11 AM EST
Tags: Technology (all tags)
Technology

RFCs - or 'Requests For Comments' - are the most important documents for the architecture of the Internet. The official RFC index at http://www.ietf.org/iesg/1rfc_index.txt lists more than 3400 RFCs today (October, 21 2002). The problem is, it is now nearly impossible for a human being to keep track of them. To make matters worse, many RFCs are now obsolete; others were never adopted in practice, making the collection confusing sometimes. The neophite is faced with a hard time to choose which documents are worth reading. There are a few guides on 'Net, most of them badly outdated. As far as the author know, no scientific studies have been previously published on the relative relevance of RFCs.

To shed some light on this problem, we performed an exhaustive research on the WWW for all known RFC references - in other words, pages that reference some RFC by number. Using the Google API, we searched for pages containing textual references to the RFC numbers. We retrieved the number of references, and indexed the RFCs accordingly. We believe that this information is a good measurement of the relative relevance of RFCs, and may be a good starting point for the student looking for pointers on the RFC collection.


The IETF RFC series - the famous "Request For Comments" documents - provides the foundation for the Internet as we know today. This extensive collection goes back as far as 1969, and it keeps growing. As of today, we have more than 3400 "official" RFCs in the IETF index. This formidable collection of documents poses a problem for the student. Several documents are only of historic value, being written in the early days of the Internet. Others were of some importance, but were later made obsolete by newer documents. Some RFCs were never implemented in practice. Others deserve a mention, if only because they permit the student to understand the prevailing social conventions, such as the April Fool's Day RFCs. All these factors contribute to make the study of the RFC collection needlessly hard for the neophite. Some type of guide, or index, pointing to the most relevant RFCs, would be handy in these situations.

In such a large collection of documents, it is indeed very difficult to pick a few documents as 'fundamental'. Any particular choice would seem biased. So we decided to develop a ranking methodology to evaluate the relative relevance of every RFC published so far.

Methodology

In order to build our ranking, we carried an exaustive research on the Internet, looking for occurrences of textual references to the RFCs by number. The individual queries are very simple. Our query look for patterns such as 'RFCxxxx OR "RFC xxxx"'. We also searched for variations, such as RFC references without the leading zeroes.

The process was automated with a Python script. Thanks to the formidable Google API, the research proved relatively painless to perform - although we had to limit the daily number of queries to 1000, conforming to Google's API license agreement. The automation script saved intermediate results, keeping track of all work done, so we could perform a limited number of queries at a time. The script itself is very simple, but it'ss beyond the scope of this article. It may be made available for anyone interested, or posted later, if there is enough interest. After a few days, we had the results, which we present now.

The top 20 RFCs, by relevance:

  1. RFC0822: Standard for the format of ARPA Internet text messages. (~65500 hits)
  2. RFC2119: Key words for use in RFCs to Indicate Requirement Levels. (~44400 hits)
  3. RFC2026: The Internet Standards Process. (~37300 hits)
  4. RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. (~35400 hits)
  5. RFC1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. (~ 31700 hits)
  6. RFC1213: Management Information Base for Network Management of TCP/IP-based internets: MIB-II. (~ 29600 hits)
  7. RFC0791: Internet Protocol. (~ 29200 hits)
  8. RFC0821: Simple Mail Transfer Protocol. (~ 28900 hits)
  9. RFC1123: Requirements for Internet Hosts - Application and Support. (~ 27400 hits)
  10. RFC0793: Transmission Control Protocol. (~ 26700 hits)
  11. RFC1157: Simple Network Management Protocol (SNMP). (~ 26400 hits)
  12. RFC1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. (~ 26100 hits)
  13. RFC1035: Domain names - implementation and specification. (~ 24700 hits)
  14. RFC1034: Domain names - concepts and facilities. (~ 22700 hits)
  15. RFC1738: Uniform Resource Locators (URL). (~ 22700 hits)
  16. RFC0959: File Transfer Protocol. (~ 22200 hits)
  17. RFC1918: Address Allocation for Private Internets. (~ 22100 hits)
  18. RFC2616: Hypertext Transfer Protocol -- HTTP/1.1. (~ 21700 hits)
  19. RFC2068: Hypertext Transfer Protocol -- HTTP/1.1. (~ 20900 hits)
  20. RFC1155: Structure and identification of management information for TCP/IP-based internets. (~ 20800 hits)
For reasons of space, we decided to limit the list to the first 20 RFCs. These RFCs alone concentrate about 11,37% of all references found, for all RFCs. It is very interesting to note the topics on the list above. In the top 20, we have nearly all the basics - SMTP, DNS, FTP, HTTP, and more important, the TCP/IP protocol itself. The relative prevalence of email-related RFCs is also worthy noting. Last but not least, the RFCs that describe the Internet standard process themselves are also highly relevant, as it is RFC1918, which describes the address scheme used for private internets. The pair of RFC2616 and RFC2068 could be said to form a single entry, although the same could be said of RFC0822 and RFC1822 (which is well positioned at 42th in the overall list); the older edition is still the most relevant RFC, according to the results of our research. Other relevant data we could extract from our research: the top 20% RFCs concentrate 60% of all references. If we get the top 44% of all RFCs, we have 80% of all references.

Pitfalls and shortcomings

As with any such study, we need to ask: is the information obtained really representative of the relevance of the RFC?

First of all, one could argue that older RFCs have the advantage, for the simple reason that they have collected more references overtime. The presence of RFC0822 at the top of the list is one possible proof for this argument. However, while this can lead to some distortions, it still does not affect the final result as a measurement of the relative relevance of the documents;it's just natural that older documents are more relevant, if only in historical terms. One possible solution to minimize this problem is to look for obsolete RFCs in the list, and then substitute them for the newer version.

It is also important to note that there are other ways to search for similar data that may lead to different results. Another such methodology is as follows: use the Google engine to count links to the actual official RFC locations on the IETF web site (for example, all the links pointing back to http://www.ietf.org/rfc/rfc1918.txt). The problem with this approach is that other repositories - for example, the one at faqs.org also concentrate a lot of references, making this research much more difficult. Given the options, we felt that the strategy we had chosen was a good compromise, and that it could give us a reasonable result.

Conclusion

The results of our study clearly proves some things that we already suspected:

  • Relatively few RFCs concentrate most of the links on the Internet. That's expected for any sufficiently large collection of documents, it should be no different with RFCs.
  • The 'basic' RFCs - those of more general interest, and of broadest focus - are closer to the top of the list.
  • With few exceptions, RFCs with too narrow scope tend to appear at the bottom of the list.
The study also brought us a few surprises. For example, entry 21 (not shown in the list above) is RFC1483 - Multiprotocol over ATM, whose link count was probably boosted as result of its relevancy in broadband access equipment such as xDSL and cable modems. Many SNMP-related RFCs appear nearly the top of the list, showing the importance of SNMP and related MIBs.

We also regard this study as a starting point only. Lots of information can be extracted, both from the data that was saved from the queries done, and even more from new queries. For example, the RFC index itself lists relevant cross-information between the RFCs, such as cross references and which RFCs were obsoleted by newer documents. All those information could be taken into account to better understand the results.

Even in light of all shortcomings, the list of the 'top 20' RFCs is a good starting point for students, as it shows what documents are currently relevant for the study of the Internet. We do recomend this list for any student that is looking for pointers to start reading the RFC collection.

[Editor Note] P.S.: Some people may point that this study is worthy an "Ig Nobel" prize. In fact, if it was not for the relative ease to perform the study - thanks to the fabulous Google API - I would think twice before working on it. Anyway, now that it's done, why not share the results with the community?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Google
o http://www .ietf.org/iesg/1rfc_index.txt
o http://www .ietf.org/rfc/rfc1918.txt
o faqs.org
o Also by cribeiro


Display: Sort:
A study on the relative relevance of RFCs | 60 comments (34 topical, 26 editorial, 0 hidden)
So? (3.00 / 6) (#1)
by Carnage4Life on Mon Oct 21, 2002 at 09:17:22 PM EST

You Googled for some RFC numbers... Big Whoop.

Your article is free of content besides some details that show you are proficient in using a Web Search engine. Please provide some analysis, opinions or anything else that makes this article worth reading besides as an indication that you spent an hour entering RFC numbers on Google.

It was not *that* simple (5.00 / 1) (#7)
by cribeiro on Mon Oct 21, 2002 at 10:03:25 PM EST

Sorry. Let me try to clarify my intentions. While I acknowledge that the research is not exactly a breakthrough, I can assure you that the process was a little bit more organized and scientific. The search itself was automated - as I wrote in the article, using a Python script and the Google API. Also, I did some analysis of the results. Let me tell you some history...

The idea for this study was born from a conversation that I had with a good friend of mine. One of the things that we've been discussing is the lack of an annotated edition of the 'fundamental' RFCs. But hey! What are the fundamental RFCs anyway? So I went with this question in mind, and did this small study just to check what the result would be.

While expected, I really found it very interesting that the top 20 "most relevant" RFCs list happened to include some of the fundamental RFCs. Most people that are familiar with the Internet will remember some RFC numbers from memory - for example, RFC0822 - but RFC 959? Everyone knows what FTP is, but to see that the actual RFC is highly referenced is kind of reassuring.

[ Parent ]

Well (none / 0) (#26)
by carbon on Tue Oct 22, 2002 at 12:15:10 AM EST

There's no reason to read the RFC unless you're doing development with said standard. Although everyone uses FTP, who cares what its datagram structure is if you're not developing with it? For example, from my experience writing most of an IRC bot, I remember the IRC RFC quite clearly (such as, for example, the fact that the most useful parts of the language are unofficial and contra-standard addons). Yes, that RFC's number is permanently etched on my mind... 1149? Or was it 1143? Hmm..


Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
Bah (none / 0) (#36)
by luserSPAZ on Tue Oct 22, 2002 at 09:02:06 AM EST

RFC1459.  If you'd been a *real* IRC hacker you'd remember that.

[ Parent ]
Weeel (none / 0) (#57)
by carbon on Wed Oct 23, 2002 at 07:09:59 PM EST

Well, I remember now.... And I was never an IRC hacker specifically. I was spending more time figuring out POE than figuring out IRC: both are mis-documented and evilly cool, so they work well together.


Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
My reason to read RFCs (none / 0) (#59)
by kyfung on Mon Oct 28, 2002 at 09:43:35 AM EST

I started reading RFCs after I read the book "The Elements of Networking Style". I found them to be wonderful documents to study to learn about protocols. I usually choose the ones that catch my eyes right away. But I will scan even the ones that are not that interesting. The only RFCs I skip for sure are the ones on MIBs for specific devices. Unless I have to work with the device, that is.

If you read the Internet Drafts as well, you can even learn how protocols get refined, and how they get rejected, etc. That helps you think about protocol design too.

After years of going through the various RFCs, I got the sense of how the Internet evolved. Just for this it is worth reading the RFCs.

Of course, for a while, you have to supplement the RFCs with ITU-T's (CCITT for the oldtimers) recommendations. And now, it is important to read W3's recommendations as well. Still, the collection of RFCs and all the Internet Drafts, obsolete or not, is the best for studying how to read and write network protocols.

[ Parent ]

that reminds me (2.00 / 1) (#43)
by khallow on Tue Oct 22, 2002 at 12:47:14 PM EST

I didn't notice any XML-related RFCs on the list though the HTML 1.1 ones have the same parent markup language as XML. It seems odd that XML-based RFCs don't have a similar visibility to say SNMP or MIME.

This does appear to me to be an interesting use of google (and particularly of the google API).

Stating the obvious since 1969.
[ Parent ]

XML etc (4.50 / 2) (#45)
by luserSPAZ on Tue Oct 22, 2002 at 12:56:00 PM EST

XML and its ilk are W3C recommendations, not RFCs. That's just the way it is.

XML 1.0: http://www.w3.org/TR/REC-xml

[ Parent ]

Language v. Protocol (5.00 / 1) (#47)
by FoxFireX on Tue Oct 22, 2002 at 01:42:30 PM EST

Bear in mind, the RFC's referenced discuss HTTP, the HyperText Transmission Protocol. HTML, being HyperText Markup Language, is another beast entirely.

[ Parent ]
How obvious (2.50 / 4) (#9)
by Miniluv on Mon Oct 21, 2002 at 10:07:39 PM EST

What you noticed is several things that are tolerably obvious, upon consideration.

First, that the RFCs most referenced in the text of Google indexed websites refer to popular protocols, i.e. HTTP, SMTP, etc.

Second, that most RFCs are crap. This means either they were poorly written, were April Fools jokes, documented useless protocols, or documented them in a useless or broken fashion, or generally were only relevant for a short period of time.

Virtually everything else you said was rather pointless drivel about how the search was performed, without actually telling us anything interesting about the methodology, or it was seemingly unsubstantiated conjecture based on sketchy results.

I can see that there may be some useful information that can be extracted now that you've done the searching, but none of such information was really presented. I wish I could think of what you could extract from this, but I'm truly at a loss.

"Too much wasabi and you'll be crying like you did at the last ten minutes of The Terminator" - Alton Brown

The RFC system is broken. (3.66 / 12) (#17)
by mdevney on Mon Oct 21, 2002 at 10:53:22 PM EST

The RFC system was an okay hack when there were maybe 5,000 people on the internet, but it certainly can't scale past that.  Now we end up with kludges like near-duplicate RFCs to correct minor wording, obsolete RFCs, and of course I never liked the April Fool RFCs because they're just not professional.

We need a list of "active" RFCs.  Where the IETF RFCs are just what the name implies -- Requests for Comment -- we need a complementary list of "Active RFCs," that is, a list of current, updated, actually in use RFCs.  822 is has been obsoleted by 1822, and 2822, and I believe the number 3822 has been reserved for a forthcoming revision.  

Screw that.  We need an RFC that is not a request for comment, but an agreed-upon document that incorporates all those comments.  Not "I think we should do it this way," but, "Everybody does it this way."  Obsolete ones can be left out, current ones can be updated instead of made obsolete.  That would be far more useful.

they're just not professional (4.42 / 7) (#30)
by Bad Harmony on Tue Oct 22, 2002 at 05:06:39 AM EST

You must be a lot of fun at parties.

5440' or Fight!
[ Parent ]

You mean, like... (5.00 / 2) (#39)
by ajf on Tue Oct 22, 2002 at 10:35:18 AM EST

STD 1, "Internet Official Protocol Standards"?

"I have no idea if it is true or not, but given what you read on the Web, it seems to be a valid concern." -jjayson
[ Parent ]
STDs are bad, mmm-kay? (none / 0) (#40)
by Fon2d2 on Tue Oct 22, 2002 at 11:27:14 AM EST



[ Parent ]
pick ... pick ... (3.50 / 2) (#28)
by nex on Tue Oct 22, 2002 at 03:42:16 AM EST

> an exhaustive research on the WWW
that's a contradiction in itself. no one has ever searched the w3 exhaustively in the past few years; google does not know every web page out there, by far. some servers are even capable of algorithmically dynamically generating more content than google can index, but, admittedly, those are art projects and applications that are very unliekly to contain references to RFCs.

but i'm just bitching about the use of that particular word here. i think the search was carried out quite sensibly and the results are interesting. i wouldn't consider it an ig nobel nomination.

> the TCP/IP protocol itself
well, actually that's two protocols, namely TCP on top of IP.

TCP/IP (none / 0) (#41)
by willie on Tue Oct 22, 2002 at 11:35:10 AM EST

Isn't TCP/IP not only TCP and IP, it's the whole suite of protocols, including UDP, ICMP, etc?

[ Parent ]
What? (none / 0) (#44)
by luserSPAZ on Tue Oct 22, 2002 at 12:52:25 PM EST

That statement makes absolutely no sense.  TCP/IP involves exactly TCP and IP.  Everything else is separate.  Granted, in operating systems they may call their whole networking stack the "TCP/IP" stack, but that doesn't change what the acronym means.

[ Parent ]
Strict vs. Fluid (4.00 / 1) (#48)
by hardburn on Tue Oct 22, 2002 at 02:31:06 PM EST

In a strict definition, you are correct. However, people tend to use a more fluid definition ("TCP/IP suite"), which includes UDP, ICMP, and even some application layer protocols.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Nope (none / 0) (#60)
by willie on Tue Nov 05, 2002 at 07:34:10 AM EST

Sorry, don't think so. This kinda annoys me, when people make big claims like "That statement makes absolutely no sense", without any backing.

I grabbed 3 random textbooks from my desk to double check this, and here goes:

"Officially named the TCP/IP Internet Protocol Suite and commonly reffered to as TCP/IP (after the names of its two main standards), it can be used to communicate across any set of interconnected networks."
Comer, D., (2000) Internetworking with TCP/IP Volume 1: Principles, Protocols and Architechtures (4th Edition), Prentice Hill, New Jersey.

Here's another:

"The protocol suite used with the Internet is known as Tranmission Control Procotol/Internet Protocol (TCP/IP). It includes both network oriented protocols and application support protocols."
Haslsall, F., (1996) Data Communications, Computer Networks and Open Systems (4th Edition), Addison Wesley, Essex.

And finally, the icing on the cake:

"The name 'TCP/IP' refers to an entire suite of data communications protocols. The suite gets its name from two of the protocols that belong to it: the Transmission Control Protocol and the Internet Protocol. Although there are many other protocols in the suite, TCP and IP are certainly two of the most important."
Hunt, C., (2002) TCP/IP Network Administration (3rd Edition), Oreilly, Sebastopol, CA.

I'm not about to go searching through RFC's to find something that says the same thing, but I'm sure they'll back me up as well.

[ Parent ]

You forgot one (4.00 / 5) (#31)
by LilDebbie on Tue Oct 22, 2002 at 05:34:42 AM EST

RFC 1925

My name is LilDebbie and I have a garden.
- hugin -

RFC1925 is #295 in the ranking (4.00 / 2) (#33)
by cribeiro on Tue Oct 22, 2002 at 06:43:00 AM EST

RFC1925 - The Twelve Networking Truths - is surely a highly relevant RFC, and this is shown by its position on the ranking. With approximately 3010 references, RFC1925 is #289. At this position it is well into the top 10% RFCs. It is nearly tied with many other relevant RFCs. Because Google results are only an approximation, it is possible that any particular RFC could be a little bit higher or lower in the ranking. However, at 3010 references, RFC1925 is very far from the top 20; the 20th entry has 20800 references.

[ Parent ]
+5 (none / 0) (#49)
by CaptainZapp on Tue Oct 22, 2002 at 02:32:36 PM EST

yes sir, you have my vote...

[ Parent ]
rfc2550 (4.00 / 1) (#51)
by I am Jack's username on Tue Oct 22, 2002 at 03:29:43 PM EST

Y10K and beyond is bloody beautiful.
--
Inoshiro for president!
"War does not determine who is right - only who is left." - Bertrand Russell
[ Parent ]
Urm, the IETF has a system for relevance... (4.66 / 3) (#34)
by L Satyl on Tue Oct 22, 2002 at 08:08:35 AM EST

it's called Standards: an RFC can get a number in the STD series, thereby making it an official internet standard.

And google statistics hardly say anything about the relevance of a standard, document or aby other type of infromation. It only says something about the interest of the general public with a web presence (if that).

Internet Standards & Google as a relevance met (4.50 / 2) (#38)
by cribeiro on Tue Oct 22, 2002 at 09:40:16 AM EST

Let me try to clarify my intentions and defend my study:
  • The study was designed to look for the relative relevance of RFCs. It's not an absolute relevance metric. The goal was to develop a ranking system. As we all know, any type of ranking will be open to debate, and it's no different with this one.
  • The Official Internet Protocol Standards list, as published by the IETF, is a very important guide to understand which RFCs are currently up-to-date. In a sense, it can be understood as an 'absolute' metric - it only states that a given RFC is a official standard or not. It is not a relative ranking system; it fails to capture the popularity of the particular RFCs. I believe that the popularity is a very important part of the relative relevance metric, because it shows what RFCs are actually referenced over the Internet. Assuming that most references are relevant themselves, we have a pretty good ranking system.
  • The use of Google to measure the relative relevance is also debatable. However, Google is widely recognized as the best tool for this job available now. Nothing stops doing the same study again using another tool, if a better one turns out to be available.


[ Parent ]
Relative relevance?? (none / 0) (#55)
by L Satyl on Wed Oct 23, 2002 at 06:52:43 AM EST

Relative to what? I'm much more interested in which RFC's are actually *used* in the design of soft- and/or hardware than I'm interested in which RFC's are referenced on the homepage of some developer wannabe. It's nice that the google API offers these possibilities, it's just that the numbers don't say anything about the true relevance of the RFC for the industry, nor about the relevance for the public at large.

It is not a relative ranking system; it fails to capture the popularity of the particular RFCs. I believe that the popularity is a very important part of the relative relevance metric, because it shows what RFCs are actually referenced over the Internet.
Again, why should I care about the perceived popularity of a certain RFC? I'm interested in the *implementation* of said RFC, which defines its relevance to me as a coder. I couldn't care less about Joe Schmuck and his happy band of helpers discussing the merits of the different RFC's thereby diluting (imho) your popularity results.

All your numbers say is how many links you found to a particular RFC. Your list may be the list of the most dubious RFC's since something controversial will receive a lot more attention than something we all agree on (just look at K5 stories). Without weighing the importance of the link, the end result is totally unusable and irrelevant.

[ Parent ]
For all your RFC searching needs. (5.00 / 5) (#42)
by raelin on Tue Oct 22, 2002 at 12:42:18 PM EST

http://www.zvon.org has them cross referenced, and will tell you what updates what, what obsoletes what, and it's searchable too.

--Wes


Excuse me... what?! (2.66 / 6) (#46)
by Shren on Tue Oct 22, 2002 at 01:15:24 PM EST

For reasons of space, we decided to limit the list to the first 20 RFCs.

"We did some useful work, but we decided to cut most of it out." Why 20? Why? What could you possibly have been thinking? "We wanted to make sure our hard work wasn't of much use to anybody." Are you afraid of using up too much bandwidth? Are you trying to make more space for you to sound pretentious in? Are you saving bits for a picture? "We had to throw out the data that made us look bad." Why would you want to do work... for publication... then publish so little of it that your results are relatively useless?

Reasons of space? You have too much space between your hygene-neglected ears. The least you could do is host it somewhere. But, no, you'd rather hide it from us and tell us what it means at the same time.

"Look, we did an interesting study - and we're flushing most of it down the garbage! HAHAHAHA!"

Full results (3.50 / 4) (#50)
by cribeiro on Tue Oct 22, 2002 at 02:46:01 PM EST

First of all, I would like to ask you to keep calm - there is no need to flame me in public. I already have posted a full explanation on why didn't I post the full result set. No, I'm not hiding it, and not, the full data will not make my study look bad. Please trust me - I had no hidden intentions when I decided to publish this study.

The reason why I didn't post the full result set is that I don't have a personal web page to publish it. Free hosting doesn't quite cut it, because they have lots of limitations that range from the platform-specific from contractual, intelectual property stuff. In the end, it was simply lazyness that prevented me from signing a good ISP with a decent hosting plan.

Now, if that helps making you feel better, I'm looking at it, seriously. So give me a chance, and I'll post the results, ok?

[ Parent ]

Bah. I flame you a second time. (1.00 / 1) (#58)
by Shren on Thu Oct 24, 2002 at 10:57:30 PM EST

If you were truly lazy, if you really understood the ancient art of minimal movement, you'd publish it once and spread the link around a bit.

[ Parent ]
Not a valid study. (4.00 / 3) (#52)
by jabber on Tue Oct 22, 2002 at 03:35:53 PM EST

How can you possibly consider your results to be valid, when the single most significant and relevant RFC, vis-a-vis the Internet, isn't even mentioned?

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Other April Fools Day RFCs (5.00 / 3) (#53)
by cribeiro on Tue Oct 22, 2002 at 03:56:25 PM EST

For those who didn't knew about it, RFC2795, or "The Infinite Monkey Protocol Suite (IMPS)", is one of the popular 'April Fool's Day' RFCs. It is ranked only at 1.475 in our list. A little higher in the list, ranked #1210, we have RFC2549 (IP over Avian Carriers with Quality of Service); however, the most popular April 1st RFC is RFC1149 (Standard for the transmission of IP datagrams on avian carriers), ranked #131.

[ Parent ]
IP over Avian Carriers (5.00 / 2) (#56)
by ilmari on Wed Oct 23, 2002 at 09:30:14 AM EST

[T]he most popular April 1st RFC is RFC1149 (Standard for the transmission of IP datagrams on avian carriers), ranked #131.
Not surprising, as it's the only one (afaik) that has actually been implemented.
--
ilmari
[ Parent ]
Forgot a very commonly used protocol (none / 0) (#54)
by dirvish on Tue Oct 22, 2002 at 06:58:24 PM EST

What about sneaker net? Slow and unreliable but available on nearly every machine.

Technical Certification Blog, Anti Spam Blog
A study on the relative relevance of RFCs | 60 comments (34 topical, 26 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!