RE: Request for clarification - multiple payloads

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

I think we specifically need to describe the multiple payload example and
use of MIME multipart/related to handle this in the spec.

David

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Monday, December 11, 2000 8:20 AM
To: dick@8760.com
Cc: David Marshall; ebxml-transport@lists.ebxml.org
Subject: Re: Request for clarification - multiple payloads


Dick is (as usual) right on the money.

The single payload container would be a multipart/* 
MIME object in the advent that there are multiple payload
objects.

HTH,

Chris

Dick Brooks wrote:
> 
> David,
> 
> > What happens if the document contains two or more payloads? Is there
> > either:
> >
> > a) a new boundary and set of MIME headers for each subsequent payload
> > (i.e. each payload forms a subpart of the enveloping multipart/related
> > envelope
> >
> > or
> >
> > b) a new multipart/related MIME envelope which represents an overall
> > payload container with each payload representing subparts within this
> > nested envelope (this appears to be what's implied in the message
> > structure diagram in section 7.1).
> > </requestForClarification>
> >
> > <opinion>
> > option a) above seems conceptually simpler in my opinion and I haven't
> > been able to think of anything that would break if multiple payloads
> > were handled this way rather than via option b). Either way, it would be
> > useful to spell it out in future revisions of the spec (a multipart
> > payload example in the appendix would be nice too).
> > </opinion>
> >
> 
> The answer is option B.
> 
> A single payload container can contain any type of MIME structure,
including
> a multipart/related or multipart/mixed.
> The use of a single payload makes it very fast/efficient for an
intermediary
> or final recipient to "extract" the payload objects intact and repackage
for
> gatewaying between transports or other purposes.
> 
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@8760.com
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
> 
> InsideAgent - Empowering e-commerce solutions
> 
> > -----Original Message-----
> > From: dmarshall@www.vmguys.com [mailto:dmarshall@www.vmguys.com]On
> > Behalf Of David Marshall
> > Sent: Monday, December 11, 2000 9:47 AM
> > To: ebxml-transport@lists.ebxml.org
> > Subject: Request for clarification - multiple payloads
> >
> >
> > List-Unsubscribe:
> >  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> > List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> > List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
> >  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
> >
> > This is a request for clarification as regards the 0.8 TR&P
> > specification:
> >
> > <background>I'm working on the infrastructure committee for the
> > OpenTravel Alliance (OTA) where we are soon to publish our next level
> > spec. One of the major areas of revision in this spec. is in the area of
> > infrastructure where we are have begun the process of ebXML alignment by
> > adopting the packaging portion of the TR&P spec.
> >
> > In future revisions of our spec we anticipate moving to full adoption of
> > TR&P, though there will be at least one more major spec revision before
> > this is possible (for historical and timing reasons).</background>
> >
> > <requirement>In the OTA we need to send at least two payload documents
> > within each ebXML message envelope.</requirement>
> >
> > <requestForClarification>
> > Referring to section 7.1 of the 0.8 spec., the message structure diagram
> > implies a single ebXML payload envelope containing one or more payload
> > documents.
> >
> > Section 7.4 states "If the ebXML Message contains a payload, then a
> > single ebXML Payload Container MUST be used to envelop it."
> >
> > What happens if the document contains two or more payloads? Is there
> > either:
> >
> > a) a new boundary and set of MIME headers for each subsequent payload
> > (i.e. each payload forms a subpart of the enveloping multipart/related
> > envelope
> >
> > or
> >
> > b) a new multipart/related MIME envelope which represents an overall
> > payload container with each payload representing subparts within this
> > nested envelope (this appears to be what's implied in the message
> > structure diagram in section 7.1).
> > </requestForClarification>
> >
> > <opinion>
> > option a) above seems conceptually simpler in my opinion and I haven't
> > been able to think of anything that would break if multiple payloads
> > were handled this way rather than via option b). Either way, it would be
> > useful to spell it out in future revisions of the spec (a multipart
> > payload example in the appendix would be nice too).
> > </opinion>
> >
> > tia,
> >
> > David Marshall
> >
> > --
> > David Marshall       mailto:dmarshall@vmguys.com
> > VM Systems, Inc.           http://www.vmguys.com
> >
> >
> >