Dean Swift was, of course, poking savage fun at the arcane and obstructive bureaucratic protocols of 17th century English government. In today's world of computer networking, we have our own obsession with protocols, and they, too, have everything to do with communication or the lack of it. Luckily, our protocols, while frequently arcane, are clearly defined and, if scrupulously observed, reliably permit rather than obstruct communication.

The protocols which bind together the Internet are colloquially known as TCP/IP and more formally known as the Internet Protocol Suite. The IPS consists of four layers, (as opposed to the more familiar seven layers of the ISO model,) respectively the Physical Link, Network, Transport and Application layers. Almost all Internet services exist at the topmost or Application layer, and that's true of the glue that binds together the many strands of the World Wide Web, the HyperText Transport Protocol or HTTP.

The original HTTP spec (http://www.w3.org/hypertext/WWW/Protocols/HTTP/Asimplemented.html), version 0.9, was defined in 1989 at CERN (http://www.cern.ch/), the European Particle Physics Laboratory, by Tim Berners-Lee (timbl@w3.org), the man who invented the World Wide Web. Version 1.0, Draft 04, the current spec, (http://www.w3.org/hypertext/WWW/Protocols/HTTP1.0/draft-ietf-http-v10-spec-04.html), is in the process of of being frozen as a Best Current Practices draft and a newer, version 1.1 specification is being prepared by Tim Berners-Lee, Roy T. Fielding (fielding@ics.uci.edu) and Henrik Frystyk Nielsen (frystyk@w3.org), who are also responsible for the version 1.0 spec.

HTTP commands are called "methods". Version 0.9 allows browsers to initiate a dialogue with a server using only the GET method, which tells the server to retrieve whatever data is identified by the specified Universal Resource Identifier (a URI can be either the familiar Universal Resource Locator or a Universal Resource Name). If the URI refers to a Common Gateway Interface (CGI) script, the server returns the output of that script, rather than the script itself. Version 1.0 added support for the PUT method, which allows the browser to request a new document be created, (using either the POST or REPLY methods) as well as the less-common HEAD, (returns only HTML header information, sans body content), CHECKIN/CHECKOUT, (document file lock/unlock requests), LINK/UNLINK (creates or destroys hyperlinks to the specified object) and other, seldom-implemented methods.

The "well-known" IP port for HTTP is port 80, but other ports can be used. HTTP is based on a client/server model, where the client intitiates a connection with a request to the server and the server then responds to the client's request. The client request consists of a request method, a URI and a protocol version identifier, followed by a message containing request modifiers, (a set of fields which specify the desired or required form of and/or conditions for the requested response,) possible client data (email ID of the user and the user agent--browser--ID and version) and, occasionally, some body content. The server responds with a status line which includes a protocol version identifier and a success or error code, followed by a message containing fields which provide server information and/or metainformation about the requested entity. Those messages are followed by any requested body content. Once the server's response has been transmitted, the session is closed, and, of course, any loss of connection during the session also closes it.

The format of the messages from both client and server is akin to the Multpurpose Internet Mail Extensions specification in RFC 1521 (http://www.cis.ohio-state.edu/htbin/rfc/rfc1521.html) and the more recent RFC 1590 update (http://www.cis.ohio-state.edu/htbin/rfc/rfc1590.html), except that additional types beyond those in the MIME spec may be employed. In addition to HTTP, the World Wide Web also embraces the File Transfer Protocol (FTP) as specified in RFC 959, Network News Transfer Protocol (NNTP) as specified in RFC 977, Gopher and the z39.50 protocol (which allows Web clients to directly access Wide Area Information Service servers).

The current version of HTTP treats each request/response exchange between client and server as a separate session and the TCP/IP connection between them is closed at the conclusion of each such session. This model generates considerable overhead when a client needs to make multiple requests of a single server, since each such request is treated as a separate session. Just as with the Internet Protocol Suite itself, the evolving requirements of the Web have generated a need for a next-generation HTTP specification which will overcome some of the performance problems of the current version. This so-called HTTP-NG specification (http://www.w3.org/hypertext/WWW/Protocols/HTTP-NG/http-ng-status.html), championed by Simon Spiero (ses@unc.edu) of Enterprise Integration Technologies, is currently at the proof-of-concept stage.

You can join the HTTP Working Group mailing list by sending mail to http-wg-request@cuckoo.hpl.hp.com (leave the Subject: line blank. The body should consist only of the word SUBSCRIBE). You can also browse the HTTP working group mail list archives at http://www.ics.uci.edu/pub/ietf/http/hypermail/ without having to subscribe to the list.