idnits 2.17.1 draft-ietf-webdav-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 1) being 59 lines 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 56 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 28, 1998) is 9547 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) == Unused Reference: 'ISO 10646' is defined on line 853, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AC' == Outdated reference: A later version (-01) exists of draft-alvestrand-charset-policy-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'CM' ** Obsolete normative reference: RFC 1866 (ref. 'HTML') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 10646' ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. 'VSE' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group J.A. Slein 2 INTERNET-DRAFT Xerox Corporation 3 F. Vitali 4 University of Bologna 5 E.J. Whitehead, Jr. 6 U.C. Irvine 7 D.G. Durand 8 Boston University 9 August 29, 1997 11 Expires February 28, 1998 13 Requirements for Distributed Authoring and Versioning 14 on the World Wide Web 16 Status of this Memo 18 This document is an Internet draft. Internet drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas and 20 its working groups. Note that other groups may also distribute working 21 information as Internet drafts. 23 Internet Drafts are draft documents valid for a maximum of six months 24 and can be updated, replaced or obsoleted by other documents at any 25 time. It is inappropriate to use Internet drafts as reference material 26 or to cite them as other than as "work in progress". 28 To learn the current status of any Internet draft please check the 29 "lid-abstracts.txt" listing contained in the Internet drafts shadow 30 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or 32 ftp.isi.edu (US West coast). Further information about the IETF can be 33 found at URL: http://www.ietf.org/ 35 Distribution of this document is unlimited. Please send comments to the 36 WWW Distributed Authoring and Versioning (WebDAV) mailing list, 37 , which may be joined by sending a message with 38 subject "subscribe" to . Discussions are 39 archived at URL: 40 http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/. 42 Abstract 44 Current World Wide Web (WWW or Web) standards provide simple support 45 for applications which allow remote editing of typed data. In practice, 46 the existing capabilities of the WWW have proven inadequate to support 47 efficient, scalable remote editing free of overwriting conflicts. 48 This document presents a list of features in the form of requirements 49 which, if implemented, would improve the efficiency of common remote 50 editing operations, provide a locking mechanism to prevent overwrite 51 conflicts, improve link management support between non-HTML 52 data types, provide a simple attribute-value metadata facility, provide 53 for the creation and reading of container data types, and integrate 54 versioning into the WWW. 56 1. Introduction 57 This document describes functionality which, if incorporated in an 58 extension to the existing HTTP proposed standard [HTTP], would allow tools 59 for remote loading, editing and saving (publishing) of various media 60 types on the WWW to interoperate with any compliant Web server. As much 61 as possible, this functionality is described without suggesting a 62 proposed implementation, since there are many ways to perform the 63 functionality within the WWW framework. It is also possible that a 64 single mechanism could simultaneously satisfy several requirements. 66 This document is intended to reflect the consensus of the WWW 67 Distributed Authoring and Versioning working group (WebDAV) as to the 68 functionality that needs to be standardized to support distributed 69 authoring and versioning on the Web. 71 2. Rationale 73 Current Web standards contain functionality which enables the editing of 74 Web content at a remote location, without direct access to the storage 75 media via an operating system. This capability is exploited by several 76 existing HTML distributed authoring tools, and by a growing number of 77 mainstream applications (e.g., word processors) which allow users to 78 write (publish) their work to an HTTP server. To date, experience from 79 the HTML authoring tools has shown they are unable to meet their users' 80 needs using the facilities of Web standards. The consequence of 81 this is either postponed introduction of distributed authoring 82 capability, or the addition of nonstandard extensions to the HTTP 83 protocol or other Web standards. These extensions, developed in 84 isolation, are not interoperable. 86 Other authoring applications have wanted to access document repositories 87 or version control systems through Web gateways, and have been similarly 88 frustrated. Where this access is available at all, it is through 89 nonstandard extensions to HTTP or other standards that force clients to 90 use a different interface for each vendor's service. 92 This document describes requirements for a set of standard extensions 93 to HTTP that would allow distributed Web authoring tools to provide 94 the functionality their users need by means of the same standard 95 syntax across all compliant servers. The broad categories of 96 functionality that need to be standardized are: 98 Properties 99 Links 100 Locking 101 Reservations 102 Retrieval of Unprocessed Source 103 Partial Write 104 Name Space Manipulation 105 Collections 106 Versioning 107 Variants 108 Security 109 Internationalization 110 3. Terminology 112 Where there is overlap, usage is intended to be consistent with that in 113 the HTTP 1.1 specification [HTTP]. 115 Client 116 A program which issues HTTP requests and accepts responses. 118 Collection 119 A collection is a resource that contains other resources, 120 either directly or by reference. 122 Distributed Authoring Tool 123 A program which can retrieve a source entity via HTTP, allow 124 editing of this entity, and then save/publish this entity 125 to a server using HTTP. 127 Entity 128 The information transferred in a request or response. 130 Hierarchical Collection 131 A hierarchical organization of resources. A hierarchical 132 collection is a resource that contains other resources, 133 including collections, either directly or by reference. 135 Link 136 A typed connection between two or more resources. 138 Lock 139 A mechanism for preventing anyone other than the owner of the 140 lock from accessing a resource. 142 Member of Version Graph 143 A resource that is a node in a version graph, and so is derived 144 from the resources that precede it in the graph, and is the 145 basis of those that succeed it. 147 Property 148 Named descriptive information about a resource. 150 Reservation 151 A declaration that one intends to edit a resource. 153 Resource 154 A network data object or service that can be identified by 155 a URI. 157 Server 158 A program which receives and responds to HTTP requests. 160 User Agent 161 The client that initiates a request. 163 Variant 164 A representation of a resource. A resource may have one or more 165 representations associated with it at any given time. 167 Version Graph 168 A directed acyclic graph with resources as its nodes, where 169 each node is derived from its predecessor(s). 171 Write Lock 172 A lock that prevents anyone except its owner from modifying 173 the resource it applies to. 175 4. General Principles 177 This section describes a set of general principles that the WebDAV 178 extensions should follow. These principles cut across categories of 179 functionality. 181 4.1. User Agent Interoperability 183 All WebDAV clients should be able to work with any WebDAV-compliant HTTP 184 server. It is acceptable for some client/server combinations to provide 185 special features that are not universally available, but the protocol 186 should be sufficient that a basic level of functionality will be 187 universal. 189 4.2. Client Simplicity 191 The WebDAV extensions should be designed to allow client implementations 192 to be simple. 194 4.3. Legacy Client Support 196 It should be possible to implement a WebDAV-compliant server in such a 197 way that it can interoperate with non-WebDAV clients. Such a server 198 would be able to understand any valid HTTP 1.1 request from an ordinary 199 Web client without WebDAV extensions, and to provide a valid HTTP 1.1 200 response that does not require the client to understand the extensions. 202 4.4. Data Format Compatibility 204 WebDAV-compliant servers should be able to work with existing resources 205 and URIs [URL]. Special additional information should not become a 206 mandatory part of document formats. 208 4.5. Replicated, Distributed Systems 210 Distribution and replication are at the heart of the Internet. All 211 WebDAV extensions should be designed to allow for distribution and 212 replication. Version trees should be able to be split across multiple 213 servers. Collections may have members on different servers. Resources 214 may have properties on different servers. Any resources may be cached 215 or replicated for mobile computing or other reasons. Consequently, the 216 WebDAV extensions must be able to operate in a distributed, replicated 217 environment. 219 4.6 Parsimony in Client-Server Interactions 221 The WebDAV extensions should keep to a minimum the number of 222 interactions between the client and the server needed to perform common 223 functions. For example, publishing a document to the Web will often mean 224 publishing content together with related properties. A client may often 225 need to find out what version graph a particular resource belongs to, 226 or to find out which resource in a version graph is the published one. 227 The extensions should make it possible to do these things efficiently. 229 4.7. Changes to HTTP 231 WebDAV adds a number of new types of objects to the Web: properties, 232 collections, version graphs, etc. Existing HTTP methods such as 233 DELETE and PUT will have to operate in well-defined ways in this 234 expanded environment. WebDAV should explicitly address not only new 235 methods, headers, and MIME types, but also any required changes to the 236 existing HTTP methods and headers. 238 4.8. Alternate Transport Mechanisms 240 It may be desirable to transport WebDAV requests and responses by other 241 mechanisms, particularly EMail, in addition to HTTP. The WebDAV protocol 242 specification should not preclude a future body from developing an 243 interoperability specification for disconnected operation via EMail. 245 5. Requirements 247 In the requirement descriptions below, the requirement will be stated, 248 followed by its rationale. 250 5.1. Properties 252 5.1.1. Functional Requirements 254 It must be possible to create, modify, read and delete arbitrary 255 properties on resources of any media type. 257 5.1.2. Rationale 259 Properties describe resources of any media type. They may 260 include bibliographic information such as author, title, publisher, 261 and subject, constraints on usage, PICS ratings, etc. These 262 properties have many uses, such as supporting searches on property 263 values, enforcing copyrights, and the creation of catalog entries as 264 placeholders for objects which are not available in electronic form, or 265 which will be available later. 267 5.2. Links 269 5.2.1. Functional Requirements 271 It must be possible to create, modify, read and delete typed 272 links between resources of any media type. 274 5.2.2. Rationale 276 One type of link between resources is the hypertext link, which is 277 browsable using a hypertext style point-and-click user interface. Links, 278 whether they are browsable hypertext links, or simply a means of 279 capturing a connection between resources, have many purposes. Links 280 can support pushbutton printing of a multi-resource document in a 281 prescribed order, jumping to the access control page for a resource, 282 and quick browsing of related information, such as a table of contents, 283 an index, a glossary, a bibliographic record, help pages, etc. While 284 link support is provided by the HTML "LINK" element, this is limited 285 only to HTML resources [HTML]. Similar support is needed for bitmap image 286 types, and other non-HTML media types. 288 5.3. Locking 290 5.3.1. General Principles 292 5.3.1.1. Independence of locks. It must be possible to lock a resource 293 without re-reading the resource, and without committing to editing the 294 resource. 296 5.3.1.2. Multi-Resource Locking. It must be possible to take out a 297 lock on multiple resources residing on the same server in a single action, 298 and this locking operation must be atomic across these resources. 300 5.3.2. Functional Requirements 302 5.3.2.1. Write Locks. It must be possible to restrict modification of 303 a resource to a specific person. 305 5.3.2.2. Lock Query. It must be possible to find out whether a given 306 resource has any active locks, and if so, who holds those locks. 308 5.3.2.3. Unlock. It must be possible to remove a lock. 310 5.3.3. Rationale 312 At present, the Web provides limited support for preventing two or more 313 people from overwriting each other's modifications when they save to a 314 given URI. Furthermore, there is no way to discover whether someone else 315 is currently making modifications to a resource. This is known as the 316 "lost update problem," or the "overwrite problem." Since there can be 317 significant cost associated with discovering and repairing lost 318 modifications, preventing this problem is crucial for supporting 319 distributed authoring. A write lock ensures that only one person may 320 modify a resource, preventing overwrites. Furthermore, locking support 321 is a key component of many versioning schemes, a desirable capability 322 for distributed authoring. 324 An author may wish to lock an entire web of resources even though he 325 is editing just a single resource, to keep the other resources from 326 changing. In this way, an author can ensure that if a local hypertext 327 web is consistent in his distributed authoring tool, it will then be 328 consistent when he writes it to the server. Because of this, it should 329 be possible to take out a lock without also causing transmission of the 330 contents of a resource. 332 It is often necessary to guarantee that a lock or unlock operation 333 occurs at the same time across multiple resources, a feature which is 334 supported by the multiple-resource locking requirement. This is useful 335 for preventing a collision between two people trying to establish locks 336 on the same set of resources, since with multi-resource locking, one of 337 the two people will get a lock. If this same multiple-resource locking 338 scenario was repeated by using atomic lock operations iterated across 339 the resources, the result would be a splitting of the locks between the 340 two people, based on resource ordering and race conditions. 342 5.4. Reservations 344 5.4.1. Functional Requirements 346 5.4.1.1. Reserve. It must be possible for a principal to register with 347 the server an intent to edit a given resource, so that other principals 348 can discover who intends to edit the resource. 350 5.4.1.2. Reservation Query. It must be possible to find out whether 351 a given resource has any active reservations, and if so, who currently 352 holds reservations. 354 5.4.1.3. Release Reservation. It must be possible to release the 355 reservation. 357 5.4.2. Rationale 359 Experience from configuration management systems has shown that people 360 need to know when they are about to enter a parallel editing situation. 361 Once notified, they either decide not to edit in parallel with the 362 other authors, or they use out-of-band communication (face-to-face, 363 telephone, etc.) to coordinate their editing to minimize the difficulty 364 of merging their results. Reservations are separate from locking, since 365 a write lock does not necessarily imply a resource will be edited, and 366 a reservation does not carry with it any access restrictions. This 367 capability supports versioning, since a check-out typically involves 368 taking out a write lock, making a reservation, and getting the resource 369 to be edited. 371 5.5. Retrieval of Unprocessed Source for Editing 373 5.5.1. Functional Requirement 375 The source of any given resource must be retrievable. 377 5.5.2. Rationale 379 There are many cases where the source stored on a server does 380 not correspond to the actual entity transmitted in response to an HTTP 381 GET. Current known cases are server side include directives, and 382 Standard Generalized Markup Language (SGML) source which is 383 converted on the fly to HyperText Markup Language (HTML) [HTML] output 384 entities. There are many possible cases, such as automatic conversion 385 of bitmap images into several variant bitmap media types (e.g. GIF, 386 JPEG), and automatic conversion of an application's native media type 387 into HTML. As an example of this last case, a word processor could 388 store its native media type on a server which automatically converts 389 it to HTML. A GET of this resource would retrieve the HTML. Retrieving 390 the source would retrieve the word processor native format. 392 5.6. Partial Write. 394 5.6.1. Functional Requirement 396 After editing a resource, it must be possible to write only the changes 397 to the resource, rather than retransmitting the entire resource. 399 5.6.2. Rationale 401 During distributed editing which occurs over wide geographic separations 402 and/or over low bandwidth connections, it is extremely inefficient 403 and frustrating to rewrite a large resource after minor changes, such 404 as a one-character spelling correction. Support is needed for 405 transmitting "insert" (e.g., add this sentence in the middle of a 406 document) and "delete" (e.g. remove this paragraph from the middle of 407 a document) style updates. Support for partial resource updates will 408 make small edits more efficient, and allow distributed authoring tools 409 to scale up for editing large documents. 411 5.7. Name Space Manipulation 413 5.7.1. Copy 415 5.7.1.1. Functional Requirements 417 It must be possible to duplicate a resource without a client loading, 418 then resaving the resource. After the copy operation, the content of 419 the destination resource must be octet for octet identical to the 420 content of the source resource. A modification to either resource must 421 not cause a modification to the other. 423 5.7.1.2. Rationale 425 There are many reasons why a resource might need to be duplicated, such 426 as changing ownership, preparing for major modifications, or making 427 a backup. Due to network costs associated with loading and saving a 428 resource, it is far preferable to have a server perform a resource copy 429 than a client. If a copied resource records which resource it is a copy 430 of, then it would be possible for a cache to avoid loading the copied 431 resource if it already locally stores the original. 433 5.7.2. Move/Rename 435 5.7.2.1. Functional Requirements 437 It must be possible to change the location of a resource without 438 a client loading, then resaving the resource under a different name. 440 After the move operation, the content of the resource at its new 441 location must be octet for octet identical to the content of the prior 442 resource. It must no longer be possible to access the resource at its 443 original location. 445 5.7.2.2. Rationale 447 It is often necessary to change the name of a resource, for example due 448 to adoption of a new naming convention, or if a typing error was made 449 entering the name originally. Due to network costs, it is undesirable 450 to perform this operation by loading, then resaving the resource, 451 followed by a delete of the old resource. Similarly, a single rename 452 operation is more efficient than a copy followed by a delete operation. 453 Note that moving a resource is considered the same function as renaming 454 a resource. 456 5.8. Collections 458 A collection is a resource that is a container for other resources, 459 including other collections. A resource may belong to a collection 460 either directly or by reference. If a resource belongs to a 461 collection directly, name space operations like copy, move, and 462 delete applied to the collection also apply to the resource. If a 463 resource belongs to a collection by reference, name space operations 464 applied to the collection affect only the reference, not the resource 465 itself. 467 5.8.1. Functional Requirements 469 5.8.1.1. List Collection. A listing of all resources in a specific 470 collection must be accessible. 472 5.8.1.2. Make Collection. It must be possible to create a new 473 collection. 475 5.8.1.3. Add to Collection. It must be possible to add a resource to a 476 collection directly or by reference. 478 5.8.1.4. Remove from Collection. It must be possible to remove a 479 resource from a collection. 481 5.8.2. Rationale 483 In [URL] it states that, "some URL schemes (such as the ftp, http, and 484 file schemes) contain names that can be considered hierarchical." 485 Especially for HTTP servers which directly map all or part of their URL 486 name space into a filesystem, it is very useful to get a listing of all 487 resources located at a particular hierarchy level. This functionality 488 supports "Save As..." dialog boxes, which provide a listing of the 489 entities at a current hierarchy level, and allow navigation through 490 the hierarchy. It also supports the creation of graphical visualizations 491 (typically as a network) of the hypertext structure among the entities 492 at a hierarchy level, or set of levels. It also supports a tree 493 visualization of the entities and their hierarchy levels. 495 In addition, document management systems may want to make their 496 documents accessible through the Web. They typically allow the 497 organization of documents into collections, and so also want their users 498 to be able to view the collection hierarchy through the Web. 500 There are many instances where there is not a strong correlation between 501 a URL hierarchy level and the notion of a collection. One example is a 502 server in which the URL hierarchy level maps to a computational process 503 which performs some resolution on the name. In this case, the contents 504 of the URL hierarchy level can vary depending on the input to the 505 computation, and the number of resources accessible via the computation 506 can be very large. It does not make sense to implement a directory 507 feature for such a name space. However, the utility of listing the 508 contents of those URL hierarchy levels which do correspond to 509 collections, such as the large number of HTTP servers which map their 510 name space to a filesystem, argue for the inclusion of this capability, 511 despite not being meaningful in all cases. If listing the contents of 512 a URL hierarchy level does not makes sense for a particular URL, then 513 a "405 Method Not Allowed" status code could be issued. 515 The ability to create collections to hold related resources supports 516 management of a name space by packaging its members into small, related 517 clusters. The utility of this capability is demonstrated by the broad 518 implementation of directories in recent operating systems. The ability 519 to create a collection also supports the creation of "Save As..." 520 dialog boxes with "New Level/Folder/Directory" capability, common in 521 many applications. 523 5.9. Versioning 525 5.9.1. Background and General Principles 527 5.9.1.1. Stability of versions. Most versioning systems are intended to 528 provide an accurate record of the history of evolution of a document. 529 This accuracy is ensured by the fact that a version eventually becomes 530 "frozen" and immutable. Once a version is frozen, further changes will 531 create new versions rather than modifying the original. In order for 532 caching and persistent references to be properly maintained, a client 533 must be able to determine that a version has been frozen. Any successful 534 attempt to retrieve a frozen version of a resource will always retrieve 535 exactly the same content, or return an error if that version (or the 536 resource itself) is no longer available. 538 5.9.1.2. Operations for Creating New Versions 540 Version management systems vary greatly in the operations they require, 541 the order of the operations, and how they are combined into atomic 542 functions. In the most complete cases, the logical operations involved 543 are: 544 o Reserve existing version 545 o Lock existing version 546 o Retrieve existing version 547 o Request or suggest identifier for new version 548 o Write new version 549 o Release lock 550 o Release reservation 551 With the exception of requesting a new version identifier, all of these 552 operations have applications outside of versioning and are either 553 already part of HTTP or are discussed in earlier sections of these 554 requirements. Typically, versioning systems combine reservation, 555 locking, and retrieval -- or some subset of these -- into an atomic 556 checkout function. They combine writing, releasing the lock, and 557 releasing the reservation -- or some subset of these -- into an atomic 558 checkin function. The new version identifier may be assigned either at 559 checkout or at checkin. 561 The WebDAV extensions must find some balance between allowing versioning 562 servers to adopt whatever policies they wish with regard to these 563 operations and enforcing enough uniformity to keep client 564 implementations simple. 566 5.9.1.3. The Versioning Model 568 Each version typically stands in a "derived from" relationship to its 569 predecessor(s). It is possible to derive several different versions 570 from a single version (branching), and to derive a single version from 571 several versions (merging). Consequently, the collection of related 572 versions forms a directed acyclic graph. In the following discussion, 573 this graph will be called a "version graph". Each node of this graph 574 is a "version" or "member of the version graph". The arcs of the graph 575 capture the "derived from" relationships. 577 It is also possible for a single resource to participate in multiple 578 version graphs. 580 The WebDAV extensions should support this versioning model, though 581 particular servers may restrict it in various ways. 583 5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and 584 Haake and Hicks [VSE], have discussed the notion of versioning styles 585 (referred to here as versioning policies, to reflect the nature of 586 client/server interaction) as one way to think about the different 587 policies that versioning systems implement. Versioning policies include 588 decisions on the shape of version histories (linear or branched), the 589 granularity of change tracking, locking requirements made by a server, 590 etc. The protocol should clearly identify the policies that it dictates 591 and the policies that are left up to versioning system implementors or 592 administrators. 594 5.9.1.5. It is possible to version resources of any media type. 596 5.9.2. Functional Requirements 598 5.9.2.1. Referring to a version graph. There must be a way to refer to 599 a version graph as a whole. 601 Some queries and operations apply, not to any one member of a 602 version graph, but to the version graph as a whole. For example, a 603 client may request that an entire graph be moved, or may ask for a 604 version history. In these cases, a way to refer to the whole version 605 graph is required. 607 5.9.2.2. Referring to a specific member of a version graph. There must 608 be a way to refer to each member of a version graph. This means that 609 each member of the graph is itself a resource. 611 Each member of a version graph must be a resource if it is to be 612 possible for a hypertext link to refer to specific version of a page, 613 or for a client to request a specific version of a document for editing. 615 5.9.2.3. A client must be able to determine whether a resource is a 616 version graph, or whether a resource is itself a member of a version 617 graph. 619 A resource may be a simple, non-versioned resource, or it may be a 620 version graph, or it may be a member of a version graph. A client needs 621 to be able to tell which sort of resource it is accessing. 623 5.9.2.4. There must be a way to refer to a server-defined default 624 member of a version graph. 626 The server should return a default version of a resource for requests 627 that ask for the default version, as well as for requests where no 628 specific version information is provided. This is one of the simplest 629 ways to guarantee non-versioning client compatibility. This does not 630 rule out the possibility of a server returning an error when no sensible 631 default exists. 633 It may also be desirable to be able to refer to other special members 634 of a version graph. For example, there may be a current version for 635 editing that is different from the default version. For a graph with 636 several branches, it may be useful to be able to request the tip version 637 of any branch. 639 5.9.2.5. It must be possible, given a reference to a member of a version 640 graph, to find out which version graph(s) that resource belongs to. 642 This makes it possible to understand the versioning context of the 643 resource. It makes it possible to retrieve a version history for the 644 graphs to which it belongs, and to browse the version graph. It also 645 supports some comparison operations: It makes it possible to determine 646 whether two references designate members of the same version graph. 648 5.9.2.6. Navigation of a version graph. Given a reference to a member 649 of a version graph, it must be possible to discover and access the 650 following related members of the version graph. 651 o root member of the graph 652 o predecessor member(s) 653 o successor member(s) 654 o default member of the graph 656 It must be possible in some way for a versioning client to access 657 versions related to a resource currently being examined. 659 5.9.2.7. Version Topology. There must be a way to retrieve the complete 660 version topology for a version graph, including information about all 661 members of the version graph. The format for this information must be 662 standardized so that the basic information can be used by all clients. 663 Other specialized formats should be accommodated, for servers and 664 clients that require information that cannot be included in the 665 standard topology. 667 5.9.2.8. A client must be able to propose a version identifier to be 668 used for a new member of a version graph. The server may refuse to use 669 the client's suggested version identifier. The server should tell the 670 client what version identifier it has assigned to the new member of the 671 version graph. 673 5.9.2.9. A version identifier must be unique across a version graph. 675 5.9.2.10. A client must be able to supply version-specific properties to 676 be associated with a new member of a version graph. (See Section 5.1 677 "Properties" above.) At a minimum, it must be possible to associate 678 comments with the new member, explaining what changes were made. 680 5.9.2.11. A client must be able to query the server for information 681 about a version tree, including which versions are locked, which are 682 reserved for editing, and by whom (Session Tracking). 684 5.9.3. Rationale 686 Versioning in the context of the world-wide web offers a variety of 687 benefits: 689 It provides infrastructure for efficient and controlled management of 690 large evolving web sites. Modern configuration management systems are 691 built on some form of repository that can track the revision history of 692 individual resources, and provide the higher-level tools to manage 693 those saved versions. Basic versioning capabilities are required to 694 support such systems. 696 It allows parallel development and update of single resources. Since 697 versioning systems register change by creating new objects, they 698 enable simultaneous write access by allowing the creation of variant 699 versions. Many also provide merge support to ease the reverse operation. 701 It provides a framework for coordinating changes to resources. While 702 specifics vary, most systems provide some method of controlling or 703 tracking access to enable collaborative resource development. 705 It allows browsing through past and alternative versions of a resource. 706 Frequently the modification and authorship history of a resource is 707 critical information in itself. 709 It provides stable names that can support externally stored links for 710 annotation and link-server support. Both annotation and link servers 711 frequently need to store stable references to portions of resources 712 that are not under their direct control. By providing stable states of 713 resources, version control systems allow not only stable pointers into 714 those resources, but also well-defined methods to determine the 715 relationships of those states of a resource. 717 It allows explicit semantic representation of single resources with 718 multiple states. A versioning system directly represents the fact that 719 a resource has an explicit history, and a persistent identity across 720 the various states it has had during the course of that history. 722 5.10. Variants 724 5.10.1. Functional Requirements 726 It must be possible to send variants to the server, describing the 727 relationships between the variants and their parent resource. In 728 addition, it must be possible to write and retrieve variants of 729 property labels, property descriptions, and property values. 731 5.10.2. Rationale 733 The HTTP working group is addressing problems of content negotiation 734 and retrieval of variants of a resource. To extend this work to an 735 authoring environment, WEBDAV must standardize mechanisms for authors 736 to use when submitting variants to a server. Authors need to be able 737 to provide variants in different file or document formats, for different 738 uses. They need to provide variants optimized for different for different 739 clients and for different output devices. They need to be able to provide 740 variants in different languages in the international environment of the Web. 741 In support of internationalization requirements (See 5.12 below), variants 742 need to be supported not just for the content of resources, but for any 743 information intended for human use, such as property values, labels, and 744 descriptions. 746 5.11. Security 748 5.11.1. Authentication. The WebDAV specification should state how the 749 WebDAV extensions interoperate with existing authentication schemes, 750 and should make recommendations for using those schemes. 752 5.11.2. Access Control. Access control requirements are specified 753 in a separate access control draft [AC]. 755 5.11.3. Interoperability with Security Protocols. The WebDAV 756 specification should provide a minimal list of security protocols 757 which any compliant server / client should support. These protocols 758 should insure the authenticity of messages and the privacy and 759 integrity of messages in transit. 761 5.12. Internationalization 763 5.12.1. Character Sets and Languages 765 Since Web distributed authoring occurs in a multi-lingual 766 environment, information intended for user comprehension must 767 conform to the IETF Character Set Policy [CHAR]. This policy 768 addresses character sets and encodings, and language tagging. 770 5.12.2. Rationale 772 In the international environment of the Internet, it is important 773 to insure that any information intended for user comprehension can be 774 displayed in a writing system and language agreeable to both the 775 client and the server. The information encompassed by this requirement 776 includes not only the content of resources, but also such things as 777 display names and descriptions of properties, property values, and 778 status messages. 780 6. Acknowledgements 782 Our understanding of these issues has emerged as the result of much 783 thoughtful discussion, email, and assistance by many people, who 784 deserve recognition for their effort. 786 Terry Allen, tallen@sonic.net 787 Alan Babich, FileNet, babich@filenet.com 788 Dylan Barrell, Open Text, dbarrell@opentext.ch 789 Barbara Bazemore, PC DOCS, barbarab@pcdocs.com 790 Martin Cagan, Continuus Software, Marty_Cagan@continuus.com 791 Steve Carter, Novell, srcarter@novell.com 792 Dan Connolly, World Wide Web Consortium, connolly@w3.org 793 Jim Cunningham, Netscape, jfc@netscape.com 794 Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov 795 Mark Day, Lotus, Mark_Day@lotus.com 796 Martin J. Duerst, mduerst@ifi.unizh.ch 797 Asad Faizi, Netscape, asad@netscape.com 798 Ron Fein, Microsoft, ronfe@microsoft.com 799 David Fiander, Mortice Kern Systems, davidf@mks.com 800 Roy Fielding, U.C. Irvine, fielding@ics.uci.edu 801 Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com 802 Yaron Y. Goland, Microsoft, yarong@microsoft.com 803 Phill Hallam-Baker, MIT, hallam@ai.mit.edu 804 Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com 805 Andre van der Hoek, University of Colorado, Boulder, 806 andre@cs.colorado.edu 807 Del Jensen, Novell, dcjensen@novell.com 808 Gail Kaiser, Columbia University, kaiser@cs.columbia.edu 809 Rohit Khare, World Wide Web Consortium, khare@w3.org 810 Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com 811 Ben Laurie, A.L. Digital, ben@algroup.co.uk 812 Mike Little, Bellcore, little@bellcore.com 813 Dave Long, America Online, dave@sb.aol.com 814 Larry Masinter, Xerox PARC, masinter@parc.xerox.com 815 Murray Maloney, SoftQuad, murray@sq.com 816 Jim Miller, World Wide Web Consortium, jmiller@w3.org 817 Howard S. Modell, Boeing, howard.s.modell@boeing.com 818 Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu 819 Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org 820 Jon Radoff, NovaLink, jradoff@novalink.com 821 Alan Robertson, alanr@bell-labs.com 822 Henry Sanders, Microsoft, 823 Andrew Schulert, Microsoft, andyschu@microsoft.com 824 Christopher Seiwald, Perforce Software, seiwald@perforce.com 825 Einar Stefferud, stef@nma.com 826 Richard Taylor, U.C. Irvine, taylor@ics.uci.edu 827 Robert Thau, MIT, rst@ai.mit.edu 828 Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com 829 Dan Whelan, FileNet, dan@FILENET.COM 830 Gregory J. Woodhouse, gjw@wnetc.com 832 7. References 834 [AC] J. Radoff, "Requirements for Access Control within 835 Distributed Authoring and Versioning Environments on the World 836 Wide Web". 838 [CHAR] H.T. Alvestrand, "IETF Policy on Character Sets and Languages", 839 June 1997, working draft, draft-alvestrand-charset-policy-00.txt. 841 [CM] P. Feiler, "Configuration Management Models in Commercial 842 Environments", Software Engineering Institute Technical Report 843 CMU/SEI-91-TR-7, 844 846 [HTML] T. Berners-Lee, D. Connolly, "HyperText Markup Language 847 Specification - 2.0", RFC 1866, MIT/LCS, November 1995. 849 [HTTP] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 850 T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, 851 U.C. Irvine, DEC, MIT/LCS, January 1997. 853 [ISO 10646] ISO/IEC 10646-1:1993. "International Standard -- 854 Information Technology -- Universal Multiple-Octet Coded Character 855 Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane." 857 [URL] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource 858 Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, 859 December 1994. 861 [VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", 862 Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996, 863 pages 224-234. 865 8. Authors' Addresses 867 Judith Slein 868 Xerox Corporation 869 800 Phillips Road 128-29E 870 Webster, NY 14580 872 EMail: slein@wrc.xerox.com 874 Fabio Vitali 875 Department of Computer Science 876 University of Bologna 877 ITALY 879 EMail: fabio@cs.unibo.it 880 E. James Whitehead, Jr. 881 Department of Information and Computer Science 882 University of California 883 Irvine, CA 92697-3425 885 Fax: 714-824-4056 886 EMail: ejw@ics.uci.edu 888 David G. Durand 889 Department of Computer Science 890 Boston University 891 Boston, MA 893 EMail: dgd@cs.bu.edu 895 Expires February 28, 1998