Re: HTTP Extensions Framework status?

In my previous mails, I deliberately did not discuss whether Experimental
is right or not right for the Extension Framework as I don't think this is
an interesting issue (especially as Experimental doesn't preclude Proposed
later on).

Whether extensions using the framework are solid or not is also besides
the point. The whole purpose of the Extension Framework is in fact to
allow people to be able to experiment with distributed extensions in an
orderly manner without requireing the extensions to be fully baked and be
able to transition from experiment to solid extension over time.

As Roy points out, we need experience with how managed distributed
extensibility can work but the problem has been we didn't have a stable
reference to the spec because it has an unknown status, namely the
twilight zone between last call and publication.

This twilight zone is what I am unhappy about and I would like to see
changed. It is not hard to see from the current discussion that there are
architectural issues involved as well as straight forward work load
problems. This is fine but I don't think these issues should be argued
with "lack of wide spread support" kind of arguments (as these are always
relative). Nor should the process black holes be used as arguments. I

The way this is normally solved in working groups is that "if you don't
agree, go write your own draft". There has been no alternative
extensibility draft for HTTP than what eventually led to the Extension
Framework.

The proposal I hava for a review/discussion working group was intended as
a mechanism to ensure that architectural concerns are being addressed in
an accountable manner. It fully works within the current process so no new
process is needed. It is not intended specifically for HTTP although I
think it would be useful. I for one is not happy about the tendency to
copy the HTTP spec and use it word for word in other protocols left and
right.

Henrik Frystyk Nielsen,
mailto:frystyk@microsoft.com

----- Original Message -----
From: "Keith Moore" <moore@cs.utk.edu>
To: "Josh Cohen (Exchange)" <joshco@exchange.microsoft.com>
Cc: "Keith Moore" <moore@cs.utk.edu>; "Henrik Frystyk Nielsen"
<frystyk@microsoft.com>; <hardie@equinix.com>; """Yaron Goland
(Exchange)""" <yarong@exchange.microsoft.com>; "'Patrik Faltstrom'"
<paf@swip.net>; "'Harald Tveit Alvestrand'" <Harald@Alvestrand.no>; "Scott
Lawrence" <lawrence@agranat.com>; <discuss@apps.ietf.org>; """Peter Ford
(Exchange)""" <peterf@exchange.microsoft.com>
Sent: Tuesday 07 December, 1999 16:10
Subject: Re: HTTP Extensions Framework status?


> > And that is the key issue which is, IMHO, the root of the problem.
> > Going back to what henrik said, its difficult to be in the position
> > of being an open forum where vendors can create interoperable
standards
> > as well as being an architectural demigod. (for lack of a better word)
>
> even open fora have limited resources that need to be managed
> and  there is a balance to be struck between letting every working
> group go off in its own direction  (no matter what the cost
> or how much it conflicts with other groups) and providing direction
> from above (leaving direction-setting in the hands of a few
> people with limited resources and imperfect vision)
>
> nobody is an architectural demigod.  if there had been solid
> community support for the http extension framework it would
> have gone to proposed standard.    if there is solid support
> in the future it can still go forward, but at this point it
> is not at all clear that there is solid support for extending
> http at all, much less via the proposed mechanisms.
>
> > I am not saying I have the answer, but I dont know if its right that
> > the IETF should say "You must not expand the scope of HTTP".
>
> the IETF is the entire community of participants.  but the 'leaders'
> of that community have to be careful to not misrepresent the
> consensus of that community by mislabelling things as proposed
> when they don't have the necessary community support.
>
> > If I want
> > to represent, lets say, my email store as a web server (with HTTP and
DAV)
> > and I want to use it as my client mail protocol, then I should be able
to.
>
> you can do whatever you want, but don't expect IETF to endorse it
> just because you do it
>
> > If other vendors wish to do the same, and we want to do it in an
> > interoperable  way, then the IETF should provide the forum to do so.
>
> if IETF were to adopt that logic, it would end up wasting resources
> on every hairbrained scheme that any particular set of vendors came up
> with.  it would be a self-induced denial-of-service attack.
>
> >  As an outsider, I feel as if the W3c has delegated the protocol work
> > of HTTP to the IETF to avoid overlapping work.  IETF does protocols.
> > If the IETF is simply taking HTTP and keeping it locked up in a cage
> > in the basement, then it is not holding up its end of the bargain.
>
> HTTP is not in a cage, but it is abundantly clear that HTTP is
> optimized for web-page access and that it is  pessimized
> for many other purposes - and the notion that one should
> try to extend HTTP for random other purposes is one that
> has met with skepticism and some opposition.
>
> remember the t-shirt with the hammers?  why do you think one
> of them was labelled HTTP?
>
> > As a result, IMHO, its stifling (my interpretation) of timbl's view of
> > the web.
>
> nobody is an architectural demigod.
>
> > Every document, email message,buddy list, etc is a resource
> > with a URL and can be manipulated by web transport protocols, a la
HTTP.
>
> the second part doesn't follow from the first.  URL notation is
> highly useful but HTTP is ill-suited for transport of many of
> the things that one would use URLs for.
>

Received on Wednesday, 8 December 1999 00:44:44 UTC