[1]
[CITE@en-US[David Baron's weblog: March 2007]] ([CODE[2007-03-25 14:52:46 +09:00]] 版) <http://dbaron.org/log/2007-03#e20070324b>
([[名無しさん]] [WEAK[2007-03-25 05:54:29 +00:00]])

[2]
[CITE@en-US[David Baron's weblog: March 2007]] ([CODE[2007-03-25 14:52:46 +09:00]] 版) <http://dbaron.org/log/2007-03#e20070324b>
([[名無しさん]] [WEAK[2007-03-25 06:14:58 +00:00]])

[3]
[CITE[The Norwegians get it! - O'Reilly XML Blog]] ([[Rick Jelliffe]] 著, [CODE[2007-05-17 20:37:56 +09:00]] 版) <http://www.oreillynet.com/xml/blog/2007/05/the_norwegians_get_it.html>
([[名無しさん]] [WEAK[2007-05-17 11:39:07 +00:00]])


[4]
[CITE[Wasting resources - Anne’s Weblog]] ([TIME[2007-05-20 06:46:44 +09:00]] 版) <http://annevankesteren.nl/2007/05/wasting-resources>
([[名無しさん]] [WEAK[2007-05-20 01:43:35 +00:00]])

[5] [CITE@en['''['''cs/0105018''']''' HTTP Cookies: Standards, Privacy, and Politics]] ([TIME[2005-09-17 23:32:47 +09:00]] 版) <http://arxiv.org/abs/cs.SE/0105018>

[7] 
[[Cookie]] の [[IETF]] における標準化の歴史と、いかにそれが失敗したかを中の人が振り返った論文です。
議論の長期化によってタイミングを逃したこと、利害関係者を集めることに失敗して誰も興味を持たない標準が生まれたこと、
理想と政治に振り回されて現実とかけ離れた結論が導かれたことなど、
大変興味深いものです。

[6] 
[CITE[Re: '''['''http-state''']''' Goals for the UA conformance section (was Re: Updated draft)]]
([TIME[2009-08-19 16:10:45 +09:00]] 版)
<http://www.ietf.org/mail-archive/web/http-state/current/msg00201.html>

>
In general, specs should be specific about what the output should be. We 
shouldn't leave things undefined or up to the implementation if it affects 
other implementations (such as servers), because otherwise we will find 
authors end up relying on the market leader's behaviour.

[8] 細部を未定義のままとしておくことは、実装の自由度が増し、最適化などの余地が生まれることで利用者にとってもメリットが増えると思えます。
しかし実はそれが成り立つのは、その未定義な動作の影響が閉じていて観察できない時に限られます。
たとえ仕様上未定義であっても、ほとんどの人は仕様がどうであるかではなく、主要な実装がどう動いているかに基づき行動します。
結果として、「未定義」は「市場のリーダーに倣え」の意味となり、標準の存在意義を危ぶむこととなるのです。

[9] [CITE[Re: '''['''http-state''']''' Goals for the UA conformance section (was Re: Updated draft)]]
([TIME[2009-08-20 00:10:08 +09:00]] 版)
<http://www.ietf.org/mail-archive/web/http-state/current/msg00202.html>

>We're documenting (or should be documenting, IMHO) what all 
implementations are going to converge on. That means describing what they 
do when they do the same thing, and considering differences to be bugs for 
which we are to find solutions that are acceptable to implementors.

[10] [CITE[IRC logs: freenode / #whatwg / 20090727]]
([TIME[2009-09-27 21:53:01 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20090727#l-301>

>
-[10:49] <Hixie> proposing spec text is a terrible way to contribute to spec development, in my experience
-[10:49] <Hixie> because unless you're truly familiar with the spec, you'll miss all kinds of things
-[10:50] <Hixie> best to propose use cases, requirements