Re: HTTP Extensions Framework status?

> The main thing I'd look for is not to change any of the criteria,
> but to focus on process improvements that would allow IETF working
> groups to reach conclusions more quickly.
>
> Personally, I think a small amount of Internet-based collaboration
> support for tracking issues in working groups, coupled with
> some better group focus and management would go a long way toward
> making the process more responsive.

Management/coordination without accountability is useless. However, there
is no reason why the accountability should be any different than for any
other working group so we should just use that mechanism already in place.
However, that coordination and review has to be there.

> As for HTTP extensions, I think draft-frystyk-http-extensions-03.txt
> is inadequate as an extension framework for HTTP.

That's interesting but unfortunately wrong. Larry - you didn't do your
homework:

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

> new URL scheme(s)

This has hardly anything to do with HTTP extensions and is already handled
by HTTP.

> new header

This is what you have the optional mechanism for.

> new value for old header

This is a bad idea in any case

> new MIME type for POST body

There already is a registry for this so why come up with another one?

> new return code

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

> new interpretation for old return code

Your example is solved using the optional mechanism (bad description of
problem)

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

Henrik

Received on Wednesday, 8 December 1999 01:00:02 UTC