Re: Potential New Issue: The Boundaries of Content Coding

* Robin Berjon wrote:
>In short, I think that it boils down to defining what exactly may  
>constitute content coding.

As far as practical advice for the EXI Working Group is concerned, it
does not. What matters here is how people are going to use the format
under consideration. If a significant portion of the format's users
are going to use it by going

  Save as EXI SVG -> ftp/scp to server -> HTTP

then you will end up with a considerable amount of content that does
not properly declare its MIME type and/or Content-Encoding, and you
will have to sniff the payloads to figure out whether the content is
EXI SVG or something else. If your architecture then assumes something
else, it's broken. So either

  * People won't create and publish their EXI SVG content as above,
    in which case it would seem that the EXI "encoder" sits on the
    server and we would be talking transfer encodings, not content
    encodings, or

  * People will do what is outlined above, and there would only be
    two solutions left, either one file extension and MIME type for
    all EXI content, or we change the relevant XML specifications
    to let XML processors sniff for EXI just like they sniff for
    character encodings

application/fastinfoset does it the pseudo character encoding way,
such resources may start with <?xml version="1.0" encoding="finf"?>
and a number of similar strings; deployed XML processors then handle
it as if they simply don't support the 'finf' character encoding.

Your comparison with 'gzip' is a good one, that's a success story:

  http://lists.w3.org/Archives/Public/www-tag/2004Dec/0008.html

Looking at these figures, I have an idea what we will end up doing.

In any case, the TAG is chartered to clarify principles of Web
architecture, and "What is the range of content codings that meet
the requirements of RFC 2616" is not so much of a principle; and
whatever RFC 2616 might say, I don't see why the EXI Working Group
should feel constrained by it, so long as they can make a sound
argument to defend whatever design they might choose.

Received on Saturday, 2 September 2006 21:55:53 UTC