[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 --AaB03x content-disposition: form-data; name="messageRequest" Content-type: multipart/mixed, boundary=BbC04ZZZ --BbC04ZZZ Content-disposition: attachment; filename="request.xml" Content-Type: text/xml <ebXMLEnvelope> <RequiredHeaders> </RequiredHeaders> <MessagePayload> ... Payload Body ... </MessagePayload> </ebXMLEnvelope> --BbC04ZZZ Content-disposition: attachment; filename="image.jpg" Content-Type: image/jpg Content-Transfer-Encoding: binary ... contents of image ... --BbC04ZZZ-- --AaB03x-- In another transmission (possibly even the response) if only the XML Message is required the transmission might simply be: Content-Type: text/xml <ebXMLEnvelope> <RequiredHeaders> </RequiredHeaders> <MessagePayload> ... Payload Body ... </MessagePayload> </ebXMLEnvelope> 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 SMTP. Jim McCarthy CTO, WebXi, Inc. http://www.webxi.com/ > -----Original Message----- > From: owner-ebxml-transport@lists.oasis-open.org > [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Mark > CRAWFORD > 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]
Powered by eList eXpress LLC