[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of Ravi Manikundalam Sent: Sunday, March 12, 2000 8:50 AM To: ebXML Transport (E-mail); email@example.com 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.
Powered by eList eXpress LLC