home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-ota-http-version-00.txt < prev    next >
Text File  |  1996-11-06  |  11KB  |  331 lines
  1.  
  2. Internet Draft                               K. Ota, NTT
  3. <draft-ntt-http-version-00>                          K. Takahashi, NTT
  4.                                                K. Sekiya, NTT Software
  5. Expires May 1997                                     November 06, 1996
  6.  
  7.  
  8.     Version management with meta-level links via HTTP/1.1
  9.  
  10. Status of Memo
  11.  
  12.      This document is an Internet-Draft.  Internet-Drafts are working
  13.      documents of the Internet Engineering Task Force (IETF), its
  14.      areas, and its working groups.  Note that other groups may also
  15.      distribute working documents as Internet-Drafts.
  16.  
  17.      Internet-Drafts are draft documents valid for a maximum of six
  18.      months and may be updated, replaced, or obsoleted by other
  19.      documents at any time.  It is inappropriate to use Internet-
  20.      Drafts as reference material or to cite them other than as
  21.      ``work in progress.''
  22.  
  23.      To learn the current status of any Internet-Draft, please check
  24.      the ``1id-abstracts.txt'' listing contained in the Internet-
  25.      Drafts Shadow Directories on ftp.is.co.za (Africa),
  26.      nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  27.      ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  28.  
  29.      Distribution of this document is unlimited. Please send comments
  30.      to Kenji Ota, NTT (ota@nttlabs.com), Kenji Takahashi
  31.      (kt@nttlabs.com), or Kazuchika Sekiya (sekiya@ntts.com).
  32.  
  33. Abstract
  34.  
  35.     This draft describes version management of the resources with
  36.     some extensions to HTTP/1.1.
  37.     The main point of our approach is to use meta-level links,
  38.     which is not an anchor of HTML format, but an attribute of the
  39.     resource. So, the contents need not to be an HTML format.
  40.  
  41. 1. Introduction
  42.  
  43.     Conventionally, most resources are linked each other with
  44.     links described in HTML files. This mechanism is not useful in
  45.     version management, because HTML files have to be edited in
  46.     order to manipulate the links between the versions of a
  47.     resource.
  48.  
  49.      This document describes a mechanism for version management of 
  50.     resources, which uses meta-level links. A meta-level link
  51.     relates two resources outside the contents of resources. So,
  52.     the contents need not to be an HTML format.
  53.  
  54.      This document also describes the classification of the
  55.     PUT method. It is used for the server to distinguish between
  56.     normal resources and versioned resources.
  57.  
  58.      The locking mechanism is also described. It prevents multiple
  59.     clients from editing the same resource at one time. So, our
  60.     policy of locking is similar to RCS.
  61.  
  62. 2. Meta-level links
  63.  
  64.     A meta-level link, that is meta-information of resources, 
  65.     relates two resources outside the contents of resources. 
  66.     It is independent from the contents of resource. So, the
  67.     content of the resource needs not to be HTML format.
  68.     The draft specification of HTTP/1.1[1] specifies "Link:"
  69.     header field in the appendices chapter. 
  70.  
  71.     The LINK and UNLINK methods manipulate the meta-level links. These
  72.     methods are also specified in the appendices chapter of
  73.     HTTP/1.1 specification.
  74.  
  75.     If the GET or HEAD request sends to the server, the server
  76.     returns the "Link:" header in the response.
  77.     If the PUT request sends to the server with the "Link:"
  78.     header, the server establishes the links between the
  79.     resource specified by Request-URI and resources specified in
  80.     the "Link:" header.
  81.  
  82.     The meta-level links can be used to manage the versions of the
  83.     resources. The chapter 5 describes details of version
  84.     management using this meta-level links. The meta-level links
  85.     themselves are so generic as to used for other purposes than
  86.     version management. For example, annotations to some web
  87.     contents can be linked by using this.
  88.  
  89. 3. Locking mechanism
  90.  
  91.     We propose LOCK/UNLOCK method for locking a resource.
  92.     Locking a resource means that the server excludes the other
  93.     requests for update to the same resource, in order to
  94.     make sure that only one user can update a resource while the
  95.     resource being locked.
  96.     We also propose "X-Lock:" header field.
  97.  
  98.     It is assumed that the client and the server have some
  99.     authentication functions. This document does not refer to it.
  100.  
  101.   3.1. LOCK/UNLOCK
  102.  
  103.     The LOCK method requests that the server lock the
  104.     resource identified by the Request-URI. 
  105.  
  106.     The UNLOCK method requests that the server cancel the
  107.     lock status of the resource identified by the
  108.     Request-URI.
  109.  
  110.     Only the user who has locked a resource can request PUT, POST,
  111.     LOCK or UNLOCK to it. Any users, however, can always request
  112.     GET, HEAD and LINK.
  113.  
  114.   3.2. X-Lock: header field
  115.  
  116.     The "X-Lock:" is a header in the server response that
  117.     represents the information about locking status of a requested
  118.     resource.
  119.     When the client sends a GET, HEAD or LOCK request to the
  120.     locked resource, the server returns the response including
  121.     the "X-Lock:" header. Then, the client can show the
  122.     information to the users. The followings are BNF and an
  123.     example of this header.
  124.  
  125.     X-Lock = "X-Lock" ":" "user=" user_name ";" "date=" HTTP-date
  126.     user_name = 1*8(ALPHA | DIGIT)
  127.  
  128.     ex.
  129.     X-Lock: user="sekiya"; date="Thu, 15 Feb 1996 23:44:20 GMT"
  130.  
  131. 4. Creation and modification of web resources via HTTP
  132.  
  133.   4.1. "X-PUT-Class" header field
  134.  
  135.     We propose "X-PUT-Class" header field for the PUT method. 
  136.     It specifies a type of a resource when the resource is
  137.     created. The server decides how to handle to the resource
  138.     according to the value of its field. The strings of "File",
  139.     "Mkdir" or "VersionedFile" are allowed as its value. The value
  140.     of the header field is stored as an attribute of the resource.
  141.     BNF is as follows,
  142.  
  143.         PUT-Class = "X-PUT-Class" : PUT_type
  144.         PUT_type = ("File" | "Mkdir" | "VersionedFile")
  145.  
  146.     The meaning of each values is as follows.
  147.  
  148.     - "File"
  149.         The resource specified by the Request-URI is created
  150.         as a normal file. The PUT request to this type of
  151.         resource requests that the server overwrite the
  152.         contents with the new entity.
  153.     - "VersionedFile"
  154.         The resource specified by the Request-URI is created
  155.         as a versioned file. The PUT request to this type of
  156.         an existing resource means that the server creates a
  157.         new version of resource with the received entity.
  158.     - "Mkdir"
  159.         The resource specified by the Request-URI is created
  160.         as an identifier of a collection of resources, such a
  161.         directory, that manages the name for some resources
  162.         under it.
  163.  
  164. 5. Versioning
  165.  
  166.      We have decided our naming scheme based on the following:
  167.  
  168.     (1) accessibility from existing browsers (e.g. Netscape)
  169.     (2) easy manipulation in existing directory-based file systems
  170.         (e.g. UNIX file system)
  171.     (3) ability of representing "composite" versions
  172.         (e.g. version 2 of composite resource that consists of
  173.         version 5 of X, a component resource, and version 3 of
  174.         Y, another component resource)
  175.  
  176.   5.1. Naming Scheme
  177.  
  178.     A series of versions of a resource is identified by a unique
  179.     directory name in a file system as a "representative"
  180.     URL. Each version of a resource is placed under the directory
  181.     and represented as follows:
  182.  
  183.         representative_URL "/" version_number
  184.  
  185.     For example, version 3 of
  186.     "http://www.nttlabs.com/project1/x.html" is represented as
  187.     follows:
  188.  
  189.         http://www.nttlabs.com/project1/x.html/3
  190.  
  191.     The latest version is referred by the representative URL and
  192.     specific version can be referred by the representative URL +
  193.     "/version_number". (Figure 1.)
  194.      In this way, users can access any version by existing
  195.     browsers and easily manipulate it in existing file systems. 
  196.  
  197.   5.2. Versioning by using Link mechanism
  198.  
  199.      Each time a version of a resource has been revised, a new
  200.     version is created and given a new URL based on the naming
  201.     scheme described above.  In the same time, the original and
  202.     new versions are linked bidirectionally with meta-level links.
  203.     A link named "new" is established from the original to new
  204.     versions and a link named "old" is established from the new to
  205.     original versions.
  206.  
  207.     For example, Figure 1. illustrates links between
  208.     versions of a resource (http://host/some/resource).
  209.  
  210.  
  211.             http://host/some/resource --------+
  212.                                                           |
  213.     ------------------------------------------------- | --------
  214.                                                           |
  215.                                                           V
  216.  
  217.              /1             /2             /3             /4
  218.     +----------+   +----------+   +----------+   +----------+
  219.     |+--------+|   |+--------+|   |+--------+|   |+--------+|
  220.     ||  new   ||-->||  new   ||-->||  new   ||-->||  new   ||
  221.     ||        ||<--||  old   ||<--||  old   ||<--||  old   ||
  222.     |+--------+|   |+--------+|   |+--------+|   |+--------+|
  223.     |+--------+|   |+--------+|   |+--------+|   |+--------+|
  224.     ||        ||   ||        ||   ||        ||   ||        ||
  225.     ||        ||   ||        ||   ||        ||   ||        ||
  226.     ||        ||   ||        ||   ||        ||   ||        ||
  227.     |+--------+|   |+--------+|   |+--------+|   |+--------+|
  228.     +----------+   +----------+   +----------+   +----------+
  229.                                                      latest version
  230.  
  231.         Figure 1. Links between versions of a resource
  232.  
  233.  
  234.      A particular version of a resource can be transmitted via
  235.     HTTP by specified by the "Content-Version:" field of HTTP
  236.     headers, or according to the naming scheme when using existing
  237.     clients. The following is an example of two type of
  238.     specifying some version of a certain resource.
  239.  
  240.         http://www.nttlabs.com/project1/x.html/3
  241.             or 
  242.         http://www.nttlabs.com/project1/x.html
  243.         Content-Version: "3"
  244.  
  245.   5.3. Examples of HTTP interactions
  246.  
  247.     5.3.1. Create a new resource
  248.  
  249.     [request]
  250.         PUT http://server/path/resource
  251.             X-PUT-Class: VersionedFile
  252.         (contents of initial version)
  253.  
  254.     [response]
  255.         201 Created
  256.         http://server/path/resource
  257.         Content-Version: "1"
  258.  
  259.     5.3.2. Retrieve latest version
  260.  
  261.     [request]
  262.         GET http://server/path/resource
  263.         (Retreive the latest version automatically)
  264.  
  265.     [response]
  266.             200 OK
  267.             Content-Version: "5"
  268.         Link: <http://server/path/resource/4>; rel="old"
  269.             (contents of version 5)
  270.  
  271.     5.3.3. Retrieve a particular version
  272.  
  273.     [request]
  274.         GET http://server/path/resource
  275.         Content-Version: "3"
  276.  
  277.           or 
  278.         GET http://server/path/resource/3
  279.  
  280.     [response]
  281.         200 OK
  282.         Content-Version: "3"
  283.         Link: <http://server/path/resource/2>; rel="old"
  284.         Link: <http://server/path/resource/4>; rel="new"
  285.         (contents of version 3)
  286.  
  287.     5.3.4. Update an existing (versioned) resource
  288.  
  289.     [request]
  290.         PUT http://server/path/resource
  291.             (changed contents)
  292.  
  293.     [response]
  294.             201 Created
  295.             (Resource for new version are created, and establish
  296.         links between created version and its new/old version)
  297.  
  298. References
  299.  
  300. [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk and T. Berners-Lee,
  301.     "Hypertext Transfer Protocol -- HTTP/1.1,"
  302.     Internet Draft, Work in Progress, August 1996
  303.  
  304. [2] E. J. Whitehead, Jr.,
  305.     "Requirements on HTTP for Distributed Content Editing,"
  306.     Internet Draft, Work in Progress, September 1996
  307.  
  308. [3] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource
  309.     Locators (URL)." RFC 1738, CERN, Xerox PARC, University of
  310.     Minnesota, December 1994.
  311.  
  312. Author Address
  313.  
  314. Kenji Ota
  315. NTT Software Laboratories
  316. 250 Cambridge Avenue, #205
  317. Palo Alto, CA 94306, USA
  318. Email: ota@nttlabs.com
  319.  
  320. Kenji Takahashi
  321. NTT Multimedia Communications Laboratories
  322. 250 Cambridge Avenue, #205
  323. Palo Alto, CA 94306, USA
  324. Email: kt@nttlabs.com
  325.  
  326. Kazuchika Sekiya
  327. NTT Software Corporation
  328. 250 Cambridge Avenue, #205
  329. Palo Alto, CA 94306, USA
  330. Email: sekiya@ntts.com
  331.