--- 1/draft-ietf-webdav-requirements-00.txt 2006-02-05 02:11:41.000000000 +0100 +++ 2/draft-ietf-webdav-requirements-01.txt 2006-02-05 02:11:41.000000000 +0100 @@ -1,22 +1,22 @@ WEBDAV Working Group J.A. Slein INTERNET-DRAFT Xerox Corporation - F. Vitali + F. Vitali University of Bologna E.J. Whitehead, Jr. U.C. Irvine D.G. Durand Boston University - May 30, 1997 + July 24, 1997 -Expires November 30, 1997 +Expires January 24, 1998 Requirements for Distributed Authoring and Versioning on the World Wide Web Status of this Memo This document is an Internet draft. Internet drafts are working documents of the Internet Engineering Task Force (IETF), its areas and its working groups. Note that other groups may also distribute working information as Internet drafts. @@ -50,42 +50,38 @@ 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 [4], would allow tools +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 possible that a single mechanism could simultaneously satisfy several requirements. This document is intended to reflect the consensus of the WWW Distributed Authoring and Versioning working group (WebDAV) as to the functionality that needs to be standardized to support distributed authoring and versioning on the Web. However, this version still has some elements that are being debated in the working group. The following elements are still under discussion: o Whether support for multi-resource locking is needed - o Whether reservations should be treated as shared or advisory - locks - o What requirements there should be for access control + o Whether support for query on properties and links is needed o What requirements there should be for internationalization - o How far WebDAV should be concerned about compatibility with - other transport protocols besides HTTP 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' @@ -100,39 +96,36 @@ 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: - Attributes + Properties Links Locking Reservations Retrieval of Unprocessed Source Partial Write Name Space Manipulation Collections Versioning Security Internationalization 3. Terminology Where there is overlap, usage is intended to be consistent with that in -the HTTP 1.1 specification [4]. - -Attribute - Named descriptive information about a resource. +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 @@ -141,50 +134,47 @@ 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 resources. + 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 to the server that one intends to edit a resource. + A declaration that one intends to edit a resource. Resource A network data object or service that can be identified by a URI. Server A program which receives and responds to HTTP requests. -Server Attribute - An attribute whose value is generated by the server. - User Agent The client that initiates a request. -User Attribute - An attribute whose value is provided by a user or a user agent. - 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 @@ -209,79 +199,78 @@ 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 [2]. Special additional information should not become a +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. Resources -may have attributes on different servers. Any resources may be cached +may have properties on different servers. Any resources 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 metadata. A client may often +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: links, +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. 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 preculde a future body from developing an +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. Attributes +5.1. Properties 5.1.1. Functional Requirements It must be possible to create, modify, query, read and delete arbitrary -attributes on resources of any media type. +properties on resources of any media type. 5.1.2. Rationale -Attributes describe resources of any media type. They may +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 -attributes have many uses, such as supporting searches on attribute - +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, query, read and delete typed links between resources of any media type. @@ -290,43 +279,42 @@ 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 connection 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 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 [1]. Similar support is needed for bitmap image +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 re-reading 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 in the same action, and this locking -operation must be atomic across these resources. +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 modification restrictions, and if so, who -currently has modification permission. +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 @@ -353,22 +341,23 @@ 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 to notify the server that -a resource is about to be edited by a given person. +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 @@ -389,21 +378,22 @@ 5.5.1. Functional Requirement The source of any given resource must be retrievable. 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) [1] output + +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. @@ -489,22 +479,21 @@ 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 [2] it states that, "some URL schemes (such as the ftp, http, and - +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. @@ -590,22 +579,22 @@ 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 [3] and -Haake and Hicks [5], have discussed the notion of versioning styles +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. @@ -656,50 +646,49 @@ 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. 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 exhamined. +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 accomodated, for servers and +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 metadata to +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 -"Attributes" above.) At a minimum, it must be possible to associate +"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: @@ -736,98 +726,126 @@ 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. Security 5.10.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.10.2. Access Control. Access control requirements are TBD, and may -eventually be specified in a separate access control draft. +5.10.2. Access Control. Access control requirements are specified +in a separate access control draft [AC]. 5.10.3. Interoperability with Security Protocols. The WebDAV specification should provide a minimal list of security protocols which any compliant server / client should support. These protocols should insure the authenticity of messages and the privacy and integrity of messages in transit. 5.11. Internationalization -Internationalization requirements are TBD. +5.11.1. Functional Requirement + +For transmission of information intended for user comprehension, +the full Universal Character Set (UCS) [ISO 10646] must be available. +Language information and negotiation must be available where +appropriate. + +5.11.2. Rationale + +In the international environment of the Internet, it is important +to insure that any information intended for user comprehension will +be transported in a form that makes it possible to display the +information in any 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 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. +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, FisherM@exch1.indy.tce.com +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@bigtime.cs.colorado.edu + 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 Mike Little, Bellcore, little@bellcore.com Dave Long, America Online, dave@sb.aol.com Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.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 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 Gregory J. Woodhouse, gjw@wnetc.com 7. References -[1] T. Berners-Lee, D. Connolly, "HyperText Markup Language -Specification - 2.0", RFC 1866, MIT/LCS, November 1995. - -[2] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource -Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, -December 1994. +[AC] J. Radoff, "Requirements for Access Control within +Distributed Authoring and Versioning Environments on the World +Wide Web". -[3] P. Feiler, "Configuration Management Models in Commercial +[CM] P. Feiler, "Configuration Management Models in Commercial Environments", Software Engineering Institute Technical Report CMU/SEI-91-TR-7, -[4] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and +[HTML] T. Berners-Lee, D. Connolly, "HyperText Markup Language +Specification - 2.0", RFC 1866, MIT/LCS, November 1995. + +[HTTP] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, U.C. Irvine, DEC, MIT/LCS, January 1997. -[5] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", +[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] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource +Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, +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. 8. Authors' Addresses Judith Slein Xerox Corporation 800 Phillips Road 128-29E Webster, NY 14580 @@ -848,11 +866,11 @@ 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 -Expires November 30, 1997 +Expires January 24, 1998