Live data from Hacker News

Pretty RFC

pretty-rfc.herokuapp.com

51–60 of 76 posts

Re: Pretty RFC

#51

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…

The way words are used in native languages and the connotations they bring up is not easily and fully explained by a 7 word blip in a dictionary... even then, this dictionary claims that must is "should (expressing necessity)": that parenthetical is key to the strength of "must".

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.)

Re: Pretty RFC

#52
post #5

When I search for "1483", my only result is 2684, which supersedes it. But when I try to view it, I'm told "The source XML for this RFC isn't available, therefore it can't be reformatted." Did the IETF shut you down? I don't think the original documents on the IETF datatracker site are that bad- it seems pretty clean and easy to read already.

The RFC for IMAP returns the same error regarding the XML source. I had assumed that it was parsing the text files, but apparently it only supports parsing the subset of RFCs that have XML available. :(

Re: Pretty RFC

#53

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…

[deleted]

Re: Pretty RFC

#55

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.…

> So basically, the all text format of RFCs is the least of their problems.

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...

Re: Pretty RFC

#56
It would be nice if the errata for each RFC was included somewhere - perhaps in the right margin for the relevant section?

Re: Pretty RFC

#59
I like the idea! But... I'm just not a fan of Bootstrap's typography. IMHO, it's too dense and low contrast, especially compared to the Flask Sphinx theme (my measuring stick for beautiful, readable documentation).
Post reply on HN