Re: Request for clarification - multiple payloads

[Prasad Yendluri <pyendluri@webmethods.com>]

Applying this to the case of Synchronous exchanges, it seems this would boil
down to a simple straightforward extension of the model. That is, multiple
responses (if any) would come back in the payload of the synchronously delivered
response message. Anyone see an issue?

Prasad

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
>

--
Principal Architect, ATG; webMethods Inc.,
432 Lakeside Drive, Sunnyvale, CA 94088-3793, USA
Tel: (408) 962-5226 mailto: pyendluri@webmethods.com