home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / http / http-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  5KB  |  147 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Jim Gettys/DEC - W3C
  5.  
  6. Minutes of the HyperText Transfer Protocol Working Group (HTTP)
  7.  
  8. These minutes are based on notes taken by Henrik Nielsen.
  9.  
  10.  
  11. HTTP 1.0
  12.  
  13. A final draft needs to be produced before the group can finish all
  14. discussion.  The draft will be available 1 August, for anticipated Last
  15. Call later in the month.
  16.  
  17.  
  18. Access Authentication - MD5 Digest
  19.  
  20. There are really no objections to the current state of this proposal.
  21. HTTP does not provide the possibility of having MIME headers after the
  22. HTTP object.
  23.  
  24. There are multiple implementations:
  25.  
  26.  
  27.    o NCSA server and client
  28.    o Spyglass
  29.    o Dave Kristol's server
  30.  
  31.  
  32. HTTP Session Extension
  33.  
  34. Ted Hardie, NASA, led this discussion.
  35.  
  36.  
  37.    o This proposal would avoid TCP latency, overhead, and slow start
  38.      performance problems.
  39.  
  40.    o Ted described a proposal from Alex Hopmann, who was not present.
  41.  
  42.    o Henrik noted that Request-ID header makes the proposal more
  43.      flexible as the server can send them back out of order
  44.  
  45.    o There was general talk about sessions with a server.
  46.  
  47.    o Jeff Mogul of DECWRL has made an extensive study and simulation of
  48.      persistent connection HTTP. The results of this work can be found
  49.      at:
  50.  
  51.      http://www.research.digital.com/wrl/publications/abstracts/95.4.html
  52.  
  53.    o Is it a good idea to save headers while a connection is kept alive?
  54.  
  55.       -  Eric Sink:  No big advantage -- 10% (from implementation).
  56.  
  57.       -  Larry Masinter:  for almost all headers, it's a win; the only
  58.          issue is those headers for which there is no way to say 'the
  59.          default' by giving a header explicitly.
  60.  
  61.       -  Authentication may be the biggest performance win.
  62.  
  63.  
  64.    o A number of implementations were mentioned; performance is unclear,
  65.      and most likely to be seen over long haul and dial up lines, rather
  66.      than in a local network, where most naive tests are performed.
  67.  
  68.    o The general consensus is that persistent connections are a good
  69.      idea.  There are concerns about upward compatibility and
  70.      interoperability with 1.0; this may or may not require 1.1; it was
  71.      suggested that operation under 1.0 might be written up as an
  72.      experimental protocol.
  73.  
  74.    o An open question is the timeouts for the TCP connection; there is
  75.      some data from Jeff Mogul's simulation.
  76.  
  77.  
  78. Problem With HTTP PUT and POST
  79.  
  80. Henrik Nielsen described a problem with HTTP PUT and POST that has
  81. recently been uncovered, and solicited feedback.
  82.  
  83.  
  84. HTTP/1.1
  85.  
  86. A HTTP/1.1 draft will be available in mid-August.
  87.  
  88.  
  89. HTTP/NG
  90.  
  91. HTTP/NG: Andy Norman, Ange@hplb.hpl.hp.com.  Stefek Zaba has an
  92. experimental implementation of what they call HTTP/NG, and has been
  93. talking to Simon Spero.  Simon was not at the meeting, so there was
  94. little discussion of NG.
  95.  
  96. Larry Masinter pointed out that people are trying to do transactions
  97. with HTTP when HTTP does not have a transaction mechanism (e.g., when
  98. you try to abort an operation in the middle, you have no way to know
  99. whether or not it completed).
  100.  
  101. Many RPC implementations do what people are trying to do with HTTP-NG:
  102. keep connections open, let them time out, handle more complex
  103. operations, interleave multiple calls and results on the same
  104. connection.
  105.  
  106. This begs the question:  Who has implemented a non-blocking (streaming)
  107. RPC system that can be used if we are to avoid rolling our own?  Does it
  108. have the needed facilities?
  109.  
  110. John Klensin, Applications Area co-Director, expressed great displeasure
  111. with the current state of the working group.  Some issues he raised, but
  112. not necessarily an exhaustive list include:
  113.  
  114.  
  115.    o Working group chairs that do not warn the Area Director before an
  116.      IETF meeting that they cannot attend are asking to be shot.  John
  117.      promised to convey his displeasure directly to the chairs.
  118.  
  119.    o How will we make progress?
  120.  
  121.    o We have a collective problem in the working group.  We should stick
  122.      to the milestones.
  123.  
  124.    o Without NG as a milestone for this group, 1.1 will likely end up
  125.      out of control.  Without Simon Spero present, and with his RSI
  126.      problems, John is very concerned about NG. Jim Gettys volunteered
  127.      to edit HTTP/NG, if Simon is unable to deal with it due to his
  128.      problems.  When will it become a Proposed Standard?
  129.  
  130.  
  131. Harald Alvestrand, Applications Area co-Director, noted that there is no
  132. reason to wait for an IETF meeting to send a document to the IESG for
  133. standardization.
  134.  
  135.  
  136. Proposed New Milestones
  137.  
  138.  Aug 1995  Send HTTP/1.0 of to the IESG as a Proposed Standard.
  139.  
  140.  Oct 1995  Session as experimental extension.
  141.  
  142.  Apr 1996  HTTP/1.1 as Proposed Standard.
  143.  
  144.  Dec 1996  HTTP/NG as Proposed Standard.  Jim Gettys volunteered to
  145.            help Simon with writing.
  146.  
  147.