Re: Allow EXI as characterization for XML in the JMS body ?

On Mon, 29 Nov 2010, Amelia A Lewis wrote:

>> c) In the case of a multipart message using, for example, MTOM, is it
>> even possible to apply EXI for the XML part of the MIME multi-part
>> payload?
>
> I want to say, "yes, certainly!" but then I went to look at the
> governing documents at the IETF, and I'm not so sure.
>
> RFC 2616 *does not define* the handling of multipart (or "composite" to
> use the MIME-defined technical term) messages.  All HTTP entities are
> single resources.  There's an extension that allows a new form of
> composite to be used for PUT (but not for resource retrieval).  In
> order to permit multipart, you have to go to RFC 2557--defined before
> 2616, and not since updated--which defines "MHTML", or MIME
> Encapsulation of Aggregate Documents.  SOAP with Attachments references
> MHTML, although with differences (MHTML is actually defined so as to
> allow transmission of HTML with its supporting files, such as images
> and stylesheets, over a MIME-compliant protocol, not over HTTP).  MTOM
> was defined, in part, because MHTML is a rather sloppy format (and in
> part because, as a MIME extension, it's fundamentally incompatible with
> HTTP, even though SOAP with Attachments used it precisely as a "MIME
> over HTTP" standard).
>
> So ... in order to determine how these un-specified issues are properly
> resolved, we need to check how other specifications handle this.  The
> most prominent examples are SOAP with Attachments and MTOM/XOP.  This
> may clarify things a bit.  Neither of these specifications creates
> HTTP-style entities inside the outermost container.  That is: both
> specifications use pure MIME parts inside the multipart/related outer
> composite part.
>
> Okay.  Distinguishing MIME from HTTP near-MIME: MIME requires a
> MIME-Version header where HTTP forbids it; MIME requires
> Content-Transfer-Encoding or defaults to 7bit where HTTP *forbids*
> Content-Transfer-Encoding and defaults to 8bit; Content-Length is
> unknown for MIME where it is required by HTTP (unless Transfer-Encoding
> specifies chunked); Content-Encoding and Transfer-Encoding are unknown
> in MIME and are defined by HTTP.  One consequence is that the
> "per-specification" answer to Eric's question is "No, that is not
> permitted."
>
> Following the specifications would lead one to creating MIME-compliant
> "packages" for SOAP with Attachments or MTOM/XOP and then tearing off
> the "MIME-Version" and "Content-Transfer-Encoding" headers from the
> outermost part, replacing them with Content-Length, Transfer-Encoding,
> and Content-Encoding as needed.  If you do that, you won't
> interoperate.  All of the SOAP implementations that I know of use HTTP
> headers inside the encapsulated MIME parts (Content-Length, in
> particular, is often required, and I have never seen an implementation
> that treated a part missing a Content-Transfer-Encoding header as 7bit
> US-ASCII).
>
> Probably not really helping?  We're in an awkward position; the
> specifications don't really match practice.  We're writing a
> specification, but we need to write one that doesn't actually
> contradict practice.  I don't know how we find the way out.

EXI is indeed defined as an HTTP Content-Coding Value [1], which means 
that it can be used in HTTP headers but not in MIME headers within the 
mime-multipart package (which is treated as payload by HTTP). So I can see 
that in practise people might want to use it or even use it (and in fact 
it would be logical and useful), however it would be wrong to so do, per 
spec.

[1] http://www.iana.org/assignments/http-parameters/

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

         ~~Yves

Received on Wednesday, 1 December 2010 13:11:59 UTC