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.









 
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.