RE: Binary XML

[Michael Brennan <Michael_Brennan@allegis.com>]

I hit "send" too quickly. Two other points worth mentioning:

When I said it's legal for intermediaries to alter text content, I should
clarify that there are rules around that. Basically, the intermediary can
alter white space (e.g. wrap long lines, translate line feeds, change the
character encoding, etc.). If binary content is misidentified as a text
media type, or not identified at all and mistakenly interpreted as text,
then the binary data can be corrupted due to this.

Since intermediaries are not supposed to interpret or alter binary types,
you can use the media type of "application/xml" rather than "text/xml" for
XML payloads, and the rules that apply to intermediaries are different. An
intermediary is supposed to treat "application/xml" as binary data, which
means it should not alter white space, change the character encoding,
translate line feeds, or anything else that means changing any of the bytes
on the wire. So when maintaining document content byte-for-byte is
important, you should always use an "application/*" media type, not a
"text/*" media type.

> -----Original Message-----
> From: Michael Brennan 
> Sent: Thursday, July 26, 2001 2:21 PM
> To: 'Stuart Naylor'; Michael Brennan
> Cc: xml-dev@lists.xml.org
> Subject: RE: Binary XML
> 
> 
> I'm not aware of any limitation sending binary content 
> through port 80. I've done it plenty of times without 
> problems. I would imagine, though, that an HTTP request (or 
> response) that fails to properly identify it's media type 
> might be mangled by an intermediary. Perhaps someone with 
> deeper protocol understanding than myself might wish to 
> comment, though.
> 
> HTTP is MIME-like in that it supports a number of standard 
> MIME headers (and a few of its own). No special MIME wrapper 
> is needed. Just specify the appropriate Content-Type header. 
> Intermediaries are free to interpret and alter text content 
> (e.g. Content-Type: text/xml), but are in violation of the 
> spec if they interpret or alter non-text content (e.g. 
> Content-Type: application/zip). Also, you can employ binary 
> compression so long as you properly identify the protocol 
> used via the Content-Encoding header. (It's also legal to use 
> Content-Transfer-Encoding for this, but I think 
> Content-Encoding has broader support in applications, at 
> present. Both IE and Netscape, for instance, will properly 
> recognize gzip-compressed data if the HTTP message includes 
> "Content-Encoding: gzip".)
> 
> You can also use MIME multipart formats to transmit multiple 
> documents over HTTP in one message. This is another area, 
> though, where you run the risk of being incompatible with 
> other tools. However, in the XML messaging world, the SOAP w/ 
> Attachments spec and ebXML have given some momentum to use of 
> multipart/related wrappers over HTTP, so the level of support 
> for this is rapidly increasing.