Re: Comments on draft-ietf-httpbis-content-disp

On Mon, Nov 1, 2010 at 7:06 AM, Eric J. Bowman <eric@bisonsystems.net> wrote:
>> I vote for 3).
>
> Of course I don't have a vote, but at least in this WG I have a say,
> whereas there appears to be no point in attempting to have any say in
> the HTML WG.  I think I'm speaking for a lot of developers, though,
> with my opposition to the entire notion of unapproachable spec
> authoring.  And in hoping that IETF doesn't follow w3c down this
> incomprehensible authoring path.
>
> Aside from a brief sabbatical, I've been a jobbing Web developer since
> 1994.  When I learned HTML in late 1993, I had a 2400 baud Compuserve
> account, which I used to download the Mosaic beta so I could get
> started, even without HTTP or even IP.  I also downloaded lots of RFCs
> from the Internet to my Compuserve e-mail, this was how I taught myself
> the ISP business, leasing T1s through the Colorado Internet Cooperative
> Association as member #30 (anyone who knows Barb from USENIX can check
> my bona-fides, there are other ways as well).
>
> Until switching to New York Internet in 2003, I was my own webhost,
> having been in that business until 2000.  Since then, I've been pursuing
> my own ends at my own speed, but I do still develop and maintain a few
> commercial websites, and pick up plenty of consulting through word-of-
> mouth.  If you know where to look, you can see that I've interacted with
> hundreds of jobbing developers over the years, and that's just what's
> public.  I consider myself more business-oriented than technical, so I
> also interact with entrepreneurs and business-incubator types, and have
> done many quick-fixes to websites in that context as well.
>
> What I've been teaching other developers for many years now, is the
> Zeldman and Meyer books, and King's "Speed Up Your Site," all of which
> are oriented around following generally well-written, approachable
> standards which are comprehensible to the average developer.  My
> personal experience with those standards, as well as plenty of other
> RFCs, has been to watch the Internet and the Web flourish as a result.
> No stronger proof-of-concept is to be found for how RFCs are drafted,
> certainly there is no track record of successful protocols defined as
> bitwise parsing models with strict component conformance requirements.
>
> I'm not opposed to change in general, but I am opposed to specifically
> changing the way specs are written to make them both incomprehensible,
> as well as unapproachable to the point where I won't be able to teach
> anyone what they say, or convince anyone to follow them instead of just
> hacking together something that works.  My opposition to Adam's
> proposed changes to HTTP should be considered a plea to the IETF from
> down here in the trenches, not to change what's been proven not only to
> work, but also to be teachable to the average jobbing developer.
>
> I know of few developers who comprehend how HTML 5 and Web Sockets are
> drafted, and even fewer who support drafting specs in such fashion
> (which, as I see it, is exactly what's being proposed for HTTP, starting
> with C-D).  It took enough effort over the years, evangelizing the
> Zeldman and Meyer books, to get folks to even read the damn specs --
> but read them, they did.  Had those specs been incomprehensible to the
> point of being unapproachable to the average developer, this effort
> would've failed, and I doubt we'd have the interoperability we see
> between browsers today, as a result of everyday developers filing bug
> reports against browsers when they've deviated from those specs.
> Browser vendors are a little too quick to pat themselves on the back
> for their ACID-3 compliance, without crediting their users' ability to
> understand the same specs and pressure them to comply, if you ask me.
>
> Defining custom parsing models on a header-by-header basis for the sake
> of "interoperability" is, IMO, a logical fallacy.  Please don't take
> HTTP down this path, it must be understood by a far wider audience than
> just those who implement browsers, or even servers.  Be clear about how
> to conform, instead of authoring volumes about how to deal with non-
> conformity.  HTTP is a big-enough spec as it is.  Don't turn it into
> something I can barely comprehend, and couldn't possibly teach.  The
> Web succeeded because it *didn't* require a degree in Computer Science
> to decipher the specs.

It's clear from this discussion that you're most familiar with the
concerns of server operators, which I imagine is the case for most
participants in this working group.  I appreciate that server
operators desire specifications that can read by a large number of
people because there are a large number of server operators.  I'm not
requesting that any of that information in the document be removed or
have its presentation altered.  I'm requesting that the document
either clarify that it is intended for that specific audience or that
more information be added to the document so that it is useful to
another audience.

For example, the approach we took in the cookie spec was to have two
descriptions of the protocol, one for server operators and one for
user agent implementors.  The description for server operators is akin
to what you see in this document and in many IETF documents, whereas
the description for user agent implementors contains all the
information you need to actually implement a user agent.  I'd expect
someone such as yourself and those you teach to be interested in the
first description, which I hope is approachable.  The second
description, however, is very useful for the handful people in the
world who need to implement cookies in browser user agents.

We are perfectly capable, of course, of ignoring the IETF and forming
our own standards body to write specifications of HTTP,
Content-Disposition, URLs, etc, that meet our needs, as you suggest.
There are certainly folks who would prefer that we went down that
road.  However, I'd rather we were more engaged in the IETF process,
but that means influencing the IETF to produce documents that are
useful to us, which is the goal of my previous message.

Adam

Received on Monday, 1 November 2010 18:05:36 UTC