- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Wed, 30 Jul 2003 10:40:17 -0700
- To: Robin Berjon <robin.berjon@expway.fr>
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
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 UTC