Re: Negotiation in draft 01

>All current browsers do accept all formats, in the form of the Save As..
>dialog.  The WG decided that it was better to assume the best than to
>require all clients to be compliant before the feature could be used.

Because I have Save As and an old browser I like sanskrit as much as I like
us-ascii?  I can see the point of a change from 0 encoding and/or charset
quality (on lack of the header) to a positive encoding and/or charset
quality, but all the way to 1?  .001 seems infinitely more appropriate.

>Any server that breaks on an empty field value is already broken,
>regardless of what the spec requires.  I can restore the 1#( if that

I'm sure our server is immune, but I can sympathize with the idea that
others might break given this previously unexistant construct (valid headers
that have no body) being introduced.

>implementations.  Besides, how is the client supposed to say that they
>do know about Accept-Encoding, but don't accept any?

I'm beginning to wonder if a construct like */* and q aren't needed for all
the Accept-Foo: headers. As in "Accept-Encoding: *;q=0.0".  Of course, then
you'll have to explicitly outlaw "Accept-Charset: iso-8859-1;q=0.0" or
similar special cases.  If we decide we really want to handle every special
case, we should also give someone the ability to indicate that they *only*
take zipped files or sanskrit files.  More work for me, but I'd rather have
a sped'c way of doing everything for completeness' sake.  Anything less
would be uncivilized.

>>5.  If qe and qc default to 0.001 instead of 0, do we provide a client with
>>[...]
>>under 01 there's no way for the robot to avoid having such content sent to it.

>Yes, that is true.  Unfortunately, current clients do not send an
>Accept-Charset header even if they do support multiple charsets.
>I was overruled once on this matter, and the WG will have to state clearly
>what they want if I am to change it back again.

Not having any way to indicate "effective quality zero" on charsets and
encodings seems like a soundly bad idea.  Why give the user-agent the abilty
to refuse text/plain, but not refuse unicode or ARCed files? (remember ARC,
good luck finding a deARCer nowadays).

I can't imagine anyone being satisfied with the current content negotiation
scheme.
-----
Dan DuBois, Software Animal                          ddubois@spyglass.com
(708) 505-1010 x532                     http://www.spyglass.com/~ddubois/

Received on Wednesday, 9 August 1995 06:14:31 UTC