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

[Ravi Manikundalam <ravima@microsoft.com>]

David Burdett et al/Pat O'Sullivan et al:

It seems like a discussion on the subject line has been going on both as
part of the ebXML Transport Working group and the RosettaNet RNIF Version
2.0 Transport Routing and Packaging Working group and to some extent the XML
working group within OBI.

Technology providers like ourselves (Microsoft) who are focused on enabling
our joint end customers use our products to implement solutions based on the
various approaches being suggested and discussed by the above mentioned
groups (and more) have an interesting challenge to say the least.

I would appreciate the groups response on the following questions to help us
better influence and support these various approaches being discussed
currently.

		<Question 1> How many existing XML based Messaging
specifications are based on the notion of having a pure XML based packaging
approach and using multi-part/related MIME as an outer packaging mechanism
where applicable and needed ?

		This typically means multiple schemas/element types (one for
the composite logical document, one for the header which contains both
addressing/routing and manifest level information and one or more for each
of the physical document/parts that are being exchanged - which use element
types from different name spaces or schemas .

		For example both BizTalk version 1.0 and SOAP version 1.0
follow this approach now. I believe David Burdett of the ebXML transport
working group and the IETF XML Messaging efforts to date is inclined to move
ebXML in this direction.

		<Question 2>How many existing B2B XML and non-XML based
Messaging specifications are based on the notion of having a pure multi-part
related MIME based packaging of the various physical parts (preamble,
service header, service content, etc) of a single interchange or message ?

		This typically means multiple schemas for the various parts
of the mult-part related MIME message in cases where they are XML.  

		For example RNIF V1.1 follows this approach now. 

		What other existing B2B TRP specs follow this approach (OBI,
EDI-INT, IOTP, etc ) ???

		What feedback do we have from the technology
providers/customers who have tried to implement this approach ?

NOTE: Based on the experiences of both technology/solution  providers and
customers who have attempted to implement solutions based on using
multi-part related MIME as the primary and only packaging approach (ala RNIF
1.1) and our own experiences it seems like using an XML based approach as
the primary mechanism to package related things has the advantages of 

		XML Schema driven development tools to  help in  the
construction of such a XML based package or interchange.
		Allows the use of MIME or S/MIME encoding based on the
transport and applications exchanging these messages.

	<Question 3> which high level approach are you guy's settling down
on for ebXML Version 1.0 and/or RNIF Version 2.0.

Knowing this will help us determine who and how we should provide our
feedback to and what support we need to plan to add to our solutions.