draft-ietf-webdav-version-goals-00.txt   draft-ietf-webdav-version-goals-01.txt 
WebDAV Working Group J. Stracke, Jim Amsden INTERNET-DRAFT Jim Amsden, IBM
INTERNET DRAFT Netscape, IBM draft-ietf-webdav-version-goals-01.txt Chris Kaler, Microsoft
J. Stracke, Netscape
Expires August, 1999 Expires December 26, 1999 June 26, 1999
Goals for Web Versioning Goals for Web Versioning
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is an Internet-Draft and is in full conformance with Internet-Drafts are working documents of the Internet Engineering Task
all provisions of Section 10 of RFC2026. Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
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 documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet- Drafts as reference material
as reference material or to cite them other than as "work in or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at
ietf-dav-versioning@w3.org, which may be joined by sending a
message with subject "subscribe" to
ietf-dav-versioning-request@w3.org. The main WebDAV mailing list at
w3c-dist-auth@w3.org may also be used for comments. To join the
mailing list, send a message with subject "subscribe" to
w3c-dist-auth-request@w3c.org. Discussions of the WebDAV versioning
working group are archived at
http://lists.w3.org/Archives/Public/ietf-dav-versioning/. Discussions
of the WebDAV working group are archived at
http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth.
Abstract Abstract
Versioning and configuration management are important features for Versioning and configuration management are important features for
controlling the evolution of remotely authored Web content. Parallel controlling the evolution of remotely authored Web content. Parallel
development leverages versioning capability to allow multiple authors development leverages versioning capability to allow multiple authors to
to simultaneously author Web content. These functions form a basis for simultaneously author Web content. These functions form a basis for
flexible, scaleable distributed authoring. This document describes a flexible, scaleable distributed authoring. This document describes a set
set of scenarios, functional, and non-functional requirements for of scenarios, functional, and non-functional requirements for web
web versioning extensions to the WebDAV protocol. It supersedes the versioning extensions to the WebDAV protocol. It supersedes the
versioning-related goals of [WEBDAV-GOALS]. versioning-related goals of [WEBDAV-GOALS].
Contents Table of Contents
GOALS FOR WEB VERSIONING 1 1 INTRODUCTION ...........................................2
Status of this Memo 1 1.1 Definitions .........................................4
Abstract 2 1.2 Storyboards .........................................6
Contents 2 1.3 Goals ..............................................14
Introduction 2 1.4 Rationale ..........................................23
Definitions 4 1.5 Non-goals ..........................................24
Scenarios 7 1.6 Security Considerations ............................25
Goals 17 1.7 References .........................................25
Rationale 29 1.8 Open Issues ........................................25
Non-goals 30
Security Considerations 31
References 31
Introduction 1 INTRODUCTION
Versioning, parallel development, and configuration management are Versioning, parallel development, and configuration management are
important features for remote authoring of Web content. Version important features for remote authoring of Web content. Version
management is concerned with tracking and accessing the history of management is concerned with tracking and accessing the history of
important states of a single Web resource, such as a standalone Web important states of a single Web resource, such as a standalone Web
page. Parallel development provides additional resource availability page. Parallel development provides additional resource
in multi-user, distributed environments and lets authors make changes availability in multi-user, distributed environments and lets
on the same resource at the same time, and merge those changes at some authors make changes on the same resource at the same time, and
later date. Configuration management addresses the problems of merge those changes at some later date. Configuration management
tracking and accessing multiple interrelated resources over time as addresses the problems of tracking and accessing multiple
sets of resources, not simply individual resources. Traditionally, interrelated resources over time as sets of resources, not simply
artifacts of software development, including code, design, test cases, individual resources. Traditionally, artifacts of software
requirements, help files, and more have been a focus of configuration development, including code, design, test cases, requirements, help
management. Web sites, comprised of multiple inter-linked resources files, and more have been a focus of configuration management. Web
(HTML, graphics, sound, CGI, and others), are another class of complex sites, comprised of multiple inter-linked resources (HTML,
graphics, sound, CGI, and others), are another class of complex
information artifacts that benefit from the application of information artifacts that benefit from the application of
configuration management. configuration management.
The WebDAV working group originally focused exclusively on defining The WebDAV working group originally focused exclusively on defining
version management capabilities for remote authoring applications and version management capabilities for remote authoring applications
group consensus on these features is reflected in [WEBDAV-GOALS]. and group consensus on these features is reflected in [WEBDAV-
However, as the WebDAV working group has constructed protocols for GOALS]. However, as the WebDAV working group has constructed
versioning functionality, it has become clear that while versioning protocols for versioning functionality, it has become clear that
functionality alone is useful for a range of content authoring while versioning functionality alone is useful for a range of
scenarios involving one, or a small set of resources, versioning alone content authoring scenarios involving one, or a small set of
is insufficient for managing larger sets of content. Protocol support resources, versioning alone is insufficient for managing larger
for parallel development and simple remote configuration management of sets of content. Protocol support for parallel development and
Web resources provides functionality for managing larger sets of simple remote configuration management of Web resources provides
interrelated content developed by multiple users at different functionality for managing larger sets of interrelated content
locations. This document contains a set of scenarios and a list of developed by multiple users at different locations.
the functional and non-functional goals for versioning, parallel
This document contains a set of scenarios and a list of the
functional and non-functional goals for versioning, parallel
development, and configuration management of Web resources. It development, and configuration management of Web resources. It
replaces the existing functional goals for versioning capability replaces the existing functional goals for versioning capability
described in [WEBDAV-GOALS], section 5.9. These scenarios and goals described in [WEBDAV-GOALS], section 5.9. These scenarios and goals
are used to develop a model of WebDAV versioning, which in turn is are used to develop a model of WebDAV versioning, which in turn is
used to develop the protocol that implements it. used to develop the protocol that implements it.
Version management is always a tradeoff between the goals for maximum Version management is always a tradeoff between the goals for
data integrity, maximum data availability, and ease of use. It is maximum data integrity, maximum data availability, and ease of use.
relatively easy to specify a design that satisfies any two of these It is relatively easy to specify a design that satisfies any two of
goals, but this is often at the expense of the third. For example, these goals, but this is often at the expense of the third. For
data availability and ease of use are easy to accomplish using example, data availability and ease of use are easy to accomplish
authoring servers that compromise data integrity by following a last using authoring servers that compromise data integrity by following
writer wins policy. In contrast, high data integrity and availability a last writer wins policy. In contrast, high data integrity and
are possible using branch and merge systems, but at the cost of ease availability are possible using branch and merge systems, but at
of use due to difficult merges. The requirements for WebDAV versioning the cost of ease of use due to difficult merges. The requirements
are based on compromises between these conflicting goals. WebDAV for WebDAV versioning are based on compromises between these
versioning specifies a set of mechanisms that can be exploited to conflicting goals. WebDAV versioning specifies a set of mechanisms
support a variety of policies allowing client applications and users that can be exploited to support a variety of policies allowing
to find a balance appropriate to their needs. client applications and users to find a balance appropriate to
their needs.
Definitions 1.1 Definitions
1. A basic resource is a resource that is not a collection or 1. A basic resource is a resource that is not a collection or
reference, i.e., an HTTP/1.1 resource. reference, i.e., an HTTP/1.1 resource.
2. A versioned resource is an abstraction for a resource which is 2. A versioned resource is an abstraction for a resource which is
subject to version control, a resource having a set of revisions, subject to version control, a resource having a set of
relationships between those revisions, revision names, and revisions, relationships between those revisions, revision
named branches that track the evolution of the resource. names, and named branches that track the evolution of the
resource.
3. A revision is a particular version of a versioned resource. An 3. A revision is a particular version of a versioned resource. An
immutable revision is a revision that once created, can never be immutable revision is a revision that once created, can never
changed without creating a new revision. A mutable revision is be changed without creating a new revision. A mutable revision
a revision that can change without creating a new version. is a revision that can change without creating a new version.
4. A working resource is an editable resource derived from a revision 4. A working resource is an editable resource derived from a
of a versioned resource by checking out the revision. A working revision of a versioned resource by checking out the revision.
resource can become a new revision, or overwrite an existing A working resource can become a new revision, or overwrite an
mutable revision on check in. existing mutable revision on check in.
5. A initial revision is the first revision of a versioned resource 5. A initial revision is the first revision of a versioned
and has no predecessors within the versioned resource. resource and has no predecessors within the versioned
resource.
6. A revision name is a unique name that can be used to refer to a 6. A revision name is a unique name that can be used to refer to
revision of a versioned resource. There are two types of revision a revision of a versioned resource. There are two types of
names, revision identifiers or labels as described below. revision names, revision identifiers or labels as described
below.
7. A revision identifier (or revision ID) is a revision name which 7. A revision identifier (or revision ID) is a revision name
uniquely and permanently identifies a revision of a versioned which uniquely and permanently identifies a revision of a
resource. Revision identifiers are assigned by the server when versioned resource. Revision identifiers are assigned by the
the revision is created and cannot be changed later to refer to server when the revision is created and cannot be changed
a different revision. later to refer to a different revision.
8. A label is a revision name which uniquely, but not necessarily 8. A label is a revision name which uniquely, but not necessarily
permanently identifies a revision of a versioned resource. A label permanently identifies a revision of a versioned resource. A
may be assigned to a revision, and may be changed to refer to label may be assigned to a revision, and may be changed to
a different revision at some later time. The same label may be refer to a different revision at some later time. The same
assigned to many different versioned resources. label may be assigned to many different versioned resources.
9. A predecessor of a revision is a revision from which this revision 9. A predecessor of a revision is a revision from which this
is created. A successor of a revision is a revision derived from revision is created. A successor of a revision is a revision
this revision. A revision may have one predecessor and multiple derived from this revision. A revision may have one
successors. The is-derived-from relationships between revisions of predecessor and multiple successors. The is-derived-from
a versioned resource form a tree. relationships between revisions of a versioned resource form a
tree.
10. The merge-predecessors of a revision are those revisions that have 10. The merge-predecessors of a revision are those revisions
been merged with this revision. that have been merged with this revision.
11. A revision history is a concrete representation of the elements of 11. A revision history is a concrete representation of the
a versioned resource including all predecessor and successor elements of a versioned resource including all predecessor and
relationships, revision names, activities, etc. successor relationships, revision names, activities, etc.
12. A line-of-descent is a sequence of revisions connected by 12. A line-of-descent is a sequence of revisions connected by
successor/predecessor relationships from the initial revision to successor/predecessor relationships from the initial revision
a specific revision. to a specific revision.
13. An activity is a resource referring to a named set of revisions 13. An activity is a resource referring to a named set of
that correspond to some unit of work or conceptual change. revisions that correspond to some unit of work or conceptual
Activities are created by authors and are used to organize related change. Activities are created by authors and are used to
changes to resources, and to provide a basis for parallel organize related changes to resources, and to provide a basis
development and merging concurrent changes to the same resource. for parallel development and merging concurrent changes to the
An activity can contain revisions of multiple versioned resources, same resource. An activity can contain revisions of multiple
and/or multiple revisions of the same versioned resource along a versioned resources, and/or multiple revisions of the same
single line-of-descent. In each activity, it is possible to refer versioned resource along a single line-of-descent. In each
to the latest revision of a versioned resource in that activity. activity, it is possible to refer to the latest revision of a
versioned resource in that activity.
14. A workspace is a resource that is used to determine what revision 14. A workspace is a resource that is used to determine what
of a versioned resource should be accessed when the resource is revision of a versioned resource should be accessed when the
referenced without a particular revision name. When a user agent resource is referenced without a particular revision name.
accesses a versioned resource, a workspace may be specified to When a user agent accesses a versioned resource, a workspace
determine the specific revision that is the target of the request. may be specified to determine the specific revision that is
A workspace contains a version selection rule that is applied when the target of the request. A workspace contains a version
the workspace is used in conjunction with the URI for a versioned selection rule that is applied when the workspace is used in
resource to perform URL mapping and select a specific revision. conjunction with the URI for a versioned resource to perform
URL mapping and select a specific revision.
15. A revision selection rule specifies what revision of a versioned 15. A revision selection rule specifies what revision of a
resource should be selected. WebDAV defines selection rules that versioned resource should be selected. WebDAV defines
allow a revision to be selected based on its checked out selection rules that allow a revision to be selected based on
status, revision name, activity name, configuration name, or the its checked out status, revision name, activity name,
latest revision. Servers may support additional selection rules. configuration name, or the latest revision. Servers may
support additional selection rules.
16. A conflict report lists all revisions that must be merged when an 16. A conflict report lists all revisions that must be merged
activity is merged into a workspace. If the merge source activity when an activity is merged into a workspace. If the merge
specifies a resource that is a predecessor or successor source activity specifies a resource that is a predecessor or
of the revision selected by the current workspace, then there is successor of the revision selected by the current workspace,
no conflict. The merged workspace will pick the revision already then there is no conflict. The merged workspace will pick the
in the workspace if the merge source specifies a predecessor, revision already in the workspace if the merge source
otherwise it will pick the successor specified by the merge specifies a predecessor, otherwise it will pick the successor
source. Conflicts result when the merge source activity picks a specified by the merge source. Conflicts result when the merge
revision on a different line-of-descent than that selected source activity picks a revision on a different line-of-
by workspace. Conflicts are resolved by merging resources together descent than that selected by workspace. Conflicts are
into the workspace. This creates a new revision that has multiple resolved by merging resources together into the workspace.
predecessors and contains the changes from both merge source and This creates a new revision that has multiple predecessors and
the current workspace revisions. contains the changes from both merge source and the current
workspace revisions.
17. A configuration is a named set of related resources where each 17. A configuration is a named set of related resources where
member refers to a specific revision of a versioned resource. A each member refers to a specific revision of a versioned
configuration is a specific instance of a set of versioned resource. A configuration is a specific instance of a set of
resources. Configurations are similar to activities, but play a versioned resources. Configurations are similar to
different role. A workspace with its current activity and version activities, but play a different role. A workspace with its
selection rule specifies what a client can see. An activity is current activity and version selection rule specifies what a
associated with work in progress and encapsulates a set of client can see. An activity is associated with work in
related changes to multiple versioned resources. Creating progress and encapsulates a set of related changes to multiple
separate activities allows developers to work in parallel on the versioned resources. Creating separate activities allows
same resources, and to reconcile conflicts through merging developers to work in parallel on the same resources, and to
activities. Configurations represent a persistent selection of reconcile conflicts through merging activities. Configurations
revisions of versioned resources for organization and represent a persistent selection of revisions of versioned
distribution. Configurations can be versioned resources, resources for organization and distribution. Configurations
activities cannot. can be versioned resources, activities cannot.
Scenarios 18. The checkout paradigm is the process by which updates are
made to versioned resources. A resource is checked out
thereby creating a working resource. The working resource is
updated or augmented as desired, and then checked in to make
it part of the version history of the resource.
1.2 Storyboards
This section provides an example usage scenario that provides a This section provides an example usage scenario that provides a
context for explaining the definitions above, and for exploring and context for explaining the definitions above, and for exploring and
validating the goals given in the rest of this document. The example validating the goals given in the rest of this document. The
consists of a fictitious company, Acme Web Solutions that is example consists of a fictitious company, Acme Web Solutions that
developing a typical Web e-business application. To provide for the is developing a typical Web e-business application. To provide for
broadest coverage, the scenarios start with a non-existent resource the broadest coverage, the scenarios start with a non-existent
typical of web applications, and follow its life cycle through resource typical of web applications, and follow its life cycle
development and multiple deployments. Other resources would likely through development and multiple deployments. Other resources would
have similar life cycles. likely have similar life cycles.
Acme Web Solutions (AWS) has developed a web-grocery store called WGS. Acme Web Solutions (AWS) has developed a web-grocery store called
The application consists of a number of HTML pages, some Java applets, WGS. The application consists of a number of HTML pages, some Java
some Java Server Pages (JSP) and a number of Java servlets that access applets, some Java Server Pages (JSP) and a number of Java servlets
a DB2 database. AWS has decided to develop a new generation of its that access a DB2 database.
flagship WGS product to include maintenance of customer profile
information, and active (push) marketing of product specials to AWS has decided to develop a new generation of its flagship WGS
interested customers using Channel Definition Format (CDF). The new product to include maintenance of customer profile information, and
product will be called Active Grocery Store or AGS. Customers who are active (push) marketing of product specials to interested customers
interested in receiving information on specials will indicate that using Channel Definition Format (CDF). The new product will be
interest by subscribing to various CDF channels targeting pre-defined called Active Grocery Store or AGS. Customers who are interested in
or user-specified product groupings. Since AGS represents significant receiving information on specials will indicate that interest by
new revenue potential for grocery stores, AWS has decided to sell it subscribing to various CDF channels targeting pre-defined or user-
as a separate product from WGS, and at a relatively high price. WGS specified product groupings. Since AGS represents significant new
revenue potential for grocery stores, AWS has decided to sell it as
a separate product from WGS, and at a relatively high price. WGS
will still be available without AGS as a lower-cost, entry-level will still be available without AGS as a lower-cost, entry-level
solution for smaller stores, or stores just getting into e-business solution for smaller stores, or stores just getting into e-business
solutions. solutions.
AGS is a typical Web application development project that will require AGS is a typical Web application development project that will
changes to existing resources in AWS as well as adding new resources. require changes to existing resources in AWS as well as adding new
These new resources will also be HTML pages, applets, JSPs, servlets, resources. These new resources will also be HTML pages, applets,
etc. WGS is an active project sold to current customers with a JSPs, servlets, etc. WGS is an active project sold to current
maintenance contract. It has on-going updates that are unrelated to customers with a maintenance contract. It has on-going updates that
the new AGS system, but may need to be included in the AGS system. are unrelated to the new AGS system, but may need to be included in
These include bug fixes or minor new functional improvements. Since the AGS system. These include bug fixes or minor new functional
AGS is based on WGS, but both can evolve and be sold separately, it is improvements. Since AGS is based on WGS, but both can evolve and be
necessary to maintain versions of resources used by both. This will sold separately, it is necessary to maintain versions of resources
require AWS developers to specify a configuration of versioned used by both. This will require AWS developers to specify a
resources corresponding to each product. As the products evolve over configuration of versioned resources corresponding to each product.
time, these configurations will be versioned resources themselves, As the products evolve over time, these configurations will be
each representing a new release of their associated product, WGS, AGS, versioned resources themselves, each representing a new release of
or both. their associated product, WGS, AGS, or both.
The AWS development organization consists of a large number of The AWS development organization consists of a large number of
developers across a variety of disciplines including webmasters, Java developers across a variety of disciplines including webmasters,
developers, relational database developers, HTML page editors, Java developers, relational database developers, HTML page editors,
graphics artists, etc. All of these developers contribute to the graphics artists, etc. All of these developers contribute to the
development of the WGS and AGS products, often working in parallel on development of the WGS and AGS products, often working in parallel
the same resource for different purposes. For example, a WGS on the same resource for different purposes. For example, a WGS
developer may be editing an HTML page to fix a usability problem developer may be editing an HTML page to fix a usability problem
while an AGS developer is working on the same page to add the new AGS while an AGS developer is working on the same page to add the new
functions. This will require coordination of their activities to AGS functions. This will require coordination of their activities
provide maximum availability of these shared resources while at the to provide maximum availability of these shared resources while at
same time ensuring the integrity of the updates. The AWS development the same time ensuring the integrity of the updates. The AWS
team has decided to allow parallel development and resolve multiple development team has decided to allow parallel development and
concurrent updates through branching and merging of the resource resolve multiple concurrent updates through branching and merging
version graph. This adds complexity to the development project as of the resource version graph. This adds complexity to the
well as some risk due to inaccurate merges, but AWS has decided it development project as well as some risk due to inaccurate merges,
cannot be competitive in the Web world if all development must be but AWS has decided it cannot be competitive in the Web world if
serialized on shared resources as this would significantly slow all development must be serialized on shared resources as this
product development. would significantly slow product development.
The following scenarios trace the life cycle of a typical Web resource The following scenarios trace the life cycle of a typical Web
from conception to product deployment and maintenance. Each scenario resource from conception to product deployment and maintenance.
exposes some aspect of WebDAV and its use of the versioning, parallel Each scenario exposes some aspect of WebDAV and its use of the
development and configuration management definitions and goals versioning, parallel development and configuration management
specified in this document. In the scenarios below, it is assumed that definitions and goals specified in this document. In the scenarios
all developers have access to a Web WorkBench (WB) application that below, it is assumed that all developers have access to a Web
provides client access to a WebDAV server called DAVServer. It is WorkBench (WB) application that provides client access to a WebDAV
further assumed that both the client and server provide level 2 WebDAV server called DAVServer. It is further assumed that both the client
services plus advanced collections, versioning, parallel development, and server provide level 2 WebDAV services plus advanced
and configuration management. collections, versioning, parallel development, and configuration
management.
There is a goal that WebDAV versioning will support perhaps multiple There is a goal that WebDAV versioning will support perhaps
levels of versioning from none (existing WebDAV specification), simple multiple levels of versioning from none (existing WebDAV
linear versioning, support for parallel development, and through to specification), simple linear versioning, support for parallel
configuration management. The scenarios below should follow this development, and through to configuration management. The scenarios
progression from simple to complex in order to help expose logical below should follow this progression from simple to complex in
points for leveling the protocol functionality. However, the intent of order to help expose logical points for leveling the protocol
this document is to at least expose the complete goals for full WebDAV functionality. However, the intent of this document is to at least
versioning support in order to ensure down-levels are a consistent expose the complete goals for full WebDAV versioning support in
subset. The exact contents of down-level servers and the number of order to ensure down-levels are a consistent subset. The exact
levels will be determined later during protocol development. contents of down-level servers and the number of levels will be
determined later during protocol development.
Resource Creation 1.2.1.1 Resource Creation
The AGS project team held a design meeting to determine the work The AGS project team held a design meeting to determine the work
products required to support the AGS project, its integration with products required to support the AGS project, its integration with
the WGS application, and to assign these work products to developers. the WGS application, and to assign these work products to
Various analysis and design techniques can be used to discover the developers. Various analysis and design techniques can be used to
required work products, but this is beyond the scope of WebDAV. At the discover the required work products, but this is beyond the scope
end of the meeting, webmaster Joe was assigned to develop the new of WebDAV. At the end of the meeting, webmaster Joe was assigned to
welcome page, index.html, for the AGS project. This page will be the develop the new welcome page, index.html, for the AGS project. This
initial page used to navigate the AGS application, and is the first page will be the initial page used to navigate the AGS application,
page seen by users. It is a new page that will not replace the WGS and is the first page seen by users. It is a new page that will not
welcome page, but will contain a reference to it. replace the WGS welcome page, but will contain a reference to it.
Joe uses WB to create a new collection, http://aws/ags/, and the new Joe uses WB to create a new collection, http://aws/ags/, and the
index.html page in the collection http://aws/ags/index.html. Neither new index.html page in the collection http://aws/ags/index.html.
the parent collection, nor index.html are versioned resources at this Neither the parent collection, nor index.html are versioned
point. A WebDAV MKCOL is used to create the collection, and a PUT is resources at this point. A WebDAV MKCOL is used to create the
used to create the initial, empty resource. collection, and a PUT is used to create the initial, empty
resource.
Resource Editing 1.2.1.2 Resource Editing
Joe uses WB to GET the resource and edit it with his favorite HTML Joe uses WB to GET the resource and edit it with his favorite HTML
editor. Each save by the HTML editor does a PUT to the DAVServer, editor. Each save by the HTML editor does a PUT to the DAVServer,
overwriting its current contents. No new versions are created. overwriting its current contents. No new versions are created. Joe
Joe may also use WB to get and set properties of index.html using may also use WB to get and set properties of index.html using
PROPFIND and PROPPATCH. Joe does not need to lock index.html because PROPFIND and PROPPATCH. Joe does not need to lock index.html
he is the only developer working on it at this time. He could however because he is the only developer working on it at this time. He
lock the resource to ensure no one else could make any changes he is could however lock the resource to ensure no one else could make
not aware of. any changes he is not aware of.
Creating a Versioned Resource 1.2.1.3 Creating a Versioned Resource
At some point, Joe decides preliminary editing on index.html is At some point, Joe decides preliminary editing on index.html is
complete, and he needs to make a stable version available to other complete, and he needs to make a stable version available to other
developers who need it for integration testing, etc. Joe however developers who need it for integration testing, etc. Joe however
wants to ensure that no other developers make changes to index.html wants to ensure that no other developers make changes to index.html
that he cannot back out, as he is the webmaster responsible for the that he cannot back out, as he is the webmaster responsible for the
resource. So Joe uses the WB to make index.html which causes resource. So Joe uses the WB to make index.html which causes
DAVServer to create a versioned resource, and make the initial DAVServer to create a versioned resource, and make the initial
version Joe's index.html. At this point, Joe's index.html is version Joe's index.html. At this point, Joe's index.html is
immutable, it cannot be changed by anyone, including Joe, and remains immutable, it cannot be changed by anyone, including Joe, and
in the repository until the versioned resource is deleted. remains in the repository until the versioned resource is deleted.
Labeling a Version 1.2.1.4 Labeling a Version
When DAVServer created the versioned resource corresponding to When DAVServer created the versioned resource corresponding to
index.html, it gave the initial version a revision id, "102847565". index.html, it gave the initial version a revision id,
This revision name is automatically assigned by the server, and "102847565". This revision name is automatically assigned by the
cannot be changed or assigned to any other version. This revision server, and cannot be changed or assigned to any other version.
name acts as the unique identifier for this version of versioned This revision name acts as the unique identifier for this version
resource index.html. The AGS development team has decided that a of versioned resource index.html. The AGS development team has
revision label "initial" will identify the initial version of all decided that a revision label _initial_ will identify the initial
resources. This ensures they stand out and can be easily accessed version of all resources. This ensures they stand out and can be
without remembering some opaque revision id. Joe uses WB to set the easily accessed without remembering some opaque revision id. Joe
label on the initial version to "initial" in order to identify the uses WB to set the label on the initial version to "initial" in
version with this more meaningful name. order to identify the version with this more meaningful name.
Accessing Versioned Resources 1.2.1.5 Accessing Versioned Resources
Fred wants to access Joe's initial version of index.html. So he uses Fred wants to access Joe's initial version of index.html. So he
URL http://aws/ags/index.html to get the contents of the resource and uses URL http://aws/ags/index.html to get the contents of the
notices he does get the right version, because it was selected by the resource and notices he does get the right version, because it was
default workspace. That is, when Fred accessed URL selected by the default workspace. That is, when Fred accessed URL
http://aws/ags/index.html, he did so without specifying a workspace. http://aws/ags/index.html, he did so without specifying a
So the default workspace was used, and the default workspace always workspace. So the default workspace was used, and the default
uses "latest" in its version selection rule. But Fred wants to be workspace always uses "latest" in its version selection rule. But
more cautions. He wants to be sure that he continues to get version Fred wants to be more cautions. He wants to be sure that he
labeled "initial", even if the latest version changes as the result continues to get version labeled "initial", even if the latest
of new changes Joe may check in. So Fred creates a workspace called version changes as the result of new changes Joe may check in. So
"initialws", and sets the version selection rule to be the revision Fred creates a workspace called "initialws", and sets the version
labeled "initial". Then Fred always accesses index.html with its URL selection rule to be the revision labeled "initial". Then Fred
and the initialws workspace to be sure he gets the specific version always accesses index.html with its URL and the initialws workspace
he needs. The workspace also ensures he gets the revision named to be sure he gets the specific version he needs. The workspace
"initial" of all other versioned resources as well, ensuring a also ensures he gets the revision named _initial_ of all other
consistent set of revisions. versioned resources as well, ensuring a consistent set of
revisions.
Later that week, there have been a number of changes to index.html, Later that week, there have been a number of changes to index.html,
and Fred wants to just take a quick look at an old version to remember and Fred wants to just take a quick look at an old version to
how the page used to look. Fred’s workspace is currently selecting remember how the page used to look. Fred's workspace is currently
the latest version, and he doesn’t want to change his workspace just selecting the latest version, and he doesn't want to change his
to look at some other revision. So Fred uses his WebDAV client to workspace just to look at some other revision. So Fred uses his
access index.html using label "initial", or revision id 32345 WebDAV client to access index.html using label _initial_, or
to override the workspace selection and get the initial revision. revision id 32345 to override the workspace selection and get the
initial revision.
Creating a New Revision 1.2.1.6 Creating a New Revision
A week later, a number of developers have noticed that index.html is A week later, a number of developers have noticed that index.html
missing both important references to their pages as well as hot is missing both important references to their pages as well as hot
images for navigation. They send email to Joe specifying their new images for navigation. They send email to Joe specifying their new
requirements. Joe now wants to make changes to index.html and create requirements. Joe now wants to make changes to index.html and
a new revision. He wants to retain the old revision, just in case the create a new revision. He wants to retain the old revision, just in
requirements he was given were incorrect and need to be backed case the requirements he was given were incorrect and need to be
out, and to allow developers using the old revision to continue their backed out, and to allow developers using the old revision to
work. To do this, Joe uses the WB to check out index.html and create continue their work. To do this, Joe uses the WB to check out
a new working resource. Joe can now access the working resource index.html and create a new working resource. Joe can now access
because working resources are always visible from the workspace in the working resource because working resources are always visible
which they were checked out. from the workspace in which they were checked out.
As before, Joe uses the WB and HTML editor to GET the working As before, Joe uses the WB and HTML editor to GET the working
resource and PUT updates. Each PUT replaces the contents of the resource and PUT updates. Each PUT replaces the contents of the
working resource with changes made by the HTML editor, no new working resource with changes made by the HTML editor, no new
revision is created. When Joe is finished making edits to support revision is created. When Joe is finished making edits to support
the new requirements, he checks the working resource back in, making the new requirements, he checks the working resource back in,
a new revision. making a new revision.
Editing a Mutable Revision 1.2.1.7 Editing a Mutable Revision
John was assigned to write a high level marketing document, ags.html John was assigned to write a high level marketing document,
that provided an overall description of the AGS application. Since ags.html that provided an overall description of the AGS
most changes to this document have no effect on the rest of AGS, John application. Since most changes to this document have no effect on
decides to allow revisions of ags.html to be editable in-place. This the rest of AGS, John decides to allow revisions of ags.html to be
is so simple spelling and grammar errors can be fixed without overwriteable. This is so simple spelling and grammar errors can be
requiring the creation of a new revision. John still wants to create fixed without requiring the creation of a new revision. John still
revisions whenever some significant new feature is added to AGS so wants to create revisions whenever some significant new feature is
the old descriptions are available to customers who don't upgrade. added to AGS so the old descriptions are available to customers who
don't upgrade.
John creates resource ags.html, edits it a number of times, and then John creates resource ags.html, edits it a number of times, and
checks it in to create a versioned resource. then checks it in to create a versioned resource.
Later on, a new feature is added and John checks out ags.html to Later on, a new feature is added and John checks out ags.html to
create a new revision, makes his edits, and checks it back in, create a new revision, makes his edits, and checks it back in,
creating a new revision. Three days later, John notices a spelling creating a new revision. Three days later, John notices a spelling
mistake in the first revision that he corrected in the new revision, mistake in the first revision that he corrected in the new
but users of the old revision would like the correction made for revision, but users of the old revision would like the correction
their users too. So John again checks out the old revision creating a made for their users too. So John again checks out the old revision
new working resource, fixes the spelling mistake, and then checks creating a new working resource, fixes the spelling mistake, and
the working resource back in. However in this case, John selects then checks the working resource back in. However in this case,
check in in-place in order to overwrite the old revision with the John selects check in in-place in order to overwrite the old
corrected revision. Now all users of the old revision will see the revision with the corrected revision. Now all users of the old
correction. This revision is now marked as mutable since it revision will see the correction. This revision is now marked as
has been changed. mutable since it has been changed.
Six months later, there have been a number of complaints about Six months later, there have been a number of complaints about
ags.html presenting misleading product information that has resulted ags.html presenting misleading product information that has
in unhappy customers. There's even talk of lawsuits. So John hurriedly resulted in unhappy customers. There's even talk of lawsuits. So
updates ags.html and checks in the new version as immutable so that in John hurriedly updates ags.html and checks in the new version as
case there is a suit, he can prove that customers had access to his immutable so that in case there is a suit, he can prove that
updated version. Now any changes can be made by creating new customers had access to his updated version. Now any changes can be
immutable revisions without ever worrying about loosing old version. made by creating new immutable revisions without ever worrying
about loosing old version.
A year later, things have cooled down, and John decides its OK to A year later, things have cooled down, and John decides its OK to
allow mutable revisions again. On his last change he checked ags.html allow mutable revisions again. On his last change he checked
in as a mutable revision allowing subsequent changes to be done ags.html in as a mutable revision allowing subsequent changes to be
without creating new versions. At the same time, the revision history done without creating new versions. At the same time, the revision
of the immutable revisions is preserved just in case that pesky history of the immutable revisions is preserved just in case that
customer re-appears. pesky customer re-appears.
Parallel Development with Activities 1.2.1.8 Parallel Development with Activities
Two weeks later, there is a major redesign of AGS that results in a Two weeks later, there is a major redesign of AGS that results in a
lot of changes to index.html. Again, Joe checks out the resource lot of changes to index.html. Again, Joe checks out the resource
creating a new working resource. But it is taking Joe a long time to creating a new working resource. But it is taking Joe a long time
finish all the edits, and in the meantime, graphics artist Jane wants to finish all the edits, and in the meantime, graphics artist Jane
to update index.html with references to the new images that resulted wants to update index.html with references to the new images that
from the AGS redesign. Jane attempts to check out index.html, but WB resulted from the AGS redesign. Jane attempts to check out
informs her that Joe already has it checked out and refuses the index.html, but WB informs her that Joe already has it checked out
request. She checks with Joe, and since they are both working on and refuses the request. She checks with Joe, and since they are
different aspects of index.html, Joe feels it would be fine for Jane both working on different aspects of index.html, Joe feels it would
to do her work in parallel with his, and then he will merge her be fine for Jane to do her work in parallel with his, and then he
changes with his to finish the required updates. Jane creates a new will merge her changes with his to finish the required updates.
activity called "images_updates", uses it to set the activity of her Jane creates a new activity called "images_updates", uses it to set
workspace, and again attempts the checkout. This time the checkout the activity of her workspace, and again attempts the checkout.
succeeds, and a new working resource is created for index.html in This time the checkout succeeds, and a new working resource is
the images_updates activity. Now any changes that Jane makes to created for index.html in the images_updates activity. Now any
images.html are completely independent of changes Joe makes to the changes that Jane makes to images.html are completely independent
same resource, but in a different activity. Note that Joe did not of changes Joe makes to the same resource, but in a different
create an activity when he checked out index.html. Instead, the activity. Note that Joe did not create an activity when he checked
default activity "mainline" was used. Jane couldn't checkout out index.html. Instead, the default activity "mainline" was used.
index.html without specifying a different activity because a Jane couldn't checkout index.html without specifying a different
resource can only be checked out once in a given activity. She also activity because a resource can only be checked out once in a given
couldn’t make any changes until the resource is checked out as activity. She also couldn't make any changes until the resource is
checked in revisions are read-only. checked out as checked in revisions are read-only.
After making her edits, she checks index.html back in, which creates a After making her edits, she checks index.html back in, which
new revision in the images_updates activity. creates a new revision in the images_updates activity.
Merging Activities 1.2.1.9 Merging Activities
Project management practice dictates that at various times during the Project management practice dictates that at various times during
development project, usually every few days or at specific project the development project, usually every few days or at specific
milestones, the updates from any parallel activities should be merged project milestones, the updates from any parallel activities should
in order to integrate the changes and produce instances of the be merged in order to integrate the changes and produce instances
products suitable for testing. This avoids the risk of revisions of of the products suitable for testing. This avoids the risk of
shared resources diverging wildly, and thereby decreases the revisions of shared resources diverging wildly, and thereby
likelihood of difficult or inaccurate merges. It also encourages decreases the likelihood of difficult or inaccurate merges. It also
communication within the development organization and avoids encourages communication within the development organization and
"big-bang" integration points late in the development cycle. This avoids "big-bang" integration points late in the development cycle.
enhances the stability of the products and helps ensure a This enhances the stability of the products and helps ensure a
deterministic, controllable development process. It also allows early deterministic, controllable development process. It also allows
product testing and better feedback to developers. early product testing and better feedback to developers.
Joe has finally finished his changes to image.html, and is ready to Joe has finally finished his changes to image.html, and is ready to
incorporate the changes from Jane’s images_update activity to get the incorporate the changes from Jane's images_update activity to get
new images. Before doing so, Joe checks his updates into revision the new images. Before doing so, Joe checks his updates into
"r0.2" so if he does something wrong when doing the merge, he can revision "r0.2" so if he does something wrong when doing the merge,
recover and try again. Now Joe specifies in his workspace that he he can recover and try again. Now Joe specifies in his workspace
wishes to merge the "image_updates" activity into his workspace. He that he wishes to merge the "image_updates" activity into his
then can obtain a conflict report from his workspace that indicates workspace. He then can obtain a conflict report from his workspace
that the resource index.html requires a merge. He then issues a merge that indicates that the resource index.html requires a merge. He
request for index.html. This checks out the resource in the mainline then issues a merge request for index.html. This checks out the
activity (the activity in Joe's workspace), and registers a merge resource in the mainline activity (the activity in Joe's
from the latest revision in the image_updates activity to the working workspace), and registers a merge from the latest revision in the
resource. This working resource now has two predecessors, r0.2 image_updates activity to the working resource. This working
and the image_updates revision. Joe then uses the differencing resource now has two predecessors, r0.2 and the image_updates
capability in his HTML editor to find the differences between his revision. Joe then uses the differencing capability in his HTML
revision and Jane’s, and to apply Jane's changes as appropriate. editor to find the differences between his revision and Jane's, and
to apply Jane's changes as appropriate.
The HTML editor Joe uses is WebDAV versioning aware, and does a 3-way The HTML editor Joe uses is WebDAV versioning aware, and does a 3-
merge by accesses the closest common ancestor in the revision history way merge by accesses the closest common ancestor in the revision
in order to help with the merge process. Joe notices that most of history in order to help with the merge process. Joe notices that
Jane’s changes do not conflict with his as they are in different most of Jane's changes do not conflict with his as they are in
places in the resource, but there are a number of places where he different places in the resource, but there are a number of places
added new functions that do not have images as Jane didn't know they where he added new functions that do not have images as Jane didn't
were there. He notes these and either fixes them himself, or sends know they were there. He notes these and either fixes them himself,
email to Jane so she can fix them in another revision. Once the or sends email to Jane so she can fix them in another revision.
changes are complete, Joe checks in the merged revision. Jane is free Once the changes are complete, Joe checks in the merged revision.
to continue making updates in her image_updates activity, and these Jane is free to continue making updates in her image_updates
changes can be merged in again later. activity, and these changes can be merged in again later.
Creating a Configuration 1.2.1.10 Creating a Configuration
At some point, enough of the work products of the AGS application are At some point, enough of the work products of the AGS application
sufficiently complete and stable that AWS wants to distribute an alpha are sufficiently complete and stable that AWS wants to distribute
release. To do this, Joe uses WB to create a configuration named an alpha release. To do this, Joe uses WB to create a configuration
"alphaRelease" that will contain a consistent set of compatible work named "alphaRelease" that will contain a consistent set of
product revisions. This configuration will contain all revisions compatible work product revisions. This configuration will contain
currently selected by Joe's workspace. If any working resources all revisions currently selected by Joe's workspace. If any working
exist in Joe's workspace, the request to create a configuration fails, resources exist in Joe's workspace, the request to create a
with an error message indicating that the failure is due to the configuration fails, with an error message indicating that the
presence of checked-out resources in Joe's workspace. failure is due to the presence of checked-out resources in Joe's
workspace.
When Jane is ready to see the alphaRelease, she modifies the revision When Jane is ready to see the alphaRelease, she modifies the
selection rules of her workspace to select this new configuration. revision selection rules of her workspace to select this new
Any conflicts between this new configuration and her current activity configuration. Any conflicts between this new configuration and her
requiring merges would be noted in the "conflicts" report of her current activity requiring merges would be noted in the "conflicts"
workspace, which Jane could then resolve with the "merge" operation. report of her workspace, which Jane could then resolve with the
"merge" operation.
Each release of AGS consists of new resources and updated revisions of Each release of AGS consists of new resources and updated revisions
existing resources. To simplify creating a new configuration for each of existing resources. To simplify creating a new configuration for
new release, Joe can make the AGS configuration a versioned resource. each new release, Joe can make the AGS configuration a versioned
For release 1 of AGS, Joe uses a configuration called AGS, and labels resource. For release 1 of AGS, Joe uses a configuration called
it R1. For release 2, he checks out version R1 of configuration AGS, AGS, and labels it R1. For release 2, he checks out version R1 of
and adds, removes, or changes the revisions of versioned resources in configuration AGS, and adds, removes, or changes the revisions of
the configuration, then checks in the configuration and labeling it versioned resources in the configuration, then checks in the
R2. configuration and labeling it R2.
Getting the Revision History of a Versioned Resource 1.2.1.11 Getting the Revision History of a Versioned Resource
In order to determine what revision should be included in the In order to determine what revision should be included in the
alphaRelease configuration, Joe must examine the revision history of alphaRelease configuration, Joe must examine the revision history
resource index.html. He does this by requesting the revision history of resource index.html. He does this by requesting the revision
of index.html and receives an XML document describing all the history of index.html and receives an XML document describing all
revisions including their revision id, labels, descriptions, the revisions including their revision id, labels, descriptions,
successors, predecessor, and merge predecessors. Joe uses an XML successors, predecessor, and merge predecessors. Joe uses an XML
enabled browser and an XSL style sheet to view the revision history. enabled browser and an XSL style sheet to view the revision
history.
Accessing Resources by Non-versioning Aware Clients 1.2.1.12 Accessing Resources by Non-versioning Aware Clients
Fred belongs to a different company, and does not have any WebDAV Fred belongs to a different company, and does not have any WebDAV
versioning aware tools. However, he is an excellent graphics artist, versioning aware tools. However, he is an excellent graphics
and has been asked to look over a particular image file, logo.gif. So artist, and has been asked to look over a particular image file,
Fred uses his image editing tool to get a copy of logo.gif. Because logo.gif. So Fred uses his image editing tool to get a copy of
his editing tool is not versioning aware, he cannot specify a logo.gif. Because his editing tool is not versioning aware, he
particular version, either with a revision name or by using a cannot specify a particular version, either with a revision name or
workspace. However, the WebDAV server provides a default workspace by using a workspace. However, the WebDAV server provides a default
that selects the latest revision when no label or workspace is workspace that selects the latest revision when no label or
specified on a request. workspace is specified on a request.
Updating Resources by Non-versioning Aware Clients 1.2.1.13 Updating Resources by Non-versioning Aware Clients
Fred has provided his review to Jane and Joe, and they decide he Fred has provided his review to Jane and Joe, and they decide he
should be allowed to update the image in logo.gif. Fred then edits should be allowed to update the image in logo.gif. Fred then edits
the image in his image editing tool, and attempts to save it on the the image in his image editing tool, and attempts to save it on the
DAVServer. Again, the editing tool does not specify a workspace, or DAVServer. Again, the editing tool does not specify a workspace, or
activity, nor can Fred check out the resource before attempting the activity, nor can Fred check out the resource before attempting the
save. Joe realizes Fred must be able to change the resource, so he save. Joe realizes Fred must be able to change the resource, so he
enables automatic versioning in logo.gif. Then when Fred attempts to enables automatic versioning in logo.gif. Then when Fred attempts
update the resource, the server automatically checks out the resource, to update the resource, the server automatically checks out the
does the put, and then checks it back in, all in the context of the resource, does the put, and then checks it back in, all in the
default workspace. context of the default workspace.
If someone else had the resource already checked out, then Fred's If someone else had the resource already checked out, then Fred's
save would have failed because the automatic check out would have save would have failed because the automatic check out would have
failed. failed.
There are some potential problems with using non-versioning aware There are some potential problems with using non-versioning aware
clients this way. If Fred got a copy of the resource, and then Jane clients this way. If Fred got a copy of the resource, and then Jane
checked it out, made changes, and then checked it back in, when Fred checked it out, made changes, and then checked it back in, when
does his save, Jane's changes will be lost. The changes will appear Fred does his save, Jane's changes will be lost. The changes will
in a previous revision, but they may have been in the same activity, appear in a previous revision, but they may have been in the same
and there would be no indication that a merge needs to be done in activity, and there would be no indication that a merge needs to be
order to pick up both changes. To avoid this problem Joe could change done in order to pick up both changes. To avoid this problem Joe
the activity in the default workspace so that all changes done by could change the activity in the default workspace so that all
non-versioning aware clients are done in a separate activity. This changes done by non-versioning aware clients are done in a separate
would allow Joe to control when these changes were merged back into activity. This would allow Joe to control when these changes were
other activities. merged back into other activities.
Freezing an Activity 1.2.1.14 Freezing an Activity
Joe has decided that the imageUpdates activity should no longer be Joe has decided that the imageUpdates activity should no longer be
used once all the changes in that activity have been merged into the used once all the changes in that activity have been merged into
mainline activity. To enforce this, Joe locks the activity. Then when the mainline activity. To enforce this, Joe locks the activity.
Jane attempts to edit index.html in her imageUpdates activity, the Then when Jane attempts to edit index.html in her imageUpdates
checkout fails as the activity is locked. activity, the checkout fails as the activity is locked.
Preventing Parallel Development 1.2.1.15 Preventing Parallel Development
Joe is responsible for another resource, getPreferences.shtml that he Joe is responsible for another resource, getPreferences.shtml that
wants complete control over. He does not want to allow anyone else to he wants complete control over. He does not want to allow anyone
ever make changes to this resource in any activity. To enforce this, else to ever make changes to this resource in any activity. To
Joe indicates getPreferences.shtml does not support multiple enforce this, Joe indicates getPreferences.shtml does not support
activities, and he checks it out to make sure no-one else can make multiple activities, and he checks it out to make sure no-one else
any changes. Then when Jane attempts to checkout getPreferences.shtml can make any changes. Then when Jane attempts to checkout
in the imageUpdates activity, the checkout fails indicating that getPreferences.shtml in the imageUpdates activity, the checkout
resource does not support parallel development. fails indicating that resource does not support parallel
development.
Goals 1.3 Goals
This section defines the goals addressed by the protocol to support This section defines the goals addressed by the protocol to support
versioning, parallel development, and configuration management. These versioning, parallel development, and configuration management.
goals are derived from the desire to support the scenarios above. These goals are derived from the desire to support the scenarios
Each goal is followed by a short description of its rationale to aid above. Each goal is followed by a short description of its
in understanding the goal, and to provide motivation for why it was rationale to aid in understanding the goal, and to provide
included. motivation for why it was included.
1. Versioning aware and non-versioning aware clients must be able to 1. Versioning aware and non-versioning aware clients must be able to
inter-operate. Non-versioning aware clients will not be able to inter-operate. Non-versioning aware clients will not be able to
perform all versioning operations, but will, at a minimum, be perform all versioning operations, but will, at a minimum, be
capable of authoring resources under version control and be capable of authoring resources under version control and be
capable of creating new revisions while implicitly maintaining capable of creating new revisions while implicitly maintaining
versioning semantics. Non-versioning aware clients are versioning semantics. Non-versioning aware clients are HTTP/1.1
HTTP/1.1 and versioning unaware WebDAV clients. and versioning unaware WebDAV clients.
Versioning and configuration management adds new capabilities to Versioning and configuration management adds new capabilities to
WebDAV servers. These servers should still be responsive to WebDAV servers. These servers should still be responsive to non-
non-versioning aware clients in such a way that these clients versioning aware clients in such a way that these clients retain
retain their capabilities in a manner that is consistent with the their capabilities in a manner that is consistent with the
versioning rules, and the capabilities those clients would have had versioning rules, and the capabilities those clients would have
on a non-versioning server. For example, non-versioning aware had on a non-versioning server. For example, non-versioning aware
clients should be able to GET the contents of a versioned resource clients should be able to GET the contents of a versioned
without specifying a revision and get some well-defined default resource without specifying a revision and get some well-defined
revision. A non-versioning aware client should be able to PUT to a default revision. A non-versioning aware client should be able to
versioned resource and have a new revision be automatically PUT to a versioned resource and have a new revision be
created. The PUT must be done by doing an implicit checkout, PUT, automatically created. The PUT must be done by doing an implicit
and checkin in order to maintain versioning semantics and avoid checkout, PUT, and checkin in order to maintain versioning
lost updates. A subsequent GET on the same versioned resource by semantics and avoid lost updates. A subsequent GET on the same
this client should return the new revision. The server should be versioned resource by this client should return the new revision.
able to be configured so that these non-versioning aware client The server should be able to be configured so that these non-
updates are placed in a different activity, or perhaps disallowed. versioning aware client updates are placed in a different
activity, or perhaps disallowed.
2. It must be possible to version resources of any media or content 2. It must be possible to version resources of any media or content
type. type.
The versioning semantics of the protocol must not depend on the The versioning semantics of the protocol must not depend on the
media type of the resource or versioning would have limited media type of the resource or versioning would have limited
applicability, and client applications would become more applicability, and client applications would become more complex.
complex.
3. Every revision of a versioned resource must itself be a resource, 3. Every revision of a versioned resource must itself be a resource,
with its own URI. with its own URI.
See section 5.9.2.2 of [WEBDAV-GOALS]. This goal has two See section 5.9.2.2 of [WEBDAV-GOALS]. This goal has two
motivations. First, to permit revisions to be referred to, so that motivations. First, to permit revisions to be referred to, so
(for example) a document comparing two revisions can include a link that (for example) a document comparing two revisions can include
to each. Second, revisions can be treated as resources for the a link to each. Second, revisions can be treated as resources for
purposes of DAV methods such as PROPFIND. the purposes of DAV methods such as PROPFIND.
4. It must be possible to prevent lost updates by providing a protocol 4. It must be possible to prevent lost updates by providing a
that reserves a revision of a resource while it is being updated protocol that reserves a revision of a resource while it is being
and preventing other users from updating the same revision at updated and preventing other users from updating the same
the same time in uncontrolled ways. revision at the same time in uncontrolled ways.
5. It must be possible to reserve the same revision more than once at 5. It must be possible to reserve the same revision more than once
the same time, and to have multiple revisions of the same versioned at the same time, and to have multiple revisions of the same
resource reserved at the same time. versioned resource reserved at the same time.
6. It should be possible for a client to specify meaningful labels to 6. It should be possible for a client to specify meaningful labels
apply to individual revisions, and to change a label to refer to a to apply to individual revisions, and to change a label to refer
different revision. to a different revision.
Although the server assigns unique revision IDs, human-meaningful Although the server assigns unique revision IDs, human-meaningful
aliases are often useful. For example, a label called "CustomerX" aliases are often useful. For example, a label called
could be assigned to the latest revision of a document which has "CustomerX" could be assigned to the latest revision of a
been delivered to customer X. When X calls to inquire about the document which has been delivered to customer X. When X calls to
document, the author(s) can simply refer to the label, rather than inquire about the document, the author(s) can simply refer to the
maintaining a separate database of which revisions have been label, rather than maintaining a separate database of which
shipped to which customers. revisions have been shipped to which customers.
7. It must be possible to use the same label for different versioned 7. It must be possible to use the same label for different versioned
resources. resources.
This allows authors to indicate that revisions of different This allows authors to indicate that revisions of different
resources are somehow related or consistent at some point in time. resources are somehow related or consistent at some point in
Configurations formalize this relationship. time. Configurations formalize this relationship.
8. The labels and revision IDs within a revision history are names in 8. The labels and revision IDs within a revision history are names
a common namespace, in which each name must be unique. The server in a common namespace, in which each name must be unique. The
may partition this namespace syntactically, in order to distinguish server may partition this namespace syntactically, in order to
labels from IDs. The server enforces uniqueness for these labels. distinguish labels from IDs. The server enforces uniqueness for
these labels.
This means the same label cannot apply to multiple revisions, the This means the same label cannot apply to multiple revisions, the
same revision ID cannot apply to multiple revisions, and no label same revision ID cannot apply to multiple revisions, and no label
can also be a revision ID or vice versa. This is required so can also be a revision ID or vice versa. This is required so
that a label, when applied to a versioned resource, refers to one that a label, when applied to a versioned resource, refers to one
and only one revision, and all revision names for a versioned and only one revision, and all revision names for a versioned
resource are unique. To enforce uniqueness, a server will have to resource are unique. To enforce uniqueness, a server will have to
reject labels that it might eventually use as revision IDs. The reject labels that it might eventually use as revision IDs. The
simplest way to do this is to partition the namespace. simplest way to do this is to partition the namespace.
9. Given a URI to a versioned resource, and a revision name, it must 9. Given a URI to a versioned resource, and a revision name, it must
be possible for a client to obtain a URI that refers to that be possible for a client to obtain a URI that refers to that
revision, and to access the revision. revision, and to access the revision.
This allows specific revisions of a resource to be accessed given This allows specific revisions of a resource to be accessed given
the URI of the versioned resource and a revision name. the URI of the versioned resource and a revision name.
10. Given a URI to a versioned resource, and a workspace, it must be 10. Given a URI to a versioned resource, and a workspace, it must
possible for a client access the revision selected by the be possible for a client access the revision selected by the
workspace. workspace.
When a user agent accesses a versioned resource, it is necessary When a user agent accesses a versioned resource, it is necessary
to provide additional information to specify which revision of to provide additional information to specify which revision of
the versioned resource should be accessed. One way to do this is the versioned resource should be accessed. One way to do this is
to specify a revision name with the resource URL to select a to specify a revision name with the resource URL to select a
particular revision as specified in the previous goal. However, particular revision as specified in the previous goal. However,
this requires users to add and remember a label for each revision, this requires users to add and remember a label for each
which is inconvenient and does not scale. In addition, labels revision, which is inconvenient and does not scale. In addition,
alone don’t provide a way of accessing revisions modified in an labels alone don't provide a way of accessing revisions modified
activity, or contained in a configuration. It is possible in an activity, or contained in a configuration. It is possible
to specify a number of different ways of accessing specific to specify a number of different ways of accessing specific
revisions using different headers for labels, activities, revisions using different headers for labels, activities,
configurations, working revisions, etc., but this leads to a lot configurations, working revisions, etc., but this leads to a lot
of complexity in the protocol, and for users. Workspaces provide of complexity in the protocol, and for users. Workspaces provide
a unified means of specifying how URLs are mapped to specific a unified means of specifying how URLs are mapped to specific
revisions. A workspace contains a revision selection rule that revisions. A workspace contains a revision selection rule that is
is applied when the workspace is used in conjunction with the applied when the workspace is used in conjunction with the URLs
URLs for versioned resources to perform URL mapping to select for versioned resources to perform URL mapping to select a
a specific revision. This allows specific revisions of a many, specific revision. This allows specific revisions of a many,
related revisions to be accessed through URLs without having to related revisions to be accessed through URLs without having to
specify a specific label for each resource. It also provides a specify a specific label for each resource. It also provides a
means to resolve URLs to particular revisions using more complex means to resolve URLs to particular revisions using more complex
revision selection rules than a single label including revisions revision selection rules than a single label including revisions
modified in an activity or contained in a configuration. modified in an activity or contained in a configuration.
11. Relative URLs appearing in versioned documents (e.g., HTML and 11. Relative URLs appearing in versioned documents (e.g., HTML and
XML) which are being edited and/or browsed by a versioning-aware XML) which are being edited and/or browsed by a versioning-aware
client should work correctly. client should work correctly.
Web resources and client applications often refer to other Web resources and client applications often refer to other
resources with relative URLs, an incompletely specified URL that resources with relative URLs, an incompletely specified URL that
is completed by pre-pending some known context that would is completed by pre-pending some known context that would not
not contain a revision or workspace name. When used with contain a revision or workspace name. When used with versioned
versioned resources, these relative URLs may be relative to a resources, these relative URLs may be relative to a versioned
versioned resource or a particular revision. In this case, the resource or a particular revision. In this case, the context must
context must include sufficient information for the relative URL include sufficient information for the relative URL to be
to be resolved to a specific revision. resolved to a specific revision.
12. If the DAV server supports searching, it should be possible to 12. If the DAV server supports searching, it should be possible to
narrow the scope of a search to the revisions of a particular narrow the scope of a search to the revisions of a particular
versioned resource. versioned resource.
It is often the case that one needs to find, for example, the It is often the case that one needs to find, for example, the
first revision at which a particular phrase was introduced, or first revision at which a particular phrase was introduced, or
all the revisions authored by a particular person. Given search all the revisions authored by a particular person. Given search
capabilities for collections, it would be far more sensible to capabilities for collections, it would be far more sensible to
leverage those capabilities than to define a separate search leverage those capabilities than to define a separate search
skipping to change at line 801 skipping to change at page 17, line 36
indicates that labels should be available properties that a indicates that labels should be available properties that a
search mechanism could access. search mechanism could access.
14. The CM protocol must be an optional extension to the base 14. The CM protocol must be an optional extension to the base
versioning protocol. versioning protocol.
It is expected that servers will want to support versioning It is expected that servers will want to support versioning
without supporting configuration management. This goal provides without supporting configuration management. This goal provides
the required flexibility. the required flexibility.
15. It must be possible to determine what properties of a checked in 15. It must be possible to determine what properties of a checked
revision may change without creating a new revision. Properties in revision may change without creating a new revision.
of a checked in revision that cannot change are called Properties of a checked in revision that cannot change are called
immutable properties. immutable properties.
It is anticipated that some properties may be calculated in such It is anticipated that some properties may be calculated in such
a way that their values may change even on a revision that is a way that their values may change even on a revision that is
checked in. Other properties may change without having any checked in. Other properties may change without having any effect
effect on the resource itself e.g., review status, approved, etc. on the resource itself e.g., review status, approved, etc. This
This results from the fact that properties may be meta-data about results from the fact that properties may be meta-data about a
a resource that is actually not describing the state of the resource that is actually not describing the state of the
resource itself. A client must be able to discover which resource itself. A client must be able to discover which
properties might change in order to maintain its state properly. properties might change in order to maintain its state properly.
16. Revisions are either mutable or immutable. Once an immutable 16. Revisions are either mutable or immutable. Once an immutable
revision has been checked in, its contents and immutable revision has been checked in, its contents and immutable
properties can never be changed. A mutable revision can be properties can never be changed. A mutable revision can be
checked out, updated, and checked back in without creating a new checked out, updated, and checked back in without creating a new
revision. It must be possible to determine if a revision is revision. It must be possible to determine if a revision is
mutable or immutable, but the mutability of a revision cannot be mutable or immutable, but the mutability of a revision cannot be
changed once it has been checked in. changed once it has been checked in.
The concept of mutable revisions is included to support typical The concept of mutable revisions is included to support typical
document management systems that want to track version histories document management systems that want to track version histories
while allowing more flexible, less formal versioning semantics. while allowing more flexible, less formal versioning semantics.
Mutable revisions will have some restrictions due to the fact Mutable revisions will have some restrictions due to the fact
that because the revision may change, certain configuration that because the revision may change, certain configuration
management semantics cannot be maintained. For example, a management semantics cannot be maintained. For example, a mutable
mutable revision cannot be a member of a configuration because revision cannot be a member of a configuration because the
the configuration would not represent a persistent set of configuration would not represent a persistent set of revisions.
revisions.
17. Each revision may have properties whose values may be changed 17. Each revision may have properties whose values may be changed
without creating a new revision. The list of these properties without creating a new revision. The list of these properties
must be discoverable. must be discoverable.
It is expected that certain live properties whose values are It is expected that certain live properties whose values are
calculated by the server may depend on information that is not calculated by the server may depend on information that is not
captured in the persistent state of an immutable revision. The captured in the persistent state of an immutable revision. The
values of these properties may change from time to time without values of these properties may change from time to time without
requiring a new revision of the versioned resource. There may requiring a new revision of the versioned resource. There may
also be some DAV properties used to support versioning and also be some DAV properties used to support versioning and
configuration management that may change without requiring a configuration management that may change without requiring a new
new revision. revision.
18. Revisions and versioned resources can be deleted. Generally this 18. Revisions and versioned resources can be deleted. Generally
is a high-privilege operation. Deleting a revision must update this is a high-privilege operation. Deleting a revision must
its predecessors’ successors. update its predecessors' successors.
This goal is included to support generally necessary maintenance This goal is included to support generally necessary maintenance
operations on versioning repositories. It is sometimes the case operations on versioning repositories. It is sometimes the case
that successors of a revision beyond some point are no longer that successors of a revision beyond some point are no longer
required and can be removed from the repository to reclaim space. required and can be removed from the repository to reclaim space.
It may also be the case that a versioned resource is no longer It may also be the case that a versioned resource is no longer
used and can be safely deleted. This goal does not intend to used and can be safely deleted. This goal does not intend to
express any policy for when or under what circumstance revisions express any policy for when or under what circumstance revisions
can be deleted. It only provides a mechanism to support particular can be deleted. It only provides a mechanism to support
client or server policies. particular client or server policies.
19. Once a revision has been deleted, its ID cannot be reused within 19. Once a revision has been deleted, its ID cannot be reused
the same versioned resource. within the same versioned resource.
In many cases, it is necessary to be able to guarantee (as far as In many cases, it is necessary to be able to guarantee (as far as
possible) that one can retrieve the exact state of a resource at possible) that one can retrieve the exact state of a resource at
a particular point in history, and/or all the states which the a particular point in history, and/or all the states which the
resource has ever taken on. For example, if a company is sued resource has ever taken on. For example, if a company is sued
for violating a warranty that the plaintiff read on the company’s for violating a warranty that the plaintiff read on the company's
Web site, it might be useful to be able to prove that the Web site, it might be useful to be able to prove that the
warranty never contained the provision that the plaintiff says it warranty never contained the provision that the plaintiff says it
did. Conversely, it may be useful for the plaintiff to be able to did. Conversely, it may be useful for the plaintiff to be able to
prove that it did. A revision history where all revisions were prove that it did. A revision history where all revisions were
immutable would provide this sort of ability. immutable would provide this sort of ability.
Of course, DAV cannot preclude the possibility of an out-of-band Of course, DAV cannot preclude the possibility of an out-of-band
method to change or delete a revision; an implementation may method to change or delete a revision; an implementation may
provide an administrative interface to do it. But such access provide an administrative interface to do it. But such access
would at least be limited to trusted administrators. would at least be limited to trusted administrators.
It is possible that a versioned resource contained in a It is possible that a versioned resource contained in a
configuration is deleted, and a new, unrelated versioned resource configuration is deleted, and a new, unrelated versioned resource
is created using the same URL, and having the same revision id. is created using the same URL, and having the same revision id.
The configuration may incorrectly include this revision. The configuration may incorrectly include this revision.
Requiring revision Ids to be UUIDs would resolve this issue. Requiring revision Ids to be UUIDs would resolve this issue.
20. A configuration can only contain immutable revisions. 20. A configuration can only contain immutable revisions.
This requirement is included in order to retain the usual semantics This requirement is included in order to retain the usual
of configurations, and to ensure that a configuration can always be semantics of configurations, and to ensure that a configuration
recreated. The implication is that unversioned resources, working can always be recreated. The implication is that unversioned
revisions, and mutable revisions cannot be members of a configuration. resources, working revisions, and mutable revisions cannot be
members of a configuration.
21. It must be possible to query a revision history to learn the 21. It must be possible to query a revision history to learn the
predecessors and successors of a particular revision, activity predecessors and successors of a particular revision, activity
names, the initial and latest revisions, etc. names, the initial and latest revisions, etc.
If a client wishes to present a user interface for browsing the If a client wishes to present a user interface for browsing the
revisions of a particular versioned resource, it must be able to revisions of a particular versioned resource, it must be able to
read the relationships represented within the version history. read the relationships represented within the version history.
22. It should be possible to obtain the entire revision history of a 22. It should be possible to obtain the entire revision history of
versioned resource in one operation. a versioned resource in one operation.
A client wishing to display a map of the revision history should A client wishing to display a map of the revision history should
not have to make queries on each individual revision within the not have to make queries on each individual revision within the
revision history. It should be able to obtain all the information revision history. It should be able to obtain all the information
at once, for efficiency's sake. at once, for efficiency's sake.
23. The protocol support for parallel development through activities 23. The protocol support for parallel development through
must be an optional capability. activities must be an optional capability.
Activities support controlled parallel development on the same Activities support controlled parallel development on the same
resource, but results in the need to merge multiple changes at resource, but results in the need to merge multiple changes at
some later time. This introduces work and the potential for some later time. This introduces work and the potential for
errors that some servers may want to avoid by requiring updates errors that some servers may want to avoid by requiring updates
to be serialized. to be serialized.
24. The protocol must support the following operations: 24. The protocol must support the following operations:
1. Creating and accessing revisions: 1. Creating and accessing revisions:
- Create a versioned resource from an unversioned resource . Create a versioned resource from an unversioned
and set its initial revision to the contents of the resource and set its initial revision to the contents
unversioned resource. This does not imply that unversioned of the unversioned resource. This does not imply that
resources are required. A server could create all resources unversioned resources are required. A server could
as versioned resources. create all resources as versioned resources.
- Obtain the URI of, or access a revision or a versioned
resource given the URL for the versioned resource and either
a revision name, or a workspace
- Check out a revision in an activity and create a working . Obtain the URI of, or access a revision or a versioned
resource resource given the URL for the versioned resource and
either a revision name, or a workspace
. Check out a revision in an activity and create a
working resource
- Check in a working resource and create either a new revision . Check in a working resource and create either a new
or update the existing revision in place creating a mutable revision or update the existing revision in place
revision creating a mutable revision
- Cancel a checkout (delete a working resource) . Cancel a checkout (delete a working resource)
- Describe a revision with human-readable comments . Describe a revision with human-readable comments
- See if a resource is versioned . See if a resource is versioned
- Get the versioning options for a resource . Get the versioning options for a resource
2. Labels: 2. Labels:
- Apply a label to a particular revision . Apply a label to a particular revision
- Change the revision to which a label refers . Change the revision to which a label refers
- Get all the revision names on a particular revision . Get all the revision names on a particular revision
- Get the revision history of a resource . Get the revision history of a resource
3. Activities: 3. Activities:
- Create and name an activity . Create and name an activity
- Checkout a revision in an activity . Checkout a revision in an activity
- Merge an activity into a workspace . Merge an activity into a workspace
- Generate and maintain the conflict report for a merge . Generate and maintain the conflict report for a merge
- Get a list of the resources modified in an activity . Get a list of the resources modified in an activity
- Apply a label operation to all resources modified in an . Apply a label operation to all resources modified in an
activity activity
4. Configurations: 4. Configurations:
- Create a configuration . Create a configuration
- Add/remove revisions from a configuration . Add/remove revisions from a configuration
- Access a revision given a configuration name that contains . Access a revision given a configuration name that
it by using a configuration in a version selection rule for contains it by using a configuration in a version
a workspace selection rule for a workspace
- Delete a configuration. . Delete a configuration.
- Determine the differences between two configurations by . Determine the differences between two configurations by
listing the activities in one and not the other. listing the activities in one and not the other.
Some of these operations come from [WEBDAV-GOALS], section Some of these operations come from [WEBDAV-GOALS], section
5.9.1.2. Not all of the operations in that section are 5.9.1.2. Not all of the operations in that section are
replicated here; some of them (e.g., locking) fall out replicated here; some of them (e.g., locking) fall out naturally
naturally from the fact that a revision is a resource. from the fact that a revision is a resource.
The protocol must find some balance between allowing The protocol must find some balance between allowing versioning
versioning servers to adopt whatever policies they wish with servers to adopt whatever policies they wish with regard to these
regard to these operations and enforcing enough uniformity to operations and enforcing enough uniformity to keep client
keep client implementations simple and interoperable. implementations simple and interoperable.
25. For each operation that the protocol defines, the protocol must 25. For each operation that the protocol defines, the protocol
define that operation's interaction with all existing [WebDAV] must define that operation's interaction with all existing
methods on all existing WebDAV resources. [WebDAV] methods on all existing WebDAV resources.
This goal applies to all HTTP extensions, not just versioning. This goal applies to all HTTP extensions, not just versioning.
However, versioning, parallel development, and configuration However, versioning, parallel development, and configuration
management are sufficiently complex and have a broad enough management are sufficiently complex and have a broad enough
effect on other methods to call out this goal specifically. effect on other methods to call out this goal specifically.
26. The protocol should clearly identify the policies that it 26. The protocol should clearly identify the policies that it
dictates and the policies that are left up to versioning system dictates and the policies that are left up to versioning system
implementers or administrators. A client must be able to discover implementers or administrators. A client must be able to discover
what policies the server supports. what policies the server supports.
skipping to change at line 1025 skipping to change at page 21, line 44
(linear or branched), the granularity of change tracking, locking (linear or branched), the granularity of change tracking, locking
requirements made by a server, naming conventions for activities requirements made by a server, naming conventions for activities
and labels, etc. and labels, etc.
27. A client must be able to determine whether a resource is a 27. A client must be able to determine whether a resource is a
versioned resource, or whether a resource is itself revision of a versioned resource, or whether a resource is itself revision of a
versioned resource. versioned resource.
A resource may be a simple, non-versioned resource, a versioned A resource may be a simple, non-versioned resource, a versioned
resource, an immutable revision, a mutable revision, or a working resource, an immutable revision, a mutable revision, or a working
resource. A client needs to be able to tell which sort of resource resource. A client needs to be able to tell which sort of
it is accessing. resource it is accessing..
28. A client must be able to access a versioned resource with a 28. A client must be able to access a versioned resource with a
simple URL and get some well-defined default revision. simple URL and get some well-defined default revision.
The server should return a default revision of a resource for The server should return a default revision of a resource for
where no specific revision information is provided. This is one where no specific revision information is provided. This is one
of the simplest ways to guarantee non-versioning client of the simplest ways to guarantee non-versioning client
compatibility. This does not rule out the possibility of a server compatibility. This does not rule out the possibility of a server
returning an error when no sensible default exists. returning an error when no sensible default exists.
skipping to change at line 1054 skipping to change at page 22, line 18
the purposes of applying version selection rules is the the purposes of applying version selection rules is the
responsibility of the client application. The server does not responsibility of the client application. The server does not
necessarily maintain this association. necessarily maintain this association.
29. It must be possible, given a reference to a revision of a 29. It must be possible, given a reference to a revision of a
versioned resource, to find out which versioned resource that versioned resource, to find out which versioned resource that
revision belongs to. revision belongs to.
This makes it possible to understand the versioning context of This makes it possible to understand the versioning context of
the revision. It makes it possible to retrieve a revision history the revision. It makes it possible to retrieve a revision history
for the versioned resource to which it belongs, and to browse for the versioned resource to which it belongs, and to browse the
the revision history. It also supports some comparison operations: revision history. It also supports some comparison operations: It
It makes it possible to determine whether two references designate makes it possible to determine whether two references designate
revisions of the same versioned resource. revisions of the same versioned resource.
30. Versioning functionality may be partitioned into levels. The 30. Versioning functionality may be partitioned into levels. The
lowest level must provide simple versioning of resources and lowest level must provide simple versioning of resources and
support for labels, checkin, and checkout. Other functions should support for labels, checkin, and checkout. Other functions should
be as orthogonal as possible so that servers have additional be as orthogonal as possible so that servers have additional
flexibility in choosing features to implement. Functionality at flexibility in choosing features to implement. Functionality at
lower levels must be a consistent subset of the functionality at lower levels must be a consistent subset of the functionality at
higher levels and not introduce special cases, incompatible, or higher levels and not introduce special cases, incompatible, or
redundant functions. redundant functions.
Servers must provide all the functions defined for a given level Servers must provide all the functions defined for a given level
in order to claim and advertise conformance to that level. A in order to claim and advertise conformance to that level. A
server may choose to implement additional features from higher server may choose to implement additional features from higher
levels to support particular business and/or client requirements. levels to support particular business and/or client requirements.
The OPTIONS method indicates exactly what features are supported The OPTIONS method indicates exactly what features are supported
while the DAV header indicates the supported level clients can while the DAV header indicates the supported level clients can
rely on. rely on.
31. It must be possible to lock an activity so that no one can make At a minimum, the following actions are actions are available at
further changes in that activity. the basic level:
32. It must be possible to indicate that a particular resource does . Checkout a revision and receive a way to update the working
not allow parallel development. That is, the resource can copy
. Checkin a working copy to create a new revision
. Cancel an active checkout
. Optional for server to support multiple checkouts on the same
resource
. Labeling of revisions to identify them
. Access to the linear checkin history of a versioned resource
31. It must be possible to lock an activity so that no one can
make further changes in that activity.
32. It must be possible to indicate that a particular resource
does not allow parallel development. That is, the resource can
effectively only be checked out in one activity. effectively only be checked out in one activity.
33. The protocol should be defined in such a way as to minimize the 33. The protocol should be defined in such a way as to minimize
adoption barriers for clients and existing repository managers. the adoption barriers for clients and existing repository
This includes integration with legacy data in repository managers. This includes integration with legacy data in
managers supporting the WebDAV protocol. repository managers supporting the WebDAV protocol.
34. The server must not require client applications to retain state 34. The server must not require client applications to retain
in order to support versioning semantics. That is, a user must be state in order to support versioning semantics. That is, a user
able to begin using versioning with one client, and continue must be able to begin using versioning with one client, and
using versioning on some other client at some other time. continue using versioning on some other client at some other
time.
35. It must be possible to discover what resources have changed in a 35. It must be possible to discover what resources have changed in
workspace from a given point. a workspace from a given point.
Rationale 36. Versioned resources, revisions, and activities must have an
associated URN that is globally unique.
37. Servers may choose to support only mutable revisions, only
immutable revisions, or both. Clients must be able to discover
the support provided by the server.
38. Activities should be able to be dependent (conceptually
include) other activities.
39. Enumeration of versioning resource types should be fast/easy.
1.4 Rationale
Versioning in the context of the worldwide web offers a variety of Versioning in the context of the worldwide web offers a variety of
benefits: benefits:
1. It provides infrastructure for efficient and controlled management 1. It provides infrastructure for efficient and controlled
of large evolving web sites. Modern configuration management management of large evolving web sites. Modern configuration
systems are built on some form of repository that can track the management systems are built on some form of repository that can
revision history of individual resources, and provide the track the revision history of individual resources, and provide
higher-level tools to manage those saved versions. Basic versioning the higher-level tools to manage those saved versions. Basic
capabilities are required to support such systems. versioning capabilities are required to support such systems.
2. It allows parallel development and update of single resources. 2. It allows parallel development and update of single resources.
Since versioning systems register change by creating new objects, Since versioning systems register change by creating new objects,
they enable simultaneous write access by allowing the creation of they enable simultaneous write access by allowing the creation of
variant versions. Many also provide merge support to ease the variant versions. Many also provide merge support to ease the
reverse operation. reverse operation.
3. It provides a framework for coordinating changes to resources. 3. It provides a framework for coordinating changes to resources.
While specifics vary, most systems provide some method of While specifics vary, most systems provide some method of
controlling or tracking access to enable collaborative resource controlling or tracking access to enable collaborative resource
development. development.
4. It allows browsing through past and alternative versions of a 4. It allows browsing through past and alternative versions of a
resource. Frequently the modification and authorship history of a resource. Frequently the modification and authorship history of a
resource is critical information in itself. resource is critical information in itself.
5. It provides stable names that can support externally stored links 5. It provides stable names that can support externally stored links
for annotation and link-server support. Both annotation and link for annotation and link-server support. Both annotation and link
servers frequently need to store stable references to portions of servers frequently need to store stable references to portions of
resources that are not under their direct control. By providing resources that are not under their direct control. By providing
stable states of resources, version control systems allow not only stable states of resources, version control systems allow not
stable pointers into those resources, but also well defined only stable pointers into those resources, but also well defined
methods to determine the relationships of those states of a methods to determine the relationships of those states of a
resource. resource.
6. It allows explicit semantic representation of single resources 6. It allows explicit semantic representation of single resources
with multiple states. A versioning system directly represents the with multiple states. A versioning system directly represents the
fact that a resource has an explicit history and a persistent fact that a resource has an explicit history and a persistent
identity across the various states it has had during the course of identity across the various states it has had during the course
that history. of that history.
Non-goals 1.5 Non-goals
These non-goals enumerate functionality that the working group has These non-goals enumerate functionality that the working group has
explicitly agreed to exclude from this document. They are documented explicitly agreed to exclude from this document. They are
here for explanatory purposes. documented here for explanatory purposes.
1. Revisions in multiple revision histories (see [WEBDAV-GOALS], 1. Revisions in multiple revision histories (see [WEBDAV-GOALS],
sections 5.9.1.3 and 5.9.2.5). This capability was felt to be too sections 5.9.1.3 and 5.9.2.5). This capability was felt to be
rarely useful. too rarely useful.
2. Federated revision histories (that is, revision histories which 2. Federated revision histories (that is, revision histories
are not stored on a single server). This capability would which are not stored on a single server). This capability
introduce great difficulties. A server implementer who needs it would introduce great difficulties. A server implementer who
can use out-of-band server-to-server communication. But, this needs it can use out-of-band server-to-server communication.
communication is arguably out of the scope of WebDAV, which is a But, this communication is arguably out of the scope of
client-to-server protocol. WebDAV, which is a client-to-server protocol. However, the
protocol shouldn't do anything to preclude federated version
histories at a later date.
3. Client-proposed version identifiers (see [WEBDAV-GOALS], section 3. Client-proposed version identifiers (see [WEBDAV-GOALS],
5.9.2.8). Labels do the job better. section 5.9.2.8). Labels do the job better.
4. Change management or change control operations. It is envisioned 4. Change management or change control operations. It is
that policies for change management and the mechanisms to implement envisioned that policies for change management and the
them will be quite variable for the number and types of users mechanisms to implement them will be quite variable for the
authoring content for the web. Therefore it is important to provide number and types of users authoring content for the web.
core capabilities for versioning, parallel development, and Therefore it is important to provide core capabilities for
configuration management without hindering the policies client versioning, parallel development, and configuration management
applications may choose to present to their users. It is intended without hindering the policies client applications may choose
that WebDAV versioning will provide these core capabilities, and to present to their users. It is intended that WebDAV
that a variety of change management policies could be implemented versioning will provide these core capabilities, and that a
on these core capabilities by client applications. variety of change management policies could be implemented on
these core capabilities by client applications.
5. Server-to-server communication (e.g., replication) is not required. 5. Server-to-server communication (e.g., replication) is not
required.
Security Considerations 1.6 Security Considerations
To be written. It is likely that implementing features to meet the To be written. It is likely that implementing features to meet the
goals described here will present few or no new security risks beyond goals described here will present few or no new security risks
those of base DAV. One possible exception is that it may become more beyond those of base DAV. One possible exception is that it may
difficult to hide the contents of a resource when there may exist become more difficult to hide the contents of a resource when there
other versions with different access control lists. may exist other versions with different access control lists.
References 1.7 References
[WEBDAV]Y.Y. Goland, E.J. Whitehead, Jr., A. Faizi, S.R. Carter, [WEBDAV]Y.Y. Goland, E.J. Whitehead, Jr., A. Faizi, S.R. Carter, D.
D. Jensen, "Extensions for Distributed Authoring on the World Wide Jensen, "Extensions for Distributed Authoring on the World Wide Web
Web -- WEBDAV", Internet-Draft draft-ietf-webdav-protocol-10. Nov., -- WEBDAV", Internet-Draft draft-ietf-webdav-protocol-10. Nov.,
1998 1998
[WEBDAV-GOALS] J. Slein, F. Vitali, J. Whitehead, D. Durand, [WEBDAV-GOALS] J. Slein, F. Vitali, J. Whitehead, D. Durand,
"Requirements for a Distributed Authoring and Versioning Protocol "Requirements for a Distributed Authoring and Versioning Protocol
for the World Wide Web", RFC-2291. February 1998. for the World Wide Web", RFC-2291. February 1998.
[WEBDAV-ACP] J. Slein, J. Davis, A. Babich, J. Whitehead, "WebDAV
[WEBDAV-ACP] J. Slein, J. Davis, A. Babich, J. Whitehead, Advanced Collections Protocol", Internet-Draft draft-ietf-webdav-
"WebDAV Advanced Collections Protocol", Internet-Draft collection-protocol-02.txt. Nov., 1998.
draft-ietf-webdav-collection-protocol-02.txt. Nov., 1998. [DASL] S. Reddy, D. Jensen, S. Reddy, R. Henderson, J. Davis, A.
Babich, "DAV Searching & Locating", Internet-Draft draft-reddy-
[DASL] S. Reddy, D. Jensen, S. Reddy, R. Henderson, J. Davis, dasl-protocol-04.txt. Nov., 1998.
A. Babich, "DAV Searching & Locating",
Internet-Draft draft-reddy-dasl-protocol-04.txt. Nov., 1998.
[CVS] http://www.cyclic.com/cyclic-pages/books.html [CVS] http://www.cyclic.com/cyclic-pages/books.html
[BONSAI] Mozilla.org, http://www.mozilla.org/bonsai.html [BONSAI] Mozilla.org, http://www.mozilla.org/bonsai.html
1.8 Open Issues
. The current write up of configurations may need to change as we
define what a "configuration" is.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/