home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / http / http-minutes-94dec.txt < prev    next >
Encoding:
Text File  |  1995-02-28  |  10.3 KB  |  224 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Dave Raggett/Hewlett-Packard
  5.  
  6. Minutes of the HyperText Transfer Protocol Working Group (HTTP)
  7.  
  8. This group met as the HTTP BOF at the 31st IETF on Wednesday, 7
  9. December, and has since become a working group.
  10.  
  11. Further info on HTTP is currently available from the URLs:
  12.  
  13.  
  14.      http://info.cern.ch/hypertext/WWW/Protocols/Overview.html
  15.      http://www.ics.uci.edu/pub/ietf/http/
  16.  
  17.  
  18. History
  19.  
  20. This BOF followed an earlier one at the World Wide Web Conference at
  21. Chicago in October in which it was decided to pursue setting up a
  22. working group for the World Wide Web hypertext transfer protocol.  The
  23. group would be set up to standardise existing practice, and then to work
  24. on improved performance, security and payments, and other improvements
  25. such as support for transaction mechanisms for distributed updates.
  26.  
  27. The meeting started with a summary by the chair of the steps leading up
  28. to the BOF. HTTP originated as a very simple protocol indeed.  This
  29. version is now known as HTTP/0.9.  It was soon extended to include a
  30. MIME style wrapper to convey the content type and encoding of the
  31. returned document.  A number of RFC 822 style headers are used to
  32. support negotiation and convey meta information, as well as a basic
  33. authentication mechanism.  This version is known as HTTP/1.0 and is in
  34. very widespread use.  The on-line documentation at CERN is no longer
  35. adequate.  Other pressures on HTTP include the need to improve
  36. performance, to avoid the penalties associated with making separate
  37. connections for the document and each of the inlined images.  We also
  38. need to standardise ways of adding support for authentication and
  39. encryption to support privacy and commercial services.  Setting up an
  40. IETF working group is now a matter of urgency to ensure the continued
  41. health of both HTTP and the Web.
  42.  
  43.  
  44. Internet-Draft for HTTP/1.0
  45.  
  46. The meeting continued with a presentation by Henrik Frystyk Nielsen and
  47. Roy Fielding on the Internet-Draft for HTTP/1.0
  48. (draft-fielding-http-spec-00.ps).  together with some ideas for
  49. extensions for consideration in HTTP/1.1.  The consensus of the meeting
  50. was that the Internet-Draft for HTTP/1.0 be proposed for the standards
  51. track as soon as possible.  Revisions to the HTTP/1.0 draft
  52. specification are being discussed on the http-wg mailing list.
  53.  
  54. The list of extensions for the 1.1 revision were:
  55.  
  56.  
  57.    o Session method
  58.       -  Intended for short-term session only (about 10 second request
  59.          timeout) though specialised servers may use longer timeout
  60.       -  Supports multiple transactions over single connection
  61.       -  Allows session-long negotiation of Accept-*, authentication,
  62.          and privacy extensions
  63.       -  More than just an MGET
  64.    o Packetised Content-Encoding
  65.    o Better Access Authentication
  66.    o Base-URL as a New Object header
  67.    o Allow relative time in Expires header (seconds)
  68.  
  69.  
  70. Performance Problems with HTTP/1.0
  71.  
  72. Simon Spero talked briefly on the performance problems with HTTP/1.0.
  73. The current protocol uses a separate connection for the document and
  74. each inlined image.  Each connection requires at least two round trip
  75. times, and in practice more due to the lengthy accept headers in common
  76. use.  Furthermore, TCP/IP uses a slow start mechanism to avoid
  77. congestion and gradually increases the throughput to match the actual
  78. bandwidth available.  As a result, most HTTP transactions operate at a
  79. reduced bandwidth.  Simon reported measurements indicating that over a
  80. congested link from Bristol, England to North Carolina for a
  81. representative home page, the current protocol only uses about 10% of
  82. the bandwidth then available (as measured by a bulk transfer over a
  83. single connection).  The approach used in the Netscape browser of
  84. opening multiple concurrent TCP/IP connections gives better performance,
  85. but still fails to utilise the full bandwidth.  One explanation, is that
  86. most TCP/IP implementations fail to share congestion information between
  87. connections to the same site.  The approach also leads to problems with
  88. many more connections left in the time-wait state at the server.
  89.  
  90.  
  91. Discussion on HTTP Issues
  92.  
  93. Larry Masinter asked whether proposals for extensions such as keep-alive
  94. were based on experience or speculation.  He prefers MIME boundary
  95. markers to packetisation schemes for determining message boundaries.
  96. Larry also suggested we should consider richer mechanisms for
  97. determining whether a document has expired.  For instance, downloading
  98. conditions in SafeTCL to be evaluated by the client.
  99.  
  100. Alex Hopmann argued in favor of reusing the connection, e.g., for a
  101. series of images, and increasing the use of proxy servers.  He has tried
  102. out a session method scheme, and has a written proposal for this and a
  103. separate proposal for a notification proposal.  (For more information
  104. send e-mail to Alex.)
  105.  
  106. Simon Spero described work on log analysis which showed clear groupings
  107. of requests at 3 to 4 images per document.  He mentioned problems in
  108. analysing logs due to accesses by Netscape browsers which initiate
  109. connections for images concurrently and are then cancelled as the user
  110. surfs to the next document.
  111.  
  112. Tim Berners-Lee argued that users connecting over phone lines need
  113. browsers that can do things concurrently with dynamic changes in
  114. priority as the user changes his/her actions, e.g., the browser should
  115. keep the pipe full by following links and then abort if the user does
  116. something else.  He also raised the issue of abstraction layers for
  117. HTTP.
  118.  
  119. Brian Behlendorf discussed the need for user authentication and realms.
  120. He wants to be able to distinguish accesses to a given machine according
  121. to the alias used for the host name, and advocates using the full URL in
  122. the GET request.
  123.  
  124. Digital has collected some 9 gigabytes of log data for requested URL and
  125. the duration the connection was kept open.  A paper analysing this data
  126. was presented at the World Wide Web Fall Conference held in October
  127. 1994, and can be found in the on-line proceedings.
  128.  
  129. Someone asked ``what does HTTP do in a couple of words?''  It is
  130. currently used for a wide variety of things -- should these be
  131. unbundled?  Roy Fielding answered that HTTP is an extensible protocol
  132. used for information transfer.  Tim Berners-Lee replied that this was a
  133. good question, and asked is MIME appropriate for small messages (for
  134. on-line accesses not for e-mail)?
  135.  
  136. Dave Crocker agreed with the need for performance improvements, and said
  137. that the current problem is in making connections.  He argued in favor
  138. of TCPng and other ideas for optimising the underlying protocol rather
  139. than hacking session protocols, etc., above TCP. We should feel free to
  140. adapt the MIME syntax to better suit the needs of the Web for on-line
  141. use.
  142.  
  143. Eric Sink asked when we can start writing code for this (improved
  144. performance).  The general reaction was that now was a good time to try
  145. out experiments to feed into the next versions of HTTP. Alex Hopmann
  146. described his session method for multiple requests.  He was encourage to
  147. carry on with this work and to repost the results so far.  Tim asked
  148. Alex why a session method rather than as an attribute of GET (e.g., a
  149. keep-alive pragma).  The main thing is to avoid unnecessary round-trip
  150. delays.
  151.  
  152. The question was raised as to the possible impact of keep-alive versus
  153. the session method on the operation of proxies.  The discussion was
  154. taken off-line.
  155.  
  156.  
  157.  
  158. HTTP Security Update from Tim Berners-Lee
  159.  
  160. Tim reported on the HTTP Security BOF, which had taken place the
  161. preceding evening.  The idea was to split work on security off from the
  162. HTTP Working Group.  This would lessen the workload and make it easier
  163. to involve security experts in a wider context than that of HTTP alone.
  164. See the minutes for more details.
  165.  
  166.  
  167. Dave Krystal -- A Proposed Extension Mechanism for HTTP
  168.  
  169. As the Web has grown, pressures have mounted to add a variety of
  170. facilities to HTTP. Some of the new features that have been proposed
  171. include:  keep-alive, packetized data, compression, security and
  172. payment.  Dave described an alternative:  well-defined hooks in a
  173. slightly modified HTTP framework that make it possible to add extensions
  174. to the basic protocol in a way that will retain compatible behaviour
  175. between clients and servers, yet allow both clients and servers to
  176. discover and use extended capabilities.  The proposed extension
  177. mechanism has two fundamental concepts:  wrapping and negotiation.  The
  178. idea is to avoid a proliferation of new methods and header fields.
  179. Instead, these would be handled through extensions with new stuff passed
  180. though to feature managers.  For further information please read the
  181. document URL:
  182.  
  183.  
  184.      http://www.research.att.com/ dmk/extend.txt
  185.  
  186.  
  187. Dave also asked whether payments would be covered by the HTTP Security
  188. group.
  189.  
  190.  
  191. Simon Spero on the HTTPng Proposal
  192.  
  193. Simon raced through the major ideas for HTTPng.  A new protocol is
  194. needed which is more efficient; has security built-in from the start;
  195. and is caching and payment aware.  HTTPng uses a session protocol above
  196. TCP/IP to support multiple asynchronous transactions interleaved on the
  197. same connection.  This allows a browser to send the request for an
  198. inlined image before finishing reading the HTML document that references
  199. it.  The approach avoids the delays associated with starting up new
  200. connections and makes better use of available bandwidth and server
  201. resources.  The proposal uses a subset of ASN.1 and the packed encoding
  202. rules to formally specify messages.  This simplifies implementations
  203. compared to using text based representations.  The lengthy Accept
  204. headers in HTTP/1.0 are avoided by using a bit vector for common cases
  205. with an extension mechanism for the rare occasions when these are
  206. insufficient.  Servers can challenge for payment.  A simple
  207. implementation of HTTPng was found to operate approaching an order of
  208. magnitude faster than HTTP/1.0 over an intercontinental link.  A
  209. transition strategy was described that allows existing HTTP/1.0 clients
  210. and servers to interoperate with HTTPng via proxy servers supporting
  211. both HTTP/1.0 and HTTPng.
  212.  
  213.  
  214. Discussion of the Charter
  215.  
  216. A show of hands indicated unanimous support for recommending to the area
  217. directors that a working group be set up for HTTP. The group briefly
  218. discussed the draft charter prepared by Roy Fielding.  Some minor
  219. revisions were agreed.  The meeting expressed confidence in Dave Raggett
  220. continuing as chair.  Subsequently, following a suggestion by John
  221. Klensin, to co-opt an IETF oldtimer as co-chair, Tim Berners-Lee agreeed
  222. to taking on this role.
  223.  
  224.