Blunt Weapon

エンジニアと仕様の議論になるとき、一方的にぶん殴れる鈍器があることをご存じだろうか。

RFCという。Request for Commentsの略だが、名前の謙虚さとは裏腹に、インターネットの標準仕様を定めた文書だ。HTTPもTCPもDNSもTLSも、すべてRFCに書いてある。独自規格の仕様を出してきたエンジニアに「RFC何番に書いてあります」と返せば、だいたい黙る。ぐうの音も出ない。仕様の根拠を国際標準に置ける強さは圧倒的だ。

使い方はシンプルだ。相手が「このAPIのレスポンスは独自フォーマットで返します」と言ったら、RFC 7807のProblem Detailsを出す。「認証トークンはクエリパラメータで渡します」と言われたら、RFC 6750を出してAuthorizationヘッダを使えと言う。相手がどれだけ経験豊富でも、RFCには勝てない。

ただし、この鈍器には欠陥がある。RFC同士がコンフリクトしていることがあるのだ。

特にOIDCの領域がひどい。OAuth 2.0のRFC 6749ではImplicit Flowが定義されているが、後発のベストプラクティスではセキュリティ上の理由で非推奨とされている。PKCEはRFC 7636で定義されたが、OAuth 2.0の本体には含まれていない。OIDC CoreはOAuth 2.0の上に構築されているが、トークンの検証やクレームの扱いで微妙に齟齬がある。どのRFCを根拠にするかで結論が変わる。

鈍器で殴ったつもりが、相手も別のRFCで殴り返してくる。そうなると議論は泥沼だ。

結局のところ、RFCは聖典ではなく合意文書だ。時代とともに更新され、矛盾し、廃止される。万能の鈍器だと思って振り回していると、自分の足を打つ。それでもRFCを読む習慣は持っておいたほうがいい。読まずに独自仕様を作る人間よりは、はるかにましだ。