Subject: Re: Review of Content-Encoding: value token

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Feb 2009 14:46:19 +1100

Well, if we leave the text how it is, it will have that effect...

On 30/01/2009, at 7:29 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> My concern is that many implementations treat content-coding like  
>> transfer-codings, in some ways; that is, they layer it in  
>> automatically (e.g., mod_gzip). The confluence of this with things  
>> like byteranges, etag comparison, etc. may be quite prone to bugs.
>> You'd also start to get into discussions like "can't JPEG just be a  
>> content-coding of GIF?" and so forth. The media type system isn't  
>> perfect by any means, but I think it's a better fit for this type  
>> of thing.
>> ...
>
> I agree with that, but right now the spec doesn't really state that.
>
> Should we change it?
>
> BR, Julian

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Feb 2009 11:30:05 +0100

> Well, if we leave the text how it is, it will have that effect...

Clarifying: I do agree that using Content-Encoding for encodings that 
are lossy on the octet stream level probably is a bad idea.

And yes, implementations that introduce content codings need to make 
sure that outgoing (Etag:) and incoming etags (conditional headers) are 
transformed correctly. If that's not yet clear enough in the spec, we 
should improve it.

That being said, the current spec text about Content Codings says:

"Content coding values indicate an encoding transformation that has been 
or can be applied to an entity. Content codings are primarily used to 
allow a document to be compressed or otherwise usefully transformed 
without losing the identity of its underlying media type and without 
loss of information." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-05.html#rfc.section.3.2>

I can see that in this case (when encoding an XML document in a new 
binary encoding), some people will argue that indeed there is no loss of 
information.

So,

- is it allowed (do not change the spec), or

- is it allowed, but considered a bad idea (add a note to the spec?), or

- it it disallows (clarify the spec to speak about octet-by-octet identity).

BR, Julian

---

From: Yves Lafon <[email-masked]>
Date: Tue, 3 Feb 2009 05:58:40 -0500 (EST)

On Tue, 3 Feb 2009, Julian Reschke wrote:

> Clarifying: I do agree that using Content-Encoding for encodings that are 
> lossy on the octet stream level probably is a bad idea.

Well, I can see this as a strong requirement for TE, but for 
Content-Encoding, it is less of a requirement, as we do not expect to be 
able to use metrics given in the HTTP message on the "decoded" entity.

> And yes, implementations that introduce content codings need to make sure 
> that outgoing (Etag:) and incoming etags (conditional headers) are 
> transformed correctly. If that's not yet clear enough in the spec, we should 
> improve it.

You mean when serving both versions from the same URI without any CL ? 
Then yes.

> "Content coding values indicate an encoding transformation that has been or 
> can be applied to an entity. Content codings are primarily used to allow a 
> document to be compressed or otherwise usefully transformed without losing 
> the identity of its underlying media type and without loss of information."

"information" being fuzzy enough to allow content-coding to be lossless at 
the byte-level.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves