The IETF process

Roy Fielding writes:
	...
 > However, I am not required to put any new proposals into the design,
 > and must not make the specification different than what the design
 > actually is when the spec is finished.
	...

 > ... In particular, I cannot be compelled to include
 > anything which has never been implemented anywhere, or for which no
 > documentation of how it was implemented is available.  This is a
 > double-edged sword -- before I can say a standards-track spec is finished,
 > I must be sure each of the features is implemented somewhere in accord
 > with the specification.  This means that in order for me to accept a
 > proposal, even when I like it, someone must implement it and verify
 > that their implementation works according to their proposed change.

For good or ill, this means that there is no direct link from
mere "customers" of HTTP to the design specification process.  If, as a
user of the protocol, one thinks a feature is necessary or something
needs improvement, it apparently doesn't make much sense to bring it
up first on http-wg, in hope of it becoming part of the standard,
without first convincing someone to build it into their system.

As a protocol "customer", this isn't very efficient, because
unless a change goes into the protocol across the board, you can't
use it.  Unless you have a relationship with someone doing
experimental server or browser development, you're out of luck.

As a server or browser developer (as opposed to researcher), there is
little motivation to build a new protocol feature into a product if it
is not part of the standard (unless you own the market...).

On the other hand, I strongly believe that people who have actually
tried to *use* a protocol to build and deploy systems that "push the
envelope" in one way or another are in the best position to say what
could use improvement, even if their proposals need work before being
included.  In fact, I think many of the issues can't even be properly
appreciated until you "get bit yourself".

So, there seems to be a bit of a catch-22 in the process you outlined.
People won't generally try implementing protocol features unless they
are already in the spec, or they have an inside track with the spec
writers, and things won't go into the spec until someone implements
them.  In short, this process could stand to be more demand-driven.

If http-wg isn't it, then what's missing is a more open forum for
actually designing the protocol before waiting for server and browser
implementers to cast it in code. I understand the need to see things
implemented before they can be standardized on, but putting the
existence of an implementation first effectively locks out those in
the HTTP *user* community who don't happen to also be developing
servers or browsers.

None of these comments should be construed to detract from the good
work that the protocol designers or spec authors have done.

Shel Kaphan

Received on Monday, 25 September 1995 17:08:15 UTC