0

I personally find RFC's quite difficult to read. They tend to be quite long, not precise enough, really old and for the most part, quite difficult to convert into actual working code. I think the evidence that I'm not the only one is quite large given that most developers I have spoken to have never seen an RFC.

Why are RFC's structured the way they are? Couldn't a set of code examples or unit tests be written in multiple languages instead? That way you could read the RFC in a language that you are familiar with...

Besides writing examples in multiple languages, are there any other specification organizations that use something else besides RFC's? If so, what do they use?

(Unrelated: I would like to add the tags: ietf, rfc, w3c but I do not have enough reputation, an edit would be appreciated)

14
  • 4
    The purpose of RFC's is to precisely specify protocols to ensure interoperability, not to provide a tutorial with code examples and so on. RFC's are supposed to be short and to the point.
    – JacquesB
    Commented Jun 12, 2015 at 7:53
  • @JacquesB: Wouldn't you say that RFC could be considered a language to some degree anyway? It has a lot of things in common in terms of structure.
    – anon
    Commented Jun 12, 2015 at 8:07
  • It is a specific jargon where some words have more precise meanings than in typical writing. This makes it harder to read but is important to avoid ambiguity. Kind of like legal jargon.
    – JacquesB
    Commented Jun 12, 2015 at 8:16
  • 2
    This is often how it is done. The IETF require at least two working interoperable implementations before a RFC is accepted.
    – JacquesB
    Commented Jun 12, 2015 at 10:25
  • 2
    @ThreaT: Honestly you seem to be ranting more than asking questions here. This is a QA site.
    – JacquesB
    Commented Jun 12, 2015 at 12:46

1 Answer 1

5

Why are RFC's hard to read?

The purpose of RFC's is to ensure interoperability on the internet by precisely specifying protocols. For this purpose precision and unambiguity is much more important than easy readability for laymen. The target audience for RFC's are systems developers implementing network stacks, not the common developer who just writes import HttpLibrary;

Furthermore RFC's are supposed to be long lived. The first RFC's are from 1969, and many older are still critical for the internet infrastructure.

These priorities leads to some choices which makes them harder to read:

  • They use an plaintext paged ASCII format which is not very browser-friendly (monospace font, strange gaps when pages split and so on). In this age were everything is HTML or at worst PDF, this seems like a relic. But in the time since RFC's was invented multiple "rich"-text formats have come and gone, but plain ASCII remains readable on all systems. And it is an unambiguous format, not subject to browser bugs and differences.

  • They use a jargon where some words have more specific meaning than in plain language, eg. the infamous:

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

    This is more akin to legal jargon, where precision is more important than easy readability.

  • RFCs attempts to be as short and to the point as possible, again to avoid ambiguities. For example, adding a code example introduces redundancy. If the code example subtly contradicts the spec, it will be unclear which is correct. If there are code examples in multiple languages this risk increases. Furthermore, code examples become dated. If RFC's from the 70ies had code examples, they might have been in Fortran or BCPL or assembler for processors long obsolete. It would have been more work making sense of the code examples than to read the RFC-prose, however obtuse.

The W3C are uses a different approach than RFC's. They write Recommendations which are generally easier to read. They are formatted in easy readable HTML, and use illustrative examples much more (the examples are typically marked as not normative to avoid ambiguities if the example contradict the spec). W3C recommendations are therefore quite readable. For example the CSS2 spec is (in my opinion) easier to understand than many CSS tutorials.

The W3C recommendations have a different audience than RFC's. The audience for RFC's are systems developers, while the audience for W3C recommendations are browser and application developers, and web authors and designers. A much broader audience.

That said, RFC's are not that difficult to read. If you get over the archaic presentation format, they are often surprisingly easy to understand.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.