W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

Re: ISSUE CONTENT-ENCODING: Proposed wording

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 9 Jul 1997 21:13:57 +0200 (MET DST)
Message-Id: <199707091913.VAA04659@wsooti08.win.tue.nl>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3702
Henrik Frystyk Nielsen:
>These are the suggested changes regarding the problems in content-encoding
>and accept-encoding as described in
>        http://www.w3.org/Protocols/HTTP/Issues/#CONTENT-ENCODING
>1) In section 3.5 (Content Codings), add this after the item for "deflate"
>        identity        The default (identity) encoding; the use
>                        of no transformation whatsoever.  This
>                        content-coding is used only in the
>                        Accept-encoding header, and SHOULD NOT

Make that MUST NOT please, else conformant clients will have to have
stupid ignore-the-identity-encoding if-statements in the parser for the
content-encoding header field.

>   An empty Accept-Encoding value indicates that only the "identity"
>   content-coding is acceptable.

If I understand this right, this says that


is identical to

 Accept-encoding: identity

which seems a bit odd.  Why not delete the above rule completely?

Also, am I right in assuming that

 Accept-encoding: gzip

now implies that the identity coding is _not_ acceptable for the
response?  If I am not right, then the text is too ambiguous.

Overall, I think that replacing the concept of `no encoding' from the
old draft with `identity encoding' does not improve the text of the
spec.  But it does not break the spec in a semantical sense, so I
could live with these proposed changes.


Received on Wednesday, 9 July 1997 12:16:22 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:02 UTC