Re: short names for headers

> Header compression has been in TCP for quite a while, so I don't think
> that the topic is "research". It is true that good careful engineering
> will be required, but that's different that research.

HTTP is not TCP.  Just about everything ever planned for HTTP has been
done before in something else.  The research question is what happens
when you add that functionality to the existing HTTP system.  Does it work
as intended? Does the improvement justify the added complexity?

Those are research questions (and yes, careful engineering does involve
research whenever the exact same thing has not been done before).  I like
research (obviously) -- I just don't like research in the name of
standardization.

> Why don't you wait until the draft comes out? I promised it by the end
> of the month, and it is well under way. If it is so hard to do, it
> should be obvious at that point. A draft will also enable experimental
> implementations, to gauge how much improvement it might make.

That does not justify a milestone on the WG charter -- we can do all that
outside the committee structure.

> If the improvement looks good, we would be very interested in deploying
> such a scheme fairly quickly.

You can deploy such a scheme any time you want -- you just can't call it
HTTP.  Note that the Upgrade header field exists for that very purpose.
Once you have answered the research questions, a specification of it can
start through the standards cycle, along with any other performance
improvements at an equivalent level of maturity.

> Even if HTTP/2.x could be finished within a year, deployment will take
> much longer becuase of the installed base of 1.x. But HTTP/2.x seems
> much more like research than any 1.x enhancement under discussion. 

HTTP/2.0 (consisting of just HTTP/1.1 in a tokenized form and encapsulated
in a multiplexed stream) can be done in six months.  We already have
specifications (albeit incomplete) for both, and more than one test
implementation showing primary gains from multiplexing.  As such, it has
the exact same risk factor, cost, and implementation time as any incompatible
change to the protocol.  The difference is in the payoff.

Even so, I would not have this WG try to standardize HTTP/2.0 -- it is
still research.  In fact, I would encourage any vendor to begin work
on it immediately, since 99% of the effort is just enabling the internals
of the application (client or server) to deal with any form of a
multiplexed, persistent connection; once that is done, converting it to
the final "standard" form is easy.

> Rapid incremental evolution, as opposed to revolution, has usually been
> more successful at getting technology to the user quickly. It's just
> part of the sociology of large distributed systems.

Allow me to refresh people's memory.  A group of people involved in the
development of the Web met at the Chicago WWW2 conference (October 94,
before this WG existed) to discuss the future of HTTP and the plan of
attack for improving its security, performance, etc.  Henrik and I
volunteered to rewrite the HTTP specification, since it was already a
year out-of-date and it was very clear that new people entering the Web
project did not understand the full capabilities of the protocol, and we
needed a shared understanding in order to avoid breaking its good qualities
when advanced to the next generation.  Simon Spero and Dave Raggett
(with Andy Norman) volunteered to work on a binary version of HTTP
[I can't remember if it included multiplexing at that time or not -- I do
know multiplexing was present soon afterword].  A few months later, we
put together the HTTP BOF at San Jose which began the HTTP-WG.

Small improvements in the protocol were to be done in HTTP/1.x in parallel
with the large performance change in HTTPng, for precisely the reason you
give: Rapid incremental evolution.  The difference, however, is that
evolution within the HTTP/1.x family would retain the existing message
format and field names to maximize compatibility (reducing complexity
of the implementations) and maintain a "safe harbor" for those unable or
unwilling to sacrifice simplicity for speed.

Adding persistent connections was one of those small improvements -- removing
the dependence on a single transaction per TCP connection was a basic step
toward supporting multi-layered proxy configurations efficiently and a
better understanding of long-lived, multiplexed connections.  And yet, it
took over six months of prodding before we could get people to experiment
with it -- before we could do the basic tests necessary to determine if
it was even worthwhile adding to the proposed standard.  In hindsight, I now
regret that we even bothered to do that much -- it alone added over eight
months to the delay in getting HTTP/1.1 finished (and, BTW, I was mighty
pissed-off when the same person who insisted on it being in HTTP/1.1 later
complained about how long it took to get draft 00 to the WG).

Almost two years later, the performance problems of HTTP remain the same.
So does the solution. The only thing that is lacking is the PEOPLE dedicated
to writing a complete specification of the solution that we already know
will work.  This doesn't have to happen inside the WG -- it just has to
happen.

In the mean time, the notion that anyone can write a complete specification
of something that hasn't been tried before, and then get this WG to agree
that adding statefulness to an otherwise stateless protocol is a good thing,
all in less than 4 months, is utterly ludicrous.  Attempting to do that
within this WG will only starve-out the other products of the WG, such as
a real specification of content negotiation, because people like me will
have to spend hours generating long-winded messages just to explain why
it is the wrong way to proceed instead of doing something that would
contribute toward accomplishing our other goals.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Friday, 12 July 1996 05:42:42 UTC