Re: Request for clarification - multiple payloads

[christopher ferris <chris.ferris@east.sun.com>]

Quite true. In fact, I sent out a specific comment
regarding this to the list not too long ago (last week?)

Once again, we agree;-)

Cheers,

Chris

"Burdett, David" wrote:
> 
> 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
> > >
> > >
> > >
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard