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

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.


Received on Saturday, 6 November 2010 08:51:50 UTC