[3] [DFN[[RUBYB[ポステルの法則]@en[Postel's Law]]]] ([DFN[Robustness Principle]])
は、[[インターネット]]の[[プロトコル]]の実装に関する大原則です。
[[受信]]に関してはより柔軟に、緩めの解釈を求め、
[[送信]]に関してはより正確に、厳密な仕様の順守を求めています。

[20] [[インターネット]]の[[開発者]]であり本原則を確立した [[Jon Postel]] に因んでいます。

* 由来

[4] 
>Be liberal in what you accept, and conservative in what you send

;; [CITE@en[RFC 1123 - Requirements for Internet Hosts - Application and Support]] ([TIME[2011-01-08 19:53:59 +09:00]] 版) <http://tools.ietf.org/html/rfc1123#page-7>

[7] 
> In general, an implementation must be conservative
in its sending behavior, and liberal in its receiving behavior.

;; [CITE@en[RFC 791 - Internet Protocol]] ([TIME[2014-05-01 22:55:17 +09:00]] 版) <https://tools.ietf.org/html/rfc791#section-3.2>

[1]
>TCP implementations will follow a general principle of robustness:  be
conservative in what you do, be liberal in what you accept from
others.

;; [CITE@en[RFC 793 - Transmission Control Protocol]]
<http://tools.ietf.org/html/rfc793#section-2.10>

* 文脈

[19] [[インターネット]]の多くの[[プロトコル]]の設計の基本原則となっています。

* 批判

[11] [[ポステルの法則]]に従った実装と、そのような実装の存在に依存して正確な送信を行わない実装が混在する場合、
次第に元々の厳密な仕様の範囲外であっても、正確な送信を行わない実装との[[相互運用性]]のために特定の受信動作が求められるようになってしまいます ([[バグ互換性]])。

[12] 大抵はおおむね[[相互運用性]]が保たれているとみなされ放置されるので、
明文化されない暗黙の仕様が生じ、新規参入が困難になったり、
仕様の拡張に支障が生じたりします。

[13] これを[[ポステルの法則]]の失敗とみなして [[draconian]] な受信動作が望ましいと考える人もいます。

[14] あるいは[[ポステルの法則]]の精神に従いつつ、受信動作をも厳密に仕様の一部として規定するべきと考える人もいます。

[EG[
[16] [[HTMLの構文解析]]は、元々ほとんど規定と言えるものがありませんでした。
90年代、[[著者]]は好き勝手な [[HTML文書]]を量産し、
[[Webブラウザー]]はどんな入力にもおおらかにできるだけ[[著者]]の意図 (と推測されるもの)
に沿って処理するようかなりの力を注いでいました。

[17] 結果として世間で流通する [[HTML文書]]の解釈には明文化されていない相当量の複雑難解な[[バッドノウハウ]]の蓄積が必要となり、
新規参入を著しく阻害していました。

[18] [[HTML5]] (現在の [CITE[HTML Standard]]) はこの状況を改善するため、
既存の[[Webブラウザー]]の動作と膨大な[[HTML文書]]の調査を経て、
[[HTML構文解析器]]の動作を完全に文書化しました。
]EG]

[26] 
失敗事例:
[[URL parser]]


* 関連

[5] [[日本]]では、しばしば[[標語]]「[[人に優しく、自分に厳しく]]」で表現されます。

* メモ

[2] [CITE[IRC logs: freenode / #whatwg / 20100629]]
([TIME[2010-07-04 19:10:47 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20100629#l-193>

[6] [CITE@en[RFC 1958 - Architectural Principles of the Internet]]
( ([TIME[2011-06-05 09:19:25 +09:00]] 版))
<http://tools.ietf.org/html/rfc1958#page-5>

[8] [CITE@en[RFC 5537 - Netnews Architecture and Protocols]] ([TIME[2014-09-14 17:08:11 +09:00]] 版) <http://tools.ietf.org/html/rfc5537#section-3.1>

[9] [CITE@en[draft-thomson-postel-was-wrong-00 - The Harmful Consequences of Postel's Maxim]]
([TIME[2015-06-13 20:22:21 +09:00]] 版)
<https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00>

[10] [CITE@en[The Robustness Principle Reconsidered | August 2011 | Communications of the ACM]]
([[Eric Allman]] 著, [TIME[2015-07-03 11:27:00 +09:00]] 版)
<http://cacm.acm.org/magazines/2011/8/114933-the-robustness-principle-reconsidered/fulltext>

[15] [CITE[Users, clients, and servers — Anne’s Blog]]
([TIME[2016-08-11 18:02:41 +09:00]])
<https://annevankesteren.nl/2016/05/client-server>

[21] [CITE@en[RFC 4648 - The Base16, Base32, and Base64 Data Encodings]]
([TIME[2018-01-28 17:12:45 +09:00]])
<https://tools.ietf.org/html/rfc4648#section-3.3>

[22] [CITE@en[martinthomson/postel-was-wrong: Tolerance is a bug]]
([TIME[2018-04-13 01:03:49 +09:00]])
<https://github.com/martinthomson/postel-was-wrong>

[23] [CITE@en[The Harmful Consequences of the Robustness Principle]]
([TIME[2018-03-05 14:05:27 +09:00]])
<https://martinthomson.github.io/postel-was-wrong/draft-thomson-postel-was-wrong.html>

[24] [CITE@en[The Harmful Consequences of the Robustness Principle]]
([TIME[2019-05-07 11:34:25 +09:00]])
<https://intarchboard.github.io/protocol-maintenance/draft-iab-protocol-maintenance.html>

[25] [CITE@en[intarchboard/protocol-maintenance: Don't apply the robustness principle, look after your protocol instead]]
([TIME[2019-06-19 15:05:58 +09:00]])
<https://github.com/intarchboard/protocol-maintenance>