diff options
Diffstat (limited to 'doc/rfc/rfc2291.txt')
| -rw-r--r-- | doc/rfc/rfc2291.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc2291.txt b/doc/rfc/rfc2291.txt new file mode 100644 index 0000000..d4123a0 --- /dev/null +++ b/doc/rfc/rfc2291.txt @@ -0,0 +1,1179 @@ + + + + + + +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] + +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 + + + o root member of the graph + o predecessor member(s) + o successor member(s) + o default member of the graph + + It must be possible in some way for a versioning client to access + versions related to a resource currently being examined. + + 5.9.2.7. Version Topology. There must be a way to retrieve the + complete version topology for a version graph, including information + about all members of the version graph. The format for this + information must be standardized so that the basic information can be + used by all clients. Other specialized formats should be + accommodated, for servers and clients that require information that + cannot be included in the standard topology. + + 5.9.2.8. A client must be able to propose a version identifier to be + used for a new member of a version graph. The server may refuse to + use the client's suggested version identifier. The server should + tell the client what version identifier it has assigned to the new + member of the version graph. + + 5.9.2.9. A version identifier must be unique across a version graph. + + 5.9.2.10. A client must be able to supply version-specific properties + to be associated with a new member of a version graph. (See Section + 5.1 "Properties" above.) At a minimum, it must be possible to + associate comments with the new member, explaining what changes were + made. + + 5.9.2.11. A client must be able to query the server for information + about a version tree, including which versions are locked, which are + reserved for editing, and by whom (Session Tracking). + +5.9.3. Rationale + + Versioning in the context of the world-wide web offers a variety of + benefits: + + It provides infrastructure for efficient and controlled management of + large evolving web sites. Modern configuration management systems are + built on some form of repository that can track the revision history + of individual resources, and provide the higher-level tools to manage + those saved versions. Basic versioning capabilities are required to + support such systems. + + + + + + +Slein, et. al. Informational [Page 15] + +RFC 2291 Distributed Authoring and Versioning February 1998 + + + It allows parallel development and update of single resources. Since + versioning systems register change by creating new objects, they + enable simultaneous write access by allowing the creation of variant + versions. Many also provide merge support to ease the reverse + operation. + + It provides a framework for coordinating changes to resources. While + specifics vary, most systems provide some method of controlling or + tracking access to enable collaborative resource development. + + It allows browsing through past and alternative versions of a + resource. Frequently the modification and authorship history of a + resource is critical information in itself. + + It provides stable names that can support externally stored links for + annotation and link-server support. Both annotation and link servers + frequently need to store stable references to portions of resources + that are not under their direct control. By providing stable states + of resources, version control systems allow not only stable pointers + into those resources, but also well-defined methods to determine the + relationships of those states of a resource. + + It allows explicit semantic representation of single resources with + multiple states. A versioning system directly represents the fact + that a resource has an explicit history, and a persistent identity + across the various states it has had during the course of that + history. + +5.10. Variants + + Detailed requirements for variants will be developed in a separate + document. + +5.10.1. Functional Requirements + + It must be possible to send variants to the server, describing the + relationships between the variants and their parent resource. In + addition, it must be possible to write and retrieve variants of + property labels, property descriptions, and property values. + +5.10.2. Rationale + + The HTTP working group is addressing problems of content negotiation + and retrieval of variants of a resource. To extend this work to an + authoring environment, WEBDAV must standardize mechanisms for authors + to use when submitting variants to a server. Authors need to be able + to provide variants in different file or document formats, for + different uses. They need to provide variants optimized for different + + + +Slein, et. al. Informational [Page 16] + +RFC 2291 Distributed Authoring and Versioning February 1998 + + + clients and for different output devices. They need to be able to + provide variants in different languages in the international + environment of the Web. In support of internationalization + requirements (See 5.12 below), variants need to be supported not just + for the content of resources, but for any information intended for + human use, such as property values, labels, and descriptions. + +5.11. Security + + 5.11.1. Authentication. The WebDAV specification should state how the + WebDAV extensions interoperate with existing authentication schemes, + and should make recommendations for using those schemes. + + 5.11.2. Access Control. Access control requirements are specified in + a separate access control work in progress [AC]. + + 5.11.3. Interoperability with Security Protocols. The WebDAV + specification must provide a minimal list of security protocols which + any compliant server / client must support. These protocols should + insure the authenticity of messages and the privacy and integrity of + messages in transit. + +5.12. Internationalization + +5.12.1. Character Sets and Languages + + Since Web distributed authoring occurs in a multi-lingual + environment, information intended for user comprehension must conform + to the IETF Character Set Policy [CHAR]. This policy addresses + character sets and encodings, and language tagging. + +5.12.2. Rationale + + In the international environment of the Internet, it is important to + insure that any information intended for user comprehension can be + displayed in a writing system and language agreeable to both the + client and the server. The information encompassed by this + requirement includes not only the content of resources, but also such + things as display names and descriptions of properties, property + values, and status messages. + +6. Acknowledgements + + Our understanding of these issues has emerged as the result of much + thoughtful discussion, email, and assistance by many people, who + deserve recognition for their effort. + + + + + +Slein, et. al. Informational [Page 17] + +RFC 2291 Distributed Authoring and Versioning February 1998 + + + Terry Allen, tallen@sonic.net + Alan Babich, FileNet, babich@filenet.com + Dylan Barrell, Open Text, dbarrell@opentext.ch + Barbara Bazemore, PC DOCS, barbarab@pcdocs.com + Martin Cagan, Continuus Software, Marty_Cagan@continuus.com + Steve Carter, Novell, srcarter@novell.com + Dan Connolly, World Wide Web Consortium, connolly@w3.org + Jim Cunningham, Netscape, jfc@netscape.com + Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov + Mark Day, Lotus, Mark_Day@lotus.com + Martin J. Duerst, mduerst@ifi.unizh.ch + Asad Faizi, Netscape, asad@netscape.com + Ron Fein, Microsoft, ronfe@microsoft.com + David Fiander, Mortice Kern Systems, davidf@mks.com + Roy Fielding, U.C. Irvine, fielding@ics.uci.edu + Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com + Yaron Y. Goland, Microsoft, yarong@microsoft.com + Phill Hallam-Baker, MIT, hallam@ai.mit.edu + Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com + Andre van der Hoek, University of Colorado, Boulder, + andre@cs.colorado.edu + Del Jensen, Novell, dcjensen@novell.com + Gail Kaiser, Columbia University, kaiser@cs.columbia.edu + Rohit Khare, World Wide Web Consortium, khare@w3.org + Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com + Ben Laurie, A.L. Digital, ben@algroup.co.uk + Mike Little, Bellcore, little@bellcore.com + Dave Long, America Online, dave@sb.aol.com + Larry Masinter, Xerox PARC, masinter@parc.xerox.com + Murray Maloney, SoftQuad, murray@sq.com + Jim Miller, World Wide Web Consortium, jmiller@w3.org + Howard S. Modell, Boeing, howard.s.modell@boeing.com + Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu + Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org + Jon Radoff, NovaLink, jradoff@novalink.com + Alan Robertson, alanr@bell-labs.com + Henry Sanders, Microsoft, + Andrew Schulert, Microsoft, andyschu@microsoft.com + Christopher Seiwald, Perforce Software, seiwald@perforce.com + Einar Stefferud, stef@nma.com + Richard Taylor, U.C. Irvine, taylor@ics.uci.edu + Robert Thau, MIT, rst@ai.mit.edu + Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com + Dan Whelan, FileNet, dan@FILENET.COM + Gregory J. Woodhouse, gjw@wnetc.com + + + + + + +Slein, et. al. Informational [Page 18] + +RFC 2291 Distributed Authoring and Versioning February 1998 + + +7. References + + [AC] J. Radoff, "Requirements for Access Control within Distributed + Authoring and Versioning Environments on the World Wide Web", + unpublished manuscript, <http://lists.w3.org/Archives/Public/w3c- + dist-auth/1997AprJun/0183.html> + + [CHAR] Alvestrand, H., "IETF Policy on Character Sets and Languages", + RFC 2277, January 1998. + + [CM] P. Feiler, "Configuration Management Models in Commercial + Environments", Software Engineering Institute Technical Report + CMU/SEI-91-TR-7, + <http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html> + + [HTML] Berners-Lee, T., and D. Connolly, "HyperText Markup Language + Specification - 2.0", RFC 1866, November 1995. + + [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, + January 1997. + + [ISO 10646] ISO/IEC 10646-1:1993. "International Standard -- + Information Technology -- Universal Multiple-Octet Coded Character + Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane." + + [URL] Berners-Lee, T., Masinter, L., and M. McCahill. "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning + Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, + 1996, pages 224-234. + + + + + + + + + + + + + + + + + + + +Slein, et. al. Informational [Page 19] + +RFC 2291 Distributed Authoring and Versioning February 1998 + + +8. Authors' Addresses + + Judith Slein + Xerox Corporation + 800 Phillips Road 128-29E + Webster, NY 14580 + + EMail: slein@wrc.xerox.com + + + Fabio Vitali + Department of Computer Science + University of Bologna + ITALY + + EMail: fabio@cs.unibo.it + + + E. James Whitehead, Jr. + Department of Information and Computer Science + University of California + Irvine, CA 92697-3425 + + Fax: 714-824-4056 + EMail: ejw@ics.uci.edu + + + David G. Durand + Department of Computer Science + Boston University + Boston, MA + + EMail: dgd@cs.bu.edu + + + + + + + + + + + + + + + + + + +Slein, et. al. Informational [Page 20] + +RFC 2291 Distributed Authoring and Versioning February 1998 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Slein, et. al. Informational [Page 21] + |