Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pretty RFC

pretty-rfc.herokuapp.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Pretty RFC

#41

Post by brian_cloutier »

jrockway wrote: post #11

Interesting. I thought I wanted something like this, but the problem with RFCs is the archaic writing style. It's hard to understand the details of a low-level network protocol when you also have to remember their redefinitions of words like SHOULD, MUST, MAY, MIGHT, PERHAPS, QUITE POSSIBLY and sort through ASCII art that is split across multiple pages. (The standards are also excessively wordy and poorly organized.…

This comment has no place at the top of the page.

> 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 [1], 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++ [2]? 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.

1: http://www.ietf.org/rfc/rfc2119.txt 2: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n333...

Re: Pretty RFC

#42

Post by smhinsey »

_delirium wrote: post #38
smhinsey wrote: post #24

Earlier quoted context omitted.

The ALL CAPS nature of weather alerts is due to the constraints of a very old but extremely widely deployed alert broadcast system. In the US, at least, the NWS is upgrading their alert broadcast systems so that this will no longer be the case, but this will definitely not happen quickly.

Couldn't they write the canonical version in mixed case, and then convert to all caps for distribution via legacy channels? It doesn't seem like it would be that hard to make it so that, even if it's all-caps in some channels, the version distributed via weather.gov is written in some more readable format. Or is there some legal requirement to have exactly one canonical ASCII version of the warning?

First of all, I'm not an insider, I'm just a weather nerd who came across this story awhile back and was really curious about it so I did some research.

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.

Re: Pretty RFC

#43

Post by japhyr »

I notice this is a heroku app. Do you mind sharing what heroku plan you are using, and how well your setup is handling today's traffic? Have you had to do anything significant to handle a spike in traffic today?

Re: Pretty RFC

#44

Post by nupark2 »

jrockway wrote: post #11

Interesting. I thought I wanted something like this, but the problem with RFCs is the archaic writing style. It's hard to understand the details of a low-level network protocol when you also have to remember their redefinitions of words like SHOULD, MUST, MAY, MIGHT, PERHAPS, QUITE POSSIBLY and sort through ASCII art that is split across multiple pages. (The standards are also excessively wordy and poorly organized.…

Compared to most specifications, RFCs are incredibly clear. While quality varies, they're remarkably approachable documents.

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.

Re: Pretty RFC

#45

Post by postfuturist »

jrockway wrote: post #11

Interesting. I thought I wanted something like this, but the problem with RFCs is the archaic writing style. It's hard to understand the details of a low-level network protocol when you also have to remember their redefinitions of words like SHOULD, MUST, MAY, MIGHT, PERHAPS, QUITE POSSIBLY and sort through ASCII art that is split across multiple pages. (The standards are also excessively wordy and poorly organized.…

Have you read RFC2616? It is quite approachable, and this is an improvement over the plain text version. Any web developer worth his or her salt should know about it enough to at least look up status codes and headers. It's resolved a number of debates at work when designing REST API's.

Re: Pretty RFC

#46

Post by elehack »

Very nice - this will make RFC reading much easier. Would be nice to have DuckDuckGo use it - will submit !bang request.

Any timeframe on finishing RFC coverage? RFC 3514 isn't prettyfied yet.

Re: Pretty RFC

#47

Post by fbuilesv »

japhyr wrote: post #43

I notice this is a heroku app. Do you mind sharing what heroku plan you are using, and how well your setup is handling today's traffic? Have you had to do anything significant to handle a spike in traffic today?

I'm not the original author but after a quick look at the application code (https://github.com/mislav/rfc/) it seems like mislav's just serving the documents from the database. It also caches the results so the free Heroku plan should be more than enough to support this.

Re: Pretty RFC

#48

Post by makmanalp »

brian_cloutier wrote: post #41
jrockway wrote: post #11

Interesting. I thought I wanted something like this, but the problem with RFCs is the archaic writing style. It's hard to understand the details of a low-level network protocol when you also have to remember their redefinitions of words like SHOULD, MUST, MAY, MIGHT, PERHAPS, QUITE POSSIBLY and sort through ASCII art that is split across multiple pages. (The standards are also excessively wordy and poorly organized.…

This comment has no place at the top of the page. > 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…

Let's take a look.

Oxford says "should" implies "used to indicate obligation, duty, or correctness"[0]. That sure does not sound like "aren't required to" to me. Sure enough, if you look into "must" [1] 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.

[0] http://oxforddictionaries.com/definition/should [1] http://oxforddictionaries.com/definition/must

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.

Re: Pretty RFC

#49

Post by mislav »

japhyr wrote: post #43

I notice this is a heroku app. Do you mind sharing what heroku plan you are using, and how well your setup is handling today's traffic? Have you had to do anything significant to handle a spike in traffic today?

The app is running on a single (free) Heroku dyno, PostgreSQL as db & full text index, and fronted with Rack::Cache using 5MB memcache for storage (also free).

It survived being first on HN for hours, no probs.

https://github.com/mislav/rfc/blob/74b4181/app.rb

Re: Pretty RFC

#50

Post by chc »

makmanalp wrote: post #48
brian_cloutier wrote: post #41

Earlier quoted context omitted.

This comment has no place at the top of the page. > 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…

Let's take a look. Oxford says "should" implies "used to indicate obligation, duty, or correctness"[0]. That sure does not sound like "aren't required to" to me. Sure enough, if you look into "must" [1] 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 you…

Trotting out brief dictionary definitions is rarely useful for precisely nailing down the common meaning of words, as it is hard to express nuance in such a small space. Fortunately, though, Oxford actually does go out of its way to make it clear. Unfortunately, you omitted those extra details. Let's look at the bullet points clarifying the meaning:

"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?

Post reply on HN