- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 16 Jun 2009 23:18:19 -0700
- To: Shane McCarron <shane@aptest.com>
- Cc: Dave Singer <singer@apple.com>, robert@ocallahan.org, Ian Hickson <ian@hixie.ch>, Larry Masinter <masinter@adobe.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, public-html@w3.org
On Tue, Jun 16, 2009 at 10:01 PM, Shane McCarron<shane@aptest.com> wrote: > Dave Singer wrote: >> (It's also odd to have a spec. which bars the user agent from 'going the >> extra mile'. Specs classically say all the things you must do to be >> conformant, and generally can't stop you from doing more.) > > Exactly! Most modern standards and "recommendations" define what happens > when presented with conforming input, and implicitly or explicitly state > that non-conforming input results unspecified or undefined behavior (see > *all* the IEEE POSIX standards, for example). It is an unparalleled act of > hubris that this work attempts not only to define good behavior, but also to > define *positive* behavior in the face of bad data. That's just insane. If > it is critical to define the behavior of implementations when handed invalid > input, then say that the implementation is required to tell the user "the > input is broken"! Defining that an implementation will somehow cleverly > deal with every broken piece of input is not just silly, it's impossible. For content sniffing, this approach causes both security and compatibility issues. Ultimately, user agents have to decide how to act when presented with non-conformant input. You're welcome to construct a user agent that displays a "the input is borken" message, but I suspect your user agent will not gain an appreciable market share. Given that user agents do process this input, the world is better off if they all do so in the same way. Adam
Received on Wednesday, 17 June 2009 06:19:24 UTC