Blunt Weapon

There is a blunt weapon that lets you beat an engineer senseless in any spec argument. You may already know it.

It's called an RFC. Request for Comments. The name sounds humble. The reality is not. RFCs define the standard specifications of the internet. HTTP, TCP, DNS, TLS — all of it is written in an RFC. When an engineer shows up with a proprietary spec, you say "It's in RFC such-and-such." They go quiet. There is no comeback. Grounding your argument in an international standard is overwhelmingly powerful.

The usage is simple. Someone says "this API returns responses in a custom format." You pull out RFC 7807, Problem Details. Someone says "we pass the auth token as a query parameter." You pull out RFC 6750 and tell them to use the Authorization header. It doesn't matter how senior the other person is. Nobody beats an RFC.

But this blunt weapon has a flaw. RFCs conflict with each other.

The OIDC space is particularly bad. OAuth 2.0's RFC 6749 defines the Implicit Flow, but later best-practice documents deprecate it for security reasons. PKCE is defined in RFC 7636 but isn't part of the OAuth 2.0 core. OIDC Core is built on top of OAuth 2.0, yet there are subtle misalignments in token validation and claim handling. Which RFC you cite determines which conclusion you reach.

You swing the blunt weapon. The other person swings a different RFC right back. The argument turns into a quagmire.

RFCs are not scripture. They are consensus documents. They get updated, contradict each other, get deprecated. Swing one around thinking it's invincible and you'll hit your own foot. Still, the habit of reading RFCs is worth keeping. It beats the person who builds a proprietary spec without reading any.