Re: CONTENT-ENCODING: FIXED revised proposed wording

Koen Holtman writes:
    
    >	(1) If the content-coding is one of the content-codings listed
    >	in the Accept-Encoding field, then it is acceptable. (Note that,
    >	as defined in section 3.9, a qvalue of 0 means "not acceptable".)
    
    This is slightly self-contradictory.
    
I know, I realized when I wrote it that it's a little awkward.  I was
trying too hard to be brief.  How about:

    (1) If the content-coding is one of the content-codings listed
	in the Accept-Encoding field, then it is acceptable, unless it
	is accompanied by a qvalue of 0.  (As defined in section 3.9, a
	qvalue of 0 means "not acceptable".)
    
Note that the section on Accept-Charset leaves this implicit, by
using the term "acceptable" without specifically defining it.

    >	(2) The special "*" symbol in an Accept-Encoding field matches
    >	any available content-coding.
    
    ..except those listed explicitly in the header field.

Sorry, my mistake.  This should be

    	(2) The special "*" symbol in an Accept-Encoding field matches
    	any available content-coding not explicitly listed in the header
	field.
    
Perhaps someone should check to see if the specification for Accept
(which allows "*/*" wildcards) needs the same correction.  It looks
like Accept-Charset (via draft-holtman-http-wildcards-00.txt) and
Accept-Language say the right thing.
    
    >    If no Accept-Encoding field is present in a request, the server MAY
    >    assume that the client will accept any content coding.  In this
    >    case, if "identity" is one of the available content-codings, then
    >    the server SHOULD use the "identity" content-coding.
    
    This SHOULD was not present in 2068, and I don't think adding it is a
    good idea.  A server which knows that a legacy client accepts an
    encoding (e.g. by looking at the user-agent field) should be
    encouraged to send content in this encoding.

The point was to fix the mistake in RFC2068, which explicitly
encourages a server to send "any content encoding" in this case.
And Henrik has demonstrated that this causes garbage-on-the-screen.

But it makes sense to modify it slightly:

    If no Accept-Encoding field is present in a request, the server MAY
    assume that the client will accept any content coding.  In this
    case, if "identity" is one of the available content-codings, then
    the server SHOULD use the "identity" content-coding, unless
    it has additional information that a different content-coding
    is meaningful to the client.

"Additional information" could be User-Agent, or the belief
that all relevant clients handle gzip, or whatever.

-Jeff