idnits 2.17.1 draft-ietf-webdav-collection-reqts-02.txt: -(130): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(497): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-03-28) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 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 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. ** There are 141 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 3 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 (January 20, 1999) is 9199 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) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group J. Slein, Xerox Corporation 2 INTERNET DRAFT J. Davis, Xerox Corporation 3 July 20, 1998 4 Expires January 20, 1999 6 Requirements for Advanced Collection Functionality in WebDAV 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or made obsolete by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress". 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe),munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US EastCoast), or ftp.isi.edu (US West 26 Coast). 28 Distribution of this document is unlimited. Please send comments 29 to the Distributed Authoring and Versioning (WebDAV) working group 30 at , which may be joined by sending a 31 message with subject "subscribe" to . 34 Discussions of the WEBDAV working group are archived at URL: 35 . 37 Abstract 39 The base WebDAV protocol [Goland et al., 1998] provides basic 40 support for collections. It defines a MKCOL method for creating 41 collections and specifies how other HTTP and WebDAV methods 42 interact with collections. It supports internal members of 43 collections, which it defines as members whose URIs are 44 immediately relative to the URI of the collection. 46 This draft sets out requirements for more advanced, optional 47 collection functionality. It extends the base functionality in two 48 general directions: support for referential members, and support 49 for ordered collections. A separate WebDAV specification is 50 expected to define protocol elements providing the functionality 51 described here. 53 1 Terminology 55 The terminology used here follows and extends that in the base 56 WebDAV protocol specification [Goland et al., 1998]. 58 Collection 59 A resource that contains member resources 61 Member Resource 62 A resource contained by a collection 64 Referential Resource (or Reference) 65 A resource that has no content of its own, but rather is 66 a reference to another resource 68 Ordinary Resource 69 A resource that is not a reference to another resource 71 Target Resource 72 The resource referenced by a referential resource 74 Direct Reference 75 A reference that has the property that operations on it are 76 passed through to its target 78 Indirect Reference 79 A reference that has the property that operations on it do 80 not affect its target 82 Strong Reference 83 A reference whose referential integrity is guaranteed by the 84 server 86 Weak Reference 87 A reference whose referential integrity is not guaranteed by the 88 server 90 Referential Integrity 91 A server guarantees the integrity of a reference if it ensures 92 that the reference will not be broken, or enables the 93 reference's owner to ensure that the reference will not be 94 broken. 96 2 Introduction and Rationale 98 The simple collections that the base WebDAV specification supports 99 are powerful enough to be widely useful. They provide for the 100 hierarchical organization of resources, with mechanisms for 101 creating and deleting collections, copying and moving them, 102 locking them, adding resources to them and deleting resources from 103 them, and getting listings of their members. Delete, copy, move, 104 list, and lock operations can be applied recursively, so that a 105 client can operate on whole hierarchies with a single request. 107 Many applications, however, need more powerful collections. There 108 are two areas in particular where more powerful functionality is 109 often needed: referential members and ordering. This draft 110 details the additional functionality that is needed in these two 111 areas. 113 2.1 Referential Resources 115 Referential resources make it possible for many collections, on the 116 same or different servers, to share the same resource. Because 117 the collections share the resource by referencing it, only one 118 physical copy of the resource need exist, and any changes made in 119 the resource are visible from all the collections that reference 120 it. 122 So, for example, the mathematics department at one university can 123 create a collection of resources on fractals that contains some 124 local resources, but also references resources at several other 125 universities. 127 A manufacturing company develops and maintains its product 128 maintenance manuals on the Web, with a separate collection for 129 each product manual. Each manual is divided into sections, one 130 section for every product component. Since many of the company�s 131 products contain some of the same components, many of the product 132 maintenance manuals have sections in common. Each manual may have 133 some unique sections, which are internal members of its 134 collection. But for product components that are common to 135 multiple products, the manual has a referential member that 136 references a resource in a shared library. 138 Strong references and weak references are both useful in different 139 contexts. Some applications cannot tolerate broken links. 140 A software development application, for example, must be able to 141 rely on the integrity of references to component modules. Such 142 applications must be able to request strong references. Other 143 applications may want to reference target resources on multiple 144 servers, where referential integrity cannot be guaranteed, and may 145 be less concerned about possible broken references. Both strong 146 references and weak references should eventually be supported by 147 WebDAV, although the complexities of enforcing referential 148 integrity make it unlikely that strong references will be supported 149 in the short term. 151 Similarly, both indirect and direct references may be useful. Each 152 of these types of references is implemented in existing systems. 153 Existing HTTP servers are capable of supporting both types of 154 references. In effect, indirect references give clients access to 155 the reference itself, and allow the reference to bear properties. 156 Direct references, once created, simplify access to the target 157 resource by hiding from clients the fact that there is a reference 158 mediating between the client and the target resource. Although it 159 is desirable for WebDAV to support both indirect and direct 160 references, the difficulties of supporting direct references make 161 it unlikely that they will be supported in the short term. 163 2.2 Ordered Collections 165 For many applications, it is useful to be able to impose an 166 ordering on a collection. In the product manual application 167 above, the sections of each manual may be ordered so that they can 168 be printed together as a book. A configuration management 169 application might use a collection to represent a version series, 170 in which case the "derives from" relationship might be represented 171 as an ordering on the collection. 173 A collection ordering may sometimes be based on property values. 174 An example of such an ordering is one that is alphabetical by 175 author�s last name, or one from most recent to oldest last- 176 modified-date. An ordering need not be based on property values, 177 however. A professor may order a collection of course readings in 178 the sequence that makes sense to coordinate them with her lectures, 179 where there is no property on the member resources that could be 180 used to create this ordering. This set of requirements is 181 primarily concerned with orderings that are not based on property 182 values. 184 Another useful distinction is between server-maintained and 185 client-maintained orderings. In server-maintained orderings, the 186 server enforces the semantics of the ordering by placing each 187 collection member at the appropriate position in the ordering; 188 clients cannot alter the ordering. In client-maintained orderings, 189 the client places each collection member in the ordering based on 190 its understanding of the semantics of the ordering; the server 191 does nothing to validate the client's positioning of the member 192 in the ordering. This set of requirements is concerned only with 193 client-maintained orderings. 195 WebDAV already provides tools that could be used for creating and 196 maintaining ordered collections. For example, using only the base 197 WebDAV specification, an application could create a WebDAV property 198 called "Order" on a collection resource. The value of this 199 property might be a list of the URIs of the collection members. 201 What the base WebDAV specification does not do is standardize a 202 single way to represent orderings for collections. 204 Different applications and services should be able to operate on 205 the same collection without private agreements about how to manage 206 and examine its order. To make this possible, there needs to be a 207 standard way to manipulate and retrieve the order of a collection, 208 and a standard representation of the ordering. 210 In any situation where collaborative management of a collection 211 takes place, and different authoring tools or WebDAV servers might 212 be used by the collaborators, standardization is important. It is 213 also important where a different tool may be used to view the 214 collection from the one that was used to create it. 216 So for example, two users from different organizations, using 217 different authoring tools, are working together to create a 218 collection. One of the tools uses a property on the collection 219 called "Order" to store an ordering of the collection. The other 220 tool uses a property on the member called "SequenceNumber". If 221 each user adds some members to the collection, there will be no 222 reliable ordering. 224 3 Requirements 226 3.1 Referential Resources 228 Requirements 3.1.1 - 3.1.7 apply to referential resources in 229 general. Requirements 3.1.8 - 3.1.10 apply to referential 230 resources only in the context of collections. Requirements 231 3.1.11 - 3.1.14 apply only to indirect references. Requirements 232 3.1.15 - 3.1.17 apply only to direct references. Requirements 233 3.1.18 - 3.1.20 relate to strong references and guarantees of 234 referential integrity. The initial release of the WebDAV 235 collections protocol specification is expected to focus on indirect 236 references and weak references. It is not expected to satisfy 237 either the requirements for strong references or the requirements 238 for direct references. 240 3.1.1 A single target resource may be referenced by multiple 241 referential resources. 243 This is the primary benefit that referential resources bring. 244 They allow resources to be shared by multiple collections, which 245 may reside on the same server as the shared resource or on other 246 servers. 248 3.1.2 It is possible to create a referential resource. 250 3.1.3 It is possible to delete a referential resource. 252 It is important to note that this is a different operation from 253 deleting the referential resource�s target resource. It must 254 be possible to delete a reference without deleting its target. 256 3.1.4 A referential resource is itself a resource. 258 This makes explicit what is suggested by several of the other 259 requirements. Requirement 3.1.14 in particular, that indirect 260 references carry their own properties, forces referential resources 261 to be resources. WebDAV properties can belong only to resources. 263 3.1.5 Operations on a target resource do not affect references to it 264 except as needed to enforce referential integrity. 266 We do not expect operations on a target to affect references to 267 it. For indirect references, locking a target does not cause the 268 indirect references to it to be locked. Modifying the properties 269 of a target does not cause changes in the properties of indirect 270 references to it. Etc. For direct references, this issue is moot, 271 since clients cannot operate on them in any case except to create 272 them or delete them. Clients cannot view their properties or 273 headers. 275 Just as in 3.1.11 passing operations through to the target can be 276 problematic, so here reflecting operations back to the referencing 277 resource can be problematic if the referential resource and the 278 target resource are on different servers. Issues about what 279 credentials to use would need to be addressed. 281 This requirement must be qualified to allow for strong references, 282 however. For strong references, whether direct or indirect, some 283 operations on targets must cause changes in the references to them. 284 For example, if the target of a strong reference is moved, the 285 reference must change to reflect the new location of the target. 287 3.1.6 A plain HTTP 1.1 browser should be able to use a referential 288 resource to access its target. 290 This minimal level of compatibility with older browsers is needed 291 to make deployment of WebDAV collection functionality feasible. 292 References are a new type of resource whose main purpose is to 293 allow ordinary resources to be shared by multiple collections. 294 Although WebDAV clients may be needed to create and manipulate 295 these new resources, older clients should be able to read and 296 make use of the collections built using references. 298 3.1.7 There is no requirement that references be acyclic. 300 From a practical standpoint, servers generally cannot control what 301 happens on other servers. If a reference R on one server points to 302 a target T on another server, R's server cannot prevent T from 303 being changed to point back to R. In addition, there may be 304 applications where cyclic references are desirable. 306 3.1.8 A listing of the members of a collection shows both its 307 ordinary members and its referential members. 309 A listing of collection members with Depth = 1 or Depth = infinity 310 shows all members of the collection, whether ordinary or 311 referential. It follows from the definitions if indirect and 312 direct references that their behaviors in a listing of collection 313 members will differ from each other. 315 For indirect references, the reference itself, and not its target, 316 will be listed. If Depth = infinity, the listing will not 317 follow references into any collections to which they may refer. 318 This is to minimize the risk of being caught in a circle of 319 references or a long chain of references. 321 For direct references, the target will be listed. If Depth = 322 infinity and the target is a collection, the members of the target 323 collection will also be listed. 325 3.1.9 Multiple referential resources with the same target may reside 326 in the same collection. 328 It is often useful to allow the same resource to be referenced in 329 a collection multiple times. Typically, these are cases where the 330 collection is ordered. Consider a case where a collection 331 represents a book, with one member resource for each page in the 332 book. A particular graphic needs to appear in several places in 333 the book, and so needs to appear in the collection several times. 335 3.1.10 A reference and its target may both be in the same collection. 337 In the example just described, the collection might contain the 338 graphic as an ordinary member, which is also referenced by 339 referential members of the same collection so that it can appear 340 multiple times in the book. 342 3.1.11 Operations on an indirect reference do not affect its target 343 resource except as needed to enforce referential integrity. 345 This requirement is really a restatement of the definition of 346 an indirect reference. There are many reasons for wanting to 347 support this sort of resource. 349 Indirect references allow clients to operate on the referential 350 resource itself. For example, they can store properties on the 351 reference distinct from those on its target. If requests to the 352 referential resource were automatically redirected to its target 353 resource, this would not be possible. 355 Passing operations through to the target resource exposes 356 servers to the risks of circular references and long chains of 357 references that refer to other references. 359 In addition, passing operations through to the target resource can 360 be problematic if the referential resource and the target resource 361 are on different servers. Issues about what credentials to use 362 would need to be addressed. 364 This requirement must be qualified to allow for strong references, 365 however. Strong references are those whose referential integrity 366 is guaranteed by the server. Requirement 3.1.n makes it possible 367 that some servers will support strong references. For some 368 implementations of strong references, operations on the 369 references may cause changes in their targets. For example, if a 370 server maintains a list of the strong references to a target in a 371 property on the target resource, creating or deleting a strong 372 reference will cause a change in this property of the target. 374 3.1.12 For any indirect referential resource, it is possible to obtain 375 the URI of its target resource. 377 This will allow clients to resolve indirect references themselves 378 in order to operate on the target resources. 380 3.1.13 For any resource, it is possible to discover whether it is an 381 indirect reference. 383 Since operations on indirect references are not passed through to 384 their targets, it is important for clients to be able to discover 385 which resources are indirect references. Then the client can 386 resolve the references in order to perform operations on their 387 targets. 389 3.1.14 It is possible for an indirect reference to carry its own 390 properties, distinct from those of its target. 392 There are properties like "who created this reference" and "when 393 was this reference created" that clearly belong to the indirect 394 reference, and not to its target resource, which may be referenced 395 by many different referential resources. 397 3.1.15 Operations on a direct reference, except for creation and 398 deletion of the reference itself, are passed through to its 399 target resource. 401 This requirement is really a restatement of the definition of 402 a direct reference. There are several reasons for wanting to 403 support this sort of resource. 405 Direct references simplify operations for clients, hiding from them 406 the fact that a reference is mediating between their requests and 407 the target resource. 409 Many existing systems, including HTTP servers, implement direct 410 references. 412 Supporting direct references does introduce issues that make it 413 unlikely that WebDAV will support them in the short term. Passing 414 operations through to the target resource exposes servers to the 415 risks of circular references and long chains of references that 416 refer to other references. In addition, passing operations through 417 to the target resource can be problematic if the referential 418 resource and the target resource are on different servers. Issues 419 about what credentials to use would need to be addressed. 421 3.1.16 For any resource, it is possible to discover whether it is a 422 direct reference. 424 Since the behavior of direct references is radically different from 425 the behavior of indirect references, it is important for clients 426 to be able to discover whether they are operating on a direct 427 reference. The client must have a way of finding out whether the 428 properties it sets will be stored on the reference or on its 429 target, etc. 431 3.1.17 It is not possible for a client to set or view properties of 432 a direct reference, distinct from those of its target. 434 Again, this follows from the definition of a direct reference. 435 Since all operations except creating the reference and deleting 436 the reference are passed through to the target, the client can 437 operate only on properties of the target. 439 3.1.18 It is possible to request creation of a referential resource 440 that the server will guarantee to have referential integrity. 442 For some applications, broken references are unacceptable. 444 Breakage may be unavoidable when a target resource resides on a 445 different server from the referential resource that references it. 446 Servers can, however, maintain the integrity of referential 447 resources when they receive MOVE or DELETE requests for target 448 resources under their own control. For applications that require 449 referential integrity, it must be possible to specify in a 450 request for creation of a referential resource that its integrity 451 be guaranteed. If the server cannot honor this request, it must 452 decline to create the referential resource. A referential resource 453 whose integrity is guaranteed by the server is called a strong 454 reference. 456 3.1.19 These requirements are silent as to what policy should be used 457 to ensure referential integrity. 459 A server guarantees the integrity of a reference if it ensures that 460 the reference will not be broken, or enables the reference's owner 461 to ensure that the reference will not be broken. 463 There are many policies that could be adopted to fulfill this 464 commitment. For example, a server could refuse to allow a target 465 to be deleted while there are strong references to the target. 466 Alternatively, the server could delete the strong references along 467 with the target. Alternatively, the server could flag the strong 468 references "Target Deleted" when it deletes the target. Or the 469 server could notify the owners of all strong references when it 470 deletes a target, allowing the owners to take whatever action they 471 wish. These requirements say nothing about what policy should be 472 used to enforce referential integrity. 474 3.1.20 It is possible to discover whether a referential resource is a 475 strong reference or a weak reference. 477 Knowing whether a referential resource is strong or weak allows a 478 client to intelligently choose its own strategy for working with 479 referential resources. For example, if a client does not know 480 whether a particular reference is strong or weak, it may choose to 481 recreate that referential resource to be sure of referential 482 integrity; but if it knows that the reference is strong, it will 483 not bother to do this. 485 3.1.21 It is possible to discover whether a resource is the target of 486 a strong reference. 488 This requirement insures that both ends of a referential integrity 489 relationship have the same information available. 491 3.2 Ordered Collections 493 3.2.1 Ordering is sufficiently standardized that different 494 applications and servers can operate on the same ordering 495 without private agreements. 497 Applications and servers can apply an ordering to a collection�s 498 members or discover the ordering of a collection's members without 499 private agreements. They can also modify an ordering, at least 500 with the help of a human user for semantics (See 3.2.3), without 501 private agreements. 503 This is the minimum that is needed to support collaborative 504 management of an ordered collection, where different authoring 505 tools might be used by the collaborators. It is also what allows 506 a different tool to be used to view the collection from the one 507 that was used to create it. Finally, it is needed in order for 508 servers to list collection members in order, as required by 3.2.6. 510 3.2.2 A collection is not required to be ordered. 512 A WebDAV server may support collections without supporting ordered 513 collections. Even if the server supports ordered collections, 514 there is no requirement that every collection on that server be 515 ordered. Since these requirements concern only client-maintained 516 orderings, clients will decide whether any given collection is 517 ordered. 519 The remaining requirements apply only to collections that are 520 ordered. 522 3.2.3 The semantics of an ordering are discoverable. 524 The semantics of an ordering is the principle or rule according to 525 which the collection members are ordered. This principle must be 526 discoverable if someone (or some application) other than the one 527 that created a collection is to be able to add a member to it and 528 determine where it makes sense to position the new member in the 529 collection's ordering. 531 In some cases it may be possible for the semantics to be expressed 532 in a machine-usable way, so that an application could automatically 533 position a new member in the ordering. In other cases the 534 semantics may require a human user to apply them. In either case 535 they should be discoverable. 537 3.2.4 Each collection member appears in the ordering exactly once. 539 It would be possible to support orderings that contain only a 540 subset of the collection members, or orderings that can contain 541 a single collection member more than once. It is not necessary, 542 however, since the same result can be achieved by creating a 543 new collection with exactly the desired members, and including 544 each member of the new collection in its ordering exactly once. 546 This requirement implies that the server will check, whenever a 547 member is added to an ordering, to make sure that it is not already 548 in the ordering. It also implies that either the protocol itself 549 or the server will insure that whenever a new member is added to 550 a collection, it is also added to the collection ordering. 552 3.2.5 An ordering does not include any resources that are not members 553 of the collection. 555 The server must insure that when a member is removed from a 556 collection, it is also removed from the collection's ordering. 558 3.2.6 When a client requests a listing of the members of a 559 collection, this listing is returned in the order specified by 560 the collection. 562 This requirement frees clients from the burden of applying the 563 ordering to the member listing. 565 3.2.7 It is possible to order the members of a collection in a 566 client-specified way, not necessarily based on property values. 568 Orderings that are based on property values can be obtained by a 569 search protocol that supports sorted result sets. This set of 570 requirements is not concerned with such orderings. It is intended 571 primarily to support orderings that cannot be obtained by sorting 572 on property values. 574 A property is not always available that can serve as the basis for 575 a desired ordering. For example, a professor may wish to order a 576 collection of course readings in the sequence that makes sense to 577 coordinate the readings with her lectures. But the properties of 578 resources at the Web site are standardized and do not include one 579 that is appropriate to use for this purpose. 581 Even if the professor in the example could create a 582 "sequencenumber" property to use in sorting the collection, this 583 strategy would be undesirable unless she knew she would not be 584 adding any readings or changing the order of her lectures once the 585 values of sequencenumber were set. Inserting a new reading into 586 the sequence would require updating the sequencenumber property of 587 each reading that comes after the new one in the sequence. Ordered 588 collections are intended to support this sort of case, where 589 sorting based on a property value is impossible or inefficient. 591 3.2.8 A single ordering may contain both ordinary and referential 592 resources. 594 The professor in the previous example may store some readings as 595 internal resources of the collection, but reference others from 596 servers at another university. Nevertheless, all the readings 597 need to be included in the ordering for her students� use. 599 4 Acknowledgements 601 This draft has benefited from thoughtful discussion by Alan Babich, 602 Steve Carter, Ellis Cohen, Spencer Dawkins, Rajiv Dulepet, 603 Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, 604 Rohit Khare, Daniel LaLiberte, Steve Martin, Surendra Koduru Reddy, 605 Sam Ruby, Nick Shelness, John Stracke, John Turner, Jim Whitehead, 606 and others. 608 5 References 610 [Goland et al., 1998] Y. Y. Goland, E. J. Whitehead, Jr., A. 611 Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed 612 Authoring on the World Wide Web - WebDAV." work in progress, 613 Draft-ietf-webdav-protocol-08. Microsoft, U.C. Irvine, Netscape, 614 Novell. April, 1998. 616 6 Authors' Addresses 618 J. Slein 619 Xerox Corporation 620 800 Phillips Road 621 Webster, NY 14580 622 Email: slein@wrc.xerox.com 624 J. Davis 625 Xerox Corporation 626 3333 Coyote Hill Road 627 Palo Alto, CA 94304 628 Email: jdavis@parc.xerox.com 630 Expires January 20, 1999