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 Tuesday, 7 December 1999 19:21:40 UTC