HTTP/1.0 Review Plan

Hi all,

By now, most of you should have downloaded the new draft 01 of the
HTTP/1.0 spec.  If not, it is available at

     http://www.ics.uci.edu/pub/ietf/http/
      ftp://www.ics.uci.edu/pub/ietf/http/
and
     http://www.w3.org/hypertext/WWW/Protocols/Overview.html
 
or from any of the Internet-Draft archives.

Our plan is to absorb as many comments as possible by August 18
and then produce a "final" draft by August 21 (final in the sense
that we believe it to be complete and reflects WG consensus on all
issues).  After another week of general comments, we would like to
submit it to the IESG as a Draft Standard (not Proposed, as said the
minutes from Stockholm) if there exists a rough consensus to do so.

In the mean time (between now and the 18th), I will be busy finishing
the HTTP/1.1 draft.  I would like to avoid getting too involved in
the debate over portions of the 1.0 draft, except where it becomes
necessary to describe the thinking behind some of the recent changes.
In particular, I would prefer it if people would attempt to understand
the draft without any recourse to the WG minutes, mailing list archives,
or the authors, since that is the intended goal of the specification.
By understand, I mean understand how you would implement each and
every feature described in the specification.  If you can't understand
a section, please make a comment to that affect and hopefully the WG
can propose specific wording that will fix the problem.

HTTP/1.0  Issues
================

There are a few outstanding issues that I am already aware of after
the weekend:

1) Content-Transfer-Encoding

   After discussion with the various camps, it appears as if the best
   thing to do is to simply forbid this header ever appearing in HTTP,
   and instead make it a requirement of gateways to do addition/removal
   of CTE when required by MIME.

   For HTTP/1.1, we can define a Transfer-Encoding header which has the
   analogous purpose, but without the MIME lossage.

2) Caching

   As far as I'm concerned, the 1.0 spec will not be complete until
   HTTP can be unambiguously cached.  In fact, this is now possible
   given the additions of "Pragma: max-age=NN" and a complete syntax
   for the URI header.  However, it seems clear that I will have to
   explain the algorithm for doing so as an appendix to the spec.
   It is also clear that we must require that servers mark content
   as being negotiated when that is so.

   The only alternative to the above is the complete removal and
   prohibition of any preemptive content negotiation.  Not supporting
   caching is not an alternative.

3) WWW-Authenticate

   The new spec now uses semicolon to separate parameters -- keeping
   it as comma-separated would prevent people from using more than
   one AA scheme per resource.  This will break existing implementations
   of Digest and PGP AA.  One alternative is to leave WWW-Authenticate
   as a fixed field (i.e., only describe it for Basic), and define a
   new syntax for an Authenticate header.

   The same applies to Authorization.

4) Comments in Headers

   I personally believe it is easier to define and parse a generic
   syntax for all headers than it is to have a separate syntax for
   each defined header.  Therefore, I have included the comments and
   \escape mechanisms of RFC 822 in the generic syntax.

   However, if the WG desires it, I can add the requirement that
   they only be allowed in those header fields which define "comment"
   as a possible field value, and then add that to User-Agent, Server,
   From, and Forwarded. 

Any others?

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Tuesday, 8 August 1995 18:30:16 UTC