Eric,
Saying that you'll tone things down isn't an opportunity to continue to rail against browser vendors. It's off-topic and counter-productive, and as such this is a public warning; if you continue in this vein, you'll be temporarily banned from posting to the list.
Let's get back to work, please.
On 06/11/2010, at 7:51 PM, Eric J. Bowman wrote:
> Maciej Stachowiak wrote:
>>
>> For a long time, browser implementors have not been a significant
>> part of the conversation for standards like HTTP. Perhaps as a result
>> of this, HTTP underserves the needs of Web browsers in some ways.
>> Now, browsers are not the only HTTP clients in the world, but they
>> are fairly important ones - a whole lot of people in the world run
>> HTTP servers with the primary goal of delivering content to users
>> browsing the Web with a Web browser. It's not the only use case, but
>> it's one important use case, and it often has specialized
>> requirements. To have a good standard, it's important to have a wide
>> range of the important stakeholders at the table.
>>
>
> Nevertheless, browser vendors have managed to generate significant ill
> will in the developer community by ignoring process and consensus. In
> the case of microdata, refusing to even reveal who the stakeholders
> *are*, and ignoring the request of the TAG to remove that document in
> favor of the consensus reached around RDFa, is just the sort of thing
> which might result in my questioning the motives of browser vendors'
> participation in this process. Desirable as that participation may be
> in the general sense, my posts reflect a suspicion that there is no
> intent to respect established consensus on the scope of HTTP. I'll
> tone it down, as I've been warned, but my suspicion remains and IMHO,
> is justified.
>
>>
>> Now, at least a few browser implementors are trying to join the
>> conversation and express our requirements. The topic of this
>> particular thread is a fairly trivial request - an optional
>> specification for error recovery when parsing the Content-Disposition
>> header. Browser implementors like to agree on error recovery, because
>> we find that in general it makes things better for our users. It
>> seems like experimenting with this approach using an *optional* spec
>> for *one* header field is a low-stakes experiment that won't hurt
>> anyone who doesn't care to participate.
>>
>
> That is one opinion. My opinion is that this is not a trivial request,
> it's a request for fundamental change. My reasoning is that there's an
> architectural concern which precludes HTTP from standardizing error
> recovery, and that this request is best handled as part of an optional
> extension to HTTP -- a set of best practices which is free to be
> updated _independently_ of the protocol specification, as such
> practices will most likely change more frequently than should the
> underlying protocol. I'm more than willing for browser vendors to
> engage on this technical issue which I find important, but no
> explanation as to why HTTP must be extended to account for error
> correction has been forthcoming, to justify even experimenting with it.
>
>>
>> Please consider the consequences of your attitude. We are all much
>> better off if browser vendors can participate effectively in this
>> group.
>>
>
> Please consider the consequences of others' attitudes. We're better
> off working together to standardize an open platform. Browser vendors
> are demanding a one-way street, from where I sit as mostly a keenly-
> interested observer. Time and again, I've watched the input from this
> group to the HTML WG be cavalierly dismissed, not to mention the input
> from the TAG, or professionals like Dr. Kay. This makes me sensitive
> to things like Julian's draft being called "useless" when it's just
> like any of the specs I read to teach myself HTTP -- specs which Julian
> played a large role in authoring, and which have resulted in my being
> able to create working, interoperable code. Including from this latest
> C-D draft, as both sender and receiver.
>
>>
>> And consider giving a little extra leeway to some people who are
>> important stakeholders, but often feel unwelcome in this group.
>>
>
> Those stakeholders need to recognize the importance of others, right
> down to lowly developers like myself who aren't standards wonks. My
> participation in this group only recently began, and my own welcome is
> up in the air, so I'd appreciate if my concerns weren't ignored by
> those they're directed at -- more like a request for common courtesy,
> than leeway.
>
> -Eric
--
Mark Nottingham http://www.mnot.net/