It's quite common to see a list of favorite at the end of year. Everyone has favorite… I'll make a list of my favorite RFCs. This is not really a favorite list as it's often boring to read (and to really understand/interpret… the most difficult part) RFCs but you are obliged if you want to implement or review software that should follow them. I'll make a quick list of the RFCs that I read the most the past two years (this is not always reflecting the quality of the RFCs but more the usefulness of them to my past works) :
- RFC 2616 - The Hypertext Transfer Protocol is everywhere but not always strictly followed by a lot of software. My favorite section is 14.36 with the misspelled "Referer". A lot of caching proxies have a different understanding of the RFC and especially with the "SHOULD"… HTTP is more and more used, just have a look at REST strongly relying on HTTP.
- RFC 2440 (and by extension RFC 4880) - The OpenPGP Message Format - not easy to master but with a companion implementation like GnuPG, this helps a lot.
- RFC 2196 - Site Security Handbook - A great and simple reference for implementing security with a pragmatic approach without the hassle of ISO 27001 or ISO 27002.
- RFC 2396 - Uniform Resource Identifiers (URI) - somehow related to RFC 2616 but a must to use if you write crawler that need to parse a lot of URI. You could be very surprised by the wide definition for URI in practice.
I have some more but I won't add them in the list because I had already a bunch of nightmare by just trying to figure out the difference between the specification and its implementation.
On the fun side (you know the 1st April RFCs), my favorite is RFC 2795 (The Infinite Monkey Protocol Suite (IMPS)) and especially the PAN (Protocol for Assessment of Novelty) section with a nice (and sometime useful) CRITIC reject code :
8.3. Table of CRITIC Reject Codes
CODE DESCRIPTION
-------------------------------------------------------------------
| 0 | <Encrypted response following; see below>
-------------------------------------------------------------------
| 1 | "You're reinventing the wheel."
-------------------------------------------------------------------
| 2 | "This will never, ever sell."
-------------------------------------------------------------------
| 3 | "Huh? I don't understand this at all."
-------------------------------------------------------------------
| 4 | "You forgot one little obscure reference from twenty years
| | ago that renders your whole idea null and void."
-------------------------------------------------------------------
| 5 | "Due to the number of submissions, we could not accept every
| | transcript."
-------------------------------------------------------------------
| 6 | "There aren't enough charts and graphs. Where is the color?"
-------------------------------------------------------------------
| 7 | "I'm cranky and decided to take it out on you."
-------------------------------------------------------------------
| 8 | "This is not in within the scope of what we are looking for."
-------------------------------------------------------------------
| 9 | "This is too derivative."
-------------------------------------------------------------------
|10 | "Your submission was received after the deadline. Try again
| | next year."
-------------------------------------------------------------------
If you are familiar with the WG at IETF with any technical meeting. It's quite common to see meeting interaction using a variety of CRITIC reject code. So most innovative people are often using a variety of them or sometime create new ones. I'm just wondering where is the IANA consideration for this table ? ;-) just if we need to update it…
Tags: fun ietf rfcs rfc list favorite
![[FSF
Associate Member]](http://www.foo.be/fsfbutton-adulau.png){kind=small}
