W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

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

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 1 Nov 2010 08:06:59 -0600
To: "Eric J. Bowman" <eric@bisonsystems.net>
Cc: Adam Barth <ietf@adambarth.com>, httpbis <ietf-http-wg@w3.org>
Message-Id: <20101101080659.76cacc76.eric@bisonsystems.net>
> 
> 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.

-Eric
Received on Monday, 1 November 2010 14:07:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT