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

[David Burdett <david.burdett@commerceone.com>]

I've just picked up this thread. A few comments:

Ravi said ...
>>> 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 [XML based outer wrapper/envelope] direction.<<<

Almost but not quite right ...

I do think that:
1. There should be just one definition of how to do the outer
wrapper/envelope for each approach (i.e. either XML or MIME). This will
require all the groups who are now working on/considering these problems to
work together ... somehow :)
2. An XML only outer wrapper would be the ideal solution since then only a
single type of technology (ie XML) would be needed to process any message
rather than two (XML & MIME) or more.
3. Right now my personal view is that there are some problems with using XML
as the outer wrapper that don't apply to MIME (see summary of benefits of
each below).
4. We need to thoroughly understand these problems and identify if they are
solvable now before we decide which way to go.

I'm not convinced they're easily solvable. So if anyone with solid
experience of an XML Wrapper approach [e.g. with BizTalk, Ravi ;-)] would
like to comment on how the identified problems are solved, then it would
provide useful insight for everyone.

To help this discussion I repear the benefits of MIME and XML enevelopes
that were recently summarized in an email to the ebXML list last Thursday
from Kit Lueder. I copy the relvant text below. 

Regards

David
==========
Email by Kit Leuder ...

<Kit>
Benefits of MIME envelope:
 - If you are using e-mail, it falls out automatically.
 - If you want to parse the header but don't want to parse the body
(content), 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.

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.
 - 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.
</Kit> 

-----Original Message-----
From: Dick Brooks (E) [mailto:dick@8760.com]
Sent: Sunday, March 12, 2000 1:29 PM
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


The ebXML group has not made a final decision as to packaging/enveloping
standards, the current proposal is based on multipart/form-data.

If you would like my personal opinion, I believe a single ebXML packaging
standard for use on all transports is desireable, provided it's feasible.

Any others have an opinion on this?

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

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


I presume you are saying then that on both HTTP and SMTP (and potentialy
FTP) you are working towards enabling MIME multipart/form-data encoding ?

-----Original Message-----
From: Dick Brooks (E) [mailto:dick@8760.com]
Sent: Sunday, March 12, 2000 12:48 PM
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


The ebXML requirements document indicates a desire to allow message exchange
over multiple protocols, reference section 4.1 item 4, "Messages can be
transported over many network protocols (e.g. HTTP, SMTP, CORBA, JMQ,
MQSeries, MSMQ, etc)". I personally am focusing on HTTP and SMTP as the
primary transports. I think others are doing the same.

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

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


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


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.