On Wed, May 02, 2001 at 07:57:04PM -0500, Brandon wrote: > > > > Why not just use the Content-Type field and set it to application/x-gzip? > > > Why add another metadata field? > > > > Because that's actually a technically wrong use of Content-Type. I forget > > which RFC I read about this in, but it was one of the HTTP or MIME ones. > > Content-Type is supposed to be set to, well, the content type, which is > > independent of how the content is encoded .. hence the Transfer-Encoding > > header in HTTP. > > The metadata field is not an HTTP header field, it is a Dublic Core > metadata field. When using FProxy, an HTTP header field with a confusingly > similar name is generated in order for FProxy to act appropriately as a > web proxy. However, the meanings of HTTP header fields with similar names > is totally irrelevant to the metadata standard, which is not based on > HTTP. So arguements about misusing the meanings of headers are irrelevant. > > The question is, do we need an encoding header in addition to a content > type header? I don't think we do, as explicated below.
Brandon, I mentioned the parallels with HTTP and MIME because the same arguments that make it technically wrong to conflate Content-Type with Transfer-Encoding apply to us as well.
