RE: XML based Manifests vs Multi-part-related MIME encoding of multi-part messages

["Dick Brooks" <dick@8760.com>]

Jim,

The approach you describe requires the transport mechanism to treat XML data
differently from all other types. What really bothers me about this idea is
that it only has
one purpose (that I can see), to be PURE XML. I fail to see the value of
PURE XML.

It seems to me an ebXML solution based on MIME, could handle ALL object
types (with embedding) and eliminate all the
special handling and complexity required to support both a MIME and XML
based packaging mechanism.

Am I missing something?

Dick Brooks
http://www.8760.com/

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of James
McCarthy
Sent: Monday, March 13, 2000 9:21 AM
To: ebXML Transport (E-mail)
Subject: RE: XML based Manifests vs Multi-part-related MIME encoding of
multi-part messages


My preference is to define an XML solution that provides an envelope for
both the header and the body when it is composed of XML data (this will
probably be 90% of the cases). This is the pure XML solution. When data not
appropriate for XML is required then the manifest tag would indicate how to
obtain this data (i.e. within the request as a named MIME element or via an
external URI).

This would mean that the implementation has to handle the following:

1. If a Multipart mime message is sent then the implementer must be prepared
to handle multiple entities for the message. The header and XML body will
still be fully wrapped in the ebXML envelope.

2. If the message is not multipart mime then the implementer can assume it
is a single header and body in an XML envelope (but still may have external
entities via a URI reference in the Manifest).

This means that in all cases if the message is XML based then it will be
fully enclosed in an envelope. If the message contains other entities then
it becomes transport specific as to how the additional entities are
represented and identified (mime will be the standard).  In the case of HTTP
we should define how a multipart mime message is handled but we should not
force feed mime to other message transports (ftp, message queue's).

I have already written solutions that deal with the above mentioned
situations for several XML enveloping specifications.

Jim McCarthy
CTO, WebXi, Inc.
http://www.webxi.com/