Re: HTTP Extensions Framework status?

> 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.

Extension declarations give you identification, very much like XML name
spaces. They don't provide any information about what is behind the
identifier. The rule is that semantics of an extension should only
change if the identifier changes as well. This is what is covered by
section 8 "Publishing an extension" which at the heart is about how
people in practice will do extensions.

You don't have to resolve all the dependencies in order to determine
whether you support an extension or not - just look at the identifier at
hand. This is equivalent of saying that it's ok to do a GET request
knowing that the document you get back may have references to things you
don't understand.

Once we solve the problem of identification (and thereby grouping) we
may be able to move on to look at higher level semantics but we have to
learn to crawl before we can walk.

> > > 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.

This is really an orthogonal issue. The URI is an identifier and may be
resolvable in many ways - or maybe not at all. In the case of using HTTP
for resolving URIs of any type, HTTP is the resolver, if you like, and
HTTP extension framework is a mechanism for extending HTTP, not the URI
space.

> > > 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.

There is no way the extension framework in any way is able to modify
what is already spec'ed and deployed in HTTP, nor should it. If you
choose to use the existing HTTP extension facilities then that is fine
and the Extension Framework doesn't in any way prevent you from doing
that.

Several of the comments on the framework are of the type: "I can get by
with existing means" . I have no objections against this what so ever.
But what is good for one if not necessarily good for everybody else. One
of the reoccuring problems with the existing extension mechanisms is
that it is hard to deploy extensions in a distributed way and even more
important, it is hard to get rid of them again. This is what the
extension framework is all about.

This is why the purpose of the extension framework is stated "to address
the tension between private agreement and public specification and to
accommodate extension of applications using HTTP clients, servers, and
proxies.". It doesn't say anything about replacing existing mechanisms.

If you think this has to be stated clearer then that's fine with me.
Maybe something like:

"The Extension Framework provides a mechanism for extending HTTP using a
certain extensibility model that is designed to work in a distributed
environment without central control. It does not disallow using any
existing HTTP extension hook instead of or in conjunction with this
mechanism."

> ??? 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.

The 510 Not Extended is a place holder where several extensions can be
placed in the header fields explaining what is needed. The problem with
a status code is that there can be only one - what if I have two
extensions that both are placed in the same message and both need a
status code? They can't do this. Instead, the extension framework uses
the only "open-ended" space in HTTP which is the header.

Therefore, don't think in terms of: "I need a 4xx HTTP status code and a
FOOBAR HTTP method" but rather: "I have an extension that defines a
FOOBAR mechanism and an error state". The extension framework allows you
to express this without conflicting with other extensions that you don't
know about.

> 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.

The new semantics is really in the header field you added and as a
header field, you just use an optional declaration.

> 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.

The current Extension Framework spec is making a very conscious
balancing act between what is needed and what you get. I agree with Roy
that it is already complex and there is no reason to make it even
harder. You can quite easily use the extension framework to implement
rfc 2324 but you have to be following the decentralized model it
provides. You can't think of it in terms of the centralized
extensibility model currently in HTTP.

Henrik

Received on Wednesday, 8 December 1999 15:09:44 UTC