Subject: Review of Content-Encoding: value token

From: Carine Bournez <[email-masked]>
Date: Wed, 21 Jan 2009 14:13:32 -0500

The Efficient XML Interchange (EXI) Working Group is seeking advice and 
review of a proposal for a new registered HTTP content coding token 
called "exi". 

The EXI Working Group has discussed the content type management issue and
is suggesting to use a Content-Encoding, whenever possible, in order
to retain the original XML or XML-based media type (e.g. xhtml, rdf,
svg...). We also register a fallback "application/exi" media type, for 
the protocols that have no Content-Encoding capability.

The EXI format specification is currently a Last Call WD [1]
The following text is the relevant part of the EXI specification 
from current editor's draft. 
(Note that the second paragraph has been added after discussion with 
the W3C Technical Archictecture Group at the November 2008 technical
plenary meeting).

-------------------------
F.1 Content Coding

Protocols that support a mechanism to indicate the encoding
transformation of the data being transferred (e.g. HTTP 1.1) SHOULD use
the label "exi" (case-insensitive) to annotate the transfer or the
request of data structured as an XML Information Set to convey the
actual use of or the acceptance of EXI encoding for the interchange that
is underway.

It must be noted that the "exi" content-coding is neither universal nor
byte- or character-preserving. First, it can be applied only to XML
documents that have an XML Information Set. Second, the information that
the coding preserves is that XML Information Set, not the actual
characters comprising the document. For instance, whether single or
double quotes were used to delimit attribute values is not preserved.

-------------------------

Thank you.

[1] http://www.w3.org/TR/exi

-- 
On behalf of the EXI Working Group,
Carine Bournez -+- W3C Europe

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 21 Jan 2009 12:01:17 -0800

> Dear HTTPbis Working Group,
>

No, it doesn't qualify as a content encoding or transfer encoding.
It is not decoded to the original type.  It is just another media type.
If you want to retain the original type (I have no idea why), then
put it in a parameter.  E.g., application/exi;orig="svg"

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Jan 2009 11:22:43 +1100

e.g., with ETag comparison, range retrieval, etc.

On 22/01/2009, at 7:01 AM, Roy T. Fielding wrote:

>
> On Jan 21, 2009, at 11:13 AM, Carine Bournez wrote:
>

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Jan 2009 07:07:21 +0100

> 
> Yes. If it doesn't preserve characters, all sorts of mess can result, 
 > ...

I was looking at 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.5>...:

"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."

...and was asking myself: is perfect reconstruction of the original 
payload really required? Is there something we need to fix here?

BR, Julian

---

From: David Morris <[email-masked]>
Date: Thu, 22 Jan 2009 22:40:57 -0800 (PST)

> Mark Nottingham wrote:
>> 
>> Yes. If it doesn't preserve characters, all sorts of mess can result, e.g., 
>> with ETag comparison, range retrieval, etc.
>> ...
>
> I was looking at 
> "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."
>
> ...and was asking myself: is perfect reconstruction of the original payload 
> really required? Is there something we need to fix here?

Exact reconstruction is always safest. But it seems to me that a new 
encoding for an html (or xml) document which stripped trailing blanks and 
tabs might satisfy the above constraints. Since ETag creation is the 
responsiblity of the origin server, I don't think the transformation I
describe would matter. The ETag would need to change if the pre-encoding 
content changed.

On the principal that encoding performed by the content owning server
needs to satisfy the semantics of "without loss of informtion" as judged 
by the content owner. I can think of cases where the content owner would
find automatic image scaling to match HTML specified height and width
appropriate encoding ...

I'm not advocating either of the above as anything more than examples of 
new encodings which shouldn't be excluded by a restriction for exact 
reconstruction of the original object.

Dave Morris

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 30 Jan 2009 18:48:49 +1100

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.

Cheers,

On 23/01/2009, at 5:07 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> Yes. If it doesn't preserve characters, all sorts of mess can  
>> result, e.g., with ETag comparison, range retrieval, etc.
> > ...
>
> I was looking at <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.5 
> >...:
>
> "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."
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jan 2009 09:29:25 +0100

Mark Nottingham wrote:
> 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.
> 
> 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