4.1. User Agent Interoperability

   All WebDAV clients should be able to work with any WebDAV-compliant
   HTTP server. It is acceptable for some client/server combinations to
   provide special features that are not universally available, but the
   protocol should be sufficient that a basic level of functionality
   will be universal.

4.2. Client Simplicity

   The WebDAV extensions should be designed to allow client
   implementations to be simple.












 
RFC 2291          Distributed Authoring and Versioning     February 1998


4.3. Legacy Client Support

   It should be possible to implement a WebDAV-compliant server in such
   a way that it can interoperate with non-WebDAV clients.  Such a
   server would be able to understand any valid HTTP 1.1 request from an
   ordinary Web client without WebDAV extensions, and to provide a valid
   HTTP 1.1 response that does not require the client to understand the
   extensions.

4.4. Data Format Compatibility

   WebDAV-compliant servers should be able to work with existing
   resources and URIs [URL]. Special additional information should not
   become a mandatory part of document formats.

4.5. Replicated, Distributed Systems

   Distribution and replication are at the heart of the Internet.  All
   WebDAV extensions should be designed to allow for distribution and
   replication.  Version trees should be able to be split across
   multiple servers.  Collections may have members on different servers.
   Any resource may be cached or replicated for mobile computing or
   other reasons.  Consequently, the WebDAV extensions must be able to
   operate in a distributed, replicated environment.

4.6 Parsimony in Client-Server Interactions

   The WebDAV extensions should keep to a minimum the number of
   interactions between the client and the server needed to perform
   common functions. For example, publishing a document to the Web will
   often mean publishing content together with related properties.  A
   client may often need to find out what version graph a particular
   resource belongs to, or to find out which resource in a version graph
   is the published one.  The extensions should make it possible to do
   these things efficiently.

4.7. Changes to HTTP

   WebDAV adds a number of new types of objects to the Web: properties,
   collections, version graphs, etc.  Existing HTTP methods such as
   DELETE and PUT will have to operate in well-defined ways in this
   expanded environment. WebDAV should explicitly address not only new
   methods, headers, and MIME types, but also any required changes to
   the existing HTTP methods and headers.








 
RFC 2291          Distributed Authoring and Versioning     February 1998


4.8. Alternate Transport Mechanisms

   It may be desirable to transport WebDAV requests and responses by
   other mechanisms, particularly EMail, in addition to HTTP.  The
   WebDAV protocol specification should not preclude a future body from
   developing an interoperability specification for disconnected
   operation via EMail.

5. Requirements

   In the requirement descriptions below, the requirement will be
   stated, followed by its rationale.

5.1. Properties