Two related things going on here, both matter ...
From: "Gregory P. Smith" <[EMAIL PROTECTED]>
Furthermore, I think you're overglorifying the IETF protocol stack. I
mean,
if it were truly as great as you say it is, why do all the most
innovative
products avoid it like the plague? Perhaps the problem lies closer to
home
than they'd like to admit.
Yep.
The HTTP/1.0 RFC1945 is dated May 1996 and is based on existing widely
deployed implementations already in use for several years.
RFC 1945 is Informational, because it describes a protocol design done
outside the IETF, so is not standards-track. It was published as an RFC as
part of the effort to bring HTTP specification work into the IETF.
By that point it was too late. The HTTP/1.1 standard was a best
effort attempt to address the major scaling and performance and
ill-defined issues that HTTP/1.0 was suffering from because for better
or worse (definately worse) the HTTP protocol "design" was going to be
with us forever.
HTTP/1.1 was standards-track IETF work, but was constrained to be
backward-compatible with HTTP/1.0. As you said, "by that point, it was too
late". There was an IETF HTTP-NG effort that never chartered as a working
group, probably because it tried to do WAY too much in one shot (a Corba-ish
RPC mechanism was only one of three components, obviously we can be finished
by lunch).
I see the point that reusing HTTP always sounds like it could make
deployment easier but since a p2p protocol necessarily requires
additional software for a node to participate in the first place there
is no major difference in having such software handle its own
bind/listen/accept/connect socket calls vs having it interface thru a
different API to a random web server potentially not designed for its
long-term bidirectional communications.
The IETF has also been pretty horsey about people using HTTP/1.1 as the IP
for the 21st century (people have referred to HTTP within my hearing as "the
new wasp waist of the Internet", and it's just not - see RFC 3205, "On the
use of HTTP as a Substrate", as an excellent example of the genre).
Unfortunately, HTTP/1.1 as a universal substrate is one of those ideas that
fails in theory but not in practice - actually, it does fail in practice,
but not quite often enough to discourage people from trying to use it that
way...
For a list of problems that need to be solved in one way or another, take a
look at "On the Design of Application Protocols", RFC 3117. I don't own
stock in BEEP, but Marshall Rose did a nice job of explaining what they were
trying to do with BEEP instead of HTTP as a substrate...
Hope this is helpful. Have a nice day.
Spencer
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
