W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2003

Re: Options for flagging MTOM processing

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Wed, 30 Jul 2003 10:40:17 -0700
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
To: Robin Berjon <robin.berjon@expway.fr>
Message-Id: <E21C1E4D-C2B4-11D7-BF6E-00039396E15A@bea.com>


On Wednesday, July 30, 2003, at 02:31 AM, Robin Berjon wrote:

> Mark Nottingham wrote:
>> * HTTP Content-Coding
>> Need for processing will be flagged by use of a HTTP content-coding, 
>> e.g., "Content-Encoding: mtom".
>
> Is this advisable? Couldn't it be stacked with, say, gzip or other 
> content codings? There was discussion yesterday on limitations of HTTP 
> content codings wrt binary infosets. Perhaps MTOM would also benefit 
> from that?

You can have multiple, serialized content-codings, e.g., 
"Content-Encoding: mtom, gzip".

I've heard the following concerns raised about the content-coding 
approach:
   - The notion of a content-aware/-specific content-coding is troubling 
to some. It's not explicitly ruled out or even discouraged by HTTP, but 
it is a bit odd.
   - This solution is specific to the HTTP, and would need to be 
reinvented for other transports.
   - Although it's a property of the HTTP entity, there's no recognized 
way to persist content-coding information on disk, so it would be 
implementation-specific; e.g. if "foo" uses content-coding "gzip", it 
could be persisted as "foo.gz", but that's just a local convention. I 
don't see this as a huge drawback, especially since we're doing MTOM as 
a binding feature, but others might.
Received on Wednesday, 30 July 2003 14:02:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT