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

["James McCarthy" <jamesm@webxi.com>]

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/