プロトコルにおける「堅牢性原則」は害悪か

Internet Architecture Board (IAB)でもあるMartin Thomson氏から「The Harmful Consequences of the Robustness Principle」という文書が提出されている。

これは、堅牢性原則(Robustness Principle)について言及している文書である

Robustness Principle

プロトコルの設計と実装に関する原則として、「送信するものに関しては厳密に、受信するものに関しては寛容に」と掲げる堅牢性原則(Robustness Principle)というものがある。

TCP/IP, SMTP, DNS, FTPなどの開発に関わった故ジョン・ポステル氏によって提唱され、ポステルの法則とも呼ばれている。

Wikipedia(ジョン・ポステル)によると

元々はポステルがTCPを規定した RFC793 において
相互運用性を確保するためにTCPの実装が持つべき性質として要約した節が
より一般化されて知られるようになったものである。

と書かれている。

当時の仕様の曖昧性や解釈の違い、実装のバグなどがあったとしても、極力通信が続けられるようにという原則である。プロトコルがデプロイされ使われるようにするため、このような原則となっている。

1996年に発行された RFC1958 Architectural Principles of the Internetでも「Be strict when sending and tolerant when receiving」と書かれている。

The Harmful Consequences of the Robustness Principle

提出された「The Harmful Consequences of the Robustness Principle」では、堅牢性原則(Robustness Principle)では、バグのある実装との通信を可能とするために受信側が寛容性を持つと、バグを定着させることになり、長期的なプロトコルのメンテナンス(拡張)を難しくすると述べています。

JSONの例があげられており、元の仕様であるRFC4627「The application/json Media Type for JSON」ではUnicodeの処理、オブジェクトメンバーの順序付け、数値のエンコーディングなど、詳細に書かれておらず、実装によってさまざまな解釈がされた。更新された RFC7159でも問題は解決されておらず、サブセットを定義し問題ある部分の仕様を禁止したRFC7493 I-JSON とも相互運用できていない。そのため、広くは使用されておらずJSONパーサは、[ECMA262]で指定されたより正確なアルゴリズムを実装している。

その他にもTLSのバグのある実装と通信を可能にするためのワークアラウンドが行われていることや、HTTP/1.1の仕様の曖昧性を無くすために数年の労力を要したことなどがあげられている。

そのためこの文書では、堅牢性原則(Robustness Principle)よりも、初期設計やデプロイを超えて長期的なプロトコルのメンテナンスの継続を推奨しています。

エラーハンドフィングとフィードバック

プロトコルのメンテナンスするうえで、実装しデプロイしている人からのフィードバックが重要です。

エラーハンドリングについては、仕様に不正状態の取扱について記述されていることが理想的です。そして実装は、エラー状態からの回復を試みるのではなく、致命的なエラーとすることでそれを改善する動機を与えます。

また、自動化されたエラーレポートの仕組みは、デプロイされたプロトコルのより良いフィードバックを得ることが出来ます。実装者に不具合をレポートする仕組みは優れていますが、ユーザのプライバシに留意する必要があります。

所感

ここ数年だけを外から見ても、ossification(硬直化)と言われているように、プロトコルのメンテナンスに対するコストは上がっているように見える。エラーハンドリングやレポーティングの仕組みが充実していくのは非常に喜ばしい一方で、やはり実際に通信するためバグ実装に対するワークアラウンドが出てくるのはどうしても不可避に感じる。

HTTPの仕様改定がまた始まっているように、プロトコルのメンテナンスは継続して進めていかれるのは明らかであるし、続けていかなければならない。そのために、より良い仕組みや考え方が広まっていけばいいなあと思いました。