home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / http / http-minutes-95apr.txt < prev    next >
Encoding:
Text File  |  1995-05-26  |  5.9 KB  |  167 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Ari Luotonen/Netscape Communications Corporation
  5.  
  6. Minutes of the HyperText Transfer Protocol Working Group (HTTP)
  7.  
  8.  
  9. Objectives of the Meeting
  10.  
  11. The objectives for the meeting were to:
  12.  
  13.  
  14.    o Finalize the HTTP/1.0 draft, as the final version of it will be
  15.      made available the following week.
  16.  
  17.    o Go through the extensions and decide which ones will be included in
  18.      HTTP/1.1.
  19.  
  20.    o Get a status report on HTTP-NG.
  21.  
  22.    o Get a status report on the Digest Authentication Scheme.
  23.  
  24.    o Introduce Mediated Digest Authentication.
  25.  
  26.  
  27. HTTP-NG Status Report
  28.  
  29. The new features added to the second checkpoint draft were briefly
  30. introduced:
  31.  
  32.  
  33.    o Included the specification for initialization of the session; at
  34.      initialization the level of synchronization is negotiated (among
  35.      other things), as well as variables defined to be used later in
  36.      that session.
  37.  
  38.    o Canceling and suspending a request.  Suspending was added to make
  39.      it possible to stop, e.g., image transfer if the user follows a
  40.      link to another page, so that the transfer can be resumed later if
  41.      the user returns to the original document (or if the next page
  42.      contains the same image).
  43.  
  44.    o Two methods for retrieving documents:
  45.  
  46.       -  Simple GET for the same level of functionality as HTTP/1.0
  47.          provides.
  48.  
  49.       -  Full GET for receiving only a range of a document,
  50.          metainformation, or a variant of the resource (different
  51.          language, format, version).
  52.  
  53.    o HTTP-TOS request for allowing existing applications to send
  54.      old-style requests, and to allow S-HTTP to work.
  55.  
  56.  
  57. HTTP/1.0
  58.  
  59. Roy Fielding and Henrik Frystyk will produce the final draft by the end
  60. of the following week.  If that one does not have unresolved points, it
  61. will be submitted to the IESG, and may finally become the final HTTP/1.0
  62. Standard.
  63.  
  64. Mainly the suggested changes were quickly walked through:  Accept:  */*
  65. default q factor 0.5; understanding the asctime() Date:  format only
  66. required by proxies; value of From:  field is mailbox instead of
  67. addr-spec; and Location:  is a valid header to give the new location in
  68. a redirect; use of the URI: header is not mandatory.
  69.  
  70. Making Language:  header hierarchical raised quite a bit of discussion.
  71. It was brought up that all the languages cannot be described
  72. hierarchically -- there are dialects of certain languages that are not
  73. understandably by people speaking another dialect of the same language
  74. (Saame was an example).
  75.  
  76.  
  77. HTTP/1.1
  78.  
  79. HTTP/1.1 will be published as an Internet-Draft before the Stockholm
  80. IETF meeting in July 1995.
  81.  
  82. The following extensions to HTTP/1.1 were discussed:
  83.  
  84.  
  85.    o Decided to have clients treat unknown 3xx series response codes by
  86.      default as 302 redirect (moved temporarily).  The Location:  header
  87.      should then be there, and if not, URI: should be used.
  88.  
  89.      This was the suggestion for having an automatable subset of HTML
  90.      for handling 300 Multiple Choices and 406 None Acceptable status
  91.      codes.  Clients supporting this would capture this special format,
  92.      and perform the function of selecting the best copy automatically.
  93.      Clients not supporting this would display the HTML normally, which
  94.      would construct an itemized list with hyperlinks to those multiple
  95.      choices.
  96.  
  97.      This suggestion got resistance -- HTTP and HTML should not be bound
  98.      together.  Also, there are cases when HTML cannot be displayed,
  99.      such as when retrieving inlined images.
  100.  
  101.      It was then suggested that these multiple choices be provided as
  102.      HTTP header fields.  The argument there was that the headers are
  103.      flat, and there are problems providing lists of choices.
  104.  
  105.      The conclusion was that the Location:  header be the default place
  106.      to redirect temporarily.
  107.  
  108.    o Orig-URI: for expressing the entire URL that initiated this
  109.      request, so that the hostname is also available to the server.  It
  110.      was brought up that this will not be backwards compatible, and that
  111.      behavior is now different with browsers that do not support this.
  112.      This is the vanity hostname issue, which has been so far solved by
  113.      having servers respond to multiple IP addresses, which wastes
  114.      resources.  However, service providers are so desperate that they
  115.      are in fact willing to accept a partial solution which will not
  116.      work with old browsers.
  117.  
  118.    o Connection:  and Keep-Alive:  for support for multiple requests
  119.      over a single connection.
  120.  
  121.    o Refresh:  header for client-pull.
  122.  
  123.    o Proxy-Authenticate:  and Proxy-Authorization:  for user
  124.      authentication for proxies, just like in HTTP/1.0.
  125.  
  126.    o Changes to headers:  allow HTTP Date to use +0000 to indicate GMT;
  127.      extend Pragma:  header; make Expires:  accept delta-seconds.
  128.  
  129.    o Two new methods:  OPTIONS for getting allowed methods, and MULTI
  130.      for allowing session-long negotiation of Accept-* headers,
  131.      authentication and privacy extensions.
  132.  
  133.    o Digest authentication scheme (discussed later in the meeting).
  134.  
  135.  
  136.  
  137. Extensions for HTTP
  138.  
  139. Dave Kristol briefly described his view of the framework for the
  140. extensions.  The Internet-Draft for this proposal is
  141. draft-kristol-http-extensions-00.txt.  Basically, to use wrapping,
  142. packetizing and recursion to handle messages, to have a small yet
  143. relatively versatile system for security, payment information,
  144. packetizing and compression.
  145.  
  146.  
  147.  
  148. Digest Authentication Scheme
  149.  
  150. Eric Sink gave a status report on the Digest Authentication Scheme.  The
  151. latest Internet-Draft is available as draft-ietf-http-digest-aa-01.txt.
  152.  
  153. The possibility for a man-in-the-middle attack that used to exist in the
  154. previous version has been removed.  Also, message integrity check is now
  155. available as an option.
  156.  
  157.  
  158.  
  159. Mediated Digest Authentication
  160.  
  161. Dave Raggett has submitted an Internet-Draft,
  162. draft-ietf-http-mda-00.txt, on Mediated Digest Authentication scheme
  163. that uses a trusted third party to authenticate both the client and the
  164. server.  This scheme is a strict superset of the Digest Authentication
  165. Scheme.
  166.  
  167.