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-pritchard-http-links-00.txt < prev    next >
Text File  |  1996-11-21  |  21KB  |  508 lines
  1.  
  2. Internet Draft                                       John Pritchard
  3. <draft-pritchard-http-links-00>         Columbia U Computer Science
  4.  
  5. Expires June 1996                                  21 November 1996
  6.  
  7.                   Efficient HyperLink Maintenance for HTTP
  8.  
  9. Status of this Memo
  10.  
  11. This document is an Internet-Draft. Internet-Drafts are working documents of
  12. the Internet Engineering Task Force (IETF), its areas, and its working
  13. groups. Note that other groups may also distribute working documents as
  14. Internet-Drafts.
  15.  
  16. Internet-Drafts are draft documents valid for a maximum of six months and
  17. may be updated, replaced, or obsoleted by other documents at any time. It is
  18. inappropriate to use Internet- Drafts as reference material or to cite them
  19. other than as ``work in progress.''
  20.  
  21. To learn the current status of any Internet-Draft, please check the
  22. ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
  23. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
  24. (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West
  25. Coast).
  26.  
  27. Distribution of this document is unlimited. Please send comments to John
  28. Pritchard at <jdp@cs.columbia.edu>
  29.  
  30. Abstract
  31.  
  32. Hyperlink maintenance allows robots and servers to cooperate in propagating
  33. the effects of daily changes in the millions of resource locations in the
  34. wwweb. Here, we propose developing the definitions of the LINK and UNLINK
  35. methods defined for HTTP since RFC 1945 and which remain largely
  36. unimplemented and unused. We believe that the only reason these methods have
  37. not been employed is that they remain too loosely defined and implicitly too
  38. inefficient. A new syntax and semantics simplify implementation and improve
  39. utility.
  40.  
  41. Author's address
  42.  
  43. John Pritchard
  44. 315 W 82nd Street, #4
  45. New York, NY 10024
  46.  
  47. <jdp@cs.columbia.edu>
  48.  
  49. Contents
  50.  
  51.   1. Introduction
  52.  
  53.   2. Link Terminology
  54.  
  55.   3. Implementation Terminology
  56.  
  57.   4. Current HTTP Link Management Protocol
  58.  
  59.   5. Some linking practices
  60.  
  61.   6. Proposed Facility
  62.  
  63.   7. Methods
  64.  
  65.        1. LINK
  66.  
  67.        2. UNLINK
  68.  
  69.        3. UNLINKR
  70.  
  71.        4. LINKMOD
  72.  
  73.   8. Implementation
  74.  
  75.   9. Indempotency
  76.  
  77.  10. Security Considerations
  78.  
  79.  11. Syntax
  80.  
  81.  12. References
  82.  
  83.   1. Introduction
  84.  
  85.      The HTTP protocol has recognized the importance of link management
  86.      since HTTP/1.0 RFC 1945 [1]. However, the methods defined in HTTP/1.0
  87.      are limited and remain largely unimplemented. The existing link concept
  88.      is defined irrespective of direction, ie, reference or resource, and so
  89.      leaves too much semantically implied. The revised methods define simple
  90.      and efficient syntax and semantics for a complete hyperlink management
  91.      protocol within HTTP.
  92.  
  93.      Dangling links are a bigger and bigger problem on a large and growing
  94.      wwweb. Messages like the following are common:
  95.  
  96.        The URL which you entered, ... , was not found on this server.
  97.        You may have entered it incorrectly, or it may no longer exist.
  98.        If you arrived here by clicking on a link in another page,
  99.        please tell that page's owner/administrator that the link no
  100.        longer exists.
  101.  
  102.  
  103.      This one resulted from a URL stored in a popular search engine. A
  104.      solution is readily available in defining HTTP's LINK and UNLINK
  105.      methods with syntax and semantics that effectively and efficiently
  106.      provide for hyperlink maintenace.
  107.  
  108.      Hyperlink maintenance implies communication, processing and storage
  109.      costs. The proposed methods cut processing with syntax by not defining
  110.      semantics that imply searching on behalf of call receivers. The
  111.      proposed methods' semantics also match storage requirements to the HTML
  112.      LINK tag concept. Storage space is not required on behalf of robots for
  113.      implementation.
  114.  
  115.      The protocol detailed here is currently being implemented in an
  116.      HTTP/1.1 compliant, commercial wwweb server and agent platform under
  117.      the extensions provisions of that specification. This protocol has been
  118.      realized as the result of that effort.
  119.  
  120.   2. Link Terminology
  121.  
  122.      In this context we refer exclusively to links that are Uniform Resource
  123.      Locators, see URL [4] and [2]. URLs are Uniform Resource Indentifiers,
  124.      URIs [1], pointing to particular resources without variation per user
  125.      identity, class or input, or other particularly perishable or localized
  126.      circumstances.
  127.  
  128.      A link has two end points, one in an HTML anchor or otherwise a URL
  129.      reference, and the other in the HTTP service providing access to a
  130.      resource via a reference. The source end of a link is the client or
  131.      anchor end, sometimes the tail, and the target end of a link is the
  132.      resource end, sometimes the head.
  133.  
  134.        source: anchor, reference, tail
  135.  
  136.        target: resource, head, server, named anchor
  137.  
  138.      Usage for source and target include direct reference to documents, or
  139.      reference locators (URLs), or the services (hosts) at the respective
  140.      ends of a link.
  141.  
  142.      For discussing efficiency, we describe a shorter URI as coarser, and a
  143.      longer one finer. The comparison could be made for URIs into the same
  144.      sub-wwweb, for example
  145.  
  146.         http://www.target.com/some/long/path/     A
  147.  
  148.         http://www.target.com/some/path/          B
  149.  
  150.      B is coarser than A. If a coarser URI replaces a finer one, the
  151.      implication of clobbered namespaces arises as well as a greater
  152.      potential need for link modifications. Remember that handling URLs, or
  153.      particular resource locators, implies that for each link there's an
  154.      unlink.
  155.  
  156.   3. Implementation Terminology
  157.  
  158.      In agreement with the HTTP specification documents and RFC 1123 [1], we
  159.      employ must, shall or required to indicate implementation syntax or
  160.      semantics that are not optional for software conforming to this
  161.      specification, may for recommended features and should for optional
  162.      features.
  163.  
  164.      Please note that this draft does not constitute a modification of any
  165.      standard, rfc, or draft document but a proposal for review by the HTTP
  166.      Working Group and the internet administration and development
  167.      community.
  168.  
  169.   4. Current HTTP Link Management Protocol
  170.  
  171.      The LINK and UNLINK methods are described in HTTP/1.1 [2] draft seven,
  172.      sections 19.6.1.2 and 3, respectively. In short, the link and unlink
  173.      request lines include method names and a request URI.
  174.  
  175.      The specification [2] states (section 5.3)
  176.  
  177.           The LINK method establishes one or more Link relationships
  178.           between the existing resource identified by the Request-URI
  179.           and other existing resources.
  180.  
  181.           The UNLINK method removes one or more Link relationships
  182.           from the existing resource identified by the Request-URI.
  183.           These relationships may have been established using the
  184.           LINK method or by any other method supporting the Link
  185.           header. The removal of a link to a resource does not imply
  186.           that the resource ceases to exist or becomes inaccessible
  187.           for future references.
  188.  
  189.      Without providing both the source and target of a link for LINKing or
  190.      UNLINKing, the processing requirements for implementation of the
  191.      current methods imply looking up the other end of the link. Link source
  192.      or unlink target information is required in request headers, or on the
  193.      request line to allow a valuable optimization -- eliminating excess
  194.      searching or indexing.
  195.  
  196.   5. Some linking practices
  197.  
  198.      Hyperlink maintenance methods are required for wwweb organization and
  199.      must be interoperable across wwweb servers and robots in order to be
  200.      effective. Robots and wanderers maintain catalogs of URI references and
  201.      hypertext. Currently, unlink maintenance of these catalogs is largely
  202.      manual. The Robot Exclusion Standard or "/robots.txt" [6] is currently
  203.      considering a new facility for informing robots of changes to a
  204.      server's sub-web, but doesn't address the server to server case that
  205.      most links fall into. The passive existance of a link directive
  206.      instrument on a server would require every server to get the linking
  207.      directives from every other server and apply them heuristically to try
  208.      to weed out broken links. This is untenable for broad use by
  209.      communication and processing requirements and by the complexity of
  210.      implementation. RES is useful for directing searches on subwebs by
  211.      robots and is fairly widely employed by search engines and other
  212.      robots.
  213.  
  214.      The URN [7] proposal is another idea that is sometimes mentioned but
  215.      really isn't relevant. It creates a hierarchical global namespace for
  216.      resources, and is designed for resources with extensive lifetimes, and
  217.      not the ordinary class of information. Named linking would be extremely
  218.      useful for putting hyperlinks into this document for reference
  219.      material. With a particular URN namespace, the reader would potentially
  220.      find the closest copy, perhaps a local copy of an RFC or Internet-Draft
  221.      document, rather than simply use the link provided to the USA East
  222.      Coast repository provided here. But even URN may not be appropriate for
  223.      drafts with six month lifetimes.
  224.  
  225.      WWWeb meta information and versioning are important in this context as
  226.      the proposed link maintenance extensions could benefit from mutual
  227.      implementation in a wwweb server's object management system in
  228.      conjunction with "Version management with meta-level links via
  229.      HTTP/1.1" [3]. Content level links (see "Link" content header in
  230.      HTTP/1.0 [2] and LINK entity in HTML 2.0 [8]) provide a default storage
  231.      mechanism for link maintenance information.
  232.  
  233.   6. Proposed Facility
  234.  
  235.      Required semantics are very limited. Only support for the LINK call,
  236.      and clean disposal of other calls, is required by implementing systems.
  237.  
  238.      This simple, lightweight form doesn't require storage overhead on
  239.      robots, crawlers, etc..
  240.  
  241.      The cost of employing this automation is lower than might first be
  242.      imagined as link changes with coarser effects are rarer than link
  243.      changes with finer effects. Unlinks potentially occur for each link,
  244.      without matching coarse URIs into fine URLs.
  245.  
  246.      If the wwweb server maintains a table of LINKs for the target document,
  247.      it can issue UNLINKs to delete or revise others' information when the
  248.      location changes or is deleted. So the average cost in simple network
  249.      calls and table size is linear in number of links. Unlink calls'
  250.      generation versus link calls' receipt ratio depends entirely on the
  251.      server site characteristics.
  252.  
  253.      The table for a particular doc.html would store link source info, or
  254.      reverse links. The UNLINK call is made to the host in the source end of
  255.      the link, with the source and target links so that it can handle the
  256.      request with minimal overhead. The LINK call is made to the host
  257.      serving the target when the reference locator is used in a link-source
  258.      document.
  259.  
  260.      Although HTML [7] defines LINK entities, in practice one doesn't want
  261.      the wwweb server to download its link set with each HTML document -- if
  262.      for no other reason than minimizing general bandwidth consumption.
  263.  
  264.   7. Methods
  265.  
  266.        1. LINK
  267.  
  268.           Linking provides for subsequent link modifications from the target
  269.           to the source. Links change at their target side, so the link
  270.           establishment between two HTTP implementing systems needs to allow
  271.           the target side to tell the source side when a link URL has
  272.           changed.
  273.  
  274.           The LINKMOD option tells the target end of the link that LINKMOD
  275.           calls should be made to the source end.
  276.  
  277.           The target maintains a table of source links associated with
  278.           particular resources so that if their URIs change the target can
  279.           notify the source.
  280.  
  281.             LINK Source-URL Target-URL
  282.  
  283.             LINK Source-URL Target-URL LINKMOD
  284.  
  285.                Request
  286.                     The source tells the target that a URL to the target has
  287.                been stored at the source.
  288.  
  289.                Reply
  290.                     The target will accept LINK calls with 200 Ok unless the
  291.                Target-URL is invalid. In this case it will respond with a
  292.                417 Invalid target URI. If the LINKMOD option is requested
  293.                but not enabled, the 207 No Linkmod reply will be generated.
  294.  
  295.        2. UNLINK
  296.  
  297.           UNLINK removes previous LINK information. A source tells a target
  298.           that the previous source referenced in a prior LINK call no longer
  299.           exists or has moved.
  300.  
  301.             UNLINK Source-URL Target-URL
  302.  
  303.             UNLINK Source-URL Target-URL Repl-Source-URL
  304.  
  305.                Request
  306.                     The source notifies the target that the source link has
  307.                changed. Optionally, the source may specify a replacement
  308.                source URL.
  309.  
  310.                Reply
  311.                     The target replies with 200 Ok unless the source has
  312.                specified invalid source or target URLs. In the case of
  313.                erroneous source or target URIs, the target replies with one
  314.                of 416 Invalid source URI or 417 Invalid target URI. The
  315.                invalid target may indicate only that UNLINKR has not been
  316.                supported by the target or source system. The invalid source
  317.                reply occurs when there is no such source link information
  318.                known to the target.
  319.  
  320.        3. UNLINKR
  321.  
  322.           This method allows the target to inform the source that a link has
  323.           changed. It specifies that the first argument refers to a source
  324.           link that it stores and the second argument refers to a target
  325.           link from that source. It is redundant on the semantics of the
  326.           UNLINK method if the semantics of the UNLINK method included
  327.           determining whether the recipient of the call is the source or the
  328.           target.
  329.  
  330.           For UNLINK, the receiver is the target end, and with UNLINKR, the
  331.           receiver is the source end.
  332.  
  333.             UNLINKR Source-URL Target-URL
  334.  
  335.             UNLINKR Source-URL Target-URL Repl-Target-URL
  336.  
  337.                Request
  338.                     The target notifies the source that the Target-URL
  339.                referenced from location Source-URL is no longer valid. The
  340.                target optionally provides the source with a replacement
  341.                target URL.
  342.  
  343.                Reply
  344.                     The source replies with 200 Ok unless the target has
  345.                specified invalid target or source URLs. In the case of
  346.                erroneous target or source URIs, the source replies with one
  347.                of 416 Invalid target URI or 417 Invalid source URI. The
  348.                invalid source may indicate only that UNLINK has not been
  349.                supported by the source or target system. The invalid target
  350.                reply occurs when there is no such target link information
  351.                known to the source.
  352.  
  353.        4. LINKMOD
  354.  
  355.           A LINKMOD call could notify robots that a page has been updated.
  356.           this would require that LINK be extended with optional request for
  357.           LINKMOD calls.
  358.  
  359.           LINKMOD would be accepted by robots and crawlers in addition to
  360.           UNLINK. The source will react according to its need for this
  361.           information.
  362.  
  363.             LINKMOD Source-URL Target-URL
  364.  
  365.                Request
  366.                     The target informs the source that the Target-URI has
  367.                been modified.
  368.  
  369.                Reply
  370.                     The source replies with 200 Ok unless the target has
  371.                specified invalid target or source URLs. In the case of
  372.                erroneous target or source URIs, the source replies with one
  373.                of 416 Invalid target URI or 417 Invalid source URI. The
  374.                invalid source may indicate only that UNLINK has not been
  375.                supported by the source or target system. The invalid target
  376.                reply occurs when there is no such target link information
  377.                known to the source.
  378.  
  379.   8. Implementation
  380.  
  381.      We can divide all classes of HTTP-implementing software into two
  382.      categories for specifying implementation requirements. The first is the
  383.      class of systems that maintain no link references (no HTML or URL
  384.      catalogs) in their internal data. These have no implementation
  385.      requirements.
  386.  
  387.      The second is systems that maintain link references in HTML or URL
  388.      catalog data. These include wwweb servers and search engines.
  389.  
  390.      The implementation must include LINK and may implement UNLINK, UNLINKR
  391.      and LINKMOD. If it is only implementing LINK, it must reply with an Ok
  392.      status code to any UNLINK, UNLINKR and LINKMOD calls it receives.
  393.  
  394.   9. Indempotency
  395.  
  396.      All of these methods are indempotent. Successive identical calls have
  397.      identical effect as a single call. However, this requires that LINK is
  398.      implemented to not replicate identical data. Please refer to RFCs 1738
  399.      [4] and 1808 [5] and HTTP/1.1 [2] Section 3.2.3 "URI Comparison" for
  400.      information on determining when a LINK request should be discarded in
  401.      preserving indempotency.
  402.  
  403.  10. Security Considerations
  404.  
  405.      The UNLINK and UNLINKR methods' calls should be manually reviewed or
  406.      automated and secured for trusted or authenticated hosts.
  407.  
  408.      At least robot-level spamming would be segmented into LINKMOD domain
  409.      until people used UNLINK <target> <target> or the variation based on
  410.      replicating pages, ie, UNLINK <target> <copy of target>.
  411.  
  412.  11. Syntax
  413.  
  414.      The syntax employs an induction operator, "=" (parser), and a deduction
  415.      operator ":" (compiler). Literals are double quoted. Alternatives
  416.      succeed "|". Where noted in ";" line comments, a syntactic variable may
  417.      be defined in HTTP/1.1 [2]. Two linebreaks terminate a clause, any
  418.      amount of whitespace is identical to a single token separator.
  419.  
  420.              Method        = "LINK"
  421.                            | "UNLINK"
  422.                            | "UNLINKR"
  423.                            | "LINKMOD"
  424.  
  425.              Request       = Link-Request-Line
  426.                            | Unlink-Request-Line
  427.                            | UnlinkR-Request-Line
  428.                            | LinkMod-Request-Line
  429.                            *( general-header  )      ; HTTP/1.1 07 4.5
  430.                            CRLF
  431.  
  432.              Link-Request-Line
  433.                = "LINK" Source-URL Target-URL
  434.                | "LINK" Source-URL Target-URL "LINKMOD"
  435.  
  436.              Unlink-Request-Line
  437.                = "UNLINK" Source-URL Target-URL
  438.                | "UNLINK" Source-URL Target-URL Repl-Source-URL
  439.  
  440.              UnlinkR-Request-Line
  441.                = "UNLINKR" Source-URL Target-URL
  442.                | "UNLINKR" Source-URL Target-URL Repl-Target-URL
  443.  
  444.              LinkMod-Request-Line
  445.                = "LINKMOD" Source-URL Target-URL
  446.  
  447.              Source-URL    : URL     ; RFC 1738 Resource Locator
  448.  
  449.              Target-URL    : URL
  450.  
  451.              Repl-Target-URL
  452.                : URL                 ; Suggested Link Replacement
  453.  
  454.              Repl-Source-URL
  455.                : URL                 ; Suggested Link Replacement
  456.  
  457.              Response      = Status-Line  ; As HTTP/1.1
  458.  
  459.              Status-Code   = "200"   ; Ok
  460.                            | "207"   ; No Linkmod
  461.                            | "400"   ; Bad Request
  462.                            | "404"   ; Not found
  463.                            | "416"   ; Invalid source URI
  464.                            | "417"   ; Invalid target URI
  465.                            | "500"   ; Internal Server Error
  466.  
  467.  12. References
  468.  
  469.        1. Hypertext Transfer Protocol -- HTTP/1.0
  470.           rfc1945
  471.           T. Berners-Lee, R. Fielding, H. Frystyk
  472.           May 1996
  473.  
  474.        2. Hypertext Transfer Protocol -- HTTP/1.1
  475.           draft-ietf-http-v11-spec-07
  476.           R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee
  477.           August 1996
  478.  
  479.        3. Version management with meta-level links via HTTP/1.1
  480.           draft-ota-http-version-00
  481.           K. Ota, K. Takahashi, K. Sekiya
  482.           November 1996
  483.  
  484.        4. Uniform Resource Locators (URL)
  485.           rfc1738
  486.           T. Berners-Lee, L. Masinter, M. McCahill
  487.           December 1994
  488.  
  489.        5. Relative Uniform Resource Locators
  490.           rfc1808
  491.           R. Fielding
  492.           June 1995
  493.  
  494.        6. Robot Exclusion Standard
  495.           norobots.html
  496.           Martijn Koster
  497.  
  498.        7. A Framework for the Assignment and Resolution of Uniform Resource
  499.           Names
  500.           draft-daigle-urnframework-00
  501.           Leslie L. Daigle
  502.           June 1996
  503.  
  504.        8. Hypertext Markup Language - 2.0
  505.           draft-ietf-html-spec-06
  506.           T. Berners-Lee, D. Connolly
  507.           September 1995
  508.