It seems there is a technical maturity curve for people attempting to
extend the web (I've personally been through each of the following stages):
1. Gee, let's tack something onto the end of a URL (e.g.,
http://foo.bar.com/index.html;checkout ) The bonus: works with existing
browsers, can be fielded immediately. The drawback: hopelessly confuses
the URI and HTTP abstractions -- for example, what if I do a PUT to the URI
above? Do I perform a checkout, or a PUT? ("Well, on my server...")
Escape criteria from this level: Realizing a URI is opaque, period.
2. Gee, let's reinvent RPC and stuff it through POST (affectionately known
as "rolling your own RPC"). Look at the early WebDAV drafts for a
particularly egregious example. The bonus: has the nice property of
tunneling through firewalls, without resorting to evil URI hacks. The
drawback: people set up firewalls for a reason, administrators don't like
it when POST is used to circumvent their security. Also, how do you
perform access control for the procedures in the POST RPC, especially if
there are multiple RPC schemes being rammed through POST? At the very
least, it horribly complicates any access control model. Escape criteria
from this level: Realization that HTTP already provides RPC semantics, OR a
standard backed by a committed coalition which doesn't have to deal with
access control or site security.
3. Gee, let's define a bunch of new HTTP methods. The current WebDAV draft
follows this approach. This appears to be the best approach while staying
within the current web framework. The bonus: extends HTTP the way it was
meant to be extended (adding methods and headers), doesn't have as many
access control bummers, and doesn't create as many weird interactions with
the existing HTTP data model. The drawback: HTTP doesn't handle
dual-object methods well (e.g., COPY, MOVE), and doesn't handle
hierarchy-acting methods well (e.g., COPY this resource tree from A to B).
HTTP also doesn't handle potentially unlimited length parameters (e.g.
headers) well. Escape criteria from this level: an RFC, working on next
generation infrastructure (or, in my case, a Ph.D. :-)
4. Gee, let's redesign HTTP from scratch and get it right this time. The
next generation web work is an example of this. The bonus: don't have to
deal with all of the weird interactions and features left over from HTTP,
WebDAV, IPP, and others. The drawback: with 1.8 million web servers on the
Internet, and more being added every day, the existing infrastrcture is, if
anything, becoming more locked-in (The good news is, the Web is here to
stay. The bad news is, the Web is here to stay.) Escape criteria: a new
infrastructure which is fielded in 2005, or realizing there is more money
to be made selling sugar water than software, and going to work for Coke.
:-)
- Jim
On Tuesday, February 17, 1998 4:51 AM, Dan Kohn [SMTP:dan@teledesic.com]
wrote:
> OK, who's right here. It can't be the MSFT folks can it.
>
> - dan
>
> P.S. Well, I just passed 1000 messages behind, so I think I better
> flush the buffers and start trying to catch up on new threads. I'm
> giving two speeches in Tokyo this week, and am going to see if I can get
> into any events at Nagano this weekend.
>
> > -----Original Message-----
> > From: Internet-Drafts@ns.ietf.org [SMTP:Internet-Drafts@ns.ietf.org]
> > Sent: Tuesday, February 17, 1998 4:10 AM
> > To: IETF-Announce@ns.ietf.org
> > Subject: I-D ACTION:draft-cohen-http-ext-postal-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > Title : Don't Go Postal - An argument against
> > improperly overloading the HTTP POST Method
> > Author(s) : J. Cohen et al.
> > Filename : draft-cohen-http-ext-postal-00.txt
> > Pages :
> > Date : 16-Feb-98
> >
> > As time goes on, more and more groups are extending HTTP's
> > functionality. In using HTTP, a decision is made to either use a new
> > method name for new functionality or to overload an existing one such
> > as POST. Our belief is that in most cases, overloading existing
> > method names, with POST as a particularly troublesome example, is a
> > bad idea. We, as a group of individuals, suggest that the default
> > requirement for new HTTP functionality must be to create a new method
> > name.
> >
> > Internet-Drafts are available by anonymous FTP. Login with the
> > username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-cohen-http-ext-postal-00.txt".
> > A URL for the Internet-Draft is:
> > ftp://ftp.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt
> >
> > Internet-Drafts directories are located at:
> >
> > Africa: ftp.is.co.za
> >
> > Europe: ftp.nordu.net
> > ftp.nis.garr.it
> >
> > Pacific Rim: munnari.oz.au
> >
> > US East Coast: ds.internic.net
> >
> > US West Coast: ftp.isi.edu
> >
> > Internet-Drafts are also available by mail.
> >
> > Send a message to: mailserv@ds.internic.net. In the body type:
> > "FILE /internet-drafts/draft-cohen-http-ext-postal-00.txt".
> >
> > NOTE: The mail server at ds.internic.net can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant mail
> > readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> << Message: Untitled Attachment >>