OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: RE: Regarding the Thursday ebXML Conf Call

As a person who listened in on today's conference call but not currently an
active participant I would like to express my understanding of the proposed
use of mime. It is my understanding that the group is pursuing two design
issues. The design of the highest priority is the XML Message envelope
design. The XML Messaging envelope will not use mime for encapsulating the
message body and will be a pure XML enveloping structure.

The problem that is being addressed by mime encapsulation only arises when
there is a need to transmit multiple XML Message bodies and provide support
for arbitrarily large binary objects (i.e. images). Most participants seemed
to agree that this type of mixed transmission would not be well suited to
further encapsulation in another XML envelope. A case was sited were only
one of the messages is desired out of a potentially large multi-part block.
With most parser implementations a pure XML encapsulation would only allow
the use of SAX parsing to avoid processing the entire message.

As an example if the RFC1867 Multipart form where used to transmit an XML
Message envelope and an image the message might look like the following
(Please note someone in the group is working on this proposal and it is not
me so do not take this example as a recommendation):

        Content-type: multipart/form-data, boundary=AaB03x

        content-disposition: form-data; name="messageRequest"
        Content-type: multipart/mixed, boundary=BbC04ZZZ

        Content-disposition: attachment; filename="request.xml"
        Content-Type: text/xml

            ... Payload Body ...
        Content-disposition: attachment; filename="image.jpg"
        Content-Type: image/jpg
        Content-Transfer-Encoding: binary

        ... contents of image ...

In another transmission (possibly even the response) if only the XML Message
is required the transmission might simply be:

        Content-Type: text/xml

            ... Payload Body ...

If my understanding of the use of mime is not correct I apologize to the
group but I believe that this is what was discussed. I hope this makes the
discussion a little more clear. In my humble opinion this approach makes
sense especially since this type of transmission is widely used in HTTP and

Jim McCarthy
CTO, WebXi, Inc.

> -----Original Message-----
> From: owner-ebxml-transport@lists.oasis-open.org
> [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Mark
> Sent: Thursday, March 02, 2000 3:29 PM
> To: dick@8760.com; kit@mitre.org; drummond@onramp.net;
> ebXML-Transport@lists.oasis-open.org
> Cc: rawlins@metronet.com
> Subject: Re:RE: Regarding the Thursday ebXML Conf Call
> Dick,
>     What was presented to us during our call today was that you
> were selecting
> mime as "the" ebXML solution.  If that is not the case, then we
> don't have an
> issue.  Although I personally can't understand why anyone would
> want to use an
> antiquated technology such as e-mail to forward XML, especially
> in a business to
> business exchange, I do see the need to accomodate folks desires.
>  If on the
> other hand, you are selecting mime as "the" ebXML solution, then
> I think that
> you will loose participation and support of the bulk of the XML
> community.
>     Mark
> Mark Crawford
> Research Fellow
> ______
> LMI Logistics Management Institute
> 2000 Corporate Ridge, McLean, VA 22102-7805
> (703) 917-7177   Fax (703) 917-7518
> mcrawfor@lmi.org
> http://www.lmi.org
> "Opportunity is what you make of it"

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC