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

Re: HTTP Extensions Framework status?

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Tue, 7 Dec 1999 21:59:22 -0800
Message-ID: <00e701bf4141$63921160$86241eac@redmond.corp.microsoft.com>
To: "Larry Masinter" <lmm@acm.org>, <moore@cs.utk.edu>, "Josh Cohen \(Exchange\)" <joshco@exchange.microsoft.com>
Cc: "Harald Tveit Alvestrand" <Harald@alvestrand.no>, "Yaron Goland \(Exchange\)" <yarong@exchange.microsoft.com>, "'Patrik Fältström'" <paf@swip.net>, "Scott Lawrence" <lawrence@agranat.com>, <discuss@apps.ietf.org>, "Peter Ford \(Exchange\)" <peterf@exchange.microsoft.com>
> 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 GMT

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