Re: Request for clarification - multiple payloads

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

Dick,

This is great, thanks for the offer. As an aside, I feel that
we should (as I have previously proposed) have these appendix
items as external documents available from the ebXML website
rather than baking them directly into the text of the spec.

Cheers,

Chris

Dick Brooks wrote:
> 
> 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
> > > > >
> > > > >
> > > > >
> >
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