rfc2291.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2291          Distributed Authoring and Versioning     February 1998


   consistent when he writes it to the server. Because of this, it
   should be possible to take out a lock without also causing
   transmission of the contents of a resource.

   It is often necessary to guarantee that a lock or unlock operation
   occurs at the same time across multiple resources, a feature which is
   supported by the multiple-resource locking requirement. This is
   useful for preventing a collision between two people trying to
   establish locks on the same set of resources, since with multi-
   resource locking, one of the two people will get a lock. If this same
   multiple-resource locking scenario was repeated by using atomic lock
   operations iterated across the resources, the result would be a
   splitting of the locks between the two people, based on resource
   ordering and race conditions.

5.4. Reservations

5.4.1. Functional Requirements

   5.4.1.1. Reserve. It must be possible for a principal to register
   with the server an intent to edit a given resource, so that other
   principals can discover who intends to edit the resource.

   5.4.1.2. Reservation Query. It must be possible to find out whether a
   given resource has any active reservations, and if so, who currently
   holds reservations.

   5.4.1.3. Release Reservation.  It must be possible to release the
   reservation.

5.4.2. Rationale

   Experience from configuration management systems has shown that
   people need to know when they are about to enter a parallel editing
   situation. Once notified, they either decide not to edit in parallel
   with the other authors, or they use out-of-band communication (face-
   to-face, telephone, etc.) to coordinate their editing to minimize the
   difficulty of merging their results. Reservations are separate from
   locking, since a write lock does not necessarily imply a resource
   will be edited, and a reservation does not carry with it any access
   restrictions. This capability supports versioning, since a check-out
   typically involves taking out a write lock, making a reservation, and
   getting the resource to be edited.








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


5.5. Retrieval of Unprocessed Source for Editing

5.5.1. Functional Requirement

   The source of any given resource must be retrievable by any principal
   with authorization to edit the resource.

5.5.2. Rationale

   There are many cases where the source stored on a server does not
   correspond to the actual entity transmitted in response to an HTTP
   GET. Current known cases are server side include directives, and
   Standard Generalized Markup Language (SGML) source which is converted
   on the fly to HyperText Markup Language (HTML) [HTML] output
   entities. There are many possible cases, such as automatic conversion
   of bitmap images into several variant bitmap media types (e.g. GIF,
   JPEG), and automatic conversion of an application's native media type
   into HTML. As an example of this last case, a word processor could
   store its native media type on a server which automatically converts
   it to HTML. A GET of this resource would retrieve the HTML.
   Retrieving the source would retrieve the word processor native
   format.

5.6. Partial Write.

5.6.1. Functional Requirement

   After editing a resource, it must be possible to write only the
   changes to the resource, rather than retransmitting the entire
   resource.

5.6.2. Rationale

   During distributed editing which occurs over wide geographic
   separations and/or over low bandwidth connections, it is extremely
   inefficient and frustrating to rewrite a large resource after minor
   changes, such as a one-character spelling correction. Support is
   needed for transmitting "insert" (e.g., add this sentence in the
   middle of a document) and "delete" (e.g. remove this paragraph from
   the middle of a document) style updates. Support for partial resource
   updates will make small edits more efficient, and allow distributed
   authoring tools to scale up for editing large documents.









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


5.7. Name Space Manipulation

5.7.1. Copy

5.7.1.1. Functional Requirements

   It must be possible to duplicate a resource without a client loading,
   then resaving the resource. After the copy operation, a modification
   to either resource must not cause a modification to the other.

5.7.1.2. Rationale

   There are many reasons why a resource might need to be duplicated,
   such as changing ownership, preparing for major modifications, or
   making a backup. Due to network costs associated with loading and
   saving a resource, it is far preferable to have a server perform a
   resource copy than a client.

5.7.2. Move/Rename

5.7.2.1. Functional Requirements

   It must be possible to change the location of a resource without a
   client loading, then resaving the resource under a different name.
   After the move operation, it must no longer be possible to access the
   resource at its original location.

5.7.2.2. Rationale

   It is often necessary to change the name of a resource, for example
   due to adoption of a new naming convention, or if a typing error was
   made entering the name originally. Due to network costs, it is
   undesirable to perform this operation by loading, then resaving the
   resource, followed by a delete of the old resource. Similarly, a
   single rename operation is more efficient than a copy followed by a
   delete operation.  Note that moving a resource is considered the same
   function as renaming a resource.

5.8. Collections

   A collection is a resource that is a container for other resources,
   including other collections.  A resource may belong to a collection
   either directly or by reference.  If a resource belongs to a
   collection directly, name space operations like copy, move, and
   delete applied to the collection also apply to the resource.  If a
   resource belongs to a collection by reference, name space operations
   applied to the collection affect only the reference, not the resource
   itself.



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


5.8.1. Functional Requirements

   5.8.1.1. List Collection. A listing of all resources in a specific
   collection must be accessible.

   5.8.1.2. Make Collection. It must be possible to create a new
   collection.

   5.8.1.3. Add to Collection.  It must be possible to add a resource to
   a collection directly or by reference.

   5.8.1.4. Remove from Collection.  It must be possible to remove a
   resource from a collection.

5.8.2. Rationale

   In [URL] it states that, "some URL schemes (such as the ftp, http,
   and file schemes) contain names that can be considered hierarchical."
   Especially for HTTP servers which directly map all or part of their
   URL name space into a filesystem, it is very useful to get a listing
   of all resources located at a particular hierarchy level. This
   functionality supports "Save As..." dialog boxes, which provide a
   listing of the entities at a current hierarchy level, and allow
   navigation through the hierarchy. It also supports the creation of
   graphical visualizations (typically as a network) of the hypertext
   structure among the entities at a hierarchy level, or set of levels.
   It also supports a tree visualization of the entities and their
   hierarchy levels.

   In addition, document management systems may want to make their
   documents accessible through the Web.  They typically allow the
   organization of documents into collections, and so also want their
   users to be able to view the collection hierarchy through the Web.

   There are many instances where there is not a strong correlation
   between a URL hierarchy level and the notion of a collection. One
   example is a server in which the URL hierarchy level maps to a
   computational process which performs some resolution on the name. In
   this case, the contents of the URL hierarchy level can vary depending
   on the input to the computation, and the number of resources
   accessible via the computation can be very large. It does not make
   sense to implement a directory feature for such a name space.
   However, the utility of listing the contents of those URL hierarchy
   levels which do correspond to collections, such as the large number
   of HTTP servers which map their name space to a filesystem, argue for
   the inclusion of this capability, despite not being meaningful in all





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


   cases. If listing the contents of a URL hierarchy level does not
   makes sense for a particular URL, then a "405 Method Not Allowed"
   status code could be issued.

   The ability to create collections to hold related resources supports
   management of a name space by packaging its members into small,
   related clusters. The utility of this capability is demonstrated by
   the broad implementation of directories in recent operating systems.
   The ability to create a collection also supports the creation of
   "Save As..." dialog boxes with "New Level/Folder/Directory"
   capability, common in many applications.

5.9. Versioning

5.9.1. Background and General Principles

   5.9.1.1. Stability of versions. Most versioning systems are intended
   to provide an accurate record of the history of evolution of a
   document. This accuracy is ensured by the fact that a version
   eventually becomes "frozen" and immutable. Once a version is frozen,
   further changes will create new versions rather than modifying the
   original. In order for caching and persistent references to be
   properly maintained, a client must be able to determine that a
   version has been frozen. Any successful attempt to retrieve a frozen
   version of a resource will always retrieve exactly the same content,
   or return an error if that version (or the resource itself) is no
   longer available.

   5.9.1.2. Operations for Creating New Versions.  Version management
   systems vary greatly in the operations they require, the order of the
   operations, and how they are combined into atomic functions.  In the
   most complete cases, the logical operations involved are:

        o Reserve existing version
        o Lock existing version
        o Retrieve existing version
        o Request or suggest identifier for new version
        o Write new version
        o Release lock
        o Release reservation

   With the exception of requesting a new version identifier, all of
   these operations have applications outside of versioning and are
   either already part of HTTP or are discussed in earlier sections of
   these requirements. Typically, versioning systems combine
   reservation, locking, and retrieval -- or some subset of these --
   into an atomic checkout function.  They combine writing, releasing




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


   the lock, and releasing the reservation -- or some subset of these --
   into an atomic checkin function.  The new version identifier may be
   assigned either at checkout or at checkin.

   The WebDAV extensions must find some balance between allowing
   versioning servers to adopt whatever policies they wish with regard
   to these operations and enforcing enough uniformity to keep client
   implementations simple.

   5.9.1.3. The Versioning Model.  Each version typically stands in a
   "derived from" relationship to its predecessor(s).  It is possible to
   derive several different versions from a single version (branching),
   and to derive a single version from several versions (merging).
   Consequently, the collection of related versions forms a directed
   acyclic graph.  In the following discussion, this graph will be
   called a "version graph".  Each node of this graph is a "version" or
   "member of the version graph".  The arcs of the graph capture the
   "derived from" relationships.

   It is also possible for a single resource to participate in multiple
   version graphs.

   The WebDAV extensions should support this versioning model, though
   particular servers may restrict it in various ways.

   5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and
   Haake and Hicks [VSE], have discussed the notion of versioning styles
   (referred to here as versioning policies, to reflect the nature of
   client/server interaction) as one way to think about the different
   policies that versioning systems implement. Versioning policies
   include decisions on the shape of version histories (linear or
   branched), the granularity of change tracking, locking requirements
   made by a server, etc. The protocol should clearly identify the
   policies that it dictates and the policies that are left up to
   versioning system implementors or administrators.

   5.9.1.5. It is possible to version resources of any media type.

5.9.2. Functional Requirements

   5.9.2.1. Referring to a version graph. There must be a way to refer
   to a version graph as a whole.

   Some queries and operations apply, not to any one member of a version
   graph, but to the version graph as a whole.  For example, a client
   may request that an entire graph be moved, or may ask for a version
   history. In these cases, a way to refer to the whole version graph is
   required.



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


   5.9.2.2. Referring to a specific member of a version graph. There
   must be a way to refer to each member of a version graph. This means
   that each member of the graph is itself a resource.

   Each member of a version graph must be a resource if it is to be
   possible for a hypertext link to refer to specific version of a page,
   or for a client to request a specific version of a document for
   editing.

   5.9.2.3. A client must be able to determine whether a resource is a
   version graph, or whether a resource is itself a member of a version
   graph.

   A resource may be a simple, non-versioned resource, or it may be a
   version graph, or it may be a member of a version graph.  A client
   needs to be able to tell which sort of resource it is accessing.

   5.9.2.4. There must be a way to refer to a server-defined default
   member of a version graph.

   The server should return a default version of a resource for requests
   that ask for the default version, as well as for requests where no
   specific version information is provided. This is one of the simplest
   ways to guarantee non-versioning client compatibility. This does not
   rule out the possibility of a server returning an error when no
   sensible default exists.

   It may also be desirable to be able to refer to other special members
   of a version graph. For example, there may be a current version for
   editing that is different from the default version.  For a graph with
   several branches, it may be useful to be able to request the tip
   version of any branch.

   5.9.2.5. It must be possible, given a reference to a member of a
   version graph, to find out which version graph(s) that resource
   belongs to.

   This makes it possible to understand the versioning context of the
   resource. It makes it possible to retrieve a version history for the
   graphs to which it belongs, and to browse the version graph. It also
   supports some comparison operations: It makes it possible to
   determine whether two references designate members of the same
   version graph.

   5.9.2.6. Navigation of a version graph.  Given a reference to a
   member of a version graph, it must be possible to discover and access
   the following related members of the version graph.




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