W3C home > Mailing lists > Public > ietf-discuss@w3.org > December 1998

RE: Looking for comments on the HTTP Extension draft

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 28 Dec 1998 16:52:09 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792C07@RED-MSG-59>
To: "'Ted Hardie'" <hardie@equinix.com>
Cc: frystyk@w3.org, masinter@parc.xerox.com, Chris.Newman@INNOSOFT.COM, discuss@apps.ietf.org, Josh Cohen <joshco@microsoft.com>
Words from the engineer formerly known as NASA Boy:

> <Yaron, do you dream in XML?>

Yes, but only in my nightmares. Do remind me to write up the paper I have
been thinking about on an analysis of XML performance as a protocol
transport. Scary reading, I assure you.

> If I'm willing to rev the protocol number, obviously I don't believe
> that this mechanism must be one which fits in the 1.x framework.  A
> really good extension mechanism that had to have one incompatible
> change would be fine by me.  Once this extension mechanism takes
> off, there will be no more major or minor protocol number changes,
> only extensions.  One big change to note that shift isn't that hard
> is it?  It's not as if all of the old clients out there are going
> to become extension aware anyway.
> 

Using ISAPI/NSAPI/CGI/Modules/etc we can extend existing servers (and some
proxies) with all sorts of goodies. My customers are much happier doing such
extensions then rolling out incompatible upgrades, especially to new
protocols their existing infrastructure don't support. This is why HTTP/1.1
was such an easy sell. We could piece meal roll it out. You up the major
version # and you will find you have a great design with very few customers.

> I think you saw the right problem, but I don't think your demands
> weren't quite met.  "a client MUST have somehow expressed to the
> server that it understands a particular mandatory extension before the
> server is allowed to use that extension on a response" is 
> great principle,
> and one I wish this spec followed.  The spec describes a way for the
> client to indicate it understands a particular mandatory 
> extension, but it
> doesn't *require* that the server wait for that indication; it allows
> the server to send it based on "a priori" knowledge.  As I said in
> my mail to Larry, anything outside of the protocol-defined indication
> is a guess, and if you are going to allow guessing, you have 
> some problems
> to solve that this doesn't solve.  
> 

If someone defines the FOOBAZ method and specifies that anyone using FOOBAZ
must support the foobaz extension then the server is well within its rights
to return a response, at some later point, to the same client that uses the
foobaz extension in the mandatory header. We can rewrite the previous
scenario using a header or even just using a particular transport (if you
use the TLS V10.9 encryption transport then your HTTP client MUST
support...).

So knowing that this isn't an interoperability issue we can do anything
about, I suppose I will be happy with whatever language you would like to
throw in.

> The document seems to me to imply to security folk "that if you allow
> 'GET' you ought to allow 'M-GET'.  If the authors agree with your
> interpretation, wordsmithing in the security section might fix the
> problem.  Other changes in the way the document describes methods
> might also be needed, but that would be wordsmithing rather than a
> design change.
> 

Agreed.

> Will manufacturers willingly give different URLs to different patch
> releases of a product, when the URLs are being used as *tokens* in a
> system like this?  Remember,
> "http://www.bigcompany.com/products/foo/v1" and
> "http://www.bigcompany.com/products/foo/v2" are completely different;
> there is no defined relationship and no way to presume if you do one
> you can do the other.  Especially, there is no way for a proxy to know
> whether allowing one through implies *anything* about letting the
> other through.  Hint: I have had systems in which all had the same
> product, with the same identifier, but a substantial percentage did
> not interoperate because of a patch release mis-match.  Trust the
> market all you like, but make damn sure that implementors understand
> the consequences of not doing the right way; "strongly recommended"
> doesn't say "fail to do this and die horribly, unspeakable rascal"
> to me, and I suspect it ought to.
> 

This is akin to the dll hell problems and believe me, I know it well.
Unfortunately a standard won't fix this. Still, if you just want to
wordsmith the language, we might as well. Put in whatever terrible cries of
damnation that will make you happy. BUT you can only complain if you come up
with alternate language. =)


			Yaron
Received on Monday, 28 December 1998 19:53:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:25 GMT