RE: Looking for comments on the HTTP Extension draft

Given that everything you say is motherhood and apple pie there isn't much
for me to respond to. You are right, people shouldn't do bad things. You are
also right that we should think carefully about what we do. But outside of
the issues I have already pointed out, which really haven't been part of
this conversation, I haven't heard anything to convince me that this
standard is seriously broken. But of course, that is just my opinion.

			Yaron

> -----Original Message-----
> From: Ted Hardie [mailto:hardie@equinix.com]
> Sent: Monday, December 28, 1998 5:46 PM
> To: Yaron Goland
> Cc: hardie@equinix.com; frystyk@w3.org; masinter@parc.xerox.com;
> Chris.Newman@INNOSOFT.COM; discuss@apps.ietf.org; Josh Cohen
> Subject: Re: Looking for comments on the HTTP Extension draft
> 
> 
> Yaron,
> 
> Needless to say, I don't really want to argue for incompatible
> upgrades.  I do want us to be very, very sure that we balance
> extensibility and interoperability.  My first message and my responses
> since are my feeble attempts to delineate where I believe this
> proposal runs the risk of sacrificing interoperability, by the use of
> certain behaviors which are either not current practice in HTTP 1.x or
> not current expectations for URLs.
> 
> Revving the protocol number makes sure everybody knows about the new
> rules.  As I've said before, I don't think it is the only possible way
> to ensure that.  I don't really even think it's the best.  Thinking
> about it in those terms, though, may be what it takes to get us to the
> right design choices.
> 
> On the issue of "a priori" knowledge, this design allows a client to
> send a vanilla request like:
> 
> GET /someresource.foo HTTP/1.1
> Host: www.foobar.nl
> User-Agent: Diva 98.2
> 
> and have the server derive from some information (which URL was
> chosen, the User-Agent, whatever) that the client *could* support an
> extended response.  That "a priori" knowledge is based on assumptions
> (that the client has not turned off the capability, that the firewall
> isn't configure to stop that, that the URL wasn't typed in from a
> friend's bookmarks, whatever).  If those assumptions are wrong, a
> response is sent that the client cannot handle properly and may not be
> able to handle at all.  In the extensible world that has been
> described, we have to acknowledge that capabilities change over
> time--sometimes resulting in the removal of capabilities.  You can't
> even rely on my previously stated support, as I may support FOOBAZ
> today and give it up tomorrow when it interferes with my
> mission-critical BARFUZZ extension.  Our lives and the lives of our
> customers would be easier if we stuck to the idea you set forth and
> only used FOOBAZ in a response when the client volunteered that it was
> willing to use it in the request.
> 
> On the issue of multiple versions behind a single URL, this is,
> indeed, like the dll hell you describe.  If we cannot solve 
> the problem
> in the standard, we can at least point others where that road leads so
> that they don't take us down it too often.
> 
> 		regards,
> 			Ted Hardie
> 			hardie@equinix.com
> 
>

Received on Monday, 28 December 1998 23:34:04 UTC