| Finally, in late 1996, vendors of many of these noninteroperable tools managed to get together and launch a concerted effort to develop a joint standard. Their desire was to eventually be able to use any Web or office productivity authoring tool for remote authoring on any Web server. To make this goal a reality, convergence on a single protocol was needed. One possibility was to pick one of the existing protocols, give it a solid specification, resolve any outstanding issues, and then declare that protocol the Web authoring standard. However, political and technical obstacles combined to make this approach undesirable for each pre-existing solution. If an existing proprietary protocol were used, it would provide significant advantages to the company owning the protocol. It would also require that the company relinquish its intellectual property rights over the protocol, since only an open standard would achieve broad interoperability. Since 1996 was the height of the war over browser market share, there was no way Microsoft would agree to use a Netscape standard, or vice versa. From a technical perspective, existing protocols were a poor choice anyway. The next sections analyze each of these protocols to show why. 2.3.1 FrontPage Server Extensions FPSE add FrontPage authoring capability to an existing Web server [FrontPage02]. The extensions accept POST requests to do operations that can't normally be done in HTTP, such as setting permissions and configuring WebBots. There are a number of problems with FPSE as a standard protocol, although it's evidently successful as a Windows solution. Protocol operations are tightly tied to FrontPage features. For example, there are operations to apply a theme (a common look and feel for a Web site) and to list which code libraries are currently in use on the server side. Some operations did not generalize well to other authoring tools. However, part of the reason that FrontPage continues to use FPSE is because WebDAV does not provide these operations. FrontPage computes and verifies links when changes are made. Not all Web authoring applications interoperate well with this feature, and it is time-consuming for the server. The protocol uses the POST method with a body containing commands to be executed on the server. POST is used even to upload file bodies, an operation for which HTTP PUT already exists. There is opposition to the use of POST to "tunnel" arbitrary commands to the server as FrontPage does (see the sidebar, Why Not Use POST?). FrontPage can grant authoring privileges to a specific directory but not to a specific file. FrontPage was designed more for Web site development process in which a few people are responsible for maintaining large areas of content, whereas general collaborative authoring scenarios require more granular permissions models. Some protocol operations are addressed to the FrontPage Server Extensions CGI scripts, while the Web resource being operated on is named inside the POST body. This is not a recommended use of the Web namespace. Instead, the IETF encourages protocol operations to address the URLs of the entities that are being operated on. Some protocol operations are addressed to special files created on the server to make FrontPage run. For example: GET http://www.example.com/_vti_inf.html
Of course, there were also political pressures to prevent adoption of a pre-existing Microsoft protocol or architecture. Nobody wanted to give Microsoft a big head start by adopting a Microsoft model. Why Not Use POST? Many applications standards developers at the IETF oppose use of the HTTP POST method to tunnel new protocol semantics. One reason for using multiple methods with meaningful names is that firewall administrators can block certain HTTP methods that might be harmful (e.g., PUT or DELETE) while allowing others like GET. Another objection is aesthetic: HTTP uses methods to convey the basic purpose of the request, and it's not very elegant to abandon that channel of communication. |
2.3.2 AOLPress The AOLPress Extensions were a strong early influence on the WebDAV protocol, since they demonstrated that remote Web authoring was possible using new HTTP methods. These included methods for overwrite prevention (LOCK/UNLOCK) and namespace manipulation (MKDIR, BROWSE). Versioning information was accessed using HTTP headers (Content-Version, Derived-From). However, this protocol didn't meet all of WebDAV's requirements: It had no metadata (property) support. Directory listing capabilities were very limited. The BROWSE method returns a simple list of lines containing {mime type} {resource name} pairs. Subcollections are indicated with a nonstandard MIME type (application/x-navidir). The model is not easily extensible, so it's hard to add extra properties to directory listings. The protocol had no support for copying or moving Web pages. Although GET and PUT can be used to copy a Web page, this is an expensive operation because the entire file must be transferred twice.
2.3.3 Netscape Extensions Of the proprietary protocols, the Netscape Extensions came closest to meeting the requirements of WebDAV. This protocol had metadata operations (GETATTRIBUTES, SETATTRIBUTES), overwrite prevention (LOCK, UNLOCK), namespace management (MKDIR, RMDIR, DESTROY, COPY, MOVE), and version control (CHECKIN, CHECKOUT, DEFAULT, LABEL, REVLOG). It even supported basic linear versioning. Assuming for the moment that political issues (caused by Netscape Extensions'origin at Netscape) could be swept away, could it have been standardized as is? There were a few technical shortcomings: The protocol was underspecified. It was discribed in only about 20 percent of the page count of the WebDAV protocol specification yet involved substantially more functionality. Under-specification generally leads to interoperability problems, since it forces implementers to make assumptions about many issues. For example, SETATTRIBUTES allowed multiple attributes to be set using a single method, but the specification provided no guidance on how to handle errors when some properties are successfully written and others are not. Attributes in the Netscape Extensions were ASCII text name/value pairs. This model would have required a centralized registration authority for properties to avoid conflicts. The ASCII attribute values provided a poor foundation for representing the wide range of characters found in current human languages. For example, they did not support any of the Unicode encodings, such as UTF-8 and UTF-16 (see the sidebar, Unicode, UTF-8, and UTF-16), and there were no provisions for character set labeling or human language labeling. While Netscape Extensions provided locking, they do not specify the exact semantics of that lock. It was unclear what methods LOCK affects. Presumably, PUT is prevented by a lock, but the specification was silent on LOCK's impact on DESTROY, RMDIR, SETATTRIBUTES, CHECKIN, and LABEL. It was also unclear whether the lock is associated with a specific person, client, or network connection. No standard error code indicated that an operation failed because a resource is locked.
While the Netscape Extensions protocol was a useful source of ideas for the WebDAV protocol, lack of detail in many areas limited its impact. Unicode, UTF-8, and UTF-16 The Unicode Standard (www.unicode.org/) has become the primary international character coding system, supporting most of the characters used in most human languages. No other single encoding system supports so many characters from so many languages. Modern distributed authoring systems require excellent internationalization support, so Unicode is a natural choice. Although some systems (such as the Java programming language) natively support Unicode, most Internet protocols and XML only support ASCII. The Internet has a long tradition of using ASCII. However, all is not lost: Two standard transformations reversibly express Unicode in an ASCII stream UTF-8 [RFC2279] and UTF-16 [RFC2781]. Nearly all new IETF protocols support both UTF-8 and UTF-16 in order to handle internationalization well. Older protocols that do not support Unicode are considered flawed. |
2.3.4 Amaya/Jigsaw The Amaya editor and browser and its Jigsaw server counterpart were created by the W3C in 1997 as showcases and reference implementations for W3C innovations. The focus in Amaya was on its WYSIWYG HTML-editing environment and support for advanced (at the time) features like Cascading Style Sheets (CSS) and XML. Amaya was capable of using HTTP PUT to save to the Jigsaw server, and its implementors intended to do more. In the end, Jigsaw turned to WebDAV for remote authoring support, releasing a WebDAV package in 2000 and adding this functionality to the core product in the 2.2 release in 2001. |
