Re: Grievances - Focused

> 1)
> First things first: the most concrete complaint I have about the latest
> http draft is that we're still defaulting to qe=1 and qc=1 for encodings
> and charset when the headers are missing.  The way I see it, this isn't
> just my opinion, but rather, this is just broken.  A 1.0 user agent could
> ask for a document, not be aware of encodings or charsets, click on stuff,
> and according to the current spec, receive "stuff.txt.zip".

Yes, and that exactly matches current practice.

> 1) The User
> gets garbage on their screen, and 2) they might not even have the
> opportunity to do a successful Save As, as a browser might have done
> end-of-line translations or high-bit stripping.  The default encoding and
> charset during lack of headers should be 0.001.  This has been discussed
> before.

Yes, this was discussed before, and the decision made on this list was
that lack of headers meant qe=1 and qc=1 and that if the client wished
to exclude other encodings and charsets, then

     Accept-Encoding:
     Accept-Charset: iso-8859-1

is what the client must send.

> 2)
> Personally, I don't understand the existence of the version control
> methods in the current spec.

They are there to support collaborative systems.  They are also optional.

> This is a glaring example of something that
> can easily be moved out to a separate draft.  The main implementors of
> the HTTP spec in the marketplace are not even using PUT: PATCH and MOVE
> are really fringe niche interests.

Ahem. May I remind you that one person's fringe interests are another
person's requirements.  The fact that the industry has only implemented
HTTP/1.0 is irrelevent to what goes in the initial draft of HTTP/1.1.
If the industry does not implement these features *by the time HTTP/1.1
is ready to proceed outside the WG*, then they will not be in the final
document(s).  However, if two implementations of these features do
exist and are interoperable, and the features are optional, then they will
be represented in the final standard (perhaps as a separate document,
but that is a non-issue).

> 3)
> I heard a number of people express the feeling that Content negotiation is
> a large, independent module that could be removed from HTTP for faster
> consensus, and also something that should be accessible to other protocols.
> I think the example of enhanced SMTP was given.  Let's see that happen!

We cannot discuss hierarchical caching without also discussing content
negotiation and its effect on the request/response semantics.  Since
HTTP/1.1 will not progress without caching, content negotiation cannot
be removed from the HTTP/1.1 standard.  One way or another, this WG must
deal with the questions at hand regardless of whether it is all done
in one document or in multiple documents.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Saturday, 9 December 1995 19:14:04 UTC