Wow, the navigation sidebar definitely increases the usability of the RFCs.
Pretty RFC
21–30 of 76 posts
Re: Pretty RFC
#22This is great. Small complaint: searching for RFC2822 comes up with nothing. 2822 gets what I want. Plz to fix :)
Done :)
Re: Pretty RFC
#23Interesting. 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.…
I don't think they have redefined any of those words, merely provided more concrete meanings.
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.
Re: Pretty RFC
#24Interesting. 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.…
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.
Re: Pretty RFC
#25As it feels relevant, here's a site of mine that includes all the HTTP Status Codes in an easy referenceable format: http://httpstatus.es/
Re: Pretty RFC
#26Interesting. 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 to remember their redefinitions of words like SHOULD, MUST, MAY, MIGHT, PERHAPS, QUITE POSSIBLY
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.
Re: Pretty RFC
#27Thank you so much. I've waded through plenty of unformatted RFCs this week, and this is everything I've hoped for.
Re: Pretty RFC
#28Interesting. 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.…
I agree, but that's more of an information design problem; adding an explanation of the RFC 2119 key words (or rather, the facility to provide a clear, concise explanation) would be an interesting next step, along with the ability to remove things like ASCII art. Anything beyond that is well into the realm of textual editing, and I suspect that there would be a lot of crying foul, considering that one of the main aim…
RFC 2119 all the things. I write all documentation touching any subject, using the definitions for RFC 2119.
Avoids a zillion of misunderstanding, and makes reading easier too.
Re: Pretty RFC
#29I might be weird but I find the RFC-editor font easier to read.
Re: Pretty RFC
#30I love this a lot.
Minor formatting issue, perhaps. The braced formed of reference ends up losing something in the current parsing. Seeing something like "reference in RFC 1234 RFC 1234" 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 RFC 1234". 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.