mime vs xml header

["Kit (Christopher) Lueder" <kit@mitre.org>]

> Dick Brooks wrote:
> I don't recall the name of the person assigned to produce the document, it
> may have been Kit Lauder.

Hi Dick,
I agreed to coordinate discussion on the MIME vs XML header question. I
don't think there was a particular document planned for that, aside from
our regular deliverables. Anyway, let's try to wrap up the MIME vs XML
header issue tomorrow's teleconference, if we can. I think we should be
prepared for a vote for your preference, MIME-based envelope, XML-based
envelope, or both.
Kit.

To recap:

On Thursday, 3/9, I posted a message giving a high-level summary of the
two enveloping approaches: mime envelope (from Dick/Nick's paper) and
pure XML envelope.


> Mark Crawford wrote (lots of questions, few answers), Friday 3/10:
> It appears to me that one of the things missing in the mime vs. XML debate is
> what are the XML server developers and XML business standards bodies doing.  At
> the Orlando meeting, Rik indicated the transport group was going to look at
> different enveloping solutions, including RosettaNet and BizTalk.  Did that
> happen?  If so, what were the results? (yes I know RosettaNet uses Mime and
> BizTalk supports Mime for binary data, but does that mean we adopt Mime as "the"
> solution?).  By the same token, are there representatives in the transport group
> from such companies as - webMethods, Bluestone, Microsoft, Sun, IBM and others
> involved in developing industrial strength XML servers? ...


On Saturday 3/11, David Burdett responded to Dale Moberg regarding using
XML or MIME to wrap arbitrary content.


On Monday 3/13, Dale Moberg posted an elaboration (Almost-everywhere XML
Packaging for ebXML: strawman for discussion) of my XML proposal,
showing tags for <XMLPackage> and other MIME-like attributes.


Here is a revised version of my (Kit's) list of benefits of both
approaches, after trying to capture the discussion of the last week:
Benefits of MIME envelope:
 - If you are using e-mail, it falls out automatically. The design 
proposed by Dick & Nick is intended to be the same as what is 
supported by browsers now.
 - If you want to parse the header but don't want to parse the body
(content), some XML parsers aren't able to arbitrarily stop in the
middle of
a document. (e.g., if you have an ebXML envelope around a huge document
content and don't want the overhead of parsing the whole thing.) MIME
allows the header to be a separate attachment from the body, so they can
be parsed separately. 
 - If you have an XML parsing error anywhere in the document, the parser
fails. Thus an error in the content will kill parsing of the envelope,
if it is all XML. The MIME processor can be tolerant of errors in 
the MIME envelope (e.g., ignore  unrecognized tags).
 - MIME can still handle the attachment even if the content-body is not 
based on XML, e.g., to support a binary attachment.
 - Having the attachment separate from the header within the MIME
message 
allows the attachment to be compressed or encrypted without concealing 
the headers.

Benefits of pure XML solution (no MIME envelope):
 - It is a pure XML solution, which meets the possible "ebXML
requirement" of our solution being W3C-compliant. Only one technology
is used for it.
 - Publishing a pure XML solution merely involves creating an XML schema 
on a repository.
 - You don't have to do special processing to strip the MIME envelope
before feeding the XML stuff to the XML parser.
 - If you have a web server and a user fills out and submits a web form,
I suspect it is easier for the server back end to generate pure XML,
rather than having to generate a MIME envelope as well.
 -  Some event-based parsers and maybe SAX parsers
could support parsing just the envelope (per Matthew MacKenzie). You 
might need to know in advance that it is an ebXL envelope, though (per
David Burdett), such as with a transport parameter such as: 
message-type: ebXML.

Aspects that are applicable to both approaches (per Prasad Yendluri 
<pyendluri@vitria.com>):
 - The ability to pack together varying number of, disparate content
types(xml and non-xml including binary forms), without having to resort
to
special conversion / data encoding schemes (e.g. binary to UUENCODE).
 - To keep business content independent of and disjoint from routing
information so that, entities performing the routing (potentially third
parties), don't need to (or should not) look into the business message. 
 - Facilitate detection and reporting of errors back to the originating
party (by the receiving party), even if the business content is not
something handled by the receiving party. That is, have a well defined
standard header and variable business content, that are packed together.


-- 
    _/    _/             Kit C. J. Lueder       
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
 _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
_/    _/  _/    _/   McLean, VA 22102        Mail: kit@mitre.org
Worse than an unanswered question is an unquestioned answer.