W3C home > Mailing lists > Public > ietf-discuss@w3.org > November 2001

Re: Why is IETF hostile to reusable technologies?

From: Roy T. Fielding <fielding@ebuilt.com>
Date: Wed, 28 Nov 2001 15:04:22 -0800
To: Jim Gettys <jg@pa.dec.com>
Cc: Keith Moore <moore@cs.utk.edu>, Discuss Apps <discuss@apps.ietf.org>
Message-ID: <20011128150422.B1986@waka.ebuilt.net>
On Wed, Nov 28, 2001 at 12:45:55PM -0800, Jim Gettys wrote:
> You missed at least one:
> 6. Many of us old-farts are strong, opinioned know-it-alls who think that
> what we've done applies to everything, and that if the other guy just
> understood things as well as we did, they'd do it our way, whether it
> be X, or MIME, or HTTP, or (fill in you favorite protocol you are expert
> at here)....  It is a rare bird who has dealt with more than one application
> protocol in detail, much less one built for a relatively wide range of
> applications to use.

7. The rest of us old-farts with strong opinions are too busy wasting our time
explaining to others why our "universal" protocol was never intended to be
"universal" in the first place, since there is no single architecture that
is best, let alone suitable, for all applications.

> The young guys with a problem don't necessarily get heard, unless your
> job is to listen to lots of different people building applications.
> And those people don't go to the IETF right now.

The IETF meetings are too expensive for me to attend, even now that I am
out of grad school.  I've been saying that for ages.  The IETF is getting
exactly what it asks for -- attendance by folks who are either independently
wealthy or whose primary purpose is to attend standards meetings for later
product marketing.

I think that the meetings should be cancelled altogether and more effort
be put on collaborative specification techniques that emphasize maintaining
a database of specs+issues+errata at a centralized location.  This is one
of the few areas where I think XML can be applied in a very effective
manner and end most of the hassles associated with being a spec author.
But stuff like that doesn't get done simply by wishing it.

> More seriously is to elaborate your .4: to build such a protocol framework, 
> you need participation (at least at some level) horizonally across the 
> IETF, when it is vertically organized.

Yes.  Forcing the HTTP security issues to be owned by a separate WG under
the Security Area effectively killed any useful forms of HTTP authentication
until that forum was dead and work moved back to the working group that had
the incentive to get it done in a timely manner.  Completely opposite to
the intentions of the IESG at the time, but inevitable given the way the
IETF is structured.

> And I think development of a protocol framework would need to be mostly 
> outside the IETF until a pretty concrete prototype and running code had 
> been produced, to avoid the other problems you note.  Arguably, this is 
> already happening, in the XML community.  But as things are currently
> running, it will be too late for the IETF to influence the outcome,
> as far as I can tell.

I don't think that is a fair example.  The work that you are referring to
was brought to the IETF as DCOM using an inefficient syntax.  It sucked,
and the IETF shouldn't be expected to provide a forum for defining
architectures that are inherently bad design for the Internet.  So, that
work migrated to the W3C's XML protocol group.  The design still sucks,
but at least it is being specified within its realm of applicability.

I don't know of any good application protocols that were created within
the IETF process -- just refined within that process.  I don't believe a
committee can do good protocol design, no matter how smart the people in
that committee, because application protocols need to be designed to be
efficient for one application (not all of the applications that may be
within the visions of multiple engineers).  What the IETF does well is
critique designs and identify discrepancies between implementation and
what is supposed to be a specification for interoperability.

My current protocol work is being done in private because I can't deal
with the cacophany of questions about "what does this part mean" when I
know the specification is incomplete.  It will only be brought to the
IETF when I think the specification answers more questions than it raises,
and it is at that point that people with more specialized knowledge of
networking than myself can point out all of the places where I made mistakes
or simply failed to take into account one thing or another.  That is how
BEEP was specified, and I think that was an effective use of the process
without diminishing the IETF's ability to influence the protocol.

Received on Wednesday, 28 November 2001 18:09:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC