Re: [#259] Handling invalid Content-Dispostion headers

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/

Received on Saturday, 6 November 2010 09:53:45 UTC