Date: Mon, 18 Mar 1996 16:11:42 -0500 From: John C Klensin Subject: Re: About that Host: header.... To: jg@w3.org Cc: Harald.T.Alvestrand@uninett.no, ari@netscape.com, paulle@microsoft.com Jim, Two more components for some of your "disadvantages" entries: * Protocols can accumulate only a certain amount of crud -- extensions, patches, fixes -- to remedy errors in the original or for which there wasn't an adequate anticipated framework before they become too clumsy for further use, development, or accurate implementation and start relying on the robustness principle alone to keep them working. It is very much in our interest to postpone as long as possible the date on which we _must_ invent and deploy an HTTPng in order to just keep the Internet working. We accelerate that date by adding complex interactions to HTTP now and push it off by trying to make extensions as clean and minimally complexity-adding as possible. "You must use this if the format of that isn't thus-and-so" creates unneeded complexity and, given that there are other alternatives, should be avoided on that basis alone. * The extra turnarounds of a "try, and, if that fails, try something else" situation are unfortunate, but have to be considered against the backdrop of: -- Very short halflives of Web clients and servers: if we push something like this out there, it is likely to be a problem for a fairly short period. -- The growth of the Web and the Internet are such, if a new protocol model is deployed tomorrow, a year from now half the users will never has encountered the old protocol. -- Since the "fix" --upgraded software-- is known, vendors who move to the newer protocol will have a competitive advantage and those who don't will be put to a proportionate disadvantage. In today's market, that is likely to further encourage rapid deployment. On the other hand, anything that makes it less painful for an implementation to stay in place than convert will put early converters at a competitive disadvantage. I contend that we have to bite the bullet sooner or later and that, given the present growth rate and software rotation rate, doing it quickly is likely to be less painful than trying to work through a gradual transition. john