RE: Request for clarification - multiple payloads

[Dick Brooks <dick@8760.com>]

I agree also - Imagine the 3 of us agreeing, frightening isn't it!

I volunteer to provide an example (or two) of a multipart payload (I'll have
plenty of
time on airplanes this week to accomplish this).


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: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Monday, December 11, 2000 11:12 AM
> To: ebxml-transport@lists.ebxml.org
> Subject: Re: Request for clarification - multiple payloads
>
>
> 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
> > > >
> > > >
> > > >
>