RE: HTTP Extensions Framework status?

> > RFC 2324 uses the following kinds of HTTP extensions:
> >
> > new method
>
> This is what you have the mandatory mechanism for. Think of M- as a macro
> facility.

But the problem is that it just pushes the complexity one level down.
The important step in the process:

   2.  Examine all extensions identified in 1) and determine if they
       are supported for this message. If not, respond with a 510 (Not
       Extended) status-code (see section 7);

is non-determinite. There is no effective way to compute whether extensions
"are supported" or not, because extensions have extensions, and the
extensions to the extension mechanisms don't have an extension mechanism.

So you can have a mandatory header that requires the recipient to
have implemented the "copyright" feature, but the "copyright" feature
itself evolves with uncontrolled complexity; there is no leverage
in ever renaming the features any more than there was in renaming
the methods.

> > new URL scheme(s)
>
> This has hardly anything to do with HTTP extensions and is already handled
> by HTTP.

But new URLs and new URL schemes are a fine way of extending web
applications that don't require any kind of changes to HTTP.
After all, the use of new URLs are the only mandatory end-to-end
extension mechanism that is uniformly deployed.

> > new header
>
> This is what you have the optional mechanism for.
>
> > new value for old header
>
> This is a bad idea in any case

Oh, surely not. There has to be some kind of extensibility mechanism
for the value space of each HTTP header. In most cases, it is some
kind of registry, but don't you need the same mechanisms for mandatory
and optional for things like TRANSFER-ENCODING?  frystyk-http-extensions
doesn't have much to say about these kinds of extensions.

> > new MIME type for POST body
>
> There already is a registry for this so why come up with another one?

The MIME type of a POST body is also a mandatory extensibility
mechanism, although I imagine it's not widely implemented. But
your document purports to cover how HTTP can be extended, and it
doesn't address this possibility.


> > new return code
>
> This is what you have 510 status code is for. Think of 510 as a macro
> facility.

??? 510 Not Extended doesn't give you a way of adding new status
codes. The extension mechanism seems to be only one way; the client
can request an extension, but the server can't return anything
new unless asked.

> > new interpretation for old return code
>
> Your example is solved using the optional mechanism (bad description of
> problem)


There is no mechanism laid out in your draft for reuse of an
old return code for a new purpose, or for defining new return
codes. I don't see how the "optional" mechanism applies.

> > Of these, frystyk-http-extension only covers a few,
> > and in a haphazard way.
>
> Come on, Larry - don't be silly. Stick to constructive arguments.

The argument is that the extensibility mechanism is on the one
hand too complicated and on the other, insufficient to deal with
many of the kinds of extensibility that people want. The silly
examples in RFC 2324 were based on real proposals for HTTP extensions.

Larry

Received on Wednesday, 8 December 1999 02:05:28 UTC