home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / http / http-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  10KB  |  205 lines

  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Minutes, HTTP Working Group, April 7, 1997, Memphis, TN.
  5. Reported by Ted Hardie
  6.  
  7. The group concentrated on closing outstanding issues.  Jim Gettys led
  8. a point-by-point review of the issues list
  9. (http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/).
  10.    
  11. In the discussion, the following issues seemed to have sufficient
  12. consensus in the meeting that "last call" will be sent to the 
  13. mailing list for each of them:
  14.    "chunked encoding" clarification
  15.    the caching issue raised by Dingle
  16.    accept-charset wildcarding
  17.    proxy authorization
  18.    the FIN-WAIT2 issue
  19.    Jeff Mogul's resolution for connection
  20.    and the impermissability of CRLF in a quoted string
  21.  
  22. Jeff Mogul's drafts on HTTP versions and proxy-revalidate will also go
  23. to last call in their current forms.
  24.  
  25. The following issues are resolved in principle, but require language
  26. to cover the needed editorial changes or clarifications:
  27.  
  28. -- Content-Disposition will be added to the Appendix, as one
  29.    of a group of common MIME headers about which implementors should
  30.    be aware; Koen Holtman will draft the addition.
  31.  
  32. -- The draft by Gettys et al on who should close the connection
  33.    represents valuable information and advice, but needs some
  34.    continued development.  A new version is expected shortly.
  35.  
  36. -- Richard Gray will provide language on sending 100 series response
  37.    codes with no date headers; Jim Gettys will then fold these into
  38.    the main document.  
  39.  
  40. -- Jeff Mogul will draft an explanation of how to cache resources
  41.    containing a "?" in the context of HTTP 1.1.
  42.  
  43. -- Paul Leach will provide an examination of the use of byte-ranges
  44.    with PUT, with the understanding that there was mild applause in
  45.    the working group for eliminating the possibility of PUT with
  46.    byte-ranges.
  47.  
  48. -- Ted Hardie will draft a missive on how to respond to a request for
  49.    a range of bytes for a resource which contains none of the bytes in
  50.    the range.
  51.  
  52. -- Roy Fielding's solution for how to define max-age for responses is
  53.    accepted in principle, subject to minor wording changes to be
  54.    worked out between Jeff Mogul and Roy.
  55.  
  56. -- Larry Masinter will author an implementation note on the
  57.    desirability of including charsets in responses.
  58.  
  59. -- Paul Leach will pen a note on a proxy being able to serve a
  60.    resource with a content-length when it received that resource with
  61.    chunked-encoding.
  62.  
  63. -- Scott Lawrence will provide a sentence or two which will cover the
  64.    possibility of leading zeros in a content-length.
  65.  
  66. -- Koen Holtman
  67.    will draft a clarification that a qvalue of 0.0 means "Don't send
  68.    me this."
  69.  
  70. -- After consulting the language in use in RFC822, Koen Holtman will
  71.    also draft an editorial correction on the use of LWS in headers
  72.    like VIA.
  73.  
  74. -- Jeff Mogul will respond to syntactic changes proposed by Koen
  75.    Holtman for the HTTP-warning draft; if appropriate, a new version
  76.    of the draft will appear.
  77.  
  78. -- The Hit-metering draft will go last call after Jeff checks it for
  79.    one last set of editorial revisions.
  80.  
  81. Not all issues reached closure.  For those which did not, particular
  82. individuals may have accepted responsibility for providing next steps.
  83. In all cases, however, input from others is solicited.
  84.  
  85. Josh Cohen will take responsibility for re-raising the issue of using an
  86. equality check for Date If Modified on the list.
  87.  
  88. While there is general agreement that 305 should be limited to use by
  89. origin servers, the proposal by Josh Cohen for 306 needs both concrete
  90. language and further discussion of the implications of a proxy-managed
  91. proxy redirect.  Josh Cohen will provide a draft explaining Netscape's
  92. vision for 306.
  93.  
  94. The issue of how to handle age calculations remains contentious; Jim
  95. Gettys has suggested that a small group interested in the problem should
  96. get together and work out a solution.  Those interested in being part of
  97. that group should volunteer on the list; implementors of proxy caches
  98. are particularly encouraged to share their experience.  To help minimize
  99. this issue, Jim will draft language which strongly encourages proxies to
  100. run with synchronized clocks.
  101.  
  102. Jeff and Henrik raised the issue of inappropriate client behavior on
  103. receipt of a content-encoding that it does not understand.  Henrik will
  104. draft a document a proposal to fix the problem; since this touches on
  105. the difference between different content- header types, careful review
  106. of the proposal by the working group will be needed.
  107.  
  108. Josh and Henrik will work off-line on the question of what a client
  109. should use in the HOST: header when it has a url with a host part that
  110. is not a fully qualified domain name.  Regardless of the outcome of that
  111. discussion, Paul Hoffman will draft language proposing that the client
  112. be allowed to chop the host part out of the URL and use that.
  113. Discussion of the two proposals should consider in particular the
  114. difficulties faced by clients which would have to resolve hosts into
  115. fully-qualified domains and the difficulties faced by proxies without
  116. access to fqdns as identifiers.
  117.  
  118. Henry Sanders will check Microsoft's implementation of chunked encoding
  119. to ascertain whether the Digest Authentication headers can be placed in
  120. the chunked encoding trailer.  If it does and there is no contrary
  121. implementation, the issue is closed; if it does not, the working group
  122. will need to examine the interoperability issues of allowing those
  123. headers in the trailer.
  124.  
  125. The question of sending a Retry-After with 503 and 3xx response codes
  126. has been tabled, pending Mr. Briscoe's providing a compelling reason for
  127. allowing the Retry-After.
  128.  
  129. Jeff and Henrik will write up a short draft on how to optimize returns
  130. on range requests by removing meta-data which is not needed to assure
  131. the client that the range returned is part of the correct resource.
  132. Henry Sanders will review based on implementation experience at
  133. Microsoft.
  134.  
  135. The issue raised by Koen Holtman regarding the asymetry in matching
  136. rule for accept language in 14.4 produced a great deal of debate on the
  137. appropriate matching semantics.  Dirk van Gulik will identify the
  138. appropriate ISO documents which indicate why matching semantics based on
  139. wildcards will not handle all cases.  Since HTTP's use of language tags
  140. is derived from RFC 1766, changes needed in HTTP might, in fact, reflect
  141. changes needed in RFC 1766.  Exactly how much of the matching algorithm
  142. belongs in the protocol is not clear, and further discussion will be
  143. needed on the mailing list.
  144.  
  145. Discussion of Koen Holtman's draft on Safe Post and Dave Morris' draft
  146. on UA-hint focused on two issues: whether safe post and history list
  147. manipulation belonged in the same mechanism and which of the two
  148. proposals best handled the issue.  No consensus emerged, but interest in
  149. this in certain user communities (Banks etc.) is high enough to warrant
  150. further work.  Some indications were given progress might be faster
  151. after splitting off the history list issue from the safe post issues
  152. required for i18n, but, again, no real consensus emerged.
  153.  
  154. Dan Connoly presented the new PEP draft.  Three major issues were
  155. raised: PEP can be overkill for some small, lightweight extensions; the
  156. cost of discovering whether or not a server understands PEP and a
  157. particular extension can be significant; and the draft's language for
  158. how to handle these extensions through HTTP 1.0 proxies does not seem
  159. adequate.  Koen Holtman suggests that the language in the hit-metering
  160. draft is a good model for how to handle PEP with 1.0 Proxies.  Dan will
  161. look at that language and the other objections; a new draft is expected.
  162.  
  163. Koen Holtman presented a portion of the TCN drafts; time constraints
  164. did not allow the group to consider the full set.  The base portion of
  165. TCN is now stable, and there are server side (Apache) and client side
  166. (Tango) implementations.  Preliminary indications from Dirk's
  167. experience as a server implementor are that this is a very successful
  168. mechanism for negotiation on things like image format, but that
  169. language and character set encoding need more implementation before
  170. they can be fully evaluated.  Yaron Golan (not speaking officially for
  171. Microsoft) noted that he did not feel that TCN was rich enough for the
  172. applications he envisioned; he felt that script-based solutions would
  173. be required for any meaningful content negotiation, and these
  174. solutions would both enable better server/author control and would
  175. shift the computational locus to the client.  Scott Lawrence and Ted
  176. Hardie spoke in favor of the TCN framework, noting that it was richer
  177. and leaner than Accept headers while being fully interoperable.  A
  178. counter-proposal by Mr. Briscoe will be sent to the list in the form
  179. of a paper.  The chair ruled after discussion that the working group
  180. is not ready for last call on these drafts.
  181.  
  182. Dave Kristol presented his new Cookie draft and discussed, briefly,
  183. the controversy which has surrounded the subject. ("In the case of RFC
  184. 2109, it was a Request For Comments, and it got some.")  Two classes
  185. of problems were raised: interoperability problems and objections to
  186. the default settings required by 2109.  The interoperability problems
  187. are being addressed in the new draft.  Those objecting have been
  188. invited to present alternative proposals.  Dan Jaye, of Engage
  189. Technologies, has proposed one solution, but it requires a public key
  190. infrastructure that would delay deployment too long.  His work and
  191. other solutions for resolving the tension between user privacy and
  192. traffic can go forward independently, but, based on Area Director
  193. input, we should not repeal what we have in favor of a technology
  194. which will take a year or more to put in place.  Interested parties
  195. should note that the W3C is putting together a forum to address this
  196. issue.
  197.  
  198. The session closed with the Chair noting that the main work of the
  199. group should be progressing HTTP 1.1 from Proposed to Draft Standard
  200. and that he hopes to close the working group by the next IETF meeting
  201. in Munich.  Other groups working on specific problems may be needed,
  202. but he believes we have reached a stage where they can operate
  203. independently.
  204.  
  205.