draft-ietf-webdav-requirements-02.txt   rfc2291.txt 
WEBDAV Working Group J.A. Slein Network Working Group J. Slein
INTERNET-DRAFT Xerox Corporation Request for Comments: 2291 Xerox Corporation
<draft-ietf-webdav-requirements-02.txt> F. Vitali Category: Informational F. Vitali
University of Bologna University of Bologna
E.J. Whitehead, Jr. E. Whitehead
U.C. Irvine U.C. Irvine
D.G. Durand D. Durand
Boston University Boston University
August 29, 1997 February 1998
Expires February 28, 1998
Requirements for Distributed Authoring and Versioning Requirements for a Distributed Authoring and Versioning
on the World Wide Web Protocol for the World Wide Web
Status of this Memo Status of this Memo
This document is an Internet draft. Internet drafts are working This memo provides information for the Internet community. It does
documents of the Internet Engineering Task Force (IETF), its areas and not specify an Internet standard of any kind. Distribution of this
its working groups. Note that other groups may also distribute working memo is unlimited.
information as Internet drafts.
Internet Drafts are draft documents valid for a maximum of six months
and can be updated, replaced or obsoleted by other documents at any
time. It is inappropriate to use Internet drafts as reference material
or to cite them as other than as "work in progress".
To learn the current status of any Internet draft please check the Copyright Notice
"lid-abstracts.txt" listing contained in the Internet drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or
ftp.isi.edu (US West coast). Further information about the IETF can be
found at URL: http://www.ietf.org/
Distribution of this document is unlimited. Please send comments to the Copyright (C) The Internet Society (1998). All Rights Reserved.
WWW Distributed Authoring and Versioning (WebDAV) mailing list,
<w3c-dist-auth@w3.org>, which may be joined by sending a message with
subject "subscribe" to <w3c-dist-auth-request@w3.org>. Discussions are
archived at URL:
http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/.
Abstract Abstract
Current World Wide Web (WWW or Web) standards provide simple support Current World Wide Web (WWW or Web) standards provide simple support
for applications which allow remote editing of typed data. In practice, for applications which allow remote editing of typed data. In
the existing capabilities of the WWW have proven inadequate to support practice, the existing capabilities of the WWW have proven inadequate
efficient, scalable remote editing free of overwriting conflicts. to support efficient, scalable remote editing free of overwriting
This document presents a list of features in the form of requirements conflicts. This document presents a list of features in the form of
which, if implemented, would improve the efficiency of common remote requirements for a Web Distributed Authoring and Versioning protocol
editing operations, provide a locking mechanism to prevent overwrite which, if implemented, would improve the efficiency of common remote
conflicts, improve link management support between non-HTML editing operations, provide a locking mechanism to prevent overwrite
data types, provide a simple attribute-value metadata facility, provide conflicts, improve link management support between non-HTML data
for the creation and reading of container data types, and integrate types, provide a simple attribute-value metadata facility, provide
versioning into the WWW. for the creation and reading of container data types, and integrate
versioning into the WWW.
1. Introduction 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 possible that a
single mechanism could simultaneously satisfy several requirements.
This document is intended to reflect the consensus of the WWW This document describes functionality which, if incorporated in an
Distributed Authoring and Versioning working group (WebDAV) as to the extension to the existing HTTP proposed standard [HTTP], would allow
functionality that needs to be standardized to support distributed tools for remote loading, editing and saving (publishing) of various
authoring and versioning on the Web. 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 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 2. Rationale
Current Web standards contain functionality which enables the editing of Current Web standards contain functionality which enables the editing
Web content at a remote location, without direct access to the storage of Web content at a remote location, without direct access to the
media via an operating system. This capability is exploited by several storage media via an operating system. This capability is exploited
existing HTML distributed authoring tools, and by a growing number of by several existing HTML distributed authoring tools, and by a
mainstream applications (e.g., word processors) which allow users to growing number of mainstream applications (e.g., word processors)
write (publish) their work to an HTTP server. To date, experience from which allow users to write (publish) their work to an HTTP server. To
the HTML authoring tools has shown they are unable to meet their users' date, experience from the HTML authoring tools has shown they are
needs using the facilities of Web standards. The consequence of unable to meet their users' needs using the facilities of Web
this is either postponed introduction of distributed authoring standards. The consequence of this is either postponed introduction
capability, or the addition of nonstandard extensions to the HTTP of distributed authoring capability, or the addition of nonstandard
protocol or other Web standards. These extensions, developed in extensions to the HTTP protocol or other Web standards. These
isolation, are not interoperable. extensions, developed in isolation, are not interoperable.
Other authoring applications have wanted to access document repositories Other authoring applications have wanted to access document
or version control systems through Web gateways, and have been similarly repositories or version control systems through Web gateways, and
frustrated. Where this access is available at all, it is through have been similarly frustrated. Where this access is available at
nonstandard extensions to HTTP or other standards that force clients to all, it is through nonstandard extensions to HTTP or other standards
use a different interface for each vendor's service. that force clients to use a different interface for each vendor's
service.
This document describes requirements for a set of standard extensions This document describes requirements for a set of standard extensions
to HTTP that would allow distributed Web authoring tools to provide to HTTP that would allow distributed Web authoring tools to provide
the functionality their users need by means of the same standard the functionality their users need by means of the same standard
syntax across all compliant servers. The broad categories of syntax across all compliant servers. The broad categories of
functionality that need to be standardized are: functionality that need to be standardized are:
Properties
Links
Locking
Reservations
Retrieval of Unprocessed Source
Partial Write
Name Space Manipulation
Collections
Versioning
Variants
Security
Internationalization
Properties
Links
Locking
Reservations
Retrieval of Unprocessed Source
Partial Write
Name Space Manipulation
Collections
Versioning
Variants
Security
Internationalization
3. Terminology 3. Terminology
Where there is overlap, usage is intended to be consistent with that in Where there is overlap, usage is intended to be consistent with that
the HTTP 1.1 specification [HTTP]. in the HTTP 1.1 specification [HTTP].
Client Client
A program which issues HTTP requests and accepts responses. A program which issues HTTP requests and accepts responses.
Collection Collection
A collection is a resource that contains other resources, A collection is a resource that contains other resources, either
either directly or by reference. directly or by reference.
Distributed Authoring Tool Distributed Authoring Tool
A program which can retrieve a source entity via HTTP, allow A program which can retrieve a source entity via HTTP, allow
editing of this entity, and then save/publish this entity editing of this entity, and then save/publish this entity to a
to a server using HTTP. server using HTTP.
Entity Entity
The information transferred in a request or response. The information transferred in a request or response.
Hierarchical Collection Hierarchical Collection
A hierarchical organization of resources. A hierarchical A hierarchical organization of resources. A hierarchical
collection is a resource that contains other resources, collection is a resource that contains other resources,
including collections, either directly or by reference. including collections, either directly or by reference.
Link Link
A typed connection between two or more resources. A typed connection between two or more resources.
Lock Lock
A mechanism for preventing anyone other than the owner of the A mechanism for preventing anyone other than the owner of the
lock from accessing a resource. lock from accessing a resource.
Member of Version Graph Member of Version Graph
A resource that is a node in a version graph, and so is derived 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 from the resources that precede it in the graph, and is the
basis of those that succeed it. basis of those that succeed it.
Property Property
Named descriptive information about a resource. Named descriptive information about a resource.
Reservation Reservation
A declaration that one intends to edit a resource. A declaration that one intends to edit a resource.
Resource Resource
A network data object or service that can be identified by A network data object or service that can be identified by a
a URI. URI.
Server Server
A program which receives and responds to HTTP requests. A program which receives and responds to HTTP requests.
User Agent User Agent
The client that initiates a request. The client that initiates a request.
Variant Variant
A representation of a resource. A resource may have one or more A representation of a resource. A resource may have one or more
representations associated with it at any given time. representations associated with it at any given time.
Version Graph Version Graph
A directed acyclic graph with resources as its nodes, where A directed acyclic graph with resources as its nodes, where each
each node is derived from its predecessor(s). node is derived from its predecessor(s).
Write Lock Write Lock
A lock that prevents anyone except its owner from modifying A lock that prevents anyone except its owner from modifying the
the resource it applies to. resource it applies to.
4. General Principles 4. General Principles
This section describes a set of general principles that the WebDAV This section describes a set of general principles that the WebDAV
extensions should follow. These principles cut across categories of extensions should follow. These principles cut across categories of
functionality. functionality.
4.1. User Agent Interoperability 4.1. User Agent Interoperability
All WebDAV clients should be able to work with any WebDAV-compliant HTTP All WebDAV clients should be able to work with any WebDAV-compliant
server. It is acceptable for some client/server combinations to provide HTTP server. It is acceptable for some client/server combinations to
special features that are not universally available, but the protocol provide special features that are not universally available, but the
should be sufficient that a basic level of functionality will be protocol should be sufficient that a basic level of functionality
universal. will be universal.
4.2. Client Simplicity 4.2. Client Simplicity
The WebDAV extensions should be designed to allow client implementations The WebDAV extensions should be designed to allow client
to be simple. implementations to be simple.
4.3. Legacy Client Support 4.3. Legacy Client Support
It should be possible to implement a WebDAV-compliant server in such a It should be possible to implement a WebDAV-compliant server in such
way that it can interoperate with non-WebDAV clients. Such a server a way that it can interoperate with non-WebDAV clients. Such a
would be able to understand any valid HTTP 1.1 request from an ordinary server would be able to understand any valid HTTP 1.1 request from an
Web client without WebDAV extensions, and to provide a valid HTTP 1.1 ordinary Web client without WebDAV extensions, and to provide a valid
response that does not require the client to understand the extensions. HTTP 1.1 response that does not require the client to understand the
extensions.
4.4. Data Format Compatibility 4.4. Data Format Compatibility
WebDAV-compliant servers should be able to work with existing resources WebDAV-compliant servers should be able to work with existing
and URIs [URL]. Special additional information should not become a resources and URIs [URL]. Special additional information should not
mandatory part of document formats. become a mandatory part of document formats.
4.5. Replicated, Distributed Systems 4.5. Replicated, Distributed Systems
Distribution and replication are at the heart of the Internet. All Distribution and replication are at the heart of the Internet. All
WebDAV extensions should be designed to allow for distribution and WebDAV extensions should be designed to allow for distribution and
replication. Version trees should be able to be split across multiple replication. Version trees should be able to be split across
servers. Collections may have members on different servers. Resources multiple servers. Collections may have members on different servers.
may have properties on different servers. Any resources may be cached Any resource may be cached or replicated for mobile computing or
or replicated for mobile computing or other reasons. Consequently, the other reasons. Consequently, the WebDAV extensions must be able to
WebDAV extensions must be able to operate in a distributed, replicated operate in a distributed, replicated environment.
environment.
4.6 Parsimony in Client-Server Interactions 4.6 Parsimony in Client-Server Interactions
The WebDAV extensions should keep to a minimum the number of The WebDAV extensions should keep to a minimum the number of
interactions between the client and the server needed to perform common interactions between the client and the server needed to perform
functions. For example, publishing a document to the Web will often mean common functions. For example, publishing a document to the Web will
publishing content together with related properties. A client may often often mean publishing content together with related properties. A
need to find out what version graph a particular resource belongs to, client may often need to find out what version graph a particular
or to find out which resource in a version graph is the published one. resource belongs to, or to find out which resource in a version graph
The extensions should make it possible to do these things efficiently. is the published one. The extensions should make it possible to do
these things efficiently.
4.7. Changes to HTTP 4.7. Changes to HTTP
WebDAV adds a number of new types of objects to the Web: properties, WebDAV adds a number of new types of objects to the Web: properties,
collections, version graphs, etc. Existing HTTP methods such as collections, version graphs, etc. Existing HTTP methods such as
DELETE and PUT will have to operate in well-defined ways in this DELETE and PUT will have to operate in well-defined ways in this
expanded environment. WebDAV should explicitly address not only new expanded environment. WebDAV should explicitly address not only new
methods, headers, and MIME types, but also any required changes to the methods, headers, and MIME types, but also any required changes to
existing HTTP methods and headers. the existing HTTP methods and headers.
4.8. Alternate Transport Mechanisms 4.8. Alternate Transport Mechanisms
It may be desirable to transport WebDAV requests and responses by other It may be desirable to transport WebDAV requests and responses by
mechanisms, particularly EMail, in addition to HTTP. The WebDAV protocol other mechanisms, particularly EMail, in addition to HTTP. The
specification should not preclude a future body from developing an WebDAV protocol specification should not preclude a future body from
interoperability specification for disconnected operation via EMail. developing an interoperability specification for disconnected
operation via EMail.
5. Requirements 5. Requirements
In the requirement descriptions below, the requirement will be stated, In the requirement descriptions below, the requirement will be
followed by its rationale. stated, followed by its rationale.
5.1. Properties 5.1. Properties
5.1.1. Functional Requirements 5.1.1. Functional Requirements
It must be possible to create, modify, read and delete arbitrary It must be possible to create, modify, read and delete arbitrary
properties on resources of any media type. properties on resources of any media type.
5.1.2. Rationale 5.1.2. Rationale
Properties describe resources of any media type. They may Properties describe resources of any media type. They may include
include bibliographic information such as author, title, publisher, bibliographic information such as author, title, publisher, and
and subject, constraints on usage, PICS ratings, etc. These subject, constraints on usage, PICS ratings, etc. These properties
properties have many uses, such as supporting searches on property have many uses, such as supporting searches on property values,
values, enforcing copyrights, and the creation of catalog entries as enforcing copyrights, and the creation of catalog entries as
placeholders for objects which are not available in electronic form, or placeholders for objects which are not available in electronic form,
which will be available later. or which will be available later.
5.2. Links 5.2. Links
5.2.1. Functional Requirements 5.2.1. Functional Requirements
It must be possible to create, modify, read and delete typed It must be possible to create, modify, read and delete typed links
links between resources of any media type. between resources of any media type.
5.2.2. Rationale 5.2.2. Rationale
One type of link between resources is the hypertext link, which is One type of link between resources is the hypertext link, which is
browsable using a hypertext style point-and-click user interface. Links, browsable using a hypertext style point-and-click user interface.
whether they are browsable hypertext links, or simply a means of Links, whether they are browsable hypertext links, or simply a means
capturing a connection between resources, have many purposes. Links of capturing a relationship between resources, have many purposes.
can support pushbutton printing of a multi-resource document in a Links can support pushbutton printing of a multi-resource document in
prescribed order, jumping to the access control page for a resource, a prescribed order, jumping to the access control page for a
and quick browsing of related information, such as a table of contents, resource, and quick browsing of related information, such as a table
an index, a glossary, a bibliographic record, help pages, etc. While of contents, an index, a glossary, a bibliographic record, help
link support is provided by the HTML "LINK" element, this is limited pages, etc. While link support is provided by the HTML "LINK"
only to HTML resources [HTML]. Similar support is needed for bitmap image element, this is limited only to HTML resources [HTML]. Similar
types, and other non-HTML media types. support is needed for bitmap image types, and other non-HTML media
types.
5.3. Locking 5.3. Locking
5.3.1. General Principles 5.3.1. General Principles
5.3.1.1. Independence of locks. It must be possible to lock a resource 5.3.1.1. Independence of locks. It must be possible to lock a
without re-reading the resource, and without committing to editing the resource without performing an additional retrieval of the resource,
resource. and without committing to editing the resource.
5.3.1.2. Multi-Resource Locking. It must be possible to take out a 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, lock on multiple resources residing on the same server in a single
and this locking operation must be atomic across these resources. action, and this locking operation must be atomic across these
resources.
5.3.2. Functional Requirements 5.3.2. Functional Requirements
5.3.2.1. Write Locks. It must be possible to restrict modification of 5.3.2.1. Write Locks. It must be possible to restrict modification of
a resource to a specific person. a resource to a specific person.
5.3.2.2. Lock Query. It must be possible to find out whether a given 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. 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.2.3. Unlock. It must be possible to remove a lock.
5.3.3. Rationale 5.3.3. Rationale
At present, the Web provides limited support for preventing two or more At present, the Web provides limited support for preventing two or
people from overwriting each other's modifications when they save to a more people from overwriting each other's modifications when they
given URI. Furthermore, there is no way to discover whether someone else save to a given URI. Furthermore, there is no way to discover whether
is currently making modifications to a resource. This is known as the someone else is currently making modifications to a resource. This is
"lost update problem," or the "overwrite problem." Since there can be known as the "lost update problem," or the "overwrite problem." Since
significant cost associated with discovering and repairing lost there can be significant cost associated with discovering and
modifications, preventing this problem is crucial for supporting repairing lost modifications, preventing this problem is crucial for
distributed authoring. A write lock ensures that only one person may supporting distributed authoring. A write lock ensures that only one
modify a resource, preventing overwrites. Furthermore, locking support person may modify a resource, preventing overwrites. Furthermore,
is a key component of many versioning schemes, a desirable capability locking support is a key component of many versioning schemes, a
for distributed authoring. desirable capability for distributed authoring.
An author may wish to lock an entire web of resources even though he 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 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 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 web is consistent in his distributed authoring tool, it will then be
consistent when he writes it to the server. Because of this, it should consistent when he writes it to the server. Because of this, it
be possible to take out a lock without also causing transmission of the should be possible to take out a lock without also causing
contents of a resource. transmission of the contents of a resource.
It is often necessary to guarantee that a lock or unlock operation It is often necessary to guarantee that a lock or unlock operation
occurs at the same time across multiple resources, a feature which is occurs at the same time across multiple resources, a feature which is
supported by the multiple-resource locking requirement. This is useful supported by the multiple-resource locking requirement. This is
for preventing a collision between two people trying to establish locks useful for preventing a collision between two people trying to
on the same set of resources, since with multi-resource locking, one of establish locks on the same set of resources, since with multi-
the two people will get a lock. If this same multiple-resource locking resource locking, one of the two people will get a lock. If this same
scenario was repeated by using atomic lock operations iterated across multiple-resource locking scenario was repeated by using atomic lock
the resources, the result would be a splitting of the locks between the operations iterated across the resources, the result would be a
two people, based on resource ordering and race conditions. splitting of the locks between the two people, based on resource
ordering and race conditions.
5.4. Reservations 5.4. Reservations
5.4.1. Functional Requirements 5.4.1. Functional Requirements
5.4.1.1. Reserve. It must be possible for a principal to register with 5.4.1.1. Reserve. It must be possible for a principal to register
the server an intent to edit a given resource, so that other principals with the server an intent to edit a given resource, so that other
can discover who intends to edit the resource. principals can discover who intends to edit the resource.
5.4.1.2. Reservation Query. It must be possible to find out whether 5.4.1.2. Reservation Query. It must be possible to find out whether a
a given resource has any active reservations, and if so, who currently given resource has any active reservations, and if so, who currently
holds reservations. holds reservations.
5.4.1.3. Release Reservation. It must be possible to release the 5.4.1.3. Release Reservation. It must be possible to release the
reservation. reservation.
5.4.2. Rationale 5.4.2. Rationale
Experience from configuration management systems has shown that people Experience from configuration management systems has shown that
need to know when they are about to enter a parallel editing situation. people need to know when they are about to enter a parallel editing
Once notified, they either decide not to edit in parallel with the situation. Once notified, they either decide not to edit in parallel
other authors, or they use out-of-band communication (face-to-face, with the other authors, or they use out-of-band communication (face-
telephone, etc.) to coordinate their editing to minimize the difficulty to-face, telephone, etc.) to coordinate their editing to minimize the
of merging their results. Reservations are separate from locking, since difficulty of merging their results. Reservations are separate from
a write lock does not necessarily imply a resource will be edited, and locking, since a write lock does not necessarily imply a resource
a reservation does not carry with it any access restrictions. This will be edited, and a reservation does not carry with it any access
capability supports versioning, since a check-out typically involves restrictions. This capability supports versioning, since a check-out
taking out a write lock, making a reservation, and getting the resource typically involves taking out a write lock, making a reservation, and
to be edited. getting the resource to be edited.
5.5. Retrieval of Unprocessed Source for Editing 5.5. Retrieval of Unprocessed Source for Editing
5.5.1. Functional Requirement 5.5.1. Functional Requirement
The source of any given resource must be retrievable. The source of any given resource must be retrievable by any principal
with authorization to edit the resource.
5.5.2. Rationale 5.5.2. Rationale
There are many cases where the source stored on a server does There are many cases where the source stored on a server does not
not correspond to the actual entity transmitted in response to an HTTP correspond to the actual entity transmitted in response to an HTTP
GET. Current known cases are server side include directives, and GET. Current known cases are server side include directives, and
Standard Generalized Markup Language (SGML) source which is Standard Generalized Markup Language (SGML) source which is converted
converted on the fly to HyperText Markup Language (HTML) [HTML] output on the fly to HyperText Markup Language (HTML) [HTML] output
entities. There are many possible cases, such as automatic conversion entities. There are many possible cases, such as automatic conversion
of bitmap images into several variant bitmap media types (e.g. GIF, of bitmap images into several variant bitmap media types (e.g. GIF,
JPEG), and automatic conversion of an application's native media type JPEG), and automatic conversion of an application's native media type
into HTML. As an example of this last case, a word processor could into HTML. As an example of this last case, a word processor could
store its native media type on a server which automatically converts store its native media type on a server which automatically converts
it to HTML. A GET of this resource would retrieve the HTML. Retrieving it to HTML. A GET of this resource would retrieve the HTML.
the source would retrieve the word processor native format. Retrieving the source would retrieve the word processor native
format.
5.6. Partial Write. 5.6. Partial Write.
5.6.1. Functional Requirement 5.6.1. Functional Requirement
After editing a resource, it must be possible to write only the changes After editing a resource, it must be possible to write only the
to the resource, rather than retransmitting the entire resource. changes to the resource, rather than retransmitting the entire
resource.
5.6.2. Rationale 5.6.2. Rationale
During distributed editing which occurs over wide geographic separations During distributed editing which occurs over wide geographic
and/or over low bandwidth connections, it is extremely inefficient separations and/or over low bandwidth connections, it is extremely
and frustrating to rewrite a large resource after minor changes, such inefficient and frustrating to rewrite a large resource after minor
as a one-character spelling correction. Support is needed for changes, such as a one-character spelling correction. Support is
transmitting "insert" (e.g., add this sentence in the middle of a needed for transmitting "insert" (e.g., add this sentence in the
document) and "delete" (e.g. remove this paragraph from the middle of middle of a document) and "delete" (e.g. remove this paragraph from
a document) style updates. Support for partial resource updates will the middle of a document) style updates. Support for partial resource
make small edits more efficient, and allow distributed authoring tools updates will make small edits more efficient, and allow distributed
to scale up for editing large documents. authoring tools to scale up for editing large documents.
5.7. Name Space Manipulation 5.7. Name Space Manipulation
5.7.1. Copy 5.7.1. Copy
5.7.1.1. Functional Requirements 5.7.1.1. Functional Requirements
It must be possible to duplicate a resource without a client loading, It must be possible to duplicate a resource without a client loading,
then resaving the resource. After the copy operation, the content of then resaving the resource. After the copy operation, a modification
the destination resource must be octet for octet identical to the to either resource must not cause a modification to the other.
content of the source resource. A modification to either resource must
not cause a modification to the other.
5.7.1.2. Rationale 5.7.1.2. Rationale
There are many reasons why a resource might need to be duplicated, such There are many reasons why a resource might need to be duplicated,
as changing ownership, preparing for major modifications, or making such as changing ownership, preparing for major modifications, or
a backup. Due to network costs associated with loading and saving a making a backup. Due to network costs associated with loading and
resource, it is far preferable to have a server perform a resource copy saving a resource, it is far preferable to have a server perform a
than a client. If a copied resource records which resource it is a copy resource copy than a client.
of, then it would be possible for a cache to avoid loading the copied
resource if it already locally stores the original.
5.7.2. Move/Rename 5.7.2. Move/Rename
5.7.2.1. Functional Requirements 5.7.2.1. Functional Requirements
It must be possible to change the location of a resource without It must be possible to change the location of a resource without a
a client loading, then resaving the resource under a different name. client loading, then resaving the resource under a different name.
After the move operation, it must no longer be possible to access the
After the move operation, the content of the resource at its new resource at its original location.
location must be octet for octet identical to the content of the prior
resource. It must no longer be possible to access the resource at its
original location.
5.7.2.2. Rationale 5.7.2.2. Rationale
It is often necessary to change the name of a resource, for example due It is often necessary to change the name of a resource, for example
to adoption of a new naming convention, or if a typing error was made due to adoption of a new naming convention, or if a typing error was
entering the name originally. Due to network costs, it is undesirable made entering the name originally. Due to network costs, it is
to perform this operation by loading, then resaving the resource, undesirable to perform this operation by loading, then resaving the
followed by a delete of the old resource. Similarly, a single rename resource, followed by a delete of the old resource. Similarly, a
operation is more efficient than a copy followed by a delete operation. single rename operation is more efficient than a copy followed by a
Note that moving a resource is considered the same function as renaming delete operation. Note that moving a resource is considered the same
a resource. function as renaming a resource.
5.8. Collections 5.8. Collections
A collection is a resource that is a container for other resources, A collection is a resource that is a container for other resources,
including other collections. A resource may belong to a collection including other collections. A resource may belong to a collection
either directly or by reference. If a resource belongs to a either directly or by reference. If a resource belongs to a
collection directly, name space operations like copy, move, and collection directly, name space operations like copy, move, and
delete applied to the collection also apply to the resource. If a delete applied to the collection also apply to the resource. If a
resource belongs to a collection by reference, name space operations resource belongs to a collection by reference, name space operations
applied to the collection affect only the reference, not the resource applied to the collection affect only the reference, not the resource
itself. itself.
5.8.1. Functional Requirements 5.8.1. Functional Requirements
5.8.1.1. List Collection. A listing of all resources in a specific 5.8.1.1. List Collection. A listing of all resources in a specific
collection must be accessible. collection must be accessible.
5.8.1.2. Make Collection. It must be possible to create a new 5.8.1.2. Make Collection. It must be possible to create a new
collection. collection.
5.8.1.3. Add to Collection. It must be possible to add a resource to a 5.8.1.3. Add to Collection. It must be possible to add a resource to
collection directly or by reference. a collection directly or by reference.
5.8.1.4. Remove from Collection. It must be possible to remove a 5.8.1.4. Remove from Collection. It must be possible to remove a
resource from a collection. resource from a collection.
5.8.2. Rationale 5.8.2. Rationale
In [URL] 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,
file schemes) contain names that can be considered hierarchical." and file schemes) contain names that can be considered hierarchical."
Especially for HTTP servers which directly map all or part of their URL Especially for HTTP servers which directly map all or part of their
name space into a filesystem, it is very useful to get a listing of all URL name space into a filesystem, it is very useful to get a listing
resources located at a particular hierarchy level. This functionality of all resources located at a particular hierarchy level. This
supports "Save As..." dialog boxes, which provide a listing of the functionality supports "Save As..." dialog boxes, which provide a
entities at a current hierarchy level, and allow navigation through listing of the entities at a current hierarchy level, and allow
the hierarchy. It also supports the creation of graphical visualizations navigation through the hierarchy. It also supports the creation of
(typically as a network) of the hypertext structure among the entities graphical visualizations (typically as a network) of the hypertext
at a hierarchy level, or set of levels. It also supports a tree structure among the entities at a hierarchy level, or set of levels.
visualization of the entities and their hierarchy levels. It also supports a tree visualization of the entities and their
hierarchy levels.
In addition, document management systems may want to make their In addition, document management systems may want to make their
documents accessible through the Web. They typically allow the documents accessible through the Web. They typically allow the
organization of documents into collections, and so also want their users organization of documents into collections, and so also want their
to be able to view the collection hierarchy through the Web. users to be able to view the collection hierarchy through the Web.
There are many instances where there is not a strong correlation between There are many instances where there is not a strong correlation
a URL hierarchy level and the notion of a collection. One example is a between a URL hierarchy level and the notion of a collection. One
server in which the URL hierarchy level maps to a computational process example is a server in which the URL hierarchy level maps to a
which performs some resolution on the name. In this case, the contents computational process which performs some resolution on the name. In
of the URL hierarchy level can vary depending on the input to the this case, the contents of the URL hierarchy level can vary depending
computation, and the number of resources accessible via the computation on the input to the computation, and the number of resources
can be very large. It does not make sense to implement a directory accessible via the computation can be very large. It does not make
feature for such a name space. However, the utility of listing the sense to implement a directory feature for such a name space.
contents of those URL hierarchy levels which do correspond to However, the utility of listing the contents of those URL hierarchy
collections, such as the large number of HTTP servers which map their levels which do correspond to collections, such as the large number
name space to a filesystem, argue for the inclusion of this capability, of HTTP servers which map their name space to a filesystem, argue for
despite not being meaningful in all cases. If listing the contents of the inclusion of this capability, despite not being meaningful in all
a URL hierarchy level does not makes sense for a particular URL, then cases. If listing the contents of a URL hierarchy level does not
a "405 Method Not Allowed" status code could be issued. 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 The ability to create collections to hold related resources supports
management of a name space by packaging its members into small, related management of a name space by packaging its members into small,
clusters. The utility of this capability is demonstrated by the broad related clusters. The utility of this capability is demonstrated by
implementation of directories in recent operating systems. The ability the broad implementation of directories in recent operating systems.
to create a collection also supports the creation of "Save As..." The ability to create a collection also supports the creation of
dialog boxes with "New Level/Folder/Directory" capability, common in "Save As..." dialog boxes with "New Level/Folder/Directory"
many applications. capability, common in many applications.
5.9. Versioning 5.9. Versioning
5.9.1. Background and General Principles 5.9.1. Background and General Principles
5.9.1.1. Stability of versions. Most versioning systems are intended to 5.9.1.1. Stability of versions. Most versioning systems are intended
provide an accurate record of the history of evolution of a document. to provide an accurate record of the history of evolution of a
This accuracy is ensured by the fact that a version eventually becomes document. This accuracy is ensured by the fact that a version
"frozen" and immutable. Once a version is frozen, further changes will eventually becomes "frozen" and immutable. Once a version is frozen,
create new versions rather than modifying the original. In order for further changes will create new versions rather than modifying the
caching and persistent references to be properly maintained, a client original. In order for caching and persistent references to be
must be able to determine that a version has been frozen. Any successful properly maintained, a client must be able to determine that a
attempt to retrieve a frozen version of a resource will always retrieve version has been frozen. Any successful attempt to retrieve a frozen
exactly the same content, or return an error if that version (or the version of a resource will always retrieve exactly the same content,
resource itself) is no longer available. or return an error if that version (or the resource itself) is no
longer available.
5.9.1.2. Operations for Creating New Versions 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:
Version management systems vary greatly in the operations they require, o Reserve existing version
the order of the operations, and how they are combined into atomic o Lock existing version
functions. In the most complete cases, the logical operations involved o Retrieve existing version
are: o Request or suggest identifier for new version
o Reserve existing version o Write new version
o Lock existing version o Release lock
o Retrieve existing version o Release reservation
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 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 With the exception of requesting a new version identifier, all of
servers to adopt whatever policies they wish with regard to these these operations have applications outside of versioning and are
operations and enforcing enough uniformity to keep client either already part of HTTP or are discussed in earlier sections of
implementations simple. these requirements. Typically, versioning systems combine
reservation, locking, and retrieval -- or some subset of these --
into an atomic checkout function. They combine writing, releasing
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.
5.9.1.3. The Versioning Model 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.
Each version typically stands in a "derived from" relationship to its 5.9.1.3. The Versioning Model. Each version typically stands in a
predecessor(s). It is possible to derive several different versions "derived from" relationship to its predecessor(s). It is possible to
from a single version (branching), and to derive a single version from derive several different versions from a single version (branching),
several versions (merging). Consequently, the collection of related and to derive a single version from several versions (merging).
versions forms a directed acyclic graph. In the following discussion, Consequently, the collection of related versions forms a directed
this graph will be called a "version graph". Each node of this graph acyclic graph. In the following discussion, this graph will be
is a "version" or "member of the version graph". The arcs of the graph called a "version graph". Each node of this graph is a "version" or
capture the "derived from" relationships. "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 It is also possible for a single resource to participate in multiple
version graphs. version graphs.
The WebDAV extensions should support this versioning model, though The WebDAV extensions should support this versioning model, though
particular servers may restrict it in various ways. particular servers may restrict it in various ways.
5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and 5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and
Haake and Hicks [VSE], have discussed the notion of versioning styles Haake and Hicks [VSE], have discussed the notion of versioning styles
(referred to here as versioning policies, to reflect the nature of (referred to here as versioning policies, to reflect the nature of
client/server interaction) as one way to think about the different client/server interaction) as one way to think about the different
policies that versioning systems implement. Versioning policies include policies that versioning systems implement. Versioning policies
decisions on the shape of version histories (linear or branched), the include decisions on the shape of version histories (linear or
granularity of change tracking, locking requirements made by a server, branched), the granularity of change tracking, locking requirements
etc. The protocol should clearly identify the policies that it dictates made by a server, etc. The protocol should clearly identify the
and the policies that are left up to versioning system implementors or policies that it dictates and the policies that are left up to
administrators. versioning system implementors or administrators.
5.9.1.5. It is possible to version resources of any media type. 5.9.1.5. It is possible to version resources of any media type.
5.9.2. Functional Requirements 5.9.2. Functional Requirements
5.9.2.1. Referring to a version graph. There must be a way to refer to 5.9.2.1. Referring to a version graph. There must be a way to refer
a version graph as a whole. to a version graph as a whole.
Some queries and operations apply, not to any one member of a Some queries and operations apply, not to any one member of a version
version graph, but to the version graph as a whole. For example, a graph, but to the version graph as a whole. For example, a client
client may request that an entire graph be moved, or may ask for a may request that an entire graph be moved, or may ask for a version
version history. In these cases, a way to refer to the whole version history. In these cases, a way to refer to the whole version graph is
graph is required. required.
5.9.2.2. Referring to a specific member of a version graph. There must 5.9.2.2. Referring to a specific member of a version graph. There
be a way to refer to each member of a version graph. This means that must be a way to refer to each member of a version graph. This means
each member of the graph is itself a resource. 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 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, 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. 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 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 version graph, or whether a resource is itself a member of a version
graph. graph.
A resource may be a simple, non-versioned resource, or it may be a 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 version graph, or it may be a member of a version graph. A client
to be able to tell which sort of resource it is accessing. 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 5.9.2.4. There must be a way to refer to a server-defined default
member of a version graph. member of a version graph.
The server should return a default version of a resource for requests 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 that ask for the default version, as well as for requests where no
specific version information is provided. This is one of the simplest specific version information is provided. This is one of the simplest
ways to guarantee non-versioning client compatibility. This does not ways to guarantee non-versioning client compatibility. This does not
rule out the possibility of a server returning an error when no sensible rule out the possibility of a server returning an error when no
default exists. sensible default exists.
It may also be desirable to be able to refer to other special members 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 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 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 several branches, it may be useful to be able to request the tip
of any branch. version of any branch.
5.9.2.5. It must be possible, given a reference to a member of a version 5.9.2.5. It must be possible, given a reference to a member of a
graph, to find out which version graph(s) that resource belongs to. version graph, to find out which version graph(s) that resource
belongs to.
This makes it possible to understand the versioning context of the This makes it possible to understand the versioning context of the
resource. It makes it possible to retrieve a version history for 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 graphs to which it belongs, and to browse the version graph. It also
supports some comparison operations: It makes it possible to determine supports some comparison operations: It makes it possible to
whether two references designate members of the same version graph. 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 5.9.2.6. Navigation of a version graph. Given a reference to a
of a version graph, it must be possible to discover and access the member of a version graph, it must be possible to discover and access
following related members of the version graph. 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 o root member of the graph
versions related to a resource currently being examined. o predecessor member(s)
o successor member(s)
o default member of the graph
5.9.2.7. Version Topology. There must be a way to retrieve the complete It must be possible in some way for a versioning client to access
version topology for a version graph, including information about all versions related to a resource currently being examined.
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 5.9.2.7. Version Topology. There must be a way to retrieve the
used for a new member of a version graph. The server may refuse to use complete version topology for a version graph, including information
the client's suggested version identifier. The server should tell the about all members of the version graph. The format for this
client what version identifier it has assigned to the new member of the information must be standardized so that the basic information can be
version graph. 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.9. A version identifier must be unique across a version graph. 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.10. A client must be able to supply version-specific properties to 5.9.2.9. A version identifier must be unique across a version graph.
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 5.9.2.10. A client must be able to supply version-specific properties
about a version tree, including which versions are locked, which are to be associated with a new member of a version graph. (See Section
reserved for editing, and by whom (Session Tracking). 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 5.9.3. Rationale
Versioning in the context of the world-wide web offers a variety of Versioning in the context of the world-wide web offers a variety of
benefits: benefits:
It provides infrastructure for efficient and controlled management of It provides infrastructure for efficient and controlled management of
large evolving web sites. Modern configuration management systems are large evolving web sites. Modern configuration management systems are
built on some form of repository that can track the revision history of built on some form of repository that can track the revision history
individual resources, and provide the higher-level tools to manage of individual resources, and provide the higher-level tools to manage
those saved versions. Basic versioning capabilities are required to those saved versions. Basic versioning capabilities are required to
support such systems. support such systems.
It allows parallel development and update of single resources. Since It allows parallel development and update of single resources. Since
versioning systems register change by creating new objects, they versioning systems register change by creating new objects, they
enable simultaneous write access by allowing the creation of variant enable simultaneous write access by allowing the creation of variant
versions. Many also provide merge support to ease the reverse operation. versions. Many also provide merge support to ease the reverse
operation.
It provides a framework for coordinating changes to resources. While It provides a framework for coordinating changes to resources. While
specifics vary, most systems provide some method of controlling or specifics vary, most systems provide some method of controlling or
tracking access to enable collaborative resource development. tracking access to enable collaborative resource development.
It allows browsing through past and alternative versions of a resource. It allows browsing through past and alternative versions of a
Frequently the modification and authorship history of a resource is resource. Frequently the modification and authorship history of a
critical information in itself. resource is critical information in itself.
It provides stable names that can support externally stored links for It provides stable names that can support externally stored links for
annotation and link-server support. Both annotation and link servers annotation and link-server support. Both annotation and link servers
frequently need to store stable references to portions of resources frequently need to store stable references to portions of resources
that are not under their direct control. By providing stable states of that are not under their direct control. By providing stable states
resources, version control systems allow not only stable pointers into of resources, version control systems allow not only stable pointers
those resources, but also well-defined methods to determine the into those resources, but also well-defined methods to determine the
relationships of those states of a resource. relationships of those states of a resource.
It allows explicit semantic representation of single resources with It allows explicit semantic representation of single resources with
multiple states. A versioning system directly represents the fact that multiple states. A versioning system directly represents the fact
a resource has an explicit history, and a persistent identity across that a resource has an explicit history, and a persistent identity
the various states it has had during the course of that history. across the various states it has had during the course of that
history.
5.10. Variants 5.10. Variants
Detailed requirements for variants will be developed in a separate
document.
5.10.1. Functional Requirements 5.10.1. Functional Requirements
It must be possible to send variants to the server, describing the It must be possible to send variants to the server, describing the
relationships between the variants and their parent resource. In relationships between the variants and their parent resource. In
addition, it must be possible to write and retrieve variants of addition, it must be possible to write and retrieve variants of
property labels, property descriptions, and property values. property labels, property descriptions, and property values.
5.10.2. Rationale 5.10.2. Rationale
The HTTP working group is addressing problems of content negotiation The HTTP working group is addressing problems of content negotiation
and retrieval of variants of a resource. To extend this work to an and retrieval of variants of a resource. To extend this work to an
authoring environment, WEBDAV must standardize mechanisms for authors authoring environment, WEBDAV must standardize mechanisms for authors
to use when submitting variants to a server. Authors need to be able to use when submitting variants to a server. Authors need to be able
to provide variants in different file or document formats, for different to provide variants in different file or document formats, for
uses. They need to provide variants optimized for different for different different uses. They need to provide variants optimized for different
clients and for different output devices. They need to be able to provide clients and for different output devices. They need to be able to
variants in different languages in the international environment of the Web. provide variants in different languages in the international
In support of internationalization requirements (See 5.12 below), variants environment of the Web. In support of internationalization
need to be supported not just for the content of resources, but for any requirements (See 5.12 below), variants need to be supported not just
information intended for human use, such as property values, labels, and for the content of resources, but for any information intended for
descriptions. human use, such as property values, labels, and descriptions.
5.11. Security 5.11. Security
5.11.1. Authentication. The WebDAV specification should state how the 5.11.1. Authentication. The WebDAV specification should state how the
WebDAV extensions interoperate with existing authentication schemes, WebDAV extensions interoperate with existing authentication schemes,
and should make recommendations for using those schemes. and should make recommendations for using those schemes.
5.11.2. Access Control. Access control requirements are specified 5.11.2. Access Control. Access control requirements are specified in
in a separate access control draft [AC]. a separate access control work in progress [AC].
5.11.3. Interoperability with Security Protocols. The WebDAV 5.11.3. Interoperability with Security Protocols. The WebDAV
specification should provide a minimal list of security protocols specification must provide a minimal list of security protocols which
which any compliant server / client should support. These protocols any compliant server / client must support. These protocols should
should insure the authenticity of messages and the privacy and insure the authenticity of messages and the privacy and integrity of
integrity of messages in transit. messages in transit.
5.12. Internationalization 5.12. Internationalization
5.12.1. Character Sets and Languages 5.12.1. Character Sets and Languages
Since Web distributed authoring occurs in a multi-lingual Since Web distributed authoring occurs in a multi-lingual
environment, information intended for user comprehension must environment, information intended for user comprehension must conform
conform to the IETF Character Set Policy [CHAR]. This policy to the IETF Character Set Policy [CHAR]. This policy addresses
addresses character sets and encodings, and language tagging. character sets and encodings, and language tagging.
5.12.2. Rationale 5.12.2. Rationale
In the international environment of the Internet, it is important In the international environment of the Internet, it is important to
to insure that any information intended for user comprehension can be insure that any information intended for user comprehension can be
displayed in a writing system and language agreeable to both the displayed in a writing system and language agreeable to both the
client and the server. The information encompassed by this requirement client and the server. The information encompassed by this
includes not only the content of resources, but also such things as requirement includes not only the content of resources, but also such
display names and descriptions of properties, property values, and things as display names and descriptions of properties, property
status messages. values, and status messages.
6. Acknowledgements 6. Acknowledgements
Our understanding of these issues has emerged as the result of much Our understanding of these issues has emerged as the result of much
thoughtful discussion, email, and assistance by many people, who thoughtful discussion, email, and assistance by many people, who
deserve recognition for their effort. deserve recognition for their effort.
Terry Allen, tallen@sonic.net Terry Allen, tallen@sonic.net
Alan Babich, FileNet, babich@filenet.com Alan Babich, FileNet, babich@filenet.com
Dylan Barrell, Open Text, dbarrell@opentext.ch Dylan Barrell, Open Text, dbarrell@opentext.ch
Barbara Bazemore, PC DOCS, barbarab@pcdocs.com Barbara Bazemore, PC DOCS, barbarab@pcdocs.com
Martin Cagan, Continuus Software, Marty_Cagan@continuus.com Martin Cagan, Continuus Software, Marty_Cagan@continuus.com
Steve Carter, Novell, srcarter@novell.com Steve Carter, Novell, srcarter@novell.com
Dan Connolly, World Wide Web Consortium, connolly@w3.org Dan Connolly, World Wide Web Consortium, connolly@w3.org
Jim Cunningham, Netscape, jfc@netscape.com Jim Cunningham, Netscape, jfc@netscape.com
Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov
Mark Day, Lotus, Mark_Day@lotus.com Mark Day, Lotus, Mark_Day@lotus.com
Martin J. Duerst, mduerst@ifi.unizh.ch Martin J. Duerst, mduerst@ifi.unizh.ch
Asad Faizi, Netscape, asad@netscape.com Asad Faizi, Netscape, asad@netscape.com
Ron Fein, Microsoft, ronfe@microsoft.com Ron Fein, Microsoft, ronfe@microsoft.com
David Fiander, Mortice Kern Systems, davidf@mks.com David Fiander, Mortice Kern Systems, davidf@mks.com
Roy Fielding, U.C. Irvine, fielding@ics.uci.edu Roy Fielding, U.C. Irvine, fielding@ics.uci.edu
Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com
Yaron Y. Goland, Microsoft, yarong@microsoft.com Yaron Y. Goland, Microsoft, yarong@microsoft.com
Phill Hallam-Baker, MIT, hallam@ai.mit.edu Phill Hallam-Baker, MIT, hallam@ai.mit.edu
Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com
Andre van der Hoek, University of Colorado, Boulder, Andre van der Hoek, University of Colorado, Boulder,
andre@cs.colorado.edu andre@cs.colorado.edu
Del Jensen, Novell, dcjensen@novell.com Del Jensen, Novell, dcjensen@novell.com
Gail Kaiser, Columbia University, kaiser@cs.columbia.edu Gail Kaiser, Columbia University, kaiser@cs.columbia.edu
Rohit Khare, World Wide Web Consortium, khare@w3.org Rohit Khare, World Wide Web Consortium, khare@w3.org
Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com
Ben Laurie, A.L. Digital, ben@algroup.co.uk Ben Laurie, A.L. Digital, ben@algroup.co.uk
Mike Little, Bellcore, little@bellcore.com Mike Little, Bellcore, little@bellcore.com
Dave Long, America Online, dave@sb.aol.com Dave Long, America Online, dave@sb.aol.com
Larry Masinter, Xerox PARC, masinter@parc.xerox.com Larry Masinter, Xerox PARC, masinter@parc.xerox.com
Murray Maloney, SoftQuad, murray@sq.com Murray Maloney, SoftQuad, murray@sq.com
Jim Miller, World Wide Web Consortium, jmiller@w3.org Jim Miller, World Wide Web Consortium, jmiller@w3.org
Howard S. Modell, Boeing, howard.s.modell@boeing.com Howard S. Modell, Boeing, howard.s.modell@boeing.com
Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu
Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org
Jon Radoff, NovaLink, jradoff@novalink.com Jon Radoff, NovaLink, jradoff@novalink.com
Alan Robertson, alanr@bell-labs.com Alan Robertson, alanr@bell-labs.com
Henry Sanders, Microsoft, Henry Sanders, Microsoft,
Andrew Schulert, Microsoft, andyschu@microsoft.com Andrew Schulert, Microsoft, andyschu@microsoft.com
Christopher Seiwald, Perforce Software, seiwald@perforce.com Christopher Seiwald, Perforce Software, seiwald@perforce.com
Einar Stefferud, stef@nma.com Einar Stefferud, stef@nma.com
Richard Taylor, U.C. Irvine, taylor@ics.uci.edu Richard Taylor, U.C. Irvine, taylor@ics.uci.edu
Robert Thau, MIT, rst@ai.mit.edu Robert Thau, MIT, rst@ai.mit.edu
Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com
Dan Whelan, FileNet, dan@FILENET.COM Dan Whelan, FileNet, dan@FILENET.COM
Gregory J. Woodhouse, gjw@wnetc.com Gregory J. Woodhouse, gjw@wnetc.com
7. References 7. References
[AC] J. Radoff, "Requirements for Access Control within [AC] J. Radoff, "Requirements for Access Control within Distributed
Distributed Authoring and Versioning Environments on the World Authoring and Versioning Environments on the World Wide Web",
Wide Web". unpublished manuscript, <http://lists.w3.org/Archives/Public/w3c-
dist-auth/1997AprJun/0183.html>
[CHAR] H.T. Alvestrand, "IETF Policy on Character Sets and Languages", [CHAR] Alvestrand, H., "IETF Policy on Character Sets and Languages",
June 1997, working draft, draft-alvestrand-charset-policy-00.txt. RFC 2277, January 1998.
[CM] P. Feiler, "Configuration Management Models in Commercial [CM] P. Feiler, "Configuration Management Models in Commercial
Environments", Software Engineering Institute Technical Report Environments", Software Engineering Institute Technical Report
CMU/SEI-91-TR-7, CMU/SEI-91-TR-7,
<http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html> <http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html>
[HTML] T. Berners-Lee, D. Connolly, "HyperText Markup Language [HTML] Berners-Lee, T., and D. Connolly, "HyperText Markup Language
Specification - 2.0", RFC 1866, MIT/LCS, November 1995. Specification - 2.0", RFC 1866, November 1995.
[HTTP] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
U.C. Irvine, DEC, MIT/LCS, January 1997. January 1997.
[ISO 10646] ISO/IEC 10646-1:1993. "International Standard -- [ISO 10646] ISO/IEC 10646-1:1993. "International Standard --
Information Technology -- Universal Multiple-Octet Coded Character Information Technology -- Universal Multiple-Octet Coded Character
Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane." Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane."
[URL] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource [URL] Berners-Lee, T., Masinter, L., and M. McCahill. "Uniform
Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, Resource Locators (URL)", RFC 1738, December 1994.
December 1994.
[VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", [VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning
Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996, Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext,
pages 224-234. 1996, pages 224-234.
8. Authors' Addresses 8. Authors' Addresses
Judith Slein Judith Slein
Xerox Corporation Xerox Corporation
800 Phillips Road 128-29E 800 Phillips Road 128-29E
Webster, NY 14580 Webster, NY 14580
EMail: slein@wrc.xerox.com EMail: slein@wrc.xerox.com
Fabio Vitali Fabio Vitali
Department of Computer Science Department of Computer Science
University of Bologna University of Bologna
ITALY ITALY
EMail: fabio@cs.unibo.it 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 E. James Whitehead, Jr.
EMail: ejw@ics.uci.edu Department of Information and Computer Science
University of California
Irvine, CA 92697-3425
David G. Durand Fax: 714-824-4056
Department of Computer Science EMail: ejw@ics.uci.edu
Boston University
Boston, MA
EMail: dgd@cs.bu.edu David G. Durand
Department of Computer Science
Boston University
Boston, MA
Expires February 28, 1998 EMail: dgd@cs.bu.edu
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.
 End of changes. 133 change blocks. 
649 lines changed or deleted 652 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/