idnits 2.17.1 draft-ietf-webdav-collection-reqts-05.txt: -(156): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(327): 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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 3 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 8 longer pages, the longest (page 1) being 63 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 101 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([WebDAV]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 18, 1999) is 8895 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) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2518 (ref. 'WebDAV') (Obsoleted by RFC 4918) 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 2 INTERNET DRAFT J. Davis, CourseNet 3 June 18, 1999 4 Expires December 18, 1999 6 Requirements for Advanced Collection Functionality in WebDAV 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), 13 its areas, and its working groups. Note that other groups may 14 also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this document is unlimited. Please send comments 29 to the Distributed Authoring and Versioning (WebDAV) working 30 group at , which may be joined by sending a 31 message with subject "subscribe" to . 33 Discussions of the WEBDAV working group are archived at URL: 34 . 36 Abstract 38 The WebDAV Distributed Authoring Protocol [WebDAV] provides basic 39 support for collections, offering the ability to create and list 40 unordered collections. Many applications, however, need more 41 powerful collections, especially for resource sharing and 42 collection ordering. 44 This draft sets out requirements for more advanced, optional 45 collection functionality. It extends the base functionality in the 46 two directions of resource sharing and collection ordering. A 47 separate WebDAV specification is expected to define protocol 48 elements providing the functionality described here. 50 1 Terminology 52 The terminology used here follows and extends that in the WebDAV 53 Distributed Authoring Protocol specification [WebDAV]. Definitions 54 of the terms resource, Uniform Resource Identifier (URI), and 55 Uniform Resource Locator (URL) are provided in [URI]. 57 Association 58 A direct or indirect connection between a resource and a 59 namespace element to support resource sharing. Bindings, URI 60 mappings, and redirect references are types of associations. 62 URI Mapping 63 An association between an absolute URL or URI and a resource. 64 Since a resource can represent items that are not network 65 retrievable, as well as those that are, it is possible for a 66 resource to have zero, one, or many URI mappings to URLs or 67 URIs. Mapping a resource to an "http" scheme URL makes it 68 possible to submit HTTP protocol requests to the resource using 69 the URL. 71 Path Segment 72 Informally, the characters found between slashes ("/") in a URL 73 or URI. Formally, as defined in section 3.3 of [URI]. 75 Binding 76 An association between a single path segment (in a collection) 77 and a resource. A binding creates one or more URI mappings, and 78 hence is a mechanism for resource sharing, allowing a single 79 resource to be accessed from multiple locations in a URI 80 namespace. 82 Collection 83 A resource that contains, as part of its state, a set of 84 bindings which identify member resources. 86 Internal Member URI 87 The URI mapping, created by a binding, that is a member of a 88 collection. While, in general, bindings can create multiple 89 URI mappings to a resource, for a given request, only one of 90 these URI mappings is referred to as the internal member. The 91 URI of the parent collection used in a given request determines 92 the base URI for internal member URI calculation. 94 2 Introduction and Rationale 96 The simple collections that the WebDAV Distributed Authoring 97 Protocol specification supports are powerful enough to be widely 98 useful. They provide for the hierarchical organization of 99 resources, with mechanisms for creating and deleting collections, 100 copying and moving them, locking them, adding resources to them 101 and deleting resources from them, and getting listings of their 102 members. Delete, copy, move, list, and lock operations can be 103 applied recursively, so that a client can operate on whole 104 hierarchies with a single request. 106 Many applications, however, need more powerful collections. There 107 are two areas in particular where more powerful functionality is 108 often needed: shared resources and ordering. This draft details 109 the additional functionality that is needed in these two areas. 111 In both areas, it should be a goal of the protocol specification 112 to be compatible with HTTP 1.1 and with the WebDAV Distributed 113 Authoring Protocol. It should be a goal that down-level clients 114 be able to take advantage of any new constructs, even if they 115 cannot create and manipulate them. It should be a goal that the 116 new functionality be relatively simple to implement, both for 117 clients and for servers. It should be a goal that the new 118 constructs satisfy the infrastructure needs of other WebDAV 119 facilities, particularly the current work on versioning and 120 configuration management. 122 2.1 Shared Resources 124 Associations make it possible for many collections, on the 125 same or different servers, to share the same resource. Only one 126 physical copy of the resource need exist, and any changes made in 127 the resource are visible from all the collections that share it. 129 A number of scenarios motivate adding associations to the 130 functionality of WebDAV: 132 Organizing resources into hierarchies places them into collections, 133 which are more easily browsed and manipulated than a flat 134 namespace. However, hierarchies require categorization decisions 135 that locate resources at a single location in the hierarchy, a 136 drawback when a resource has multiple valid categories. For 137 example, in a hierarchy of vehicle descriptions containing 138 collections for cars and boats, a description of a combination 139 car/boat vehicle could belong in either collection. Ideally, the 140 description should be accessible from both. 142 Sharing between collections on different servers may be desired. 143 For example, the mathematics department at one university may wish 144 to create a collection of information on fractals that contains 145 some local resources, but also provides access to resources at 146 several other universities. For many reasons, it may be 147 undesirable to make physical copies of the shared resources on the 148 local server - to conserve disk space, to respect copyright 149 constraints, or to make any changes in the shared resources visible 150 automatically. 152 In another scenario, a manufacturing company develops and maintains 153 its product maintenance manuals on the Web. There is a separate 154 collection for each product manual. Each manual is divided into 155 sections, one section for every product component. Since many of 156 the company�s products contain some of the same components, many of 157 the product maintenance manuals have sections in common. Each 158 manual may have some unique sections, but for product components 159 that are common to multiple products, the manual's collection 160 accesses a resource in a shared library. 162 These requirements do not address issues of the integrity of 163 associations, though integrity will be of great importance to 164 some applications. Some applications cannot tolerate broken links. 165 A software development application, for example, must be able to 166 rely on the integrity of references to component modules. Other 167 applications may want integrity not to be enforced. For example, 168 a Web site manager might want to be able to create access paths 169 before the resources are created for which they will provide 170 access, or might want to be able to remove content temporarily 171 without deleting and later recreating the associations to the 172 content. Addressing these concerns is considered too difficult 173 for the planned protocol specification, however. Consequently, 174 they are not included in this set of requirements. 176 2.2 Ordered Collections 178 For many applications, it is useful for clients to be able to 179 impose orderings on collections at the server. When the server 180 receives a request for a list of a collection's members, it always 181 responds with a list ordered according to the ordering specified 182 for that collection. In the product manual application above, the 183 sections of each manual may be ordered so that they can be printed 184 together as a book. A configuration management application might 185 use a collection to represent a version series, in which case the 186 "derives from" relationship might be represented as an ordering on 187 the collection. 189 A collection ordering may sometimes be based on property values. 190 An example of such an ordering is one that is alphabetical by 191 author�s last name, or one from most recent to oldest last- 192 modified-date. An ordering need not be based on property values, 193 however. A professor may order a collection of course readings in 194 the sequence that makes sense to coordinate them with her lectures, 195 where there is no property on the member resources that could be 196 used to create this ordering. This set of requirements is 197 primarily concerned with orderings that are not based on property 198 values. The rationale for this emphasis is that property-based 199 orderings can be obtained, even if inefficiently, using the planned 200 search facility being developed by the DAV Searching and Locating 201 working group. But there is no other planned WebDAV facility that 202 could provide orderings that are not based on property values. 204 Another useful distinction is between server-maintained and 205 client-maintained orderings. For server-maintained orderings, the 206 server enforces the semantics of the ordering by placing each 207 collection member at the appropriate position in the ordering; 208 clients cannot alter the position of any collection mamber in the 209 ordering. In client-maintained orderings, the client places each 210 collection member in the ordering based on its understanding of the 211 semantics of the ordering; the server does nothing to validate the 212 client's positioning of the member in the ordering. These 213 requirements address both client-maintained and server-maintained 214 orderings. 216 WebDAV already provides tools that could be used for creating and 217 maintaining ordered collections. For example, using only the base 218 WebDAV specification, an application could create a WebDAV property 219 called "Order" on a collection resource. The value of this 220 property might be a list of the collection's member URIs. 222 What the base WebDAV specification does not do is standardize a 223 single way to represent orderings for collections. 225 Different applications and services should be able to operate on 226 the same collection without private agreements about how to manage 227 and examine its order. To make this possible, there needs to be a 228 standard way to manipulate and retrieve the order of a collection, 229 and a standard representation of the ordering. 231 In any situation where collaborative management of a collection 232 takes place, and different authoring tools or WebDAV servers might 233 be used by the collaborators, standardization is important. It is 234 also important where a different tool may be used to view the 235 collection from the one that was used to create it. 237 So for example, two users from different organizations, using 238 different authoring tools, are working together to create a 239 collection. One of the tools uses a property on the collection 240 called "Order" to store an ordering of the collection. The other 241 tool uses a property called "SequenceNumber" on the resources 242 identified by the collection's member URIs. If each user adds some 243 members to the collection, there will be no reliable ordering. 245 3 Requirements 247 3.1 Shared Resources 249 3.1.1 A single target resource may be accessed through more than 250 one association. 252 This is the primary benefit that associations bring. They allow 253 resources to be accessed using alternative Request-URIs, and so 254 allow them to be shared by multiple collections, on the same or 255 different servers. 257 3.1.2 It is possible for clients to create additional associations 258 that provide access to an existing resource. 260 It has always been possible for Web server administrators to create 261 alternative paths to the same resource. However, clients have not 262 had the ability to do this. Giving clients the ability to create 263 associations makes it possible for them to create collections that 264 share the same resources. For several scenarios motivating this 265 requirement, see Section 2.1 above. 267 3.1.3 It is possible to create cross-server associations. 269 It is often desirable to share provide access from a collection 270 on one server to a resource that resides on another server. For 271 many reasons, it may be undesirable to make a physical copy of the 272 shared resource on the local server - to conserve disk space, to 273 respect copyright constraints, or to make any changes in the 274 shared resources visible automatically. 276 3.1.4 It is possible for a client to delete an association. 278 It is important to note that this is a different operation from 279 deleting the resource to which the association provides access. 280 It must be possible to delete one association without affecting 281 the ability to access the same resource through other associations. 283 3.1.5 For any resource, it is possible to request a list of 284 the associations that provide access to it. 286 This allows clients to discover what collections share the 287 resource, thus allowing end users to navigate upward from a 288 resource through all the collections that provide access to 289 it. They can use this facility to locate other related 290 resources and to understand the contexts in which the resource 291 is being used. 293 3.1.6 A down-level HTTP 1.1 or WebDAV client is 294 able to use an association to access its target resource. 296 This minimal level of compatibility with older clients is needed 297 to make deployment of WebDAV collection functionality feasible. 298 Although new clients may be needed to create and manipulate 299 associations, older clients should be able to read and 300 make use of the collections built using these associations. 302 3.1.8 There is no requirement that associations be acyclic. 304 It is particularly problematic to require detection of cycles when 305 associations cross server boundaries, but even on a single server 306 it may be too burdensome to require detection of cycles when 307 associations are created. In addition, there may be 308 applications where cyclic references are desirable. 310 3.1.9 There may be multiple associations from the same collection 311 to a given resource. 313 It is often useful to allow the same resource to be used in one 314 collection multiple times. Typically, these are cases where the 315 collection is ordered. Consider a case where a collection 316 represents a book, with one internal member URI for each page in 317 the book. A particular graphic needs to appear in several places 318 in the book, and so there need to be multiple internal member URIs 319 in the collection pointing to that graphic. 321 3.2 Ordered Collections 323 3.2.1 Ordering is sufficiently standardized that different 324 applications and servers can operate on the same ordering 325 without private agreements. 327 Applications and servers can apply an ordering to a collection�s 328 members or discover the ordering of a collection's members without 329 private agreements. They can also modify an ordering, at least 330 with the help of a human user for semantics (See 3.2.3), without 331 private agreements. 333 This is the minimum that is needed to support collaborative 334 management of an ordered collection, where different authoring 335 tools might be used by the collaborators. It is also what allows 336 a different tool to be used to view the collection from the one 337 that was used to create it. Finally, it is needed in order for 338 servers to list collection members in order, as required by 3.2.6. 340 3.2.2 A collection is not required to be ordered. 342 A WebDAV server may support collections without supporting ordered 343 collections. Even if the server supports ordered collections, 344 there is no requirement that every collection on that server be 345 ordered. Clients decide whether any given collection is 346 ordered. 348 The remaining requirements apply only to collections that are 349 ordered. 351 3.2.3 The semantics of an ordering are discoverable. 353 The semantics of an ordering define the principle or rule according 354 to which the collection members are ordered. This principle must 355 be discoverable if someone (or some application) other than the one 356 that created a collection is to be able to add a member to it and 357 determine where it makes sense to position the new member in the 358 collection's ordering. 360 In some cases it may be possible for the semantics to be expressed 361 in a machine-usable way, so that an application could automatically 362 position a new member in the ordering. In other cases the 363 semantics may require a human user to apply them. In either case 364 they should be discoverable. 366 3.2.4 Each collection member appears in the ordering exactly once. 368 It would be possible to support orderings that contain only a 369 subset of the collection members, or orderings that can contain 370 a single collection member more than once. It is not necessary, 371 however, since the same result can be achieved by creating a 372 new collection with exactly the desired members, and including 373 each member of the new collection in its ordering exactly once. 375 This requirement implies that the server will check, whenever a 376 member is added to an ordering, to make sure that it is not already 377 in the ordering. It also implies that either the protocol itself 378 or the server will insure that whenever a new member is added to 379 a collection, it is also added to the collection ordering. 381 3.2.5 An ordering does not include any resources that are not members 382 of the collection. 384 The server must insure that when a member is removed from a 385 collection, it is also removed from the collection's ordering. 387 3.2.6 When a client requests a listing of the members of a 388 collection, this listing is returned in the order specified by 389 the collection. 391 This requirement frees clients from the burden of applying the 392 ordering to the member listing. It also insures that whatever 393 client retrieves the collection listing, the listing will appear 394 in the same order. (An application using the listing can, of 395 course, re-order it on the client side for its own purposes.) 397 3.2.7 It is possible to order the members of a collection in a 398 client-specified way, not necessarily based on property values. 400 Orderings that are based on property values can be obtained by a 401 search protocol that supports sorted result sets. This set of 402 requirements is not concerned with such orderings. It is intended 403 primarily to support orderings that cannot be obtained by sorting 404 on property values. 406 A property is not always available that can serve as the basis for 407 a desired ordering. For example, a professor may wish to order a 408 collection of course readings in the sequence that coordinates the 409 readings with her lectures. But the properties of resources at the 410 Web site are standardized and do not include one that is 411 appropriate to use for this purpose. 413 Even if the professor in the example could create a 414 "sequencenumber" property to use in sorting the collection, this 415 strategy would be undesirable unless she knew she would not be 416 adding any readings or changing the order of her lectures once the 417 values of sequencenumber were set. Inserting a new reading into 418 the sequence would require updating the sequencenumber property of 419 each reading that comes after the new one in the sequence. Ordered 420 collections are intended to support this sort of case, where 421 sorting based on a property value is impossible or inefficient. 423 3.2.8 It is possible for clients to discover available 424 server-maintained orderings and to request that one of those 425 orderings be used for a collection. 427 Servers may wish to make available some set of server-maintained 428 orderings, and allow clients to choose which of them is applied 429 to a given collection. These orderings are likely to be based on 430 properties of the resources in a collection. For example, a server 431 might allow resources in collections to be ordered alphabetically 432 by author, alphabetically by title, or from most recent to earliest 433 publication date. In order for clients to take advantage of these 434 orderings, some way must be provided for them to discover what 435 server-maintained orderings are available and to select one to be 436 applied to a given collection. 438 4 Acknowledgements 440 This draft has benefited from thoughtful discussion by Jim Amsden, 441 Alan Babich, Steve Carter, Geoffrey Clemm, Ken Coar, Ellis Cohen, 442 Bruce Cragun, Spencer Dawkins, Rajiv Dulepet, David Durand, 443 Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, 444 Marcus Jager, Chris Kaler, Manoj Karichainula, Rohit Khare, 445 Daniel LaLiberte, Steve Martin, Surendra Koduru Reddy, Sam Ruby, 446 Nick Shelness, John Stracke, John Turner, Jim Whitehead, and 447 others. 449 5 References 451 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 452 Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, 453 Xerox. August, 1998. 455 [WebDAV] Y. Y. Goland, E. J. Whitehead Jr., A. Faizi, 456 S. R. Carter, D. Jensen, "HTTP Extensions for Distributed 457 Authoring - WebDAV." RFC 2518. Microsoft, U.C. Irvine, Netscape, 458 Novell. February, 1999. 460 6 Authors' Addresses 462 J. Slein 463 Xerox Corporation 464 800 Phillips Road 465 Webster, NY 14580 466 Email: jslein@crt.xerox.com 468 J. Davis 469 CourseNet Systems 470 170 Capp Street 471 San Francisco, CA 94110 472 Email: jrd3@alum.mit.edu 474 Expires December 18, 1999