There are many badly written RFCs, but I encountered one annoying one today
Update: Thanks for the comments, and I concede that the next page refers to "value" being quoted. Even so, the whole idea of using BNF syntax is to be unambiguous, and this is still therefor a rather badly written RFC!
So, for those less techie, "RFC" is "Request for comment" which is a sort of passive way of pushing proposals on other people when the Internet first started. The "standards" we now follow are all RFCs. There is a slightly more formal process that can promote an RFC to an actual standard.
The idea is that the RFC says how something works, especially when it is a protocol. People they try to make their systems work to the RFC.
Now, there is always a degree of ambiguity, and so there is a really good principle which has worked well for the Internet which is that you should be tolerant of what you receive and strict in what you send. Basically, if the standard says to do something you should aim to be as accurate and correct as possible in what you send. However, when someone sends something to you, and there is some flexibility in what you accept, you should try to be flexible and work out what it means.
This has allowed the slightly flawed and imperfect implementation of many standards.
Today's issue was an RFC over MIME email, specifically RFC 2387 which apparently has status of "proposed standard", and is 19 years old.
We were sending a MIME object in an email that is multipart/related with a "type" field, specifically type=text/html which says that the "root" of that object is of a type text/html. All well and good. Indeed, a type= attribute is mandatory in RFC2387.
The problem is that the email did not work properly when emailing yahoo addresses. But other email systems did work. We experimented and found the "fix" was to send type="text/html" instead.
Now, I am not happy about this! The RFC has this to say on the type attribute :-
This defines that type is specified (after a ;) has the text type, then the character = and then the type and the character / and then the subtype.
So, unless we are saying that the type is "text and the subtype is html", sending type="text/html" is simply wrong.
The problem is the examples in the RFC (and errata), such as :-
(the errata added the missing ; on the end of the first and third line)
Where the hell did those quote marks come from?
So, yahoo are not being tolerant in what they accept, they are actually expecting non standard data, and we were being strict in what we sent, but to make it work we are now being non standard.
There really is not much worse than an RFC where its own examples do not comply with the RFC!
I have submitted and errata to the RFC editors for this.