idnits 2.17.1 draft-ota-http-version-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-26) 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. == Mismatching filename: the document gives the document name as 'draft-ntt-http-version-00', but the file name used is 'draft-ota-http-version-00' == 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 330 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 190 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 06, 1996) is 10033 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: '2' is defined on line 300, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 304, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft K. Ota, NTT 2 K. Takahashi, NTT 3 K. Sekiya, NTT Software 4 Expires May 1997 November 06, 1996 6 Version management with meta-level links via HTTP/1.1 8 Status of 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 obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. Please send comments 28 to Kenji Ota, NTT (ota@nttlabs.com), Kenji Takahashi 29 (kt@nttlabs.com), or Kazuchika Sekiya (sekiya@ntts.com). 31 Abstract 33 This draft describes version management of the resources with 34 some extensions to HTTP/1.1. 35 The main point of our approach is to use meta-level links, 36 which is not an anchor of HTML format, but an attribute of the 37 resource. So, the contents need not to be an HTML format. 39 1. Introduction 41 Conventionally, most resources are linked each other with 42 links described in HTML files. This mechanism is not useful in 43 version management, because HTML files have to be edited in 44 order to manipulate the links between the versions of a 45 resource. 47 This document describes a mechanism for version management of 48 resources, which uses meta-level links. A meta-level link 49 relates two resources outside the contents of resources. So, 50 the contents need not to be an HTML format. 52 This document also describes the classification of the 53 PUT method. It is used for the server to distinguish between 54 normal resources and versioned resources. 56 The locking mechanism is also described. It prevents multiple 57 clients from editing the same resource at one time. So, our 58 policy of locking is similar to RCS. 60 2. Meta-level links 62 A meta-level link, that is meta-information of resources, 63 relates two resources outside the contents of resources. 64 It is independent from the contents of resource. So, the 65 content of the resource needs not to be HTML format. 66 The draft specification of HTTP/1.1[1] specifies "Link:" 67 header field in the appendices chapter. 69 The LINK and UNLINK methods manipulate the meta-level links. These 70 methods are also specified in the appendices chapter of 71 HTTP/1.1 specification. 73 If the GET or HEAD request sends to the server, the server 74 returns the "Link:" header in the response. 75 If the PUT request sends to the server with the "Link:" 76 header, the server establishes the links between the 77 resource specified by Request-URI and resources specified in 78 the "Link:" header. 80 The meta-level links can be used to manage the versions of the 81 resources. The chapter 5 describes details of version 82 management using this meta-level links. The meta-level links 83 themselves are so generic as to used for other purposes than 84 version management. For example, annotations to some web 85 contents can be linked by using this. 87 3. Locking mechanism 89 We propose LOCK/UNLOCK method for locking a resource. 90 Locking a resource means that the server excludes the other 91 requests for update to the same resource, in order to 92 make sure that only one user can update a resource while the 93 resource being locked. 94 We also propose "X-Lock:" header field. 96 It is assumed that the client and the server have some 97 authentication functions. This document does not refer to it. 99 3.1. LOCK/UNLOCK 101 The LOCK method requests that the server lock the 102 resource identified by the Request-URI. 104 The UNLOCK method requests that the server cancel the 105 lock status of the resource identified by the 106 Request-URI. 108 Only the user who has locked a resource can request PUT, POST, 109 LOCK or UNLOCK to it. Any users, however, can always request 110 GET, HEAD and LINK. 112 3.2. X-Lock: header field 114 The "X-Lock:" is a header in the server response that 115 represents the information about locking status of a requested 116 resource. 117 When the client sends a GET, HEAD or LOCK request to the 118 locked resource, the server returns the response including 119 the "X-Lock:" header. Then, the client can show the 120 information to the users. The followings are BNF and an 121 example of this header. 123 X-Lock = "X-Lock" ":" "user=" user_name ";" "date=" HTTP-date 124 user_name = 1*8(ALPHA | DIGIT) 126 ex. 127 X-Lock: user="sekiya"; date="Thu, 15 Feb 1996 23:44:20 GMT" 129 4. Creation and modification of web resources via HTTP 131 4.1. "X-PUT-Class" header field 133 We propose "X-PUT-Class" header field for the PUT method. 134 It specifies a type of a resource when the resource is 135 created. The server decides how to handle to the resource 136 according to the value of its field. The strings of "File", 137 "Mkdir" or "VersionedFile" are allowed as its value. The value 138 of the header field is stored as an attribute of the resource. 139 BNF is as follows, 141 PUT-Class = "X-PUT-Class" : PUT_type 142 PUT_type = ("File" | "Mkdir" | "VersionedFile") 144 The meaning of each values is as follows. 146 - "File" 147 The resource specified by the Request-URI is created 148 as a normal file. The PUT request to this type of 149 resource requests that the server overwrite the 150 contents with the new entity. 151 - "VersionedFile" 152 The resource specified by the Request-URI is created 153 as a versioned file. The PUT request to this type of 154 an existing resource means that the server creates a 155 new version of resource with the received entity. 156 - "Mkdir" 157 The resource specified by the Request-URI is created 158 as an identifier of a collection of resources, such a 159 directory, that manages the name for some resources 160 under it. 162 5. Versioning 164 We have decided our naming scheme based on the following: 166 (1) accessibility from existing browsers (e.g. Netscape) 167 (2) easy manipulation in existing directory-based file systems 168 (e.g. UNIX file system) 169 (3) ability of representing "composite" versions 170 (e.g. version 2 of composite resource that consists of 171 version 5 of X, a component resource, and version 3 of 172 Y, another component resource) 174 5.1. Naming Scheme 176 A series of versions of a resource is identified by a unique 177 directory name in a file system as a "representative" 178 URL. Each version of a resource is placed under the directory 179 and represented as follows: 181 representative_URL "/" version_number 183 For example, version 3 of 184 "http://www.nttlabs.com/project1/x.html" is represented as 185 follows: 187 http://www.nttlabs.com/project1/x.html/3 189 The latest version is referred by the representative URL and 190 specific version can be referred by the representative URL + 191 "/version_number". (Figure 1.) 192 In this way, users can access any version by existing 193 browsers and easily manipulate it in existing file systems. 195 5.2. Versioning by using Link mechanism 197 Each time a version of a resource has been revised, a new 198 version is created and given a new URL based on the naming 199 scheme described above. In the same time, the original and 200 new versions are linked bidirectionally with meta-level links. 201 A link named "new" is established from the original to new 202 versions and a link named "old" is established from the new to 203 original versions. 205 For example, Figure 1. illustrates links between 206 versions of a resource (http://host/some/resource). 208 http://host/some/resource --------+ 209 | 210 ------------------------------------------------- | -------- 211 | 212 V 214 /1 /2 /3 /4 215 +----------+ +----------+ +----------+ +----------+ 216 |+--------+| |+--------+| |+--------+| |+--------+| 217 || new ||-->|| new ||-->|| new ||-->|| new || 218 || ||<--|| old ||<--|| old ||<--|| old || 219 |+--------+| |+--------+| |+--------+| |+--------+| 220 |+--------+| |+--------+| |+--------+| |+--------+| 221 || || || || || || || || 222 || || || || || || || || 223 || || || || || || || || 224 |+--------+| |+--------+| |+--------+| |+--------+| 225 +----------+ +----------+ +----------+ +----------+ 226 latest version 228 Figure 1. Links between versions of a resource 230 A particular version of a resource can be transmitted via 231 HTTP by specified by the "Content-Version:" field of HTTP 232 headers, or according to the naming scheme when using existing 233 clients. The following is an example of two type of 234 specifying some version of a certain resource. 236 http://www.nttlabs.com/project1/x.html/3 237 or 238 http://www.nttlabs.com/project1/x.html 239 Content-Version: "3" 241 5.3. Examples of HTTP interactions 243 5.3.1. Create a new resource 245 [request] 246 PUT http://server/path/resource 247 X-PUT-Class: VersionedFile 248 (contents of initial version) 250 [response] 251 201 Created 252 http://server/path/resource 253 Content-Version: "1" 255 5.3.2. Retrieve latest version 257 [request] 258 GET http://server/path/resource 259 (Retreive the latest version automatically) 261 [response] 262 200 OK 263 Content-Version: "5" 264 Link: ; rel="old" 265 (contents of version 5) 267 5.3.3. Retrieve a particular version 269 [request] 270 GET http://server/path/resource 271 Content-Version: "3" 273 or 274 GET http://server/path/resource/3 276 [response] 277 200 OK 278 Content-Version: "3" 279 Link: ; rel="old" 280 Link: ; rel="new" 281 (contents of version 3) 283 5.3.4. Update an existing (versioned) resource 285 [request] 286 PUT http://server/path/resource 287 (changed contents) 289 [response] 290 201 Created 291 (Resource for new version are created, and establish 292 links between created version and its new/old version) 294 References 296 [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk and T. Berners-Lee, 297 "Hypertext Transfer Protocol -- HTTP/1.1," 298 Internet Draft, Work in Progress, August 1996 300 [2] E. J. Whitehead, Jr., 301 "Requirements on HTTP for Distributed Content Editing," 302 Internet Draft, Work in Progress, September 1996 304 [3] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource 305 Locators (URL)." RFC 1738, CERN, Xerox PARC, University of 306 Minnesota, December 1994. 308 Author Address 310 Kenji Ota 311 NTT Software Laboratories 312 250 Cambridge Avenue, #205 313 Palo Alto, CA 94306, USA 314 Email: ota@nttlabs.com 316 Kenji Takahashi 317 NTT Multimedia Communications Laboratories 318 250 Cambridge Avenue, #205 319 Palo Alto, CA 94306, USA 320 Email: kt@nttlabs.com 322 Kazuchika Sekiya 323 NTT Software Corporation 324 250 Cambridge Avenue, #205 325 Palo Alto, CA 94306, USA 326 Email: sekiya@ntts.com