Sounds good. But making HTTP faster is somewhat less of a concern to me than making it easier to make it more robust. And the big problem in all these schemes has been how to detect that there is a speedier option and WHICH ONE TO CHOOSE. Anyone can make a 'negotiation' mechanism that allows you to choose between existing HTTP and their scheme du jour. Thats not really architecture in my view, you have to solve for the rather more general case without having code of this type if (token1 = frobble) protocol = speedy elseif (token2 = magicQ) protocol= m12 elseif (token3 = ei3ir) protocol = jeie else protocol = http This approach works only so long as you have code to support. It tends to assume we are surfing not web servicing. We have this SRV header that has some really useful mechanism to help provide reliable service. As a side benefit it also allows us to avoid the need to always use port 80. That could be an important factor in conserving IPv4 addresses We need a general purpose signalling mechanism that is DNS based and applicable to any protocol negotiation of this sort. On Thu, Nov 12, 2009 at 4:24 PM, Mark Nottingham <mnot@xxxxxxxx> wrote: > Chromium has been experimenting with speeding up HTTP using a new protocol, > SPDY. > > See: > http://blog.chromium.org/2009/11/2x-faster-web.html > http://dev.chromium.org/spdy/spdy-whitepaper > > My (personal) take: > http://www.mnot.net/blog/2009/11/13/flip > > Interesting times. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf