idnits 2.17.1 draft-ietf-webdav-version-goals-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 341 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([WEBDAV-GOALS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 357 has weird spacing: '...to make index...' == Line 590 has weird spacing: '...editing tool ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 1999) is 9043 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'WEBDAV-GOALS' on line 1234 looks like a reference -- Missing reference section? 'DASL' on line 1240 looks like a reference -- Missing reference section? 'WebDAV' on line 1013 looks like a reference -- Missing reference section? 'WEBDAV-ACP' on line 1237 looks like a reference -- Missing reference section? 'CVS' on line 1243 looks like a reference -- Missing reference section? 'BONSAI' on line 1244 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jim Amsden, IBM 2 draft-ietf-webdav-version-goals-01.txt Chris Kaler, Microsoft 3 J. Stracke, Netscape 5 Expires December 26, 1999 June 26, 1999 7 Goals for Web Versioning 9 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 29 Versioning and configuration management are important features for 30 controlling the evolution of remotely authored Web content. Parallel 31 development leverages versioning capability to allow multiple authors to 32 simultaneously author Web content. These functions form a basis for 33 flexible, scaleable distributed authoring. This document describes a set 34 of scenarios, functional, and non-functional requirements for web 35 versioning extensions to the WebDAV protocol. It supersedes the 36 versioning-related goals of [WEBDAV-GOALS]. 38 Table of Contents 40 1 INTRODUCTION ...........................................2 41 1.1 Definitions .........................................4 42 1.2 Storyboards .........................................6 43 1.3 Goals ..............................................14 44 1.4 Rationale ..........................................23 45 1.5 Non-goals ..........................................24 46 1.6 Security Considerations ............................25 47 1.7 References .........................................25 48 1.8 Open Issues ........................................25 50 1 INTRODUCTION 52 Versioning, parallel development, and configuration management are 53 important features for remote authoring of Web content. Version 54 management is concerned with tracking and accessing the history of 55 important states of a single Web resource, such as a standalone Web 56 page. Parallel development provides additional resource 57 availability in multi-user, distributed environments and lets 58 authors make changes on the same resource at the same time, and 59 merge those changes at some later date. Configuration management 60 addresses the problems of tracking and accessing multiple 61 interrelated resources over time as sets of resources, not simply 62 individual resources. Traditionally, artifacts of software 63 development, including code, design, test cases, requirements, help 64 files, and more have been a focus of configuration management. Web 65 sites, comprised of multiple inter-linked resources (HTML, 66 graphics, sound, CGI, and others), are another class of complex 67 information artifacts that benefit from the application of 68 configuration management. 70 The WebDAV working group originally focused exclusively on defining 71 version management capabilities for remote authoring applications 72 and group consensus on these features is reflected in [WEBDAV- 73 GOALS]. However, as the WebDAV working group has constructed 74 protocols for versioning functionality, it has become clear that 75 while versioning functionality alone is useful for a range of 76 content authoring scenarios involving one, or a small set of 77 resources, versioning alone is insufficient for managing larger 78 sets of content. Protocol support for parallel development and 79 simple remote configuration management of Web resources provides 80 functionality for managing larger sets of interrelated content 81 developed by multiple users at different locations. 83 This document contains a set of scenarios and a list of the 84 functional and non-functional goals for versioning, parallel 85 development, and configuration management of Web resources. It 86 replaces the existing functional goals for versioning capability 87 described in [WEBDAV-GOALS], section 5.9. These scenarios and goals 88 are used to develop a model of WebDAV versioning, which in turn is 89 used to develop the protocol that implements it. 91 Version management is always a tradeoff between the goals for 92 maximum data integrity, maximum data availability, and ease of use. 93 It is relatively easy to specify a design that satisfies any two of 94 these goals, but this is often at the expense of the third. For 95 example, data availability and ease of use are easy to accomplish 96 using authoring servers that compromise data integrity by following 97 a last writer wins policy. In contrast, high data integrity and 98 availability are possible using branch and merge systems, but at 99 the cost of ease of use due to difficult merges. The requirements 100 for WebDAV versioning are based on compromises between these 101 conflicting goals. WebDAV versioning specifies a set of mechanisms 102 that can be exploited to support a variety of policies allowing 103 client applications and users to find a balance appropriate to 104 their needs. 106 1.1 Definitions 108 1. A basic resource is a resource that is not a collection or 109 reference, i.e., an HTTP/1.1 resource. 111 2. A versioned resource is an abstraction for a resource which is 112 subject to version control, a resource having a set of 113 revisions, relationships between those revisions, revision 114 names, and named branches that track the evolution of the 115 resource. 117 3. A revision is a particular version of a versioned resource. An 118 immutable revision is a revision that once created, can never 119 be changed without creating a new revision. A mutable revision 120 is a revision that can change without creating a new version. 122 4. A working resource is an editable resource derived from a 123 revision of a versioned resource by checking out the revision. 124 A working resource can become a new revision, or overwrite an 125 existing mutable revision on check in. 127 5. A initial revision is the first revision of a versioned 128 resource and has no predecessors within the versioned 129 resource. 131 6. A revision name is a unique name that can be used to refer to 132 a revision of a versioned resource. There are two types of 133 revision names, revision identifiers or labels as described 134 below. 136 7. A revision identifier (or revision ID) is a revision name 137 which uniquely and permanently identifies a revision of a 138 versioned resource. Revision identifiers are assigned by the 139 server when the revision is created and cannot be changed 140 later to refer to a different revision. 142 8. A label is a revision name which uniquely, but not necessarily 143 permanently identifies a revision of a versioned resource. A 144 label may be assigned to a revision, and may be changed to 145 refer to a different revision at some later time. The same 146 label may be assigned to many different versioned resources. 148 9. A predecessor of a revision is a revision from which this 149 revision is created. A successor of a revision is a revision 150 derived from this revision. A revision may have one 151 predecessor and multiple successors. The is-derived-from 152 relationships between revisions of a versioned resource form a 153 tree. 155 10. The merge-predecessors of a revision are those revisions 156 that have been merged with this revision. 158 11. A revision history is a concrete representation of the 159 elements of a versioned resource including all predecessor and 160 successor relationships, revision names, activities, etc. 162 12. A line-of-descent is a sequence of revisions connected by 163 successor/predecessor relationships from the initial revision 164 to a specific revision. 166 13. An activity is a resource referring to a named set of 167 revisions that correspond to some unit of work or conceptual 168 change. Activities are created by authors and are used to 169 organize related changes to resources, and to provide a basis 170 for parallel development and merging concurrent changes to the 171 same resource. An activity can contain revisions of multiple 172 versioned resources, and/or multiple revisions of the same 173 versioned resource along a single line-of-descent. In each 174 activity, it is possible to refer to the latest revision of a 175 versioned resource in that activity. 177 14. A workspace is a resource that is used to determine what 178 revision of a versioned resource should be accessed when the 179 resource is referenced without a particular revision name. 180 When a user agent accesses a versioned resource, a workspace 181 may be specified to determine the specific revision that is 182 the target of the request. A workspace contains a version 183 selection rule that is applied when the workspace is used in 184 conjunction with the URI for a versioned resource to perform 185 URL mapping and select a specific revision. 187 15. A revision selection rule specifies what revision of a 188 versioned resource should be selected. WebDAV defines 189 selection rules that allow a revision to be selected based on 190 its checked out status, revision name, activity name, 191 configuration name, or the latest revision. Servers may 192 support additional selection rules. 194 16. A conflict report lists all revisions that must be merged 195 when an activity is merged into a workspace. If the merge 196 source activity specifies a resource that is a predecessor or 197 successor of the revision selected by the current workspace, 198 then there is no conflict. The merged workspace will pick the 199 revision already in the workspace if the merge source 200 specifies a predecessor, otherwise it will pick the successor 201 specified by the merge source. Conflicts result when the merge 202 source activity picks a revision on a different line-of- 203 descent than that selected by workspace. Conflicts are 204 resolved by merging resources together into the workspace. 205 This creates a new revision that has multiple predecessors and 206 contains the changes from both merge source and the current 207 workspace revisions. 209 17. A configuration is a named set of related resources where 210 each member refers to a specific revision of a versioned 211 resource. A configuration is a specific instance of a set of 212 versioned resources. Configurations are similar to 213 activities, but play a different role. A workspace with its 214 current activity and version selection rule specifies what a 215 client can see. An activity is associated with work in 216 progress and encapsulates a set of related changes to multiple 217 versioned resources. Creating separate activities allows 218 developers to work in parallel on the same resources, and to 219 reconcile conflicts through merging activities. Configurations 220 represent a persistent selection of revisions of versioned 221 resources for organization and distribution. Configurations 222 can be versioned resources, activities cannot. 224 18. The checkout paradigm is the process by which updates are 225 made to versioned resources. A resource is checked out 226 thereby creating a working resource. The working resource is 227 updated or augmented as desired, and then checked in to make 228 it part of the version history of the resource. 230 1.2 Storyboards 232 This section provides an example usage scenario that provides a 233 context for explaining the definitions above, and for exploring and 234 validating the goals given in the rest of this document. The 235 example consists of a fictitious company, Acme Web Solutions that 236 is developing a typical Web e-business application. To provide for 237 the broadest coverage, the scenarios start with a non-existent 238 resource typical of web applications, and follow its life cycle 239 through development and multiple deployments. Other resources would 240 likely have similar life cycles. 242 Acme Web Solutions (AWS) has developed a web-grocery store called 243 WGS. The application consists of a number of HTML pages, some Java 244 applets, some Java Server Pages (JSP) and a number of Java servlets 245 that access a DB2 database. 247 AWS has decided to develop a new generation of its flagship WGS 248 product to include maintenance of customer profile information, and 249 active (push) marketing of product specials to interested customers 250 using Channel Definition Format (CDF). The new product will be 251 called Active Grocery Store or AGS. Customers who are interested in 252 receiving information on specials will indicate that interest by 253 subscribing to various CDF channels targeting pre-defined or user- 254 specified product groupings. Since AGS represents significant new 255 revenue potential for grocery stores, AWS has decided to sell it as 256 a separate product from WGS, and at a relatively high price. WGS 257 will still be available without AGS as a lower-cost, entry-level 258 solution for smaller stores, or stores just getting into e-business 259 solutions. 261 AGS is a typical Web application development project that will 262 require changes to existing resources in AWS as well as adding new 263 resources. These new resources will also be HTML pages, applets, 264 JSPs, servlets, etc. WGS is an active project sold to current 265 customers with a maintenance contract. It has on-going updates that 266 are unrelated to the new AGS system, but may need to be included in 267 the AGS system. These include bug fixes or minor new functional 268 improvements. Since AGS is based on WGS, but both can evolve and be 269 sold separately, it is necessary to maintain versions of resources 270 used by both. This will require AWS developers to specify a 271 configuration of versioned resources corresponding to each product. 272 As the products evolve over time, these configurations will be 273 versioned resources themselves, each representing a new release of 274 their associated product, WGS, AGS, or both. 276 The AWS development organization consists of a large number of 277 developers across a variety of disciplines including webmasters, 278 Java developers, relational database developers, HTML page editors, 279 graphics artists, etc. All of these developers contribute to the 280 development of the WGS and AGS products, often working in parallel 281 on the same resource for different purposes. For example, a WGS 282 developer may be editing an HTML page to fix a usability problem 283 while an AGS developer is working on the same page to add the new 284 AGS functions. This will require coordination of their activities 285 to provide maximum availability of these shared resources while at 286 the same time ensuring the integrity of the updates. The AWS 287 development team has decided to allow parallel development and 288 resolve multiple concurrent updates through branching and merging 289 of the resource version graph. This adds complexity to the 290 development project as well as some risk due to inaccurate merges, 291 but AWS has decided it cannot be competitive in the Web world if 292 all development must be serialized on shared resources as this 293 would significantly slow product development. 295 The following scenarios trace the life cycle of a typical Web 296 resource from conception to product deployment and maintenance. 297 Each scenario exposes some aspect of WebDAV and its use of the 298 versioning, parallel development and configuration management 299 definitions and goals specified in this document. In the scenarios 300 below, it is assumed that all developers have access to a Web 301 WorkBench (WB) application that provides client access to a WebDAV 302 server called DAVServer. It is further assumed that both the client 303 and server provide level 2 WebDAV services plus advanced 304 collections, versioning, parallel development, and configuration 305 management. 307 There is a goal that WebDAV versioning will support perhaps 308 multiple levels of versioning from none (existing WebDAV 309 specification), simple linear versioning, support for parallel 310 development, and through to configuration management. The scenarios 311 below should follow this progression from simple to complex in 312 order to help expose logical points for leveling the protocol 313 functionality. However, the intent of this document is to at least 314 expose the complete goals for full WebDAV versioning support in 315 order to ensure down-levels are a consistent subset. The exact 316 contents of down-level servers and the number of levels will be 317 determined later during protocol development. 319 1.2.1.1 Resource Creation 321 The AGS project team held a design meeting to determine the work 322 products required to support the AGS project, its integration with 323 the WGS application, and to assign these work products to 324 developers. Various analysis and design techniques can be used to 325 discover the required work products, but this is beyond the scope 326 of WebDAV. At the end of the meeting, webmaster Joe was assigned to 327 develop the new welcome page, index.html, for the AGS project. This 328 page will be the initial page used to navigate the AGS application, 329 and is the first page seen by users. It is a new page that will not 330 replace the WGS welcome page, but will contain a reference to it. 332 Joe uses WB to create a new collection, http://aws/ags/, and the 333 new index.html page in the collection http://aws/ags/index.html. 334 Neither the parent collection, nor index.html are versioned 335 resources at this point. A WebDAV MKCOL is used to create the 336 collection, and a PUT is used to create the initial, empty 337 resource. 339 1.2.1.2 Resource Editing 341 Joe uses WB to GET the resource and edit it with his favorite HTML 342 editor. Each save by the HTML editor does a PUT to the DAVServer, 343 overwriting its current contents. No new versions are created. Joe 344 may also use WB to get and set properties of index.html using 345 PROPFIND and PROPPATCH. Joe does not need to lock index.html 346 because he is the only developer working on it at this time. He 347 could however lock the resource to ensure no one else could make 348 any changes he is not aware of. 350 1.2.1.3 Creating a Versioned Resource 352 At some point, Joe decides preliminary editing on index.html is 353 complete, and he needs to make a stable version available to other 354 developers who need it for integration testing, etc. Joe however 355 wants to ensure that no other developers make changes to index.html 356 that he cannot back out, as he is the webmaster responsible for the 357 resource. So Joe uses the WB to make index.html which causes 358 DAVServer to create a versioned resource, and make the initial 359 version Joe's index.html. At this point, Joe's index.html is 360 immutable, it cannot be changed by anyone, including Joe, and 361 remains in the repository until the versioned resource is deleted. 363 1.2.1.4 Labeling a Version 365 When DAVServer created the versioned resource corresponding to 366 index.html, it gave the initial version a revision id, 367 "102847565". This revision name is automatically assigned by the 368 server, and cannot be changed or assigned to any other version. 369 This revision name acts as the unique identifier for this version 370 of versioned resource index.html. The AGS development team has 371 decided that a revision label _initial_ will identify the initial 372 version of all resources. This ensures they stand out and can be 373 easily accessed without remembering some opaque revision id. Joe 374 uses WB to set the label on the initial version to "initial" in 375 order to identify the version with this more meaningful name. 377 1.2.1.5 Accessing Versioned Resources 379 Fred wants to access Joe's initial version of index.html. So he 380 uses URL http://aws/ags/index.html to get the contents of the 381 resource and notices he does get the right version, because it was 382 selected by the default workspace. That is, when Fred accessed URL 383 http://aws/ags/index.html, he did so without specifying a 384 workspace. So the default workspace was used, and the default 385 workspace always uses "latest" in its version selection rule. But 386 Fred wants to be more cautions. He wants to be sure that he 387 continues to get version labeled "initial", even if the latest 388 version changes as the result of new changes Joe may check in. So 389 Fred creates a workspace called "initialws", and sets the version 390 selection rule to be the revision labeled "initial". Then Fred 391 always accesses index.html with its URL and the initialws workspace 392 to be sure he gets the specific version he needs. The workspace 393 also ensures he gets the revision named _initial_ of all other 394 versioned resources as well, ensuring a consistent set of 395 revisions. 397 Later that week, there have been a number of changes to index.html, 398 and Fred wants to just take a quick look at an old version to 399 remember how the page used to look. Fred's workspace is currently 400 selecting the latest version, and he doesn't want to change his 401 workspace just to look at some other revision. So Fred uses his 402 WebDAV client to access index.html using label _initial_, or 403 revision id 32345 to override the workspace selection and get the 404 initial revision. 406 1.2.1.6 Creating a New Revision 408 A week later, a number of developers have noticed that index.html 409 is missing both important references to their pages as well as hot 410 images for navigation. They send email to Joe specifying their new 411 requirements. Joe now wants to make changes to index.html and 412 create a new revision. He wants to retain the old revision, just in 413 case the requirements he was given were incorrect and need to be 414 backed out, and to allow developers using the old revision to 415 continue their work. To do this, Joe uses the WB to check out 416 index.html and create a new working resource. Joe can now access 417 the working resource because working resources are always visible 418 from the workspace in which they were checked out. 420 As before, Joe uses the WB and HTML editor to GET the working 421 resource and PUT updates. Each PUT replaces the contents of the 422 working resource with changes made by the HTML editor, no new 423 revision is created. When Joe is finished making edits to support 424 the new requirements, he checks the working resource back in, 425 making a new revision. 427 1.2.1.7 Editing a Mutable Revision 429 John was assigned to write a high level marketing document, 430 ags.html that provided an overall description of the AGS 431 application. Since most changes to this document have no effect on 432 the rest of AGS, John decides to allow revisions of ags.html to be 433 overwriteable. This is so simple spelling and grammar errors can be 434 fixed without requiring the creation of a new revision. John still 435 wants to create revisions whenever some significant new feature is 436 added to AGS so the old descriptions are available to customers who 437 don't upgrade. 439 John creates resource ags.html, edits it a number of times, and 440 then checks it in to create a versioned resource. 442 Later on, a new feature is added and John checks out ags.html to 443 create a new revision, makes his edits, and checks it back in, 444 creating a new revision. Three days later, John notices a spelling 445 mistake in the first revision that he corrected in the new 446 revision, but users of the old revision would like the correction 447 made for their users too. So John again checks out the old revision 448 creating a new working resource, fixes the spelling mistake, and 449 then checks the working resource back in. However in this case, 450 John selects check in in-place in order to overwrite the old 451 revision with the corrected revision. Now all users of the old 452 revision will see the correction. This revision is now marked as 453 mutable since it has been changed. 455 Six months later, there have been a number of complaints about 456 ags.html presenting misleading product information that has 457 resulted in unhappy customers. There's even talk of lawsuits. So 458 John hurriedly updates ags.html and checks in the new version as 459 immutable so that in case there is a suit, he can prove that 460 customers had access to his updated version. Now any changes can be 461 made by creating new immutable revisions without ever worrying 462 about loosing old version. 464 A year later, things have cooled down, and John decides its OK to 465 allow mutable revisions again. On his last change he checked 466 ags.html in as a mutable revision allowing subsequent changes to be 467 done without creating new versions. At the same time, the revision 468 history of the immutable revisions is preserved just in case that 469 pesky customer re-appears. 471 1.2.1.8 Parallel Development with Activities 473 Two weeks later, there is a major redesign of AGS that results in a 474 lot of changes to index.html. Again, Joe checks out the resource 475 creating a new working resource. But it is taking Joe a long time 476 to finish all the edits, and in the meantime, graphics artist Jane 477 wants to update index.html with references to the new images that 478 resulted from the AGS redesign. Jane attempts to check out 479 index.html, but WB informs her that Joe already has it checked out 480 and refuses the request. She checks with Joe, and since they are 481 both working on different aspects of index.html, Joe feels it would 482 be fine for Jane to do her work in parallel with his, and then he 483 will merge her changes with his to finish the required updates. 484 Jane creates a new activity called "images_updates", uses it to set 485 the activity of her workspace, and again attempts the checkout. 486 This time the checkout succeeds, and a new working resource is 487 created for index.html in the images_updates activity. Now any 488 changes that Jane makes to images.html are completely independent 489 of changes Joe makes to the same resource, but in a different 490 activity. Note that Joe did not create an activity when he checked 491 out index.html. Instead, the default activity "mainline" was used. 492 Jane couldn't checkout index.html without specifying a different 493 activity because a resource can only be checked out once in a given 494 activity. She also couldn't make any changes until the resource is 495 checked out as checked in revisions are read-only. 497 After making her edits, she checks index.html back in, which 498 creates a new revision in the images_updates activity. 500 1.2.1.9 Merging Activities 502 Project management practice dictates that at various times during 503 the development project, usually every few days or at specific 504 project milestones, the updates from any parallel activities should 505 be merged in order to integrate the changes and produce instances 506 of the products suitable for testing. This avoids the risk of 507 revisions of shared resources diverging wildly, and thereby 508 decreases the likelihood of difficult or inaccurate merges. It also 509 encourages communication within the development organization and 510 avoids "big-bang" integration points late in the development cycle. 511 This enhances the stability of the products and helps ensure a 512 deterministic, controllable development process. It also allows 513 early product testing and better feedback to developers. 515 Joe has finally finished his changes to image.html, and is ready to 516 incorporate the changes from Jane's images_update activity to get 517 the new images. Before doing so, Joe checks his updates into 518 revision "r0.2" so if he does something wrong when doing the merge, 519 he can recover and try again. Now Joe specifies in his workspace 520 that he wishes to merge the "image_updates" activity into his 521 workspace. He then can obtain a conflict report from his workspace 522 that indicates that the resource index.html requires a merge. He 523 then issues a merge request for index.html. This checks out the 524 resource in the mainline activity (the activity in Joe's 525 workspace), and registers a merge from the latest revision in the 526 image_updates activity to the working resource. This working 527 resource now has two predecessors, r0.2 and the image_updates 528 revision. Joe then uses the differencing capability in his HTML 529 editor to find the differences between his revision and Jane's, and 530 to apply Jane's changes as appropriate. 532 The HTML editor Joe uses is WebDAV versioning aware, and does a 3- 533 way merge by accesses the closest common ancestor in the revision 534 history in order to help with the merge process. Joe notices that 535 most of Jane's changes do not conflict with his as they are in 536 different places in the resource, but there are a number of places 537 where he added new functions that do not have images as Jane didn't 538 know they were there. He notes these and either fixes them himself, 539 or sends email to Jane so she can fix them in another revision. 540 Once the changes are complete, Joe checks in the merged revision. 541 Jane is free to continue making updates in her image_updates 542 activity, and these changes can be merged in again later. 544 1.2.1.10 Creating a Configuration 546 At some point, enough of the work products of the AGS application 547 are sufficiently complete and stable that AWS wants to distribute 548 an alpha release. To do this, Joe uses WB to create a configuration 549 named "alphaRelease" that will contain a consistent set of 550 compatible work product revisions. This configuration will contain 551 all revisions currently selected by Joe's workspace. If any working 552 resources exist in Joe's workspace, the request to create a 553 configuration fails, with an error message indicating that the 554 failure is due to the presence of checked-out resources in Joe's 555 workspace. 557 When Jane is ready to see the alphaRelease, she modifies the 558 revision selection rules of her workspace to select this new 559 configuration. Any conflicts between this new configuration and her 560 current activity requiring merges would be noted in the "conflicts" 561 report of her workspace, which Jane could then resolve with the 562 "merge" operation. 564 Each release of AGS consists of new resources and updated revisions 565 of existing resources. To simplify creating a new configuration for 566 each new release, Joe can make the AGS configuration a versioned 567 resource. For release 1 of AGS, Joe uses a configuration called 568 AGS, and labels it R1. For release 2, he checks out version R1 of 569 configuration AGS, and adds, removes, or changes the revisions of 570 versioned resources in the configuration, then checks in the 571 configuration and labeling it R2. 573 1.2.1.11 Getting the Revision History of a Versioned Resource 575 In order to determine what revision should be included in the 576 alphaRelease configuration, Joe must examine the revision history 577 of resource index.html. He does this by requesting the revision 578 history of index.html and receives an XML document describing all 579 the revisions including their revision id, labels, descriptions, 580 successors, predecessor, and merge predecessors. Joe uses an XML 581 enabled browser and an XSL style sheet to view the revision 582 history. 584 1.2.1.12 Accessing Resources by Non-versioning Aware Clients 586 Fred belongs to a different company, and does not have any WebDAV 587 versioning aware tools. However, he is an excellent graphics 588 artist, and has been asked to look over a particular image file, 589 logo.gif. So Fred uses his image editing tool to get a copy of 590 logo.gif. Because his editing tool is not versioning aware, he 591 cannot specify a particular version, either with a revision name or 592 by using a workspace. However, the WebDAV server provides a default 593 workspace that selects the latest revision when no label or 594 workspace is specified on a request. 596 1.2.1.13 Updating Resources by Non-versioning Aware Clients 598 Fred has provided his review to Jane and Joe, and they decide he 599 should be allowed to update the image in logo.gif. Fred then edits 600 the image in his image editing tool, and attempts to save it on the 601 DAVServer. Again, the editing tool does not specify a workspace, or 602 activity, nor can Fred check out the resource before attempting the 603 save. Joe realizes Fred must be able to change the resource, so he 604 enables automatic versioning in logo.gif. Then when Fred attempts 605 to update the resource, the server automatically checks out the 606 resource, does the put, and then checks it back in, all in the 607 context of the default workspace. 609 If someone else had the resource already checked out, then Fred's 610 save would have failed because the automatic check out would have 611 failed. 613 There are some potential problems with using non-versioning aware 614 clients this way. If Fred got a copy of the resource, and then Jane 615 checked it out, made changes, and then checked it back in, when 616 Fred does his save, Jane's changes will be lost. The changes will 617 appear in a previous revision, but they may have been in the same 618 activity, and there would be no indication that a merge needs to be 619 done in order to pick up both changes. To avoid this problem Joe 620 could change the activity in the default workspace so that all 621 changes done by non-versioning aware clients are done in a separate 622 activity. This would allow Joe to control when these changes were 623 merged back into other activities. 625 1.2.1.14 Freezing an Activity 627 Joe has decided that the imageUpdates activity should no longer be 628 used once all the changes in that activity have been merged into 629 the mainline activity. To enforce this, Joe locks the activity. 630 Then when Jane attempts to edit index.html in her imageUpdates 631 activity, the checkout fails as the activity is locked. 633 1.2.1.15 Preventing Parallel Development 635 Joe is responsible for another resource, getPreferences.shtml that 636 he wants complete control over. He does not want to allow anyone 637 else to ever make changes to this resource in any activity. To 638 enforce this, Joe indicates getPreferences.shtml does not support 639 multiple activities, and he checks it out to make sure no-one else 640 can make any changes. Then when Jane attempts to checkout 641 getPreferences.shtml in the imageUpdates activity, the checkout 642 fails indicating that resource does not support parallel 643 development. 645 1.3 Goals 647 This section defines the goals addressed by the protocol to support 648 versioning, parallel development, and configuration management. 649 These goals are derived from the desire to support the scenarios 650 above. Each goal is followed by a short description of its 651 rationale to aid in understanding the goal, and to provide 652 motivation for why it was included. 654 1. Versioning aware and non-versioning aware clients must be able to 655 inter-operate. Non-versioning aware clients will not be able to 656 perform all versioning operations, but will, at a minimum, be 657 capable of authoring resources under version control and be 658 capable of creating new revisions while implicitly maintaining 659 versioning semantics. Non-versioning aware clients are HTTP/1.1 660 and versioning unaware WebDAV clients. 662 Versioning and configuration management adds new capabilities to 663 WebDAV servers. These servers should still be responsive to non- 664 versioning aware clients in such a way that these clients retain 665 their capabilities in a manner that is consistent with the 666 versioning rules, and the capabilities those clients would have 667 had on a non-versioning server. For example, non-versioning aware 668 clients should be able to GET the contents of a versioned 669 resource without specifying a revision and get some well-defined 670 default revision. A non-versioning aware client should be able to 671 PUT to a versioned resource and have a new revision be 672 automatically created. The PUT must be done by doing an implicit 673 checkout, PUT, and checkin in order to maintain versioning 674 semantics and avoid lost updates. A subsequent GET on the same 675 versioned resource by this client should return the new revision. 676 The server should be able to be configured so that these non- 677 versioning aware client updates are placed in a different 678 activity, or perhaps disallowed. 680 2. It must be possible to version resources of any media or content 681 type. 683 The versioning semantics of the protocol must not depend on the 684 media type of the resource or versioning would have limited 685 applicability, and client applications would become more complex. 687 3. Every revision of a versioned resource must itself be a resource, 688 with its own URI. 690 See section 5.9.2.2 of [WEBDAV-GOALS]. This goal has two 691 motivations. First, to permit revisions to be referred to, so 692 that (for example) a document comparing two revisions can include 693 a link to each. Second, revisions can be treated as resources for 694 the purposes of DAV methods such as PROPFIND. 696 4. It must be possible to prevent lost updates by providing a 697 protocol that reserves a revision of a resource while it is being 698 updated and preventing other users from updating the same 699 revision at the same time in uncontrolled ways. 701 5. It must be possible to reserve the same revision more than once 702 at the same time, and to have multiple revisions of the same 703 versioned resource reserved at the same time. 705 6. It should be possible for a client to specify meaningful labels 706 to apply to individual revisions, and to change a label to refer 707 to a different revision. 709 Although the server assigns unique revision IDs, human-meaningful 710 aliases are often useful. For example, a label called 711 "CustomerX" could be assigned to the latest revision of a 712 document which has been delivered to customer X. When X calls to 713 inquire about the document, the author(s) can simply refer to the 714 label, rather than maintaining a separate database of which 715 revisions have been shipped to which customers. 717 7. It must be possible to use the same label for different versioned 718 resources. 720 This allows authors to indicate that revisions of different 721 resources are somehow related or consistent at some point in 722 time. Configurations formalize this relationship. 724 8. The labels and revision IDs within a revision history are names 725 in a common namespace, in which each name must be unique. The 726 server may partition this namespace syntactically, in order to 727 distinguish labels from IDs. The server enforces uniqueness for 728 these labels. 730 This means the same label cannot apply to multiple revisions, the 731 same revision ID cannot apply to multiple revisions, and no label 732 can also be a revision ID or vice versa. This is required so 733 that a label, when applied to a versioned resource, refers to one 734 and only one revision, and all revision names for a versioned 735 resource are unique. To enforce uniqueness, a server will have to 736 reject labels that it might eventually use as revision IDs. The 737 simplest way to do this is to partition the namespace. 739 9. Given a URI to a versioned resource, and a revision name, it must 740 be possible for a client to obtain a URI that refers to that 741 revision, and to access the revision. 743 This allows specific revisions of a resource to be accessed given 744 the URI of the versioned resource and a revision name. 746 10. Given a URI to a versioned resource, and a workspace, it must 747 be possible for a client access the revision selected by the 748 workspace. 750 When a user agent accesses a versioned resource, it is necessary 751 to provide additional information to specify which revision of 752 the versioned resource should be accessed. One way to do this is 753 to specify a revision name with the resource URL to select a 754 particular revision as specified in the previous goal. However, 755 this requires users to add and remember a label for each 756 revision, which is inconvenient and does not scale. In addition, 757 labels alone don't provide a way of accessing revisions modified 758 in an activity, or contained in a configuration. It is possible 759 to specify a number of different ways of accessing specific 760 revisions using different headers for labels, activities, 761 configurations, working revisions, etc., but this leads to a lot 762 of complexity in the protocol, and for users. Workspaces provide 763 a unified means of specifying how URLs are mapped to specific 764 revisions. A workspace contains a revision selection rule that is 765 applied when the workspace is used in conjunction with the URLs 766 for versioned resources to perform URL mapping to select a 767 specific revision. This allows specific revisions of a many, 768 related revisions to be accessed through URLs without having to 769 specify a specific label for each resource. It also provides a 770 means to resolve URLs to particular revisions using more complex 771 revision selection rules than a single label including revisions 772 modified in an activity or contained in a configuration. 774 11. Relative URLs appearing in versioned documents (e.g., HTML and 775 XML) which are being edited and/or browsed by a versioning-aware 776 client should work correctly. 778 Web resources and client applications often refer to other 779 resources with relative URLs, an incompletely specified URL that 780 is completed by pre-pending some known context that would not 781 contain a revision or workspace name. When used with versioned 782 resources, these relative URLs may be relative to a versioned 783 resource or a particular revision. In this case, the context must 784 include sufficient information for the relative URL to be 785 resolved to a specific revision. 787 12. If the DAV server supports searching, it should be possible to 788 narrow the scope of a search to the revisions of a particular 789 versioned resource. 791 It is often the case that one needs to find, for example, the 792 first revision at which a particular phrase was introduced, or 793 all the revisions authored by a particular person. Given search 794 capabilities for collections, it would be far more sensible to 795 leverage those capabilities than to define a separate search 796 protocol for revision histories. For example, if the server 797 supports [DASL], then the revision histories could be searched 798 via DASL operations. 800 13. If the DAV server supports searching, revision IDs and label 801 names should be searchable. 803 This would allow client applications to search for resources that 804 have a particular revision name. This goal does not specify that 805 any particular search mechanism is implied or needed. It only 806 indicates that labels should be available properties that a 807 search mechanism could access. 809 14. The CM protocol must be an optional extension to the base 810 versioning protocol. 812 It is expected that servers will want to support versioning 813 without supporting configuration management. This goal provides 814 the required flexibility. 816 15. It must be possible to determine what properties of a checked 817 in revision may change without creating a new revision. 818 Properties of a checked in revision that cannot change are called 819 immutable properties. 821 It is anticipated that some properties may be calculated in such 822 a way that their values may change even on a revision that is 823 checked in. Other properties may change without having any effect 824 on the resource itself e.g., review status, approved, etc. This 825 results from the fact that properties may be meta-data about a 826 resource that is actually not describing the state of the 827 resource itself. A client must be able to discover which 828 properties might change in order to maintain its state properly. 830 16. Revisions are either mutable or immutable. Once an immutable 831 revision has been checked in, its contents and immutable 832 properties can never be changed. A mutable revision can be 833 checked out, updated, and checked back in without creating a new 834 revision. It must be possible to determine if a revision is 835 mutable or immutable, but the mutability of a revision cannot be 836 changed once it has been checked in. 838 The concept of mutable revisions is included to support typical 839 document management systems that want to track version histories 840 while allowing more flexible, less formal versioning semantics. 841 Mutable revisions will have some restrictions due to the fact 842 that because the revision may change, certain configuration 843 management semantics cannot be maintained. For example, a mutable 844 revision cannot be a member of a configuration because the 845 configuration would not represent a persistent set of revisions. 847 17. Each revision may have properties whose values may be changed 848 without creating a new revision. The list of these properties 849 must be discoverable. 851 It is expected that certain live properties whose values are 852 calculated by the server may depend on information that is not 853 captured in the persistent state of an immutable revision. The 854 values of these properties may change from time to time without 855 requiring a new revision of the versioned resource. There may 856 also be some DAV properties used to support versioning and 857 configuration management that may change without requiring a new 858 revision. 860 18. Revisions and versioned resources can be deleted. Generally 861 this is a high-privilege operation. Deleting a revision must 862 update its predecessors' successors. 864 This goal is included to support generally necessary maintenance 865 operations on versioning repositories. It is sometimes the case 866 that successors of a revision beyond some point are no longer 867 required and can be removed from the repository to reclaim space. 868 It may also be the case that a versioned resource is no longer 869 used and can be safely deleted. This goal does not intend to 870 express any policy for when or under what circumstance revisions 871 can be deleted. It only provides a mechanism to support 872 particular client or server policies. 874 19. Once a revision has been deleted, its ID cannot be reused 875 within the same versioned resource. 877 In many cases, it is necessary to be able to guarantee (as far as 878 possible) that one can retrieve the exact state of a resource at 879 a particular point in history, and/or all the states which the 880 resource has ever taken on. For example, if a company is sued 881 for violating a warranty that the plaintiff read on the company's 882 Web site, it might be useful to be able to prove that the 883 warranty never contained the provision that the plaintiff says it 884 did. Conversely, it may be useful for the plaintiff to be able to 885 prove that it did. A revision history where all revisions were 886 immutable would provide this sort of ability. 888 Of course, DAV cannot preclude the possibility of an out-of-band 889 method to change or delete a revision; an implementation may 890 provide an administrative interface to do it. But such access 891 would at least be limited to trusted administrators. 893 It is possible that a versioned resource contained in a 894 configuration is deleted, and a new, unrelated versioned resource 895 is created using the same URL, and having the same revision id. 896 The configuration may incorrectly include this revision. 897 Requiring revision Ids to be UUIDs would resolve this issue. 899 20. A configuration can only contain immutable revisions. 901 This requirement is included in order to retain the usual 902 semantics of configurations, and to ensure that a configuration 903 can always be recreated. The implication is that unversioned 904 resources, working revisions, and mutable revisions cannot be 905 members of a configuration. 907 21. It must be possible to query a revision history to learn the 908 predecessors and successors of a particular revision, activity 909 names, the initial and latest revisions, etc. 911 If a client wishes to present a user interface for browsing the 912 revisions of a particular versioned resource, it must be able to 913 read the relationships represented within the version history. 915 22. It should be possible to obtain the entire revision history of 916 a versioned resource in one operation. 918 A client wishing to display a map of the revision history should 919 not have to make queries on each individual revision within the 920 revision history. It should be able to obtain all the information 921 at once, for efficiency's sake. 923 23. The protocol support for parallel development through 924 activities must be an optional capability. 926 Activities support controlled parallel development on the same 927 resource, but results in the need to merge multiple changes at 928 some later time. This introduces work and the potential for 929 errors that some servers may want to avoid by requiring updates 930 to be serialized. 932 24. The protocol must support the following operations: 934 1. Creating and accessing revisions: 936 . Create a versioned resource from an unversioned 937 resource and set its initial revision to the contents 938 of the unversioned resource. This does not imply that 939 unversioned resources are required. A server could 940 create all resources as versioned resources. 942 . Obtain the URI of, or access a revision or a versioned 943 resource given the URL for the versioned resource and 944 either a revision name, or a workspace 946 . Check out a revision in an activity and create a 947 working resource 949 . Check in a working resource and create either a new 950 revision or update the existing revision in place 951 creating a mutable revision 953 . Cancel a checkout (delete a working resource) 955 . Describe a revision with human-readable comments 957 . See if a resource is versioned 959 . Get the versioning options for a resource 961 2. Labels: 963 . Apply a label to a particular revision 965 . Change the revision to which a label refers 967 . Get all the revision names on a particular revision 969 . Get the revision history of a resource 971 3. Activities: 973 . Create and name an activity 975 . Checkout a revision in an activity 977 . Merge an activity into a workspace 979 . Generate and maintain the conflict report for a merge 981 . Get a list of the resources modified in an activity 983 . Apply a label operation to all resources modified in an 984 activity 986 4. Configurations: 988 . Create a configuration 990 . Add/remove revisions from a configuration 992 . Access a revision given a configuration name that 993 contains it by using a configuration in a version 994 selection rule for a workspace 996 . Delete a configuration. 998 . Determine the differences between two configurations by 999 listing the activities in one and not the other. 1001 Some of these operations come from [WEBDAV-GOALS], section 1002 5.9.1.2. Not all of the operations in that section are 1003 replicated here; some of them (e.g., locking) fall out naturally 1004 from the fact that a revision is a resource. 1006 The protocol must find some balance between allowing versioning 1007 servers to adopt whatever policies they wish with regard to these 1008 operations and enforcing enough uniformity to keep client 1009 implementations simple and interoperable. 1011 25. For each operation that the protocol defines, the protocol 1012 must define that operation's interaction with all existing 1013 [WebDAV] methods on all existing WebDAV resources. 1015 This goal applies to all HTTP extensions, not just versioning. 1016 However, versioning, parallel development, and configuration 1017 management are sufficiently complex and have a broad enough 1018 effect on other methods to call out this goal specifically. 1020 26. The protocol should clearly identify the policies that it 1021 dictates and the policies that are left up to versioning system 1022 implementers or administrators. A client must be able to discover 1023 what policies the server supports. 1025 Many writers have discussed the notion of versioning styles 1026 (referred to here as versioning policies, to reflect the nature 1027 of client/server interaction) as one way to think about the 1028 different policies that versioning systems implement. Versioning 1029 policies include decisions on the shape of version histories 1030 (linear or branched), the granularity of change tracking, locking 1031 requirements made by a server, naming conventions for activities 1032 and labels, etc. 1034 27. A client must be able to determine whether a resource is a 1035 versioned resource, or whether a resource is itself revision of a 1036 versioned resource. 1038 A resource may be a simple, non-versioned resource, a versioned 1039 resource, an immutable revision, a mutable revision, or a working 1040 resource. A client needs to be able to tell which sort of 1041 resource it is accessing.. 1043 28. A client must be able to access a versioned resource with a 1044 simple URL and get some well-defined default revision. 1046 The server should return a default revision of a resource for 1047 where no specific revision information is provided. This is one 1048 of the simplest ways to guarantee non-versioning client 1049 compatibility. This does not rule out the possibility of a server 1050 returning an error when no sensible default exists. 1052 It may also be desirable to be able to refer to other special 1053 revisions of a versioned resource. For example, there may be a 1054 current revision for editing that is different from the default 1055 revision. For a graph with several branches, it may be useful to 1056 be able to request the tip revision of any branch. 1058 The association of a workspace with a particular user agent for 1059 the purposes of applying version selection rules is the 1060 responsibility of the client application. The server does not 1061 necessarily maintain this association. 1063 29. It must be possible, given a reference to a revision of a 1064 versioned resource, to find out which versioned resource that 1065 revision belongs to. 1067 This makes it possible to understand the versioning context of 1068 the revision. It makes it possible to retrieve a revision history 1069 for the versioned resource to which it belongs, and to browse the 1070 revision history. It also supports some comparison operations: It 1071 makes it possible to determine whether two references designate 1072 revisions of the same versioned resource. 1074 30. Versioning functionality may be partitioned into levels. The 1075 lowest level must provide simple versioning of resources and 1076 support for labels, checkin, and checkout. Other functions should 1077 be as orthogonal as possible so that servers have additional 1078 flexibility in choosing features to implement. Functionality at 1079 lower levels must be a consistent subset of the functionality at 1080 higher levels and not introduce special cases, incompatible, or 1081 redundant functions. 1083 Servers must provide all the functions defined for a given level 1084 in order to claim and advertise conformance to that level. A 1085 server may choose to implement additional features from higher 1086 levels to support particular business and/or client requirements. 1087 The OPTIONS method indicates exactly what features are supported 1088 while the DAV header indicates the supported level clients can 1089 rely on. 1091 At a minimum, the following actions are actions are available at 1092 the basic level: 1094 . Checkout a revision and receive a way to update the working 1095 copy 1097 . Checkin a working copy to create a new revision 1099 . Cancel an active checkout 1101 . Optional for server to support multiple checkouts on the same 1102 resource 1104 . Labeling of revisions to identify them 1106 . Access to the linear checkin history of a versioned resource 1108 31. It must be possible to lock an activity so that no one can 1109 make further changes in that activity. 1111 32. It must be possible to indicate that a particular resource 1112 does not allow parallel development. That is, the resource can 1113 effectively only be checked out in one activity. 1115 33. The protocol should be defined in such a way as to minimize 1116 the adoption barriers for clients and existing repository 1117 managers. This includes integration with legacy data in 1118 repository managers supporting the WebDAV protocol. 1120 34. The server must not require client applications to retain 1121 state in order to support versioning semantics. That is, a user 1122 must be able to begin using versioning with one client, and 1123 continue using versioning on some other client at some other 1124 time. 1126 35. It must be possible to discover what resources have changed in 1127 a workspace from a given point. 1129 36. Versioned resources, revisions, and activities must have an 1130 associated URN that is globally unique. 1132 37. Servers may choose to support only mutable revisions, only 1133 immutable revisions, or both. Clients must be able to discover 1134 the support provided by the server. 1136 38. Activities should be able to be dependent (conceptually 1137 include) other activities. 1139 39. Enumeration of versioning resource types should be fast/easy. 1141 1.4 Rationale 1143 Versioning in the context of the worldwide web offers a variety of 1144 benefits: 1146 1. It provides infrastructure for efficient and controlled 1147 management of large evolving web sites. Modern configuration 1148 management systems are built on some form of repository that can 1149 track the revision history of individual resources, and provide 1150 the higher-level tools to manage those saved versions. Basic 1151 versioning capabilities are required to support such systems. 1153 2. It allows parallel development and update of single resources. 1154 Since versioning systems register change by creating new objects, 1155 they enable simultaneous write access by allowing the creation of 1156 variant versions. Many also provide merge support to ease the 1157 reverse operation. 1159 3. It provides a framework for coordinating changes to resources. 1160 While specifics vary, most systems provide some method of 1161 controlling or tracking access to enable collaborative resource 1162 development. 1164 4. It allows browsing through past and alternative versions of a 1165 resource. Frequently the modification and authorship history of a 1166 resource is critical information in itself. 1168 5. It provides stable names that can support externally stored links 1169 for annotation and link-server support. Both annotation and link 1170 servers frequently need to store stable references to portions of 1171 resources that are not under their direct control. By providing 1172 stable states of resources, version control systems allow not 1173 only stable pointers into those resources, but also well defined 1174 methods to determine the relationships of those states of a 1175 resource. 1177 6. It allows explicit semantic representation of single resources 1178 with multiple states. A versioning system directly represents the 1179 fact that a resource has an explicit history and a persistent 1180 identity across the various states it has had during the course 1181 of that history. 1183 1.5 Non-goals 1185 These non-goals enumerate functionality that the working group has 1186 explicitly agreed to exclude from this document. They are 1187 documented here for explanatory purposes. 1189 1. Revisions in multiple revision histories (see [WEBDAV-GOALS], 1190 sections 5.9.1.3 and 5.9.2.5). This capability was felt to be 1191 too rarely useful. 1193 2. Federated revision histories (that is, revision histories 1194 which are not stored on a single server). This capability 1195 would introduce great difficulties. A server implementer who 1196 needs it can use out-of-band server-to-server communication. 1197 But, this communication is arguably out of the scope of 1198 WebDAV, which is a client-to-server protocol. However, the 1199 protocol shouldn't do anything to preclude federated version 1200 histories at a later date. 1202 3. Client-proposed version identifiers (see [WEBDAV-GOALS], 1203 section 5.9.2.8). Labels do the job better. 1205 4. Change management or change control operations. It is 1206 envisioned that policies for change management and the 1207 mechanisms to implement them will be quite variable for the 1208 number and types of users authoring content for the web. 1209 Therefore it is important to provide core capabilities for 1210 versioning, parallel development, and configuration management 1211 without hindering the policies client applications may choose 1212 to present to their users. It is intended that WebDAV 1213 versioning will provide these core capabilities, and that a 1214 variety of change management policies could be implemented on 1215 these core capabilities by client applications. 1217 5. Server-to-server communication (e.g., replication) is not 1218 required. 1220 1.6 Security Considerations 1222 To be written. It is likely that implementing features to meet the 1223 goals described here will present few or no new security risks 1224 beyond those of base DAV. One possible exception is that it may 1225 become more difficult to hide the contents of a resource when there 1226 may exist other versions with different access control lists. 1228 1.7 References 1230 [WEBDAV]Y.Y. Goland, E.J. Whitehead, Jr., A. Faizi, S.R. Carter, D. 1231 Jensen, "Extensions for Distributed Authoring on the World Wide Web 1232 -- WEBDAV", Internet-Draft draft-ietf-webdav-protocol-10. Nov., 1233 1998 1234 [WEBDAV-GOALS] J. Slein, F. Vitali, J. Whitehead, D. Durand, 1235 "Requirements for a Distributed Authoring and Versioning Protocol 1236 for the World Wide Web", RFC-2291. February 1998. 1237 [WEBDAV-ACP] J. Slein, J. Davis, A. Babich, J. Whitehead, "WebDAV 1238 Advanced Collections Protocol", Internet-Draft draft-ietf-webdav- 1239 collection-protocol-02.txt. Nov., 1998. 1240 [DASL] S. Reddy, D. Jensen, S. Reddy, R. Henderson, J. Davis, A. 1241 Babich, "DAV Searching & Locating", Internet-Draft draft-reddy- 1242 dasl-protocol-04.txt. Nov., 1998. 1243 [CVS] http://www.cyclic.com/cyclic-pages/books.html 1244 [BONSAI] Mozilla.org, http://www.mozilla.org/bonsai.html 1246 1.8 Open Issues 1248 . The current write up of configurations may need to change as we 1249 define what a "configuration" is.