[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: MIME enveloping and Packaging work paper for Thursday con-call.
The attached file is the work paper Nick and I agreed to produce during the last con-call. Please review and prepare to discuss during the con-call on Thursday. Thanks, Dick Brooks http://www.8760.com/
ebXML Message Routing and Transport
Enveloping and Packaging DISCUSSION-ONLY Paper
March 6, 2000
Authors:
Dick Brooks Nick Kassem
dick@8760.com Nick.Kassem@eng.sun.com
PURPOSE
This paper is intended to help MR&T workgroup participants understand the various ways XML and non-XML
payloads can be expressed using MIME enveloping/packaging standards. The main objective of this paper
is to provide workgroup members with a sufficient technical understanding of MIME technology to enable
a consensus adoption or rejection of MIME as the packaging/enveloping standard for ebXML messages.
There are several decisions facing the MR&T group in the quest for a global standard for Transport, Routing
and Packaging of digital payloads (XML and non-XML), including (but not limited to):
- selection/definition of header elements
- support for various communication modes (simplex,
request/response, fire'n'forget with asynchronous
receipt delivery)
- algorithms used to implement privacy, authentication,
integrity and non-repudiation
- which transports to support
- potential adoption of other transport
specifications for XML (e.g. SOAP, XML-RPC)
- packaging and enveloping standards
This paper is ONLY intended to assist the group in its decision related to packaging and enveloping standards.
Any reference to transports, header names and values are coincidental and used solely to convey concepts relating
to packaging and enveloping.
INTRODUCTION
This paper is organized around two scenarios:
- a very simple scenario with a single XML payload
- a moderately complex scenario using a multipart/mixed payload,
containing both XML and binary objects
Three examples are given for each scenario:
1. E-mail based approach
2. HTTP based approach using Multipart/form-data packaging (ref
RFC 1867) with a single body part per ebXML header and one
bodypart for payload (this capability exists in all
currently shipping browsers)
3. HTTP based approach using Multipart/form-data
packaging (ref RFC 1867) using one bodypart to contain an XML
representation of all ebXML headers and one bodypart for payload.
NOTE: The examples below use a single bodypart as a "payload container". MIME packaging/enveloping does NOT
restrict the type of data allowed in the payload bodypart. Consenting trading partners are free to place any
type of data into the payload bodypart including ascii, unicode, binary, multipart objects and XML( which
can also contain binary objects or other XML documents). It is up to consenting trading partners to agree
on the structure, type and format of payloads.
In the simple scenario a company is using XML to communicate a single business transaction (invoice) to a
trading partner. The XML object used in this scenario can be replaced with X12, EDIFACT or any other
business transaction syntax companies may wish to exchange using the ebXML transport standard.
In the moderately complex scenario, a binary JPEG file is sent along with the same XML payload used in
the simple scenario.
Any of the approaches described below can be used in a simplex, request/response of fire'n'forget communication
mode. Additional functionality can be added through the use of additional headers ( requesting signed receipts,
async receipt delivery, crypto algorithms, etc.). This document does not attempt to define ebXML behavioral
requirements or header data elements, all references to header data elements are coincidental and used solely
to convey concepts related to packaging/enveloping.
SIMPLE EXAMPLES (ONE XML DOCUMENT PAYLOAD)
Example 1. The following represents a simple message exchange using a XML payload over an SMTP infrastructure.
From:<dick@8760.com>
To: <nick@sun.com>
Message-ID: 1111
Subject: Your invoice
Content-type: text/xml
<Invoice>transaction tags and business data....
</Invoice>
Example 2. The following is a simple B2C or B2B scenario with XML over a HTTP infrastructure, using a browser
to send data. This example uses one body part per ebXML header element and one body part for payload.
Content-type: multipart/form-data;
boundary=---------------------------222875935764
Content-Length: 1373
-----------------------------222875935764
Content-Disposition: form-data; name="from"
dick@8760.com
-----------------------------222875935764
Content-Disposition: form-data; name="to"
nick@sun.com
-----------------------------222875935764
Content-Disposition: form-data; name="Message-ID"
1111
-----------------------------222875935764
Content-Disposition: form-data; name="Subject"
Your invoice
-----------------------------222875935764
Content-Disposition: form-data; name="input-data";
filename="D:\GISBLite\as2testtextfile.aes"
Content-Type: text/xml
<Invoice>transaction tags and business data....
</Invoice>
-----------------------------222875935764--
Example 3. The following is a B2C or B2B scenario with a simple XML header & payload over an HTTP infrastructure.
This example uses one bodypart to contain all ebXML header elements and one body part for payload.
Content-type: multipart/form-data;
boundary=---------------------------222875935764
Content-Length: 1373
-----------------------------222875935764
Content-Disposition: form-data; name="ebXML-header"
<ebxml-header>
<from>dick@8760.com</from>
<to>nick@sun.com</to>
<Message-ID>1111</Message-ID>
<Subject>Your invoice</Subject>
</ebxml-header>
-----------------------------222875935764
Content-Disposition: form-data; name="input-data";
filename="D:\GISBLite\as2testtextfile.aes"
Content-Type: text/xml
<Invoice>transaction tags and business data....
</Invoice>
-----------------------------222875935764--
MODERATELY COMPLEX EXAMPLES (two related objects, one XML the other JPEG):
Example 4 - The following represents a multipart payload object (containing XML and binary data) over an
SMTP infrastructure.
From:<dick@8760.com>
To: <nick@sun.com>
Message-ID: 1111
Subject: Your invoice and image of original purchase order
Content-type: multipart/mixed, boundary=BbC04ZZZ
--BbC04ZZZ
Content-disposition: attachment; filename="invoice.xml"
Content-Type: text/xml
<Invoice>transaction tags and business data....
</Invoice>
--BbC04ZZZ
Content-disposition: attachment; filename="image.jpg"
Content-Type: image/jpg
Content-Transfer-Encoding: base64
base64 encoded contents of image ...
--BbC04ZZZ--
Example 5 - The following represents a multipart payload object containing XML and binary data in a
B2C or B2B scenario over a HTTP infrastructure, using a browser to send data. This example uses one
body part per ebXML header element and one body part for payload.
Content-type: multipart/form-data;
boundary=---------------------------222875935764
Content-Length: 1373
-----------------------------222875935764
Content-Disposition: form-data; name="from"
dick@8760.com
-----------------------------222875935764
Content-Disposition: form-data; name="to"
nick@sun.com
-----------------------------222875935764
Content-Disposition: form-data; name="Message-ID"
1111
-----------------------------222875935764
Content-Disposition: form-data; name="Subject"
Your invoice and image of original purchase order
-----------------------------222875935764
Content-disposition: form-data; name="input-data";
filename="invoice-info.data"
Content-type: multipart/mixed, boundary=BbC04ZZZ
--BbC04ZZZ
Content-disposition: attachment; filename="invoice.xml"
Content-Type: text/xml
<Invoice>transaction tags and business data....
</Invoice>
--BbC04ZZZ
Content-disposition: attachment; filename="image.jpg"
Content-Type: image/jpg
binary contents of image ...
--BbC04ZZZ--
-----------------------------222875935764--
Example 6 - The following represents a multipart payload object containing XML and binary data in a B2C
or B2B scenario over a HTTP infrastructure, using a browser to send data. This example uses one bodypart
to contain all ebXML header elements and one body part for payload.
Content-type: multipart/form-data;
boundary=---------------------------222875935764
Content-Length: 1373
-----------------------------222875935764
Content-Disposition: form-data; name="ebXML-header"
<ebxml-header>
<from>dick@8760.com</from>
<to>nick@sun.com</to>
<Message-ID>1111</Message-ID>
<Subject>Your invoice and image of original P.O.</Subject>
</ebxml-header>
-----------------------------222875935764
Content-Disposition: form-data; name="input-data";
filename="invoice-info.data"
Content-type: multipart/mixed, boundary=BbC04ZZZ
--BbC04ZZZ
Content-disposition: attachment; filename="invoice.xml"
Content-Type: text/xml
<Invoice>transaction tags and business data....
</Invoice>
--BbC04ZZZ
Content-disposition: attachment; filename="image.jpg"
Content-Type: image/jpg
Content-Transfer-Encoding: binary
binary contents of image ...
--BbC04ZZZ--
-----------------------------222875935764--
ACKNOWLEDGEMENTS
Thanks to James McCarthy, jamesm@webxi.com, for providing the multipart/mixed example used in this document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC