Re: Content-Encoding confusion

At 07:50 PM 2000-04-26 -0400, Hugo Haas wrote:
>
>My understanding of that is it is encoding of the transfer, not of the
>data.

Sorry, but assuming there is a binary answer just muddies the question.

The content type is itself ususally and encoding of a deeper form of
representation.

The transport protocol agents may yet apply another content transfer
encoding over the "content encoding" and strip it transparently to either
of the above.

So:

Content-Encoding means that it is an encoding [transformation] applied
after the content is in the form indicated in the Content-Type parameter
and before presentation to the HTTP transfer agent for transport.

The default behavior of User Agents is to strip the Content-Encoding and
recover the content in the form compliant with the Content-Type indication.
 The [default] file identification by which the content is identified in
the local file system when so saved should comply with the practices of the
local file system as to the patterns of file identification which best
match the data form saved in the file.  So, yes, saving data that is in PDF
format in a file named .tgz in Windows is not cool.

>
>What is the correct behavior (of both clients and servers)?
>

I believe that your interpretation of the ideal or most desirable behavior
is correct.

I would want to hear about the actual behavior prevalent in the field
before deciding where to go next with this.

Coordination with the ietf-types list seems appropriate.

To the extent that there is an extant "header harmonization" caucus across
the "sons of RFC-822" it would seem prudent to stay in touch with wherever
that is happening, if not on ietf-types.  Explanation: to the extent
possible it is desirable to define and use common headers or at least a
compatible information model for manipulating type information across HTTP
and MIME and anything else which communicates type information similar to
what is exposed in Content-Type and Content-Encoding.

Al

Received on Tuesday, 2 May 2000 16:52:28 UTC