idnits 2.17.1 draft-whitehead-http-distreq-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 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 414 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance 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 (September 1996) is 10078 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1866 (ref. '2') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group E. J. Whitehead, Jr. 3 INTERNET-DRAFT U.C. Irvine 4 September 1996 6 Expires March, 1997 8 Requirements on HTTP for Distributed Content Editing 10 Status of this Memo 12 This document is an Internet draft. Internet drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas and 14 its working groups. Note that other groups may also distribute working 15 information as Internet drafts. 17 Internet Drafts are draft documents valid for a maximum of six months 18 and can be updated, replaced or obsoleted by other documents at any 19 time. It is inappropriate to use Internet drafts as reference material 20 or to cite them as other than as "work in progress". 22 To learn the current status of any Internet draft please check the 23 "lid-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). Further information about the IETF can be 27 found at URL: http://www.ietf.org/ 29 Distribution of this document is unlimited. Please send comments to the 30 WWW Distributed Authoring and Versioning mailing list, 31 , which may be joined by sending a message with 32 subject "subscribe" to . Discussions are 33 archived at URL: 34 http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/. The HTTP 35 working group at also discusses the HTTP 36 protocol. Discussions of the HTTP working group are archived at URL: 37 http://www.ics.uci.edu/pub/ietf/http/. General discussions about HTTP 38 and the applications which use HTTP should take place on the 39 mailing list. 41 Abstract 43 The HyperText Transfer Protocol, version 1.1 (HTTP/1.1), provides 44 simple support for applications which allow remote editing of typed 45 data. In practice, the existing capabilities of HTTP/1.1 have proven 46 inadequate to support efficient, scalable remote editing free of 47 overwriting conflicts. This document presents a list of features in 48 the form of requirements which, if implemented, would improve the 49 efficiency of common remote editing operations, provide a locking 50 mechanism to prevent overwrite conflicts, improve relationship 51 management support between non-HTML data types, provide a simple 52 attribute-value metadata facility, and provide for the creation and 53 reading of container data types. These requirements are also supportive 54 of versioning capability. 56 1. Introduction 58 This document describes functionality which, if provided in the 59 HyperText Transfer Protocol (HTTP) [4], would support the 60 interoperability of tools which allow remote loading, editing and 61 saving (publishing) of various media types using HTTP. As much as 62 possible, this functionality is described without suggesting a proposed 63 implementation, since there are many ways to perform the functionality 64 within the HTTP framework. It is also possible that a single mechanism 65 within HTTP could simultaneously satisfy several requirements. 67 Much of the functionality described in this document stems from the 68 assumption that people performing distributed authoring only have 69 access to the objects they are editing via the HTTP protocol. This is 70 in contrast to the majority of current authoring practice, where there 71 is access to the underlying storage media, often with a shell or 72 graphical user interface mediating access to a filesystem. Authors need 73 more than just remote control over their individual documents: they 74 need remote control over the namespace in which those documents 75 reside. Currently, authors control their namespace by interacting 76 directly with the underlying storage system, but when performing 77 distributed authoring this access is not available. 79 2. Requirements 81 In the requirement descriptions below, the requirement will be stated, 82 followed by its rationale. If any current distributed authoring tools 83 currently implement the requirement, this is also mentioned. It is 84 assumed that "server" means "a program which receives and responds to 85 HTTP requests," and that "distributed authoring tool" or "intranet 86 enabled tool" means "a program which can retrieve a source entity via 87 HTTP, allow editing of this entity, and then save/publish this entity 88 to a server using HTTP." A "client" is "a program which issues HTTP 89 requests and accepts responses." 91 1. Source Retrieval. The source of any given entity should be 92 retrievable via HTTP. 94 There are many cases where the source entity stored on a server 95 does not correspond to the actual entity transmitted in response 96 to an HTTP GET. Current known cases are server side include 97 directives, and Standard Generalized Markup Language (SGML) source 98 entities which are converted on the fly to HyperText Markup 99 Language (HTML) [2] output entities. There are many possible 100 cases, such as automatic conversion of bitmap images into several 101 variant bitmap media types (e.g. GIF, JPEG), and automatic 102 conversion of an application's native media type into HTML. As an 103 example of this last case, a word processor could store its native 104 media type on a server which automatically converts it to HTML. A 105 GET of this entity would retrieve the HTML. Retrieving the source 106 of this entity would retrieve the word processor native entity. 108 This requirement should be met by a general mechanism which can 109 handle both the "single-step" source processing described above, 110 where the source is converted into the transmission entity via a 111 single conversion step, as well as "multi-step" source processing, 112 where there are one or more intermediary processing steps and 113 outputs. An example of multi-step source processing is the 114 relationship between an executable binary image, its object files, 115 and its source language files. It should be noted that the 116 relationship between source and transmission entity could be 117 expressed using the relationship functionality described below in 118 "Relationships." 120 2. Relationships. Via HTTP, it should be possible to create, query, 121 and delete typed relationships between entities of any media type. 123 A hypertext link is a relationship between entities which is 124 browsable using a hypertext style point-and-click user 125 interface. Relationships, whether they are browsable hypertext 126 links, or simply a means of capturing a interrelation between 127 entities, have many purposes. Relationships can support 128 pushbutton printing of a multi-resource document in a prescribed 129 order, jumping to the access control page for an entity, and quick 130 browsing of related information, such as a table of contents, an 131 index, a glossary, help pages, etc. While relationship support is 132 provided by the HTML "LINK" element, this is limited only to HTML 133 entities, and does not support bitmap image types, and other 134 non-HTML media types. AOLpress from America Online [1] currently 135 "allows pages to add toolbar buttons on the fly using the HTML 3.2 136 tag. For example, your page can add toolbar buttons 137 that link to a home page, table of contents, index, glossary, 138 copyright page, next page, previous page, help page, higher level 139 page, or a bookmark in the document." 141 3. Write Locks. It should be possible, via HTTP, to restrict 142 modification of an entity to a specific person, or list of 143 persons. It should be possible to set single or multi-person write 144 locks with a single action. 145 4. Read Locks. It should be possible, via HTTP, to indicate to the 146 HTTP server that the contents of an entity should not be modified 147 until the read lock is released. It should be possible to assign a 148 read lock to a single person or a list of persons with a single 149 action. 150 5. Lock Query. It should be possible to query for whether a given URL 151 has any active modification restrictions, and if so, who currently 152 has modification permission. 153 6. Independence of locks. It should be possible to lock an entity 154 without re-reading the entity, and without committing to editing 155 an entity. 156 7. Multi-Entity Locking. It should be possible to take out a write or 157 read lock on multiple entities in the same action, and this 158 locking operation must be atomic across these entities. 159 8. Partial-Entity Locking. It should be possible to take out a write 160 or a read lock on subsections of an entity. 162 At present, HTTP provides limited support for preventing two or 163 more people from overwriting each other's modifications when they 164 save to a given URL. Furthermore, there is no way for people to 165 discover if someone else is currently making modifications to an 166 entity. This is known as the "lost update problem," or the 167 "overwrite problem." Since there can be significant cost 168 associated with discovering and repairing lost modifications, 169 preventing this problem is crucial for supporting distributed 170 authoring. A "write" lock ensures that only one person (or list of 171 persons) may modify an entity, preventing overwrites. 172 Furthermore, locking support is also a key component of many 173 versioning schemes, a desirable capability for distributed 174 authoring. 176 An author may wish to lock an entire web of entities even though 177 they are editing just a single entity, to keep the other entities 178 from changing. In this way, an author can ensure that if a local 179 hypertext web is consistent in their distributed authoring tool, 180 it will then be consistent when they write it to the 181 server. Because of this, it should be possible to take out a lock 182 without also causing transmission of the contents of an 183 entity. Since it should not be assumed that because an entity is 184 locked, that it will necessarily be modified, and since many 185 people may wish to have simultaneous guarantees that an entity 186 will not be modified, but still not want to modify the entity 187 themselves, it is desirable to have a "read" lock capability. A 188 read lock, by being less restrictive, provides better support than 189 a write lock for providing a guarantee that an entity will not be 190 modified. Put differently, a read lock states that the entity is 191 guaranteed not to change for the duration of the lock. A write 192 lock states that an entity is guaranteed not to change only if the 193 owner of the lock does not change it, and only the owner of the 194 lock may change it. 196 It is often necessary to guarantee that a lock or unlock operation 197 occurs at the same time across multiple entities, a feature which 198 is supported by the multiple-entity locking requirement. This is 199 useful for preventing a collision between two people trying to 200 establish locks on the same set of entities, since with 201 multi-entity locking, one of the two people will get a lock. If 202 this same multiple-entity locking scenario was repeated by using 203 atomic lock operations iterated across the entities, the result 204 would be a splitting of the locks between the two people, based on 205 entity ordering and race conditions. 207 Partial entity locking provides support for collaborative editing 208 applications, where multiple users may be editing the same entity 209 simultaneously. Partial entity locking also allows multiple people 210 to simultaneously work on a database type entity. 212 9. Notification of Intention to Edit. It should be possible to notify 213 the HTTP server that an entity is about to be edited by a given 214 person. It should be possible to query the HTTP server for the 215 list of people who have notified the server of their intent to 216 edit an entity. 218 Experience from configuration management systems has shown that 219 people need to know when they are about to enter a parallel 220 editing situation. Once notified, they either decide not to edit 221 in parallel with the other authors, or they use out-of-band 222 communication (face-to-face, telephone, etc.) to coordinate their 223 editing to minimize the difficulty of merging their 224 results. Notification is separate from locking, since a write lock 225 does not necessarily imply an entity will be edited, and a 226 notification of intention to edit does not carry with it any 227 access restrictions. This capability is supportive of versioning, 228 since a check-out is typically involves taking out a write lock, 229 making a notification of intention to edit, and getting the entity 230 to be edited. 232 10. Partial Write. After editing an entity, it should be possible, via 233 HTTP, to only write the changes to an entity, rather than 234 retransmitting the entire entity. 236 During distributed editing which occurs over wide geographic 237 separations and/or over low bandwidth connections, it would be 238 extremely inefficient (and frustrating) to rewrite a large entity 239 after minor changes, such as a one-character spelling 240 correction. Ideally, support will be provided for transmitting 241 "insert" (e.g., add this sentence in the middle of a document) and 242 "delete" (e.g. remove this paragraph from the middle of a 243 document) style updates. Support for partial entity updates will 244 make small edits more efficient, and allow distributed authoring 245 tools to scale up for editing of large documents. 247 11. Attributes. Via HTTP, it should be possible to create, modify, 248 query, read and delete arbitrary attributes on entities of any 249 media type. 251 Attributes can be used to define fields such as author, title, 252 subject, and organization, on resources of any media type. These 253 attributes have many uses, such as supporting searches on 254 attribute contents, and the creation of catalog entries as a 255 placeholder for an entity which is not available in electronic 256 form, or which will be available later. 258 12. List URL Hierarchy Level. A listing of all entities, along with 259 their media type, and last modified date, which are located at a 260 specific URL [3] hierarchy level in an http URL scheme should be 261 accessible via HTTP, so long as this operation is meaningful. 263 In [3] it states that, "some URL schemes (such as the ftp, http, 264 and file schemes) contain names that can be considered 265 hierarchical." Especially for HTTP servers which directly map all 266 or part of their URL name space into a filesystem, it is very 267 useful to get a listing of all resources located at a particular 268 hierarchy level. This functionality supports "Save As..." dialog 269 boxes, which provide a listing of the entities at a current 270 hierarchy level, and allow navigation through the hierarchy. It 271 also supports the creation of graphical visualizations (typically 272 as a network) of the hypertext structure among the entities at a 273 hierarchy level, or set of levels. It also supports a tree 274 visualization of the entities and their hierarchy levels. 276 There are many instances where there is not a strong correlation 277 between a URL hierarchy level and the notion of a container. One 278 example is a server in which the URL hierarchy level maps to a 279 computational process which performs some resolution on the 280 name. In this case, the contents of the URL hierarchy level can 281 vary depending on the input to the computation, and the number of 282 entities accessible via the computation can be very large. It does 283 not make sense to implement a directory feature for such a 284 namespace. However, the utility of listing the contents of those 285 URL hierarchy levels which do correspond to containers, such as 286 the large number of HTTP servers which map their namespace to a 287 filesystem, argue for the inclusion of this capability, despite 288 not being meaningful in all cases. If listing the contents of a 289 URL hierarchy level does not makes sense for a particular URL, 290 then a "405 Method Not Allowed" status code could be issued. 292 AOLpress from America Online currently supports "Save As..." 293 dialog boxes, and graphical network visualization of a portion of 294 a site's hypertext structure, which they term a "mini-web." 295 FrontPage from Microsoft [5] also currently supports a graphical 296 network visualization and additionally supports a tree 297 visualization of a portion of a site's structure. 299 13. Make URL Hierarchy Level. Via HTTP, it should be possible to 300 create a new URL hierarchy level in an http URL scheme. 302 The ability to create containers to hold related entities supports 303 management of a name space by packaging its members into small, 304 related clusters. The utility of this capability is demonstrated 305 by the broad implementation of directories in recent operating 306 systems. The ability to create a URL hierarchy level also supports 307 the creation of "Save As..." dialog boxes with "New 308 Level/Folder/Directory" capability, common in many applications. 309 AOLpress from America Online, currently supports this capability 310 through their "Save As..." dialog box, and their custom MKDIR 311 method. 313 14. Copy. Via HTTP, it should be possible to make a byte-for-byte 314 duplicate of an entity without a client loading, then resaving the 315 entity. This copy should leave an audit trail. 317 There are many reasons why an entity might need to be duplicated, 318 such as change of ownership, a precursor to major modifications, 319 or to make a backup. In combination with delete functionality, 320 copy can be used to implement rename and move capabilities, by 321 performing a copy to a new name, and a delete of the old name. Due 322 to network costs associated with loading and saving an entity, it 323 is far preferable to have a server perform an entity copy than a 324 client. If a copied entity records which entity it is a copy of, 325 then it would be possible for a cache to avoid loading the copied 326 entity if it already locally stores the original. 328 15. Move/Rename. Via HTTP, it should be possible to change the URL of an 329 entity without a client loading, then resaving the entity under a 330 different name. 332 It is often necessary to change the name of an entity, for example 333 due to adoption of a new naming convention, or if a typing error 334 was made entering the name originally. Due to network costs, it is 335 undesirable to perform this operation by loading, then resaving 336 the entity, followed by a delete of the old entity. Similarly, a 337 single rename operation is more efficient than a copy followed by 338 a delete operation. Ideally an HTTP server should record the move 339 operation, and issue a "301 Moved Permanently" status code for 340 requests on the old URL. A move operation, if implemented with 341 attribute support, should also preserve most attributes across a 342 move. Note that moving an entity is considered the same function 343 as renaming an entity. 345 3. Acknowledgements 347 My understanding of these issues has emerged as the result of much 348 thoughtful discussion, email, and assistance by many people, who 349 deserve recognition for their effort. 351 Martin Cagan, Continuus Software, Marty_Cagan@continuus.com 352 Dan Connolly, World Wide Web Consortium, connolly@w3.org 353 David Durand, Boston University, dgd@cs.bu.edu 354 Ron Fein, Microsoft, ronfe@microsoft.com 355 David Fiander, Mortice Kern Systems, davidf@mks.com 356 Roy Fielding, U.C. Irvine, fielding@ics.uci.edu 357 Yaron Goland, Microsoft, yarong@microsoft.com 358 Phill Hallam-Baker, MIT, hallam@ai.mit.edu 359 Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com 360 Andre van der Hoek, University of Colorado, Boulder, 361 andre@bigtime.cs.colorado.edu 362 Gail Kaiser, Columbia University, kaiser@cs.columbia.edu 363 Rohit Khare, World Wide Web Consortium, khare@w3.org 364 Dave Long, America Online, dave@sb.aol.com 365 Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org 366 Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com 367 Larry Masinter, Xerox PARC, masinter@parc.xerox.com 368 Murray Maloney, SoftQuad, murray@sq.com 369 Jim Miller, World Wide Web Consortium, jmiller@w3.org 370 Andrew Schulert, Microsoft, andyschu@microsoft.com 371 Christopher Seiwald, Perforce Software, seiwald@perforce.com 372 Judith Slein, Xerox, slein@wrc.xeroc.com 373 Richard Taylor, U.C. Irvine, taylor@ics.uci.edu 374 Robert Thau, MIT, rst@ai.mit.edu 375 Fabio Vitali, University of Bologna, Italy, fabio@dm.unibo.it 377 4. References 379 [1] America Online, "AOL Web Tools -- AOLpress 1.2 Features." WWW page. 380 http://www.aolpress.com/press/1.2features.html. 382 [2] T. Berners-Lee, D. Connolly. "HyperText Markup Language 383 Specification - 2.0." RFC 1866, MIT/LCS, November 1995. 385 [3] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource 386 Locators (URL)." RFC 1738, CERN, Xerox PARC, University of Minnesota, 387 December 1994. 389 [4] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 390 T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1." RFC XXXX, 391 U.C. Irvine, DEC, MIT/LCS, August 1996. 393 [5] Microsoft. "Microsoft FrontPage for Windows Data Sheet." WWW page. 394 http://www.microsoft.com/msoffice/frontpage/productinfo/brochure/ 395 default.htm. 397 Author's Address 399 E. James Whitehead, Jr. 400 Department of Information and Computer Science 401 University of California 402 Irvine, CA 92697-3425 404 Fax: 714-824-4056 405 EMail: ejw@ics.uci.edu