Small bug: RFCs < 1000 that are not prettifiable have a extraneous zero in the datatracker.ietf.org link.
redirects to: http://pretty-rfc.herokuapp.com/RFC0123 (left padding is probably a mistake here; some day we will have >9999 RFCs)
links to: http://datatracker.ietf.org/doc/rfc0123/ (404)
should link to: http://datatracker.ietf.org/doc/rfc123/
ps. XML format for RFCs that this leans on: http://pretty-rfc.herokuapp.com/RFC2629
Unfortunately every RFC I tried, except for the provided examples, returned "Could not prettify this RFC".
Yes, "could not prettify this RFC" is a problem I'm having right now because most sources aren't available. I'm working on obtaining those sources.
DISCLAIMER: This reply contains a slightly modified implementation of RFC 1097.
Still, it sounds like a great resource. If anyone knows of a working link for the epub, please let us know.
Minor formatting issue, perhaps. The braced formed of reference ends up losing something in the current parsing. Seeing something like "reference in RFC 1234 <a>RFC 1234</a>" jars me out of reading the document. It would be pretty neat in those cases to collapse the string so it was simply "reference in <a>RFC 1234</a>". In the cases where you can't collapse the string, to preserve reading flow, it might make sense to leave the braces surrounding the link.
What's this using as a data source?
correct link : http://pretty-rfc.herokuapp.com/RFC2616#character.sets
link in text : http://pretty-rfc.herokuapp.com/RFC2616#character-sets
I don't think the original documents on the IETF datatracker site are that bad- it seems pretty clean and easy to read already.
Any timeframe on finishing RFC coverage? RFC 3514 isn't prettyfied yet.
dunno, maybe those two efforts can be joined.
Compared to reading some other specs (like, say, some of the SCSI ones) RFCs are just painful. Especially with the ASCII art diagrams.
Now, if only the IETF could realise that "being liberal in what you accept" is a horrible idea and remove all usages of SHOULD/MAY or "infer", we'd really be rolling.
So basically, the all text format of RFCs is the least of their problems. But this is a nice attempt.
(I wonder how many people die every year because the National Weather Service issues tornado warnings in ALL CAPS with VROUS ABREVS throughout the text. Computers can do lowercase now, guys...)
The HTTP RFCs have been, in my experience, better written. They just seem to be more solid.
The "archaic" style is really just how you write a spec. The all-caps MUST, SHOULD, etc. stuff is about being as specific as possible. That's a good thing for a spec.
I find that to be one of the easier parts. They establish a very careful set of vocabulary and then use it consistently and CAPS it to make sure you don't accidentally miss it. The definitions match the standard of the definitions, so it's not hard to remember. They embody the concepts "you have to", "you are not allowed to", "you can if you want", "we encourage you to", and "we don't know for sure but we think so", and a couple others.
They have to be precise, they're trying to write the equivalent of human code. Wiggle room and vagueness is bad.
One problem with RFC quality is that they pull in standards from other areas, so sometimes X was written for one standards body, Y for yet another, but they were both converted to an RFC and thus the styles differ.
Of all the things to dislike, I find your dislike of SHOULD/MUST/MAY to be incredibly bizarre. The definitions of the words are intuitive, they place the definitions at the top of the document, and they use the words to eliminate all ambiguity when reading the document.
If you don't like RFCs, I'd be very curious to know what specification documents you do like.
It is true that the writing style RFCs is hard to read, but I don't think there's much hope of changing that while maintaining the sort of precision that is necessary in this sort of document. Legal documents are also hard to read.
That said, my understanding is that they are basically going towards a widespread mixed-mode setup now, but they haven't yet for historical and budgetary reasons.
The system they'll be replacing is largely the result of tragedies like the Andrea Doria and countless less famous weather-related accidents that were caused by faulty communication of important weather bulletins. Because of this there was a pretty significant investment in designing and deploying a really robust system, and it was rolled out extremely widely, including far flung and remote weather stations, and was adopted elsewhere as a standard as well.
Fast forward to today and the aging system does the job but is in a rather precarious state because everyone who designed and built it is long dead, and in the face of shrinking budgets, like the NYC subway system and the national air traffic control systems, for most of its history it was maintained just enough to keep pace but rarely upgraded.
Only relatively recently has there been momentum behind modernization and the big driver behind that has been the increasingly deadly tornado seasons we've been experiencing over the past decade or so. The need to be able to push out more geographically precise bulletins as well as to make them more impactful (they recently started using phrases like "you will die if you do not seek shelter" in select tornado alley locations) in the hope of decreasing casualties has been a major driver behind this change.
> the problem with RFCs is the archaic writing style
I'll admit, reading standards is more difficult than reading regular prose, it is nearly impossible to use language precisely without getting too verbose. Languages, and English especially, are full of little ambiguities; even simple words like "or" have more than one meaning! This doesn't quite cut it when it comes to specifications. If the spec is ambiguous then it's possible for two different implementors two come up with incompatible implementations, which kinda ruins the point of a spec. Try to think of RFCs (and standards in general) as the legalese of the software world. They're more verbose than you're used to, but that's necessary.
>have to remember their redefinitions of words like SHOULD, MUST, MAY...
Let's take a look at RFC2119 , where these terms are defined. The word "MUST" means you must do something, the word "SHOULD" means you should do it, but you aren't required to, and the word "MAY" means you could if you wanted to, but aren't required to. Well... that's what those words mean in English too! Are you really complaining that you must know English in order to read English?
The only slightly confusing word is SHALL, which is fairly uncommon in modern English. Even SHALL has not been redefined though, in RFCs it means exactly what it means anywhere else.
> And if you think the problem is just me, try finding any piece of software that actually correctly implements any RFC spec :)
Adding a smile to the end of your sentence doesn't make it any less stupid or wrong. Almost everything you touch today when using the internet is defined by an RFC. ARP (RFC826) is dead simple, and has been correctly implemented for decades. TCP (RFC793) admittedly took a few revisions to get right, but if it wasn't correctly implemented we wouldn't be able to have this conversation. Come up with your own examples, there are plenty more. If you think engineers are so stupid they don't know how to understand text which is a slightly more verbose than usual you have a pretty low opinion of humanity.
> So basically, the all text format of RFCs is the least of their problems.
Have you ever tried to read a spec which is actually difficult, like c++ ? Specifying a language is at least an order of magnitude more difficult than specifying a protocol or "best practice", and it shows in how dense language specifications are. RFCs are pretty damn readable, I often browse through them for entertainment.
> (I wonder how many people die every year because the National Weather Service issues tornado warnings in ALL CAPS with VROUS ABREVS throughout the text. Computers can do lowercase now, guys...)
Once again, you must have a pretty low opinion of humanity to think we don't know how to read abbreviations or uppercase characters.
Oxford says "should" implies "used to indicate obligation, duty, or correctness". That sure does not sound like "aren't required to" to me. Sure enough, if you look into "must"  you see that it is defined as "be obliged to; should".
Maybe you shouldn't be chiding people implying how simple English is when you're not so solid on it yourself, especially when you've given a whole treatise in your previous paragraph about how language is full of ambiguities and words can have multiple meanings and such.
Edit: Am I wrong? Am I ruder than the parent? Awaiting comments.
Edit2: Okay, so it looks like I'm wrong about "should". I really don't know why the heck "should" is listed as a definition for "must", then. I'd still like to point out that even the dictionary seems confused and maintain my point that it's not as simple and clear as portrayed.
In fact, looking at it, you dropped half of the definition you pulled for "should" ("typically when criticizing someone's actions") and I will claim are mischaracterizing what an "obligation" is (just because I am obligated to do something, doesn't mean it is a necessity for me to do it).
Putting this into practice, if you tell someone that they /should/ stop at the kiosk before parking in the lot, normal speakers of English will treat that drastically differently than if you instead say that they /must/ stop at the kiosk before parking in the lot; the former feels subjective while the latter feels objective.
For a rather clear example of this: "you /must/ open the drawer before you [can] take things out of it" would go unquestioned, while "you /should/ open the drawer before you take things out of it" will cause many people to wonder what the alternative to opening the drawer could be.
(edit: I see that chc made a similar complaint about your comment to me 10 minutes earlier, but I didn't see that comment as I was working on mine; I think mine has some value still with the examples, and a slightly different focus, so I will leave it in the thread as a reply.)
"indicating a desirable or expected state"
"used to give … advice or suggestions"
One of the examples it gives is, "by now pupils should be able to read with a large degree of independence." Few native English-speakers would read that sentence as saying that there is no option but for students to read with a large degree of independence. What it means is that such a level of reading is desirable or expected, but not required.
In common usage, should is much weaker than must. Another good example: "I should exercise tonight" vs. "I must exercise tonight." The former almost sounds like the speaker knows it won't happen and feels guilty, whereas the latter sounds like the speaker is bound and determined to exercise. Don't you think?
It's right there in the first couple of sections, usually.
try reading specs that are from 3gpp, and then you would realize the bastion of clarity that is ietf. and the format of 3gpp specs is ms-word (yes you read that right), there is zero hyper-linking across various specs, finding how something works etc. is a matter of opening up at least 3-5 documents, and have a standards guy next to you to make sense of it all...
As for the ms-word-ness, I recommend this site for PDF versions of the documents . Just bask in the ridiculous amount of versions and documents in that list and be happy that RFCs are at least human-readable and in a standardized format...
Avoids a zillion of misunderstanding, and makes reading easier too.
I'll take the RFC format (short, to the point and really clear) over others any day.
Most of the times I feel as though those that write specs have received explicit instructions to make things as verbose as possible to justify the insane pricing of standards documents.
Archaic in this case is just another word for continuity and that's not a bad thing. Imagine every RFC hopping on to the latest bandwagon in terms of presentation, powerpoints, pdfs, html animated images and so on. It would be a cacophony, now it is just the minimal amount of information required to implement something. It's great in a minimalist way.
So why not generate them with tooltips, i.e. when you hover your mouse over an ALL CAPS word, you'll get a tooltip with RFC2119?
It survived being first on HN for hours, no probs.