Deciphering and interpreting an RFC is never an easy thing and many times the same RFC can be interpreted different ways.  My favourite RFC is RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 specifically section 13 on caching and section 14 on headers make for a very interesting read.  I frequently encounter situations where browsers and applications don't appear to behave as the RFC states they should.  Here are a couple of examples I have come across:

Firefox 3 Expires and Max-Age

According to section 14.9.3 "If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive."  Recent testing with Firefox 3 has revealed that this is not the case.   If the Expires header is in the future then the Max-Age value from Cache-Control header is honoured, but if the Expires header is in the past then Firefox 3 will cache the content on the browser with an immediate expiry. Neither  Internet Explorer 7 nor Chrome exhibit this same behaviour the cache-control headers always override the Expires header even when the value is in the past.   This discrepancy in behaviour when a customer said they were getting inconsistent results during their testing of WebAccelerator, just goes to show the importance of performing cross-browser functional testing of your application.  

Maximum Value for Expires Header

Section 14.21 covers more details on the use of the Expires header specifically appropriate values for the header. 

"HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."  However I occasionally see headers like the one below that is set for almost 30 years.

Expires    Sun, 17 Jan 2038 19:14:07 GMT

I'm all for setting expires in the future but isn't 1 year sufficient or is 30 years really necessary?

Cache-Control Private

This came to my attention through one of the forum posts on DevCentral in regards to the insertion of a Cache-Control=private header into responses and how this was impacting Akamai.  It turns out that Akamai does not honour the Cache-Control header of private.  Section 14.9.1 of the RFC states a private header  "Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. "  In my opinion Akamai is a shared cache and should not cache content with the Cache-Control header of private. 

These are just 3 examples of how items in the RFC can either be interpreted differently and sometimes ignored.  I'm sure there are others out there.  Do you have any other examples?