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

[Ravi Manikundalam <ravima@microsoft.com>]

Thanks for the update. 

Is the view that ebXML messages will always be MIME multipart/form-data on
all transports (FTP, FAX, SMTP, HTTP, etc).

Who is the other group that is developing the pure XML wrapper and is there
an early draft of it available.

-----Original Message-----
From: Dick Brooks (E) [mailto:dick@8760.com]
Sent: Sunday, March 12, 2000 9:38 AM
To: Ravi Manikundalam; ebXML Transport (E-mail);
rnif_v2@lists.rosettanet.org
Subject: RE: XML based Manifests vs Multi-part-related MIME encoding of
multi-part messages


Ravi,

<Answer 1> I won't attempt to answer your "how many" question, however I
feel one of your comments needs clarification.
You state "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." It depends on what you mean by "direction":

If you mean the use of independent body parts for header and payload, then
we are in total agreement. If you mean the use of multipart/related for the
outer envelope then there is a disconnect.

During the last ebXML TR&P con-call there was a discussion of packaging
options. A discussion paper was created by Nick Kassem and myself, which
served as the basis for the discussion. I'll spare you the details but the
approach described in the paper, which the group seemed to converge on, is
based on a multipart/form-data outer wrapper with two MIME body parts:
- ebXML-header
- ebXML-payload

The ebXML-header contains a text/xml object representing the message
headers. The headers remain undefined at this time, but we are moving
quickly toward defining them.

The ebXML-payload can contain ANYTHING, including multipart/related,
multipart/encrypted, text/xml, application/EDI-X12, application/EDIFACT,
application/EDI-consent. Let the implementers decide how best to utilize the
ebXML-payload container.

The reason we chose multipart/form-data as the outer wrapper has to do with
the capabilities of existing browsers. It doesn't appear that existing
browsers are able to construct an HTTP POST with a multipart/related outer
wrapper (at least I'm not aware of one that can do this). Certainly, it
would be easy to add multipart/related enveloping for HTTP POST to
browsers,so it could be done, but people are already using the existing
multipart/form-data mechanism for B2B exchanges.

FYI, another group is developing a paper to demonstrate a "pure XML"
wrapper, this will be discussed at the next con-call.
</Answer 1>

<Answer 2>
I can only speak for what's happening in the Energy Industry; the Gas
Industry Standards Board defined a B2B standard in 1996 that's based on
multipart/form-data enveloping. The electric companies in the state of
Pennsylvania recently adopted the GISB standard for B2B. The AIAG adopted
the same approach as GISB, multipart/form-data approach, in 1998. I'm not
aware of anyone in the Energy industry using multipart/related outer
enveloping for B2B.
</Answer 2>

<Answer 3> ebXML has not settled on a TR&P enveloping standard yet, but the
last con-call seemed to indicate support for multipart/form-data outer
wrapper with two MIME body parts (see Answer 1).
</Answer 3>

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Ravi
Manikundalam
Sent: Sunday, March 12, 2000 8:50 AM
To: ebXML Transport (E-mail); rnif_v2@lists.rosettanet.org
Subject: XML based Manifests vs Multi-part-related MIME encoding of
multi-part messages


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.