idnits 2.17.1 draft-ietf-webdav-scenarios-00.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 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 1 longer page, the longest (page 1) being 942 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. 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 (May 1997) is 9836 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: '4' is defined on line 909, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-02) exists of draft-ietf-webdav-requirements-00 ** Downref: Normative reference to an Informational draft: draft-ietf-webdav-requirements (ref. '4') Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group Ora Lassila 3 INTERNET-DRAFT Nokia Research Center 4 May 1997 6 Expires November, 1997 8 HTTP-based Distributed Content Editing Scenarios 10 Status of this Document 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 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 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. Please send any comments 29 or questions regarding this document to Ora Lassila, Nokia Research 30 Center (ora.lassila@research.nokia.com). The subject matter of this 31 document is discussed on the WWW Distributed Authoring and Versioning 32 mailing list, w3c-dist-auth@w3.org, which may be joined by sending a 33 message with subject "subscribe" to w3c-dist-auth-request@w3.org. 35 Abstract 37 This document contains examples of distributed editing conducted 38 through HTTP. These scenarios have been developed by the Distributed 39 Authoring and Versioning Group in the course of specifying 40 requirements for distributed editing, and aim to demonstrate the 41 concepts of distributed editing. The document presents a logical 42 hierarchy of scenarios, separating actual editing actions from 43 document management. 45 1. Introduction 47 The purpose of this document is to catalog scenarios of distributed 48 editing and authoring as well as versioning, as related to the work of 49 the Distributed Authoring and Versioning group, and particularly to 50 the Interned Draft document "Requirements on HTTP for Distributed 51 Content Editing" [1]. These scenarios can serve as examples of 52 distributed authoring and versioning HTTP extensions' usage, and can 53 be used as basis for discussion of various requirements and protocol 54 features. 56 The scenarios in this document have been divided into sections 57 addressing different aspects of the distributed authoring area: the 58 first section focuses on the manipulation of the contents of resources 59 (documents), the second section focuses on the management of the 60 documents themselves and their relationships to other documents and 61 the URL space. A third section has also been included for scenarios 62 not clearly belonging to either of the first two sections. 64 The individuals "Jane" and "Joe", used in the scenarios, can in most 65 scenarios (if not all of them) be understood as either real people or 66 as some types of software agents. 68 2. Distributed Editing 70 This section contains scenarios where contents of resources are 71 changed through the use of HTTP (as opposed to through local file 72 system operations). 74 2.1. Opening and Closing Documents 76 Scenarios in this section illustrate opening and closing of documents 77 and retrieving their contents for editing. They are related to (and 78 partially overlap) scenarios in section 2.2. 80 2.1.1. Opening Documents 82 Scenario A: Jane requests that document D be opened. D is available 83 in English, Finnish and Swedish, each using different word processors 84 and each with different revision histories. 86 Scenario B: Jane requests that document D be opened. D contains links 87 to headers, footers and graphical material. Variation 1: Jane's 88 client side environment is a browser. Variation 2: Jane's client side 89 environment is an editor. 91 Notes: 93 1. In both scenarios it is important that source entities have 94 meta-data identifying both the native (or "source") format (MS 95 Word, Corel WP, etc.) and format revision. 97 2. Scenario B also illustrates the possible desirability of 98 server-side support for conversion of document source to a normal 99 (canonical) form (such as HTML/MIME) for viewer/browser support. 100 A typical DMS might, upon receipt of the OPEN request, retrieve 101 the document meta-data and content from the store and create a 102 temporary file containing the document content in its native 103 format (such as Microsoft Word) on the system(s) hosting the 104 store. The DMS would then respond (via the server) with status, 105 the URL of the temporary file and the document meta-data 106 (establishing context for the document object). The client-side 107 process might then issue a GET request for either the source 108 document (for editing), or the normal form document (for 109 viewing). Though one might expect that editing source implies 110 GETting source, one must not rule out the possibility of editing 111 the (temporary) source file in-situ (server side); editing server 112 side in-situ is one plausible approach to collaborative editing. 113 While the Extension may not initially support collaborative 114 editing of a single document, the Extension architecture should 115 neither proscribe such functionality nor should it favor the 116 adoption of any one particular implementation architecture. 118 2.1.2. Checking Documents In and Out 120 Scenario A: Jane "checks out" a document D with an "intent to edit" 121 (i.e., a high probability that Jane will delete, add-to or change 122 document content or document meta-data). Variation 1: Jane wants 123 exclusive editing rights ("write lock") to D. Jane has no objection 124 to letting others view as it is edited. Variation 2: Jane wants 125 exclusive editing rights to D and objects to others viewing D as it is 126 edited ("read/write lock"). Variation 3: Jane wants to edit a local 127 copy of D with the intent to merge and resolve conflicts later at 128 "check in". Note that this case accommodates editing "off-line" 129 (disconnected mode). Variation 4: Jane is willing to engage in 130 "free-for-all" editing, but wishes to make it known to other potential 131 editors that she is entering/leaving the melee. 133 2.2. Editing Documents 135 Scenarios in this section are related to retrieving the contents of a 136 document in various formats for editing. The are related to (and 137 partially overlap) scenarios in the previous section. 139 2.2.1. Editing HTML 141 Scenario A: Jane, the maintainer of a web page, needs to update its 142 HTML source. There are no other variants to this page, such as 143 translations into other languages. She is working with a distributed 144 authoring tool, DistEdit. She loads the HTML source into DistEdit via 145 HTTP. She then performs some edits to the HTML source. The HTML 146 source is then written back to its original URL using HTTP. The 147 distributed editing session is ended. 149 Relevant requirements (see [1]) and/or protocol features: Source 150 Retrieval, HTTP PUT, Partial Write. 152 2.2.2. Editing a Particular Language Version of an HTML Resource 154 Scenario A: Jane, who is fluent in Finnish, needs to update the HTML 155 source of the Finnish language variant of a web page which has 156 English, Finnish, and Swedish language variants. She is working with 157 a distributed authoring tool, DistEdit. She loads the Finnish 158 language HTML source into DistEdit using HTTP, and makes some 159 corrections and modifications. She then writes the HTML source back 160 to the original URL using HTTP. The distributed editing session is 161 ended. 163 Relevant requirements and/or protocol features: Source Retrieval, HTTP 164 PUT, Partial Write. 166 2.2.3. Editing HTML with Server Side Includes 168 Scenario A: Jane needs to update the HTML source of a web page. The 169 HTML source includes a server side include (SSI) directive which 170 instructs the HTTP server to insert the current date into the 171 document, and is written in English. There are no other variants to 172 this page, such as translations into other languages. Jane is working 173 with a distributed authoring tool, DistEdit. She loads the HTML 174 source (including the source of the server side include directive) 175 into DistEdit via HTTP. She then performs some edits to the HTML 176 source. The HTML source is then written back to its original URL 177 using HTTP. The distributed editing session is ended. 179 Relevant requirements and/or protocol features: Source Retrieval, HTTP 180 PUT, Partial Write. 182 2.2.4. Editing Word Processor Source which Gets Converted to HTML 184 Scenario A: Jane needs to update the source of a web page, stored in 185 the native format of the HTTP-aware word processor DistProc. The HTTP 186 server containing this resource has extensions provided by the vendor 187 of DistProc which automatically convert the DistProc native files into 188 HTML which is served whenever the web page is accessed from its URL, 189 U. The web page does not include any graphic content, and is written 190 in English. She loads the web page source into DistProc from URL U 191 using HTTP, and begins to edit this DistProc native format source 192 file. After making some modifications, she saves the source file back 193 to the original URL, U, using HTTP. She then checks the HTML source 194 by retrieving URL U using their favorite web browser. Since it looks 195 fine, she ends the distributed editing session. 197 Relevant requirements and/or protocol features: Source Retrieval, HTTP 198 PUT. 200 2.2.5. Multiple Simultaneous Editors 202 Scenario A: A certain Web site is maintained by two people, both of 203 whom make changes on an ad hoc basis. As is frequently the case, 204 there are a few documents that are hot points of congestion, even 205 between these two people. Both people (we'll call them "Jane" and 206 "Joe") have a fancy, version-aware Web authoring tool that interacts 207 with their Web server. 209 Joe downloads a document from the Web site, and decides that it needs 210 work. He clicks on the "edit" button from his browser/authoring tool, 211 and the tool reports two things: first, that the Web server has 212 acknowledged his edit operation (giving him assurance that a 213 subsequent PUT will not be a complete surprise to the server); second, 214 that the document he will edit is identical to that which he viewed. 215 This may not always be the case: sometimes the document viewed by 216 users is not the true, editable source of the document. But in this 217 case it is. Joe proceeds to revamp the document. 219 Jane meanwhile is viewing the same document and realizes that in the 220 document the word "fuchsia" has a typo. Jane also clicks the "edit" 221 button, but the authoring tool has a lengthier report for her: in 222 addition to what Joe was told, Jane is told that Joe is also working 223 on the same document. Jane calls Joe and they reach an agreement: 224 Jane will make her fix now (because the error is embarrassing) and Joe 225 will make sure this alteration makes it into his revision. 227 Jane makes her changes and clicks the "save" button. Her authoring 228 tool prompts her for a brief description of her changes, and then the 229 server informs Jane that her change has resulted in a new, named 230 revision of the document, and that name is displayed. 232 Joe forgets what he was doing, and weeks later (while working on 233 something else) clicks the "what am I working on" button. In the long 234 list of documents that Joe has started to change is the document we've 235 been discussing, and Joe decides it is time to finish it off. He 236 makes his final edits, and clicks the "save" button. Joe, however, 237 gets a message indicating that what he edited is no longer the latest 238 version of the document, and Joe clicks the "merge" button. The 239 authoring tool has the latest and greatest merge mechanisms, and in 240 the process of resolving Jane's work with his he realizes that Jane 241 did more than just fix the misspelling she said she would. That 242 doesn't matter, because the merge mechanism uses actual differences, 243 not verbally stated intentions. 245 Joe again clicks the "save" button, and this time he is prompted for a 246 description and his new version of the document is saved. 248 [Continued in 3.6.1.] 250 3. Distributed Document Management 252 Scenarios in this section describe remote management of the properties 253 of resources, remote management of URL hierarchies (these could be 254 called "directories"), as well as visualization of the relationships 255 among graphs. 257 3.1. Opening/Closing Document Containers 259 Scenarios in this section are illustrate management of document 260 containers (e.g., "folders"). 262 3.1.1. Opening a Document Container 264 Scenario A: Jane requests that repository R (a web, a DMS store, etc.) 265 be opened. The server response to Jane establishes context for R; for 266 example, a list of R attributes and corresponding attribute values, 267 followed by a list cataloging the objects immediately subordinate to R 268 (folders, files, pages, whatever). Variation 1: Jane requests by 269 location (URL). Variation 2: Jane requests by identity (URI). 271 Scenario B: Jane requests that file F (containing document D) be 272 opened. The server response to Jane establishes context for F; for 273 example a "reference handle" for accessing the attributes and content 274 of F. 276 Scenario C: Jane opens folder S. In response, Jane receives context 277 for S. Just after Jane's OPEN request Joe initiates a MOVE of S. 279 Notes: 281 1. A semantic problem: how does Jane understand the object-context 282 response of the OPEN well enough to make use of it? 284 2. The need to support URI's as well as URL's. We should keep a 285 close eye on the URI/URC work groups (see URI specification [2], 286 and see also [3]). 288 3. The issue of locking resources. In scenario C, suppose Jane opens 289 S in something like a "share deny none" mode. What might happen? 290 a) The server might reject Joe's MOVE request. b) The server 291 might honor Joe's MOVE request and "shadow" the old URL for S 292 until there is no pending operation or unresolved state with 293 respect to S via the shadow URL. c) The server might honor 294 Joe's MOVE request and do nothing about pending operations or 295 unresolved states with respect to S via the orphaned URL. 297 3.1.2. Closing a Document Container 299 Scenario A: Jane, having examined the list of container attributes for 300 folder S, uses an editing tool in order to change the value V1 of the 301 attribute A to V2. The new attribute value has local instantiation at 302 the remote host(s) which are providing an environment for Jane's 303 editing tool. The (server side) object S itself does not yet reflect 304 V2 at A. Through some action, either explicitly (such as requesting a 305 "close" transaction with S) or implicitly (such as ending the edit 306 session) Jane asks for closure with S. Variation 1: A second party 307 Joe has meanwhile requested to PUT a value to A. Variation 2: At the 308 time of Jane's CLOSE request, Jane is disconnected from the network. 310 Scenario B: Jane has opened folder S and requested that all objects in 311 S not accessed within the last six months be deleted. Before the 312 deletion is complete, Jane requests closure with the repository R 313 containing S. 315 Notes: 317 1. The problem of encountering a race condition is the explicit 318 issue raised by Scenario A. But there is also the implicit issue 319 of providing a common semantic space for Jane's editing 320 environment and the server-side DMS. In this case it would be 321 nice if Jane's environment had lexicological connection with A, 322 i.e., could ascertain how the value of A is represented (data 323 type, range, etc.). Semantic problems such as these are often 324 resolved by promoting standard formats for the transport 325 container. Will the work group get involved with format issues? 327 2. Scenario B illustrates an obvious closure issue, to wit: all 328 ongoing processes and unresolved state conditions that are 329 artifacts of the interaction between Jane, S and R must be 330 "cleanly" terminated and resolved before closure. Usually. 332 3.2. Creating Documents 334 Scenarios in this section illustrate various ways of creating new 335 documents. 337 3.2.1. Creating a New Resource 339 Scenario A: Jane is working with distributed authoring tool DistEdit 340 on a new HTML page which does not contain any embedded graphical 341 content. She has finished her edits, and saves the HTML resource to a 342 web server using the HTTP protocol. She is prompted for a URL for the 343 new document; the page is then written to this URL using the HTTP 344 "PUT" method. 346 Relevant requirements and/or protocol features: HTTP PUT. 348 3.2.2. Creating a New Resource Through a "Save As" Dialog Box" 350 Scenario A: Jane is working with distributed authoring tool DistEdit 351 on a new HTML page which does not contain any embedded graphical 352 content. She has finished her edits, and wishes to save the HTML 353 resource to a web server using the HTTP protocol, but does not know 354 the exact name of the level of the URL hierarchy where she wants the 355 document to be stored. She invokes the "Save As..." feature of 356 DistEdit, which includes a hierarchy level viewer, a list of all the 357 entities and their MIME types at a specific level of the hierarchy, 358 along with the ability to go up or down a level of the hierarchy by 359 clicking on either ".." to go up, or the name of a hierarchy level to 360 go down. She moves up and down within the URL hierarchy using the 361 facilities of the hierarchy level viewer, finally finding a good 362 hierarchy level for the resource. She then enters a name for the HTML 363 resource, and hits the "Save" button. The DistEdit tool now writes 364 the HTML page to the URL created by combining the hierarchy level 365 selected using the hierarchy level viewer, and the name just entered 366 by her. The web page is written to the URL using the HTTP "PUT" 367 method. 369 Notes: 371 1. The AOLpress distributed authoring tool currently provides this 372 capability, which they term "Network saving of HTML pages" using 373 the "AOLpress file dialog." 375 2. For file-based servers, there is typically a mapping between URL 376 hierarchy levels and directories in the filesystem. 378 Relevant requirements and/or protocol features: List URL Hierarchy 379 Level, HTTP PUT. 381 3.2.3. Creating a New Resource in a New Hierarchy Level 383 Scenario A: Jane is working with distributed authoring tool DistEdit 384 on a new HTML page which contains some associated embedded graphical 385 content. She finishes her edits, and wishes to save the HTML resource 386 to a web server using the HTTP protocol, as well as save the graphical 387 images (collectively we will call this publishing). She invokes the 388 publishing feature of DistEdit, which includes the hierarchy level 389 viewer (as described in the previous scenario). She finds a level of 390 the hierarchy using the hierarchy viewer, but since this is a new web, 391 she decides to create a new level of the hierarchy just to contain 392 this web. Pressing the "Create New Hierarchy" button causes the 393 author to be queried for the name of the new hierarchy level. Once 394 entered, DistEdit informs the HTTP server that a new hierarchy level 395 should be added below the level currently displayed in the hierarchy 396 level viewer. If the author has the correct access permissions to 397 create a new hierarchy, the new hierarchy level is created. The web 398 author then presses the "Publish" button, and his web of HTML and 399 graphic entities are written to the HTTP server. 401 Notes: 403 1. The AOLpress distributed authoring tool currently provides the 404 capability to make new hierarchy levels, supported by their 405 "MKDIR" HTTP method. 407 Relevant requirements and/or protocol features: List URL Hierarchy 408 Level, Make URL Hierarchy Level, HTTP PUT. 410 3.2.4. Visualizing Webs as Graphs 412 Scenario A: In order to understand the link structure and resource 413 inclusion relationships at a hierarchy level, a web maintainer chooses 414 the "Graph View" option of their distributed editing tool DistEdit. 415 DistEdit queries the web maintainer for which level of the hierarchy 416 to display using a graph visualization, and then uses the HTTP 417 protocol to read information about that level of the hierarchy. 418 DistEdit uses this information to display a graphical visualization of 419 the hierarchy level, including an icon for each resource, solid lines 420 between the icons representing links, and dashed lines representing 421 inclusion (for example, images loaded using the IMG tag). Entities 422 the web maintainer has read and write access to are displayed in 423 green, those which they have read access to are in white, and those 424 which they have no access to are in red. To create the graph 425 visualization, DistEdit must, using HTTP, get a listing of all the 426 entities at a level of the hierarchy, and their access control 427 permissions. 429 Notes: 431 1. The AOLpress distributed authoring tool currently provides a 432 similar capability, which they term the "MiniWeb," a "bird's-eye" 433 graphical view of web site documents and how they are linked 434 together. 436 2. The FrontPage distributed authoring tool provides equivalent 437 capability, which they call a "Link View," and also supports the 438 related "Outline View" and "Summary View." 440 Relevant requirements and/or protocol features: List URL Hierarchy 441 Level. 443 3.3. Attribute Management 445 Scenarios in this section illustrate management of document attribute 446 data, and the administration of access rights. 448 3.3.1. Getting Attribute Values 450 Scenario A: Jane submits a list of document URIs with the request that 451 the "subject/summary" attribute value be returned for each document. 453 3.3.2. Modifying/Setting Document Attribute Values 455 Scenario A: Jane requests that the value of the document attribute 456 "subject/summary" for document D be modified to correct an error. 458 Scenario B: Jane is creating a new document on the Web. She sends it 459 to the server, but also wants to set a bunch of attributes that can be 460 used later in searches (author, title, type of document, subject, 461 organization, etc.). Sometimes she may also want to create catalog 462 entries for documents that are not available in electronic form. 463 There will be no content for these documents, just attributes. 465 Relevant requirements and/or protocol features: Attributes. 467 3.3.3. Access Control 469 Scenarios in this subsection illustrate various situations of 470 assigning, modifying and revoking access rights to a document or group 471 of documents. 473 3.3.3.1. Modifying Access Rights 475 Scenario A (Realistic): A sales manager at a company which contains an 476 organization-wide intranet is working with an intranet-enabled 477 spreadsheet program, DistCalc. After entering the sales figures for 478 the previous month (which are below projections), a graph of the sales 479 figures is generated as a JPEG image, and then saved to the 480 departmental HTTP server using the HTTP "PUT" method. Realizing that 481 it might be best to limit access to this information, in their web 482 browser they bring up the graph image. After selecting the menu 483 option, "Modify Access Permissions," the browser displays the access 484 control page for the graph image resource. The sales manager uses the 485 (server-specific) facilities on this page to modify the sales chart's 486 access control rights so it is password protected. 488 Scenario B (Ideal): In the ideal case, the DistCalc program would 489 display a dialog box asking the user for what access rights the graph 490 resource should have before the graph is saved to the departmental 491 HTTP server. 493 Notes: 495 1. The "realistic" case assumes that reaching consensus on an access 496 control standard for HTTP resources is not achievable in the near 497 term, and hence access control will vary with server type. It 498 also assumes a continuation of the current trend of having an 499 access control URL for each resource. The "ideal" case shows 500 what could be achieved if an HTTP access control standard is 501 created. 503 No matching requirements or protocol features. 505 3.3.3.2. Using Special Access Rights 507 Scenario A: A museum's paintings are being made available online. 508 There are several different collections of paintings with different 509 access rules. Paintings may migrate from one collection to another 510 from time to time. 512 1. One collection, meant to entice visitors into the museum, is 513 freely available to all. 515 2. In another collection, anyone can view metadata or retrieve a 516 low-resolution rendition of any painting for free, but retrieval 517 of a high-resolution rendition requires payment of a fee. Museum 518 members can retrieve even high-resolution renditions from this 519 collection without charge. 521 3. A children's collection lets children submit art works. The 522 child registers when he submits an art work. Any child can add, 523 remove, or modify his own work. Anyone can view works in this 524 collection for free. Access control for this site can be managed 525 by creating the three collections, and setting access rights for 526 each collection at the server. The curator can move paintings 527 from one collection to another with a Web-based tool. The museum 528 application enforces access rights by consulting the museum's 529 membership database and the children's registry, together with 530 the access policies. 532 Scenario B: A university library wants to put reserve readings on line 533 for its students. In order not to violate any copyright laws, it 534 needs to set permissions so that only students registered for a 535 particular course can view the readings for that course. The 536 librarian putting the reserve readings online is using a Web-based 537 tool. Whenever he adds a reading to the Web site, the tool prompts 538 him for the course numbers whose students should be allowed to access 539 that reading. The reserve readings application at the Web server is 540 tied to the course registration database to enforce these permissions 541 when students try to access materials. 543 Scenario C: Some products support a notion of community-administered 544 Web sites. Anyone can set up an account for himself at one of these 545 sites. Then, when logged on as himself, he can add collections and 546 materials to the site, and determine access rights for any objects he 547 adds. He can change these access rights at any time. He can create 548 groups and users, and administer the groups and users he owns or has 549 permission to administer. 551 Notes: 553 1. Xerox's DocuShare system supports Scenario C. 555 3.3.3.3. Access Rights and Document State 557 A team is working on a project that involves sensitive business data. 558 The project's deliverables include several papers, each of which goes 559 through several cycles of writing and review before it is approved for 560 distribution. A person who is an author of one paper may be on the 561 review team for several others. Outside reviewers are also engaged 562 for each of the papers. While a paper is in a writing phase, only its 563 authors have write access to it, and only project team members have 564 read access to it. When a paper is in a review cycle, read and print 565 access is extended to reviewers. This access is removed once review 566 is complete. When a version is approved for distribution, a short 567 list of users throughout the company is given read and print 568 permission (each of these users can print at most one copy); a longer 569 list can read the paper, but not make printed copies. The project 570 lead assigns people to the authoring and reviewing groups and 571 distribution lists for each paper, and determines when each paper 572 moves from one phase to another. All this is done with Web-based 573 tools. 575 3.3.3.4. Access Rights and Versioning 577 A versioned document describing a company's product offerings is being 578 developed at a Web site. It is expected to evolve over time as 579 product offerings change. The team leader designates one version of a 580 document as the public version. Everyone in the world has read access 581 to this version. The team leader can change which version is the 582 public version at any time. The team leader also gets to decide which 583 version of the document team members are allowed to modify at any 584 time. Only team members have write access to this version. Any other 585 versions are viewable, but not modifiable, by team members. The team 586 leader makes these changes to the access restrictions on versions 587 using a Web-based tool. 589 3.4. Copying, Moving and Deleting 591 Scenarios in this section illustrate typical "housekeeping" involved 592 with managing documents, such as renaming, moving them around, and 593 deleting them. 595 3.4.1. Copying Documents 597 Scenario A: Jane is looking at the list of monthly reports available 598 on the server. She selects one from the list that she wants to use as 599 the basis for a new monthly report. She asks for a copy of this 600 monthly report to be made in the same directory but with a different 601 name. Since she is not intending to work on it now, there is no 602 reason to pull the content to the client. 604 Relevant requirements and/or protocol features: Copy. 606 3.4.2. Copying Document Containers 608 Scenario A: Jane directs that folder S1 be copied to folder S2. While 609 the copy is in progress, Joe directs that S1 be moved to folder S3. 611 Scenario B: Jane directs that a container F be copied to a location 612 outside the repository R. Although F contains only a simple text 613 document, the structure of F both as a logical and a physical entity 614 is highly idiosyncratic, being intimately bound to R. Consequently, F 615 cannot be expressed in the external domain. Variation 1: The DMS has 616 export capability (to the external file system) with a granularity 617 that can resolve F. Variation 2: The document contained by F has a 618 native format corresponding to the tool used to generate the document 619 (HTML, WPD, etc.). In this case one could interpret the copy as a 620 transform from F in the DMS domain to the native document format D in 621 the external domain. Variation 3: The container to be copied is 622 folder-like, i.e. a proper container, and the container hierarchy in R 623 is compatible with the external domain container hierarchy. In this 624 case, some kind of copy/transform could be implemented, with the 625 understanding that container attributes might be largely distorted or 626 lost. 628 Notes: 630 1. Copying within R should be no big deal, though scenario 6a does 631 illustrate why one might desire some kind of "read-lock" 632 mechanism. As scenario B illustrates, copying container structure 633 and content from one repository to another can be problematical. 634 For example: how does one, in general, map a plex container model 635 to a hierarchical model? 637 3.4.3. Deleting and Undeleting Documents 639 Scenario A: Jane directs that page P and all subordinate objects be 640 deleted from web W. Pn is subordinate to Pk is subordinate to P, and 641 both Pk and Pn are in scope (i.e., in W). It so happens that Pn 642 forward links to Pk. The delete process DEL recursively chains down 643 from P, eventually encountering Pk, and asserts a "read lock" on Pk 644 preparatory to deleting Pk. Since Pk has subordinate links, DEL 645 continues down the chain until it encounters Pn, where it asserts a 646 "read lock" and recursively chains forward to Pk. DEL requests a 647 "read lock" on Pk. 649 Notes: 651 1. Document deletions (like container deletions) can be subject to 652 qualifying conditions such as meeting query and scope criteria. 654 2. Developers must be wary of deadlocks. 656 3.4.4. Deleting and Undeleting Document Containers 658 Scenario A: Jane opens folder S and examines its content. Jane 659 decides to delete all non-folder objects in S, but is unsure if 660 existing folders subordinate to S have valuable content. Jane directs 661 that all non-folder objects in S be deleted. 663 Scenario B: Jane directs that folder S and all subordinate folders and 664 content be deleted. A document subordinate to S is currently open to 665 Joe. 667 Scenario C: Jane directs that file F containing document D be deleted. 668 A copy process of D to some other repository is in progress. 670 Scenario D: Jane directs that all containers and related content 671 subordinate to folder S with content that has not been modified since 672 a given date (supplied by Jane or otherwise provided) be deleted. One 673 or more active documents in the repository reference a common header 674 that is in a file F subordinate to S. F meets the delete criterion. 676 Scenario E (Undeleting): Container S1 (subordinate to S) and all 677 subordinate containers have been deleted. Jane requests that 678 container S3 and all subordinate objects be undeleted, where S3 was 679 subordinate to S2 which in turn was subordinate to S1. Variation 1: 680 The container structure is "plex", so that S3 was also subordinate to 681 Sk which was not subordinate to S1. 683 Notes: 685 1. The delete might need to act within the context of query results 686 on container/content attributes as well as scope conditions on 687 the store hierarchy. 689 2. B and C show how "locking" might be a good thing. 691 3. D illustrates how someone might wish to incorporate a "reference 692 count" attribute on linked objects, and desire that reference 693 count values be appropriately factored into the query/scope 694 constraints for certain kinds of transactions. 696 3.4.5. Moving Documents 698 Scenario A: Jane notices that after recently editing the content of a 699 document its assigned name no longer makes logical sense. She decides 700 to rename the document. She selects the document from a list of 701 existing documents and is prompted for a new name. Since she does not 702 intend to work on it now, there is no reason to pull the content to 703 the client. 705 3.4.6. Moving Document Containers 707 Scenario A: Jane directs that folder S1 be moved to folder S2. In the 708 container hierarchy, S2 is subordinate to S1. 710 Scenario B: Jane directs that container S1 be moved to container S2. 711 There exists in web W a page P that is external to S which makes 712 (forward) reference (via URI) to one or more objects in S. 714 Notes: 716 1. Again we see in the second scenario why it might be desirable to 717 support the URI initiative. 719 3.5. Working with Multiple Documents/Resources 721 Scenarios in this section illustrate situations where manipulation of 722 a (logical) collection of related document is necessary. 724 3.5.1. Printing a Multi-Resource Document 726 Scenario A (Browsing): A net surfer browsing the web loads the 727 introductory page for a book which has been written in HTML and 728 subdivided so that there is a separate resource for each chapter, and 729 many side links to clarifying text and standalone figures. Since the 730 book is of interest, the net surfer would like to print the entire 731 document. Clicking on the "Print" button of their web browser brings 732 up the Print dialog box, which contains an option, "Print 733 multi-resource document," which they select, before pressing the 734 "Start Printing" button. 736 The browser now begins, in the background, to load all of the chapters 737 of the book along with their explanatory sidebars, sending them one by 738 one, in order, to the printer. When complete, the browser pops-up a 739 dialog box stating that the document has been completely printed. 741 Scenario B (Distributed Authoring): This scenario applies equally well 742 to a distributed authoring situation. If the author of a 743 multi-resource document is using a distributed authoring tool to write 744 the document, it is desirable for them to be able to print the 745 document as a whole, rather than by loading and printing each resource 746 in turn. 748 Notes: 750 1. This type of printing capability is supported by the KMS 751 hypertext system, an early monolithic (but very feature-rich) 752 hypertext environment. 754 2. Another common example of a multi-resource document which would 755 be desirable to print as a whole is a slide presentation which 756 has been converted into HTML. 758 3.5.2. Quick Browsing of Related Resources 760 Scenario A: A professor is working on a new textbook using their 761 favorite intranet-enabled word processor, DistProc. Once the initial 762 draft of this book is complete, they use the "Publish" feature of 763 DistProc to save their book as multiple resources, one per chapter, on 764 a web server. Since the author intends for their students to read the 765 text using web browsers employing a DistProc reader plug-in, the 766 professor has the book on the HTTP server in DistProc native format, 767 preserving layout information. 769 In order to provide additional browsing structure to the students, the 770 professor uses the feature of DistProc to automatically create links 771 to the table of contents, index, and glossary for the book. To make 772 generating feedback easier, all book chapters automatically have a 773 link to a corrections and feedback page. As the students are reading 774 the text, these automatic links are displayed as special toolbar icons 775 in their browser. 777 Notes: 779 1. The AOLpress distributed authoring tool currently "allows pages 780 to add toolbar buttons on the fly using the HTML 3.2 782 784 -tag. For example, your page can add toolbar buttons that link 785 to a home page, table of contents, index, glossary, copyright 786 page, next page, previous page, help page, higher level page, or 787 a bookmark in the document." 789 2. The scenario above is currently unachievable because LINK tags 790 are only supported in HTML. 792 3.6. Publishing and Reverting 794 These scenarios are hopefully illustrative of the need of a versioning 795 scheme for distributed editing. 797 3.6.1. Revising a Set of Documents and Publishing Them When Complete 799 [Continued from 2.2.5.] 801 Scenario A: Jane and Joe's version-aware web server is fairly simple: 802 normally, it serves up the latest revision of each document, but if 803 instructed it will instead serve up the revisions of documents as 804 listed in a named configuration. In this way, they can make their 805 trivial changes and have them show up immediately, but if they plan to 806 make a heavy-duty overhaul they can save the current set as a working 807 configuration and tell the server to use those until the work is 808 complete (this can all be carried out without the explicit knowledge 809 of Jane and Joe's authoring tool, because the Web server makes itself 810 configurable via Web pages with forms on them). 812 Joe is about to make a set of minor changes, and to be on the safe 813 side tells the server to save the current configuration as "stable", a 814 name he uses for these occasions. He goes through the various 815 documents, clicking "edit" on any that he thinks are in need of 816 updating. 818 Once again Joe forgets what he is doing, but a few days later the 819 "what am I working on" button again comes in handy. He realizes that 820 his work is about complete, and makes his final edits. 822 Joe's changes really are a coherent set that should appear 823 simultaneously, and he doesn't want to find out halfway through saving 824 that Jane has made changes that need merging, so he clicks the "Save 825 All" button. Fortunately, Jane has been busy viewing other parts of 826 the web and hasn't made any changes to their local Web pages, and so 827 Joe is prompted for a description of the changes he has made. Since 828 Joe is saving all the documents at once, a single description applies 829 to all the changes. One by one the new documents are saved, and in 830 the end Joe gets confirmation that all documents are in place. Joe 831 browses the result and is satisfied that their customers are seeing 832 what he has just finished. 834 Joe goes on vacation. 836 [Continued in 3.6.2.] 838 3.6.2. Reverting the Revised Document Set 840 [Continued from 3.6.1.] 842 Scenario A: Jane gets back to real work and realizes that every 843 document that Joe edited has the same old spelling problem. In a 844 panic she calls Joe but realizes that he is on vacation. Knowing that 845 the errors would harm their image, she decides to undo what Joe has 846 done until he returns and can correct his mistakes. 848 Jane begins by browsing the revision history of each document, and 849 notes that all the erroneous documents came about at the same time 850 when Joe saved his changes just before vacation. 852 Jane browses the configuration lists in the version-aware web server 853 and sees that Joe had made a "stable" configuration before his latest 854 work. Jane instructs the server to serve up only documents from the 855 "stable" configuration. As this doesn't involve changing any of Joe's 856 work, it is a quick fix to the pages on their public web server. Jane 857 now browses the documents on their server and is satisfied that they 858 are the precursors to Joe's latest change. 860 When Joe returns, he fixes his spelling mistakes and then tells the 861 server to resume using the latest documents. 863 4. Versioning Issues 865 Versioning (the ability to retain revision histories for documents) is 866 discussed in several scenarios in this document. Section 3.6 867 (Publishing and Reverting) presents scenarios where versioning is 868 necessary, as well as section 2.1.2 (Checking Documents In and Out) 869 variation 3 and section 2.2.5 (Multiple Simultaneous Editors). The 870 relationship between versioning and access privileges is discussed in 871 section 3.3.3.4 (Access Rights and Versioning). 873 5. Miscellaneous Scenarios 875 Scenario A: Jane's department keeps its documents organized in 876 hierarchical collections. There is a collection called "Monthly 877 Reports" with subcollections for each month. There is also a 878 collection called "Monthly Business Letters" with subcollections for 879 each month. The monthly reports are used to derive the monthly 880 business letters, so the monthly reports appear in the appropriate 881 "Monthly Business Letters" subcollections as well. When Jane writes 882 her monthly report, she puts it into Monthly Reports/199608 and into 883 Monthly Business Letters/199608. Only one copy of the report should 884 exist on the server, but it appears in both places when users browse 885 or search the collections. 887 Scenario B: The first time Jane's monthly report gets printed, it gets 888 converted to PostScript, which she wants to store on the server. Now 889 there will be two renditions of the same (versions of the same) 890 document from which she can choose when she retrieves the document in 891 the future. She also saves the printing instructions (duplex, 892 landscape, stapled, etc.) for the document, which she may want to 893 retrieve with the PostScript later. 895 6. References 897 [1] Jim Whitehead, 1996. "Requirements on HTTP for Distributed 898 Content Editing", Internet Draft (available on-line from the 899 Internet Draft collections as draft-whitehead-http-distreq-00.txt) 901 [2] Tim Berners-Lee, 1994. "Universal Resource Identifiers in WWW - A 902 Unifying Syntax for the Expression of Names and Addresses of 903 Objects on the Network as used in the World-Wide Web", Request for 904 Comments #1630 906 [3] --, "Uniform Resource Identifiers", available on-line as 907 http://www.acl.lanl.gov/URI/uri.html 909 [4] J.A.Slein, F.Vitali, E.J.Whitehead and D.G.Durand, 1997. 910 "Requirements for Distributed Authoring and Versioning on the 911 World Wide Web", Internet Draft (available on-line from the 912 Internet Draft collections as 913 draft-ietf-webdav-requirements-00.txt) 915 Acknowledgments 917 The following people have contributed to this document by submitting 918 sample scenarios and/or by commenting: 920 * Eui-Suk Chung, Ericsson, euisuk@w3.org 921 * Del Jensen, Novell 922 * Dave Long, dave@sb.aol.com 923 * Christopher Seiwald, Perforce Software, seiwald@perforce.com 924 * Judith A. Slein, Xerox, slein@wrc.xerox.com 925 * Jim Whitehead, UC Irvine, ejw@ics.uci.edu 927 Author's Address 929 Ora Lassila 931 Nokia Research Center / Boston 932 3 Burlington Woods Drive, Suite #250 933 Burlington, MA 01803 935 Phone: +1 (617) 238-4908 936 Fax: +1 (617) 238-4949 937 E-Mail: ora.lassila@research.nokia.com