rfc2291.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,180 行 · 第 1/3 页

Network Working Group                                          J. Slein
Request for Comments: 2291                            Xerox Corporation
Category: Informational                                       F. Vitali
                                                  University of Bologna
                                                           E. Whitehead
                                                            U.C. Irvine
                                                              D. Durand
                                                      Boston University
                                                          February 1998


        Requirements for a Distributed Authoring and Versioning
                    Protocol for the World Wide Web

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   Current World Wide Web (WWW or Web) standards provide simple support
   for applications which allow remote editing of typed data. In
   practice, the existing capabilities of the WWW have proven inadequate
   to support efficient, scalable remote editing free of overwriting
   conflicts. This document presents a list of features in the form of
   requirements for a Web Distributed Authoring and Versioning protocol
   which, if implemented, would improve the efficiency of common remote
   editing operations, provide a locking mechanism to prevent overwrite
   conflicts, improve link management support between non-HTML data
   types, provide a simple attribute-value metadata facility, provide
   for the creation and reading of container data types, and integrate
   versioning into the WWW.

1. Introduction

   This document describes functionality which, if incorporated in an
   extension to the existing HTTP proposed standard [HTTP], would allow
   tools for remote loading, editing and saving (publishing) of various
   media types on the WWW to interoperate with any compliant Web server.
   As much as possible, this functionality is described without
   suggesting a proposed implementation, since there are many ways to
   perform the functionality within the WWW framework. It is also



Slein, et. al.               Informational                      [Page 1]

RFC 2291          Distributed Authoring and Versioning     February 1998


   possible that a single mechanism could simultaneously satisfy several
   requirements.

   This document reflects the consensus of the WWW Distributed Authoring
   and Versioning working group (WebDAV) as to the functionality that
   should be standardized to support distributed authoring and
   versioning on the Web.  As with any set of requirements, practical
   considerations may make it impossible to satisfy them all.  It is the
   intention of the WebDAV working group to come as close as possible to
   satisfying them in the specifications that make up the WebDAV
   protocol.

2. Rationale

   Current Web standards contain functionality which enables the editing
   of Web content at a remote location, without direct access to the
   storage media via an operating system. This capability is exploited
   by several existing HTML distributed authoring tools, and by a
   growing number of mainstream applications (e.g., word processors)
   which allow users to write (publish) their work to an HTTP server. To
   date, experience from the HTML authoring tools has shown they are
   unable to meet their users' needs using the facilities of Web
   standards. The consequence of this is either postponed introduction
   of distributed authoring capability, or the addition of nonstandard
   extensions to the HTTP protocol or other Web standards.  These
   extensions, developed in isolation, are not interoperable.

   Other authoring applications have wanted to access document
   repositories or version control systems through Web gateways, and
   have been similarly frustrated.  Where this access is available at
   all, it is through nonstandard extensions to HTTP or other standards
   that force clients to use a different interface for each vendor's
   service.

   This document describes requirements for a set of standard extensions
   to HTTP that would allow distributed Web authoring tools to provide
   the functionality their users need by means of the same standard
   syntax across all compliant servers. The broad categories of
   functionality that need to be standardized are:

        Properties
        Links
        Locking
        Reservations
        Retrieval of Unprocessed Source
        Partial Write
        Name Space Manipulation
        Collections



Slein, et. al.               Informational                      [Page 2]

RFC 2291          Distributed Authoring and Versioning     February 1998


        Versioning
        Variants
        Security
        Internationalization

3. Terminology

   Where there is overlap, usage is intended to be consistent with that
   in the HTTP 1.1 specification [HTTP].

   Client
        A program which issues HTTP requests and accepts responses.

   Collection
        A collection is a resource that contains other resources, either
        directly or by reference.

   Distributed Authoring Tool
        A program which can retrieve a source entity via HTTP, allow
        editing of this entity, and then save/publish this entity to a
        server using HTTP.

   Entity
        The information transferred in a request or response.

   Hierarchical Collection
        A hierarchical organization of resources.  A hierarchical
        collection is a resource that contains other resources,
        including collections, either directly or by reference.

   Link
        A typed connection between two or more resources.

   Lock
        A mechanism for preventing anyone other than the owner of the
        lock from accessing a resource.

   Member of Version Graph
        A resource that is a node in a version graph, and so is derived
        from the resources that precede it in the graph, and is the
        basis of those that succeed it.

   Property
        Named descriptive information about a resource.

   Reservation
        A declaration that one intends to edit a resource.




Slein, et. al.               Informational                      [Page 3]

RFC 2291          Distributed Authoring and Versioning     February 1998


   Resource
        A network data object or service that can be identified by a
        URI.

   Server
        A program which receives and responds to HTTP requests.

   User Agent
        The client that initiates a request.

   Variant
        A representation of a resource.  A resource may have one or more
        representations associated with it at any given time.

   Version Graph
        A directed acyclic graph with resources as its nodes, where each
        node is derived from its predecessor(s).

   Write Lock
        A lock that prevents anyone except its owner from modifying the
        resource it applies to.

4. General Principles

   This section describes a set of general principles that the WebDAV
   extensions should follow.  These principles cut across categories of
   functionality.

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.











Slein, et. al.               Informational                      [Page 4]

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.







Slein, et. al.               Informational                      [Page 5]

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

5.1.1. Functional Requirements

   It must be possible to create, modify, read and delete arbitrary
   properties on resources of any media type.

5.1.2. Rationale

   Properties describe resources of any media type.  They may include
   bibliographic information such as author, title, publisher, and
   subject, constraints on usage, PICS ratings, etc. These properties
   have many uses, such as supporting searches on property values,
   enforcing copyrights, and the creation of catalog entries as
   placeholders for objects which are not available in electronic form,
   or which will be available later.

5.2. Links

5.2.1. Functional Requirements

   It must be possible to create, modify, read and delete typed links
   between resources of any media type.

5.2.2. Rationale

   One type of link between resources is the hypertext link, which is
   browsable using a hypertext style point-and-click user interface.
   Links, whether they are browsable hypertext links, or simply a means
   of capturing a relationship between resources, have many purposes.
   Links can support pushbutton printing of a multi-resource document in
   a prescribed order, jumping to the access control page for a
   resource, and quick browsing of related information, such as a table





Slein, et. al.               Informational                      [Page 6]

RFC 2291          Distributed Authoring and Versioning     February 1998


   of contents, an index, a glossary, a bibliographic record, help
   pages, etc. While link support is provided by the HTML "LINK"
   element, this is limited only to HTML resources [HTML]. Similar
   support is needed for bitmap image types, and other non-HTML media
   types.

5.3. Locking

5.3.1. General Principles

   5.3.1.1. Independence of locks. It must be possible to lock a
   resource without performing an additional retrieval of the resource,
   and without committing to editing the resource.

   5.3.1.2. Multi-Resource Locking. It must be possible to take out a
   lock on multiple resources residing on the same server in a single
   action, and this locking operation must be atomic across these
   resources.

5.3.2. Functional Requirements

   5.3.2.1. Write Locks. It must be possible to restrict modification of
   a resource to a specific person.

   5.3.2.2. Lock Query. It must be possible to find out whether a given
   resource has any active locks, and if so, who holds those locks.

   5.3.2.3. Unlock. It must be possible to remove a lock.

5.3.3. Rationale

   At present, the Web provides limited support for preventing two or
   more people from overwriting each other's modifications when they
   save to a given URI. Furthermore, there is no way to discover whether
   someone else is currently making modifications to a resource. This is
   known as the "lost update problem," or the "overwrite problem." Since
   there can be significant cost associated with discovering and
   repairing lost modifications, preventing this problem is crucial for
   supporting distributed authoring. A write lock ensures that only one
   person may modify a resource, preventing overwrites. Furthermore,
   locking support is a key component of many versioning schemes, a
   desirable capability for distributed authoring.

   An author may wish to lock an entire web of resources even though he
   is editing just a single resource, to keep the other resources from
   changing. In this way, an author can ensure that if a local hypertext
   web is consistent in his distributed authoring tool, it will then be




Slein, et. al.               Informational                      [Page 7]