Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]

[Prasad Yendluri <pyendluri@vitria.com>]

This is not entirely correct. RNIF 1.1 did not have any messages that attached
any non-XML componenets. A clear need was identified by users of RNIF 1.0,  to
separate out the headers and payload, for the reasons I alredy listed  in my
earlier ports. We needed a way to pack the header and payload and MIME provoded
the best solution at that time.

BTW S/MIME was not used for of RNIF 1.1.

--PY

Simon Johnston wrote:

> I will add my 2 pennies from the RosettaNet point of view. MIME, S/MIME was
> chosen specifically because of the requirement to pass non-XML components as
> part of the business document. For example a .GIF image with a catalog entry
> or a .PDF wiring diagram with a component specification. As these types
> cannot be defined ahead of time MIME allowed the self-describing packaging
> of such content. At the point that MIME was chosen as the primary 'message'
> format it was a logical step to allow the envelope to be a seperate MIME
> entry.
>
> -----
> Simon Johnston (skj@acm.org)
> Product Manager, Rational Software Corp.
> Mobile: 425-985-6163
>
> -----Original Message-----
> From: owner-ebxml-transport@lists.oasis-open.org
> [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of
> dick@8760.com
> Sent: Tuesday, April 11, 2000 5:26 AM
> To: Ravi Manikundalam; 'Prasad Yendluri'; James McCarthy; dick@8760.com
> Cc: ebXML Transport (E-mail)
> Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
>
> Ravi,
>
> The ebXML TRP requirements include digitally signed payloads and headers for
> non-repudiation. Please provide specifications showing how  PGP and S/MIME
> digitally signed XML payloads are represented in a monolithic (combined
> header/payload) XML document. Please provide references to RFC's or W3C
> standard
> specifications showing details of this solution.
>
> I know that several people from ebXML have solicited Microsoft's involvement
> during the creation of ebXML specifications. I personally asked David Turner
> to
> provide Microsoft's pure XML packaging solution for consideration, I never
> received a response.  I'm to infer that Microsoft, from the non-reply, does
> not
> have a "pure XML" solution that meets ebXML requirements. If this is
> incorrect,
> please post Microsoft's "pure XML" solution that meets the ebXML TRP
> requirements to this list. The ebXML packaging spec is still under
> development
> so there is still time to add this functionality.
>
> Thanks,
>
> Dick Brooks
> http://www.8760.com/
>
> ----- Original Message -----
> From: Ravi Manikundalam <ravima@microsoft.com>
> To: 'Prasad Yendluri' <pyendluri@vitria.com>; James McCarthy
> <jamesm@webxi.com>
> Cc: ebXML Transport (E-mail) <ebXML-Transport@lists.oasis-open.org>
> Sent: Monday, April 10, 2000 9:57 PM
> Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
>
> > I completly agree with James McCarthy in that taking the approach that we
> > (Microsoft took) i.e
> >
> >     If a message has only XML types then packaging multiple XML document
> > instances as a
> >     single XML Document separated by name spaces and using a SAX compliant
> > parser to
> >     process it is very efficient and possible
> >
> >     If a message contains mixed types then packaging all the XML document
> > instances in a
> >     single MIME part and each of the other parts as other MIME parts is a
> > reasonable
> >     approach that also works.
> >
> > Taking this approach has been found to work and does not seem to burden
> the
> > processing of most XML based business messages which today are not of
> mixed
> > types, yet allowing the border cases where there are some messages that
> > could be of mixed type.
> >
> > NOTE: The reason I think folks like RosettaNet took and anybody else who
> has
> > based there packaging structure assuming DTD's as three or more separate
> XML
> > documents each packaged as individual MIME parts is that with DTD's you
> did
> > not have the luxury of using "Name Spaces" as you can more easily with
> > XML/XDR as well as XML/XSD combinations.
> >
> > -----Original Message-----
> > From: Prasad Yendluri [mailto:pyendluri@vitria.com]
> > Sent: Monday, April 10, 2000 6:44 PM
> > To: James McCarthy
> > Cc: ebXML Transport (E-mail)
> > Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> >
> >
> > Hi,
> >
> > Other frameworks like RosettaNet have discovered that it is desirable to
> > keep
> > the envelope and content disjoint (i.e. two different XML documents packed
> > together (with MIME) instead one XML document).
> >
> > Some of the advantages are:
> >
> > 1. Having fixed header DTD / Schema makes it easier / efficient to route
> the
> > message without having to look into the business content.
> > 2. Clear separation between different business (payload) documents and
> > headers
> > so that headers can be changed without impacting all business documents.
> > 3. Error can be reported back even if the business content can not be
> > parsed.
> >
> > Prasad
> >
> > James McCarthy wrote:
> >
> > > > -----Original Message-----
> > > > From: owner-ebxml-transport@lists.oasis-open.org
> > > > [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Dick
> > > > Brooks
> > > > Sent: Monday, April 10, 2000 5:41 PM
> > > > To: srh@us.ibm.com; David Burdett
> > > > Cc: Jon Bosak; ebXML-Transport@lists.oasis-open.org; Nicholas Kassem
> > > > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP
> Syntax/Semantics]
> > > >
> > > >
> > > > The packaging sub-group has spent several weeks coming up with this
> > design
> > > > and now it seems some people want to "unravel" it and start all
> > > > over again.
> > > > If we keep revisiting and rehashing decisions we will not meet our
> > > > deadlines.
> > > >
> > >
> > > No one is trying to "unravel" anything. The only real change that was
> > > suggested was that all pure XML content is packaged in a single MIME
> part
> > > using namespaces. This is currently being done by the Biztalk
> > specification
> > > and I have written SAX handlers to parse these messages. All non-XML
> will
> > > NOT be in the XML envelope but in separate MIME parts following the XML
> > > portion of the message.
> > >
> > > I think this is a very reasonable approach which is a great compromise
> > > between pure XML and MIME and takes full advantage of both
> specifications.
> > > MIME to separate mixed message types and namespaces to separate multiple
> > XML
> > > body parts all represented by a single ebXML header.
> > >
> > > > The packaging sub-group discussed one container versus two and the
> > reasons
> > > > we decided on two containers follow:
> > > >
> > > > - One XML container means that the entire document (which could
> > > > be GIGABYTES
> > > > of data) would have to be processed/parsed as a single XML document.
> > This
> > > > would make processing time slow and could seriously impact response
> > time.
> > > >
> > >
> > > If the GIGABYTES of data is pure XML, IMHO, it is easier to process this
> > as
> > > an input stream using a SAX handler than it is to have to first separate
> > the
> > > message from its outer wrapper, MIME, and then parsing it using an XML
> > > parser.
> > >
> > > > - There is no XML based standard for packaging mixed payloads. The
> ebXML
> > > > group would have to create a XML based packaging standard and this
> > didn't
> > > > seem practical when we could very easily apply MIME to a task it was
> > well
> > > > designed to handle. this also met the group requirement to use
> existing
> > > > solutions whenever possible (don't re-invent the wheel).
> > > >
> > >
> > > MIME will still be used for this no one is suggesting a change here.
> > >
> > > > - There is a large installed base of products that support MIME and
> > > > developers who are familiar with MIME. Scott, MIME is not that
> > "difficult"
> > > > to process - I'll bet I could teach you how to process the ebXML MIME
> > > > envelope in less than two hours using MIME++, assuming you're
> > > > familiar with
> > > > C++ ;^).
> > > >
> > > > I assert that a MIME solution using two "containers", is superior to a
> > > > single XML container for for the following reasons:
> > > >       - there are no illeagal characters to deal with in MIME as
> > > > there are in XML
> > > > (&amp &lt all have to be transformed)
> > > >       - there are mature, proven packages available to parse MIME, an
> > XML
> > > > solution would have to be developed
> > > >       - binary objects are transportable without any conversion
> > > > with MIME (no
> > > > base64 needed when using HTTP transport);
> > > >         with XML binary objects must be base64 encoded
> > > >       - applying base64 to a payload adds appx 40% to its size
> > > > and this adds time
> > > > to transmit and process.
> > > >       - There are already MIME based STANDARDS for packaging a
> > > > significant body
> > > > of objects (jpeg, EDI, XML, html, et al), these would all have to
> > > > be created
> > > > for an XML based packaging solution.
> > > >
> > >
> > > David's original post on this thread did not suggest a single package
> for
> > > everything. MIME would still be used and would be required for mixed
> > > payloads.
> > >
> > > > Some people have suggested using the existing MIME headers and media
> > types
> > > > to create an XML packaging specifcation, then we could have MIME in
> XML.
> > > > Why - what is the benefit of this - the ability to say we have a pure
> > XML
> > > > packaging solution?
> > > >
> > > > The packaging sub-group is certainly open to a better solution - if
> one
> > > > exists. Please announce to the list any STANDARD based XML packaging
> > > > solutions that we should consider, please be sure to include how
> > > > the issues
> > > > above are addressed.
> > > >
> > > > Thank you,
> > > >
> > > > Dick Brooks
> > > > http://www.8760.com/
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: srh@us.ibm.com [mailto:srh@us.ibm.com]
> > > > Sent: Monday, April 10, 2000 3:34 PM
> > > > To: David Burdett
> > > > Cc: 'dick@8760.com'; Jon Bosak; ebXML-Transport@lists.oasis-open.org;
> > > > Nicholas Kassem
> > > > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP
> Syntax/Semantics]
> > > >
> > > >
> > > >
> > > >
> > > > David,
> > > > This was going to be my next question coming out of the Dallas
> meeting.
> > > > ---- why do we *need* the header envelope to be a seperate mime part
> > from
> > > > the payload envelope? ----
> > > >
> > > > Without it, as you describe, essentially decouples the core ebXML
> > > > spec from
> > > > the lower level transport,
> > > > and essentially only demands that an application use a mime-based
> lower
> > > > transport only if binary
> > > > passed-by-value is required with high performance. As before, nothing
> > > > precludes an application
> > > > from base64ing a binary pass-by-value payload, and still leverage the
> > core
> > > > ebXML TRP specs
> > > > consistently over a transport that has nothing to do with mime.
> > > >
> > > > Somebody shoot this down. I think its difficult.
> > > >
> > > > Scott R. Hinkelman
> > > > IBM Austin
> > > > SWG Java Solutions
> > > > XML/Java Standards Architecture
> > > > Office: 512-823-8097 TL793-8097
> > > > Home: 512-930-5675
> > > > Cell: 512-940-0519
> > > > srh@us.ibm.com
> > > > Fax: 512-838-1074
> > > >
> > > >
> > > >
> > > > David Burdett <david.burdett@commerceone.com> on 04/10/2000 01:37:33
> PM
> > > >
> > > > To:   "'dick@8760.com'" <dick@8760.com>, Jon Bosak
> > > > <Jon.Bosak@eng.sun.com>,
> > > >       ebXML-Transport@lists.oasis-open.org, Nicholas Kassem
> > > >       <Nick.Kassem@eng.sun.com>
> > > > cc:
> > > > Subject:  RE: [Fwd: Re[2]: Concern with basic ebXML TRP
> > Syntax/Semantics]
> > > >
> > > >
> > > >
> > > >
> > > > Now this may be off the wall somewhat, but there might be a way
> > > > that we can
> > > > provide support for BOTH XML and MIME. The basic idea is described in
> > the
> > > > following structure that just *might* work. What you would have is:
> > > >
> > > > 1. A MIME outer wrapper that contains:
> > > >    a) an initial MIME part that contains:
> > > >       i) a single XML document that contains:
> > > >         * a mandatory Message Header element that contains
> > > >           several header parts as are being developed/
> > > >           discused on this list
> > > >         * zero or more body parts that each consist of XML payloads,
> > > >           where each payload has a single XML element that has a
> > > >           separate XML namespace
> > > >    b) zero or more additional MIME parts that can contain
> > > >       anything that is *not* XML
> > > >
> > > > This way, if you only needed XML, then you would have no additional
> MIME
> > > > parts. On the other hand if you did need non-XML documents then you
> > could
> > > > use separate MIME parts to hold it.
> > > >
> > > > This also resolves the real problem with XML in that you can't put XML
> > > > inside XML without, either base64 encoding it (CDATA doesn't work
> > > > since you
> > > > can't put CDATA inside CDATA).
> > > >
> > > > Thoughts?
> > > >
> > > > David
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: dick@8760.com [mailto:dick@8760.com]
> > > > Sent: Saturday, April 08, 2000 8:53 AM
> > > > To: Jon Bosak; ebXML-Transport@lists.oasis-open.org; Nicholas Kassem
> > > > Cc: dick@8760.com
> > > > Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP
> Syntax/Semantics]
> > > >
> > > >
> > > > The packaging group investigated every "lead" in the search for a pure
> > XML
> > > > packaging solution. I asked David Turner from Microsoft if they had a
> > pure
> > > > XML
> > > > packaging solution, he never responded.  Some other proposals looked
> > > > promising
> > > > (XMTP, for example), but none were on a standards track with any
> > standards
> > > > making body.
> > > >
> > > > Nick is 100% on the mark. The ebXML packaging specification DOES
> support
> > > > pure
> > > > XML payloads, as well as other non-XML payloads. The reason we chose
> > MIME
> > > > to
> > > > encapsulate the ebXML header (which is pure XML) and Payload (be it
> XML,
> > > > EDI,
> > > > JPEG, text, et al)  is because we could not find a STANDARDS TRACK
> > "pure
> > > > XML"
> > > > packaging solution that provided the capabilities of MIME.
> > > >
> > > > The bottom line is, MIME is the ONLY standard packaging technology
> > > > available
> > > > that meets the ebXML requirements for Transport, Routing and
> Packaging.
> > > > However,
> > > > the packaging group does recognize that a XML based packaging standard
> > > > could
> > > > emerge and for this reason the specification will "leave open" the
> > > > possibilities
> > > > of a pure XML packaging solution becoming part of the specification in
> > the
> > > > future.
> > > >
> > > > Dick Brooks
> > > > http://www.8760.com/
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Nicholas Kassem <Nick.Kassem@eng.sun.com>
> > > > To: Jon Bosak <Jon.Bosak@eng.sun.com>;
> > > > <ebXML-Transport@lists.oasis-open.org>
> > > > Sent: Friday, April 07, 2000 10:01 PM
> > > > Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP
> Syntax/Semantics]
> > > >
> > > >
> > > > > I believe we have agreed to support:
> > > > >
> > > > > 1) Pure XML for Message Headers
> > > > > 2) Pure XML for payloads
> > > > > 3) *optionally* non-XML payloads (because there is a large non-XML
> > > > legacy).
> > > > >
> > > > > The fact that the current packaging proposal recommends using
> > > > > multipart-related to bind the elements into a single message is
> simply
> > > > > pragmatic. IMO. We are proposing to use an existing Internet
> > > > standard. No
> > > > > application will ever have to see the outer wrapper (be it in MIME
> or
> > > > > whatever) - in the same way that one normally doesn't see TCP
> headers
> > or
> > > > > "200 OK" from HTTP. Most importantly applications will see pure XML
> if
> > > > > that's in the message payload. If this approach offends the
> > > > sensibilities
> > > > > of some then we should go out of our way to solicit counter
> proposals
> > -
> > > > and
> > > > > review them openly.
> > > > >
> > > > > Jon, are we completely off-track here ?
> > > > >
> > > > > Regards,
> > > > > Nick
> > > > >
> > > > >
> > > > > At 01:30 PM 4/7/2000 -0400, Christopher Ferris wrote:
> > > > >
> > > > >
> > > > > >-------- Original Message --------
> > > > > >Subject: Re[2]: Concern with basic ebXML TRP Syntax/Semantics
> > > > > >Date: Fri, 07 Apr 2000 11:56:39 -0400
> > > > > >From: "Mark CRAWFORD"<mcrawfor@lmi.org>
> > > > > >To: <chris.ferris@East.Sun.COM>
> > > > > >CC: <ebXML-Requirements@lists.oasis-open.org>
> > > > > >
> > > > > >Chris,
> > > > > >
> > > > > >     I think we will have to agree to disagree.  My argument all
> > along
> > > > > >has been
> > > > > >that we are about XML, not using the guise of ebXML for individuals
> > to
> > > > > >resurrect
> > > > > >their pet technology standards projects of the last several years.
> > (and
> > > > > >I am not
> > > > > >just talking about TRP, but some of the other efforts within ebXML
> as
> > > > > >well).  If
> > > > > >webMethods can exchange information using XML wrappers, and if
> > BizTalk
> > > > > >can
> > > > > >exchange information using XML wrappers (yes I know they use mime
> to
> > > > > >encapsulate
> > > > > >binary objects within the XML document instance), then why can't
> we?
> > > > > >And oh by
> > > > > >the way, if MIME is the answer and simple e-mail attachments are
> the
> > > > > >best
> > > > > >solution, explain to me how come people still have serious email
> and
> > > > > >attachment
> > > > > >interoperability problems? Also, if we are going to use MIME
> > > > as the only
> > > > > >ebXML
> > > > > >solution, which MIME RFC are we going to use?
> > > > > >
> > > > > >     At a more basic level, there is a philosophy issue that I
> > > > am afraid
> > > > > >is being
> > > > > >overlooked.  In the ISO and IETF world, there is a lot of good
> > > > standards
> > > > > >work
> > > > > >that goes on by some very smart people, but in many cases that work
> > is
> > > > > >just for
> > > > > >the sake of building standards without regard to who really wants
> > them.
> > > > > >My
> > > > > >clients really could care less about ebXML if it is just rehashing
> > IETF
> > > > > >MIME or
> > > > > >OO technology, or Open EDI, or Business Message Modeling, or X12
> SITG
> > > > > >registry
> > > > > >and repository, or any of the other hidden agenda's that I see
> moving
> > > > > >behind the
> > > > > >scenes of ebXML.  I can only sell ebXML as a solution if it
> > > > provides XML
> > > > > >based
> > > > > >standards for exchange - and more importantly - content. We are not
> > > > > >headed in
> > > > > >that direction, and I am under increasing pressure to just go
> > implement
> > > > > >CommerceOne or webMethods and stop the XML "standards" push.
> Despite
> > > > > >all the
> > > > > >ebXML stuff about creating an interoperable technical framework,
> the
> > > > > >real
> > > > > >interest being expressed by my clients is in standardizing the
> > content,
> > > > > >not the
> > > > > >wrapper so they know what data elements they need to support in
> their
> > > > > >databases
> > > > > >and applications (databases and applications that will not be
> moving
> > to
> > > > > >an OO
> > > > > >environment for years and years).
> > > > > >
> > > > > >     If TRP believes that XML technology does not support all of
> > > > > >requirements for
> > > > > >interchange they have addressed, then I believe this is an
> > > > issue for the
> > > > > >entire
> > > > > >ebXML plenary not just TRP.  There are a number of alternatives
> open
> > -
> > > > > >
> > > > > >     1) Provide XML solutions for those requirements that can be
> > > > > >addressed
> > > > > >(reduce requirements)
> > > > > >     2) Provide dual path XML and MIME solutions
> > > > > >     3) Provide a MIME solution and publically state that we are
> not
> > > > > >developing
> > > > > >XML based solutions, but another MIME standard for exchanging XML
> > > > > >content
> > > > > >because the technology is too immature to support B2B data
> exchanges.
> > > > > >
> > > > > >     .
> > > > > >     Mark
> > > > > >Mark Crawford
> > > > > >Research Fellow
> > > > > >______
> > > > > >LMI Logistics Management Institute
> > > > > >2000 Corporate Ridge, McLean, VA 22102-7805
> > > > > >(703) 917-7177   Fax (703) 917-7518
> > > > > >mcrawfor@lmi.org
> > > > > >http://www.lmi.org
> > > > > >"Opportunity is what you make of it"
> > > > > >
> > > > > >-------------------------------------------------
> > > > > >Chris Ferris Wrote -
> > > > > >
> > > > > >Mark,
> > > > > >
> > > > > >Not at all! Again, I think that the issue is getting overblown.
> > > > > >The MIME wrapper is merely a means of packaging
> > > > > >XML documents (header information and payload) which
> > > > > >can be:
> > > > > >     - parsed separately so that for routing purposes, the
> > > > > >     entire message need not be parsed
> > > > > >     - separately signed (there might be a different certificate
> > > > > >     applied to the header than to the payload)
> > > > > >     - include non-XML content such as medical images (JPEG, MPEG)
> > > > > >
> > > > > >and more. The MIME use is simply a mechanism which existing
> > > > > >technology can handle, enabling SME's to jump right in without
> > > > > >having to expend significant resources. There does not yet exist
> > > > > >a W3C XML packaging specification to achieve these aims.
> > > > > >Our intent is to submit these requirements to the W3C so that
> > > > > >they are considered in any packaging work and ultimately so that
> > > > > >the ebXML packaging approach can be migrated (in a later
> > > > > >release) to such technology.
> > > > > >
> > > > > >Chris
> > > > > >-------------------------------------
> > > > > >Mark CRAWFORD wrote:
> > > > > >
> > > > > > > Chris,
> > > > > > >
> > > > > > >     Perhaps we should just change our name to ebMime since TRP
> > > > > > considers XML
> > > > > >too immature or hard.
> > > > > > >
> > > > > > >     Mark
> > > > > > > Mark Crawford
> > > > > > > Research Fellow
> > > > > >
> > > > > >---------------------------------------------------------
> > > > > >Chris Ferris Wrote -
> > > > > >
> > > > > >Kit,
> > > > > >
> > > > > >While I wasn't able to participate the the f2f meeting in
> > > > > >Dallas and can't speak to the finalized packaging minutia
> > > > > >I can address this from the perspective of one of the
> > > > > >members of the packaging sub-team.
> > > > > >
> > > > > >We discussed this in depth in the packaging sub-team.
> > > > > >We felt that there was inadequate support in the various
> > > > > >W3C XML recommendations to support our requirements
> > > > > >which follow:
> > > > > >
> > > > > >- Able to handle large documents
> > > > > >- Able to envelope any document type
> > > > > >- Minimize intrusion to payload (special encodings or alterations)
> > > > > >- Minimize potential for abnormal termination caused by envelopes
> > > > > >- Facilitate a migration path for existing installed base and
> > > > > >technologies
> > > > > >- Low processing overhead
> > > > > >- Support for recursive documents
> > > > > >- Able to preserve digital signatures
> > > > > >- Able to unambiguously identify signed data
> > > > > >
> > > > > >To quote Dick's minutes of our sub-team meeting:
> > > > > >
> > > > > ><db>
> > > > > >Both MIME and XML were discussed relative to these requirements. It
> > > > > >was the groups consensus that MIME was better positioned today to
> > > > > >meet the stated requirements. However, it was also believed that
> XML
> > > > > >would mature as a packaging technology and the ebXML group should
> > > > > >continue to monitor XML's progress for possible inclusion at a
> later
> > > > > >date.
> > > > > >It was also believed that Microsoft may have addressed some of the
> > > > > >issues affecting XML's packaging ability. Dick Brooks accepted an
> > > > > >action item to contact Microsoft to request information describing
> > > > > >BizTalk's packaging functions to see if this may provide an XML
> > > > > >packaging solution that meets the above requirements.
> > > > > ></db>
> > > > > >
> > > > > >Another consideration in our work, and something clearly called out
> > > > > >in the ebXML requirements document are the vision bullets.
> > > > Specifically:
> > > > > >     - is fully compliant with W3C XML technical specifications
> > holding
> > > > a
> > > > > >         recommended status
> > > > > >     - maximizes interoperability and efficiency while providing a
> > > > > >         transition path from accredited electronic data
> interchange
> > > > > >(EDI)
> > > > > >         and developing XML business standards
> > > > > >
> > > > > >The first is key. It refers to W3C technical specifications holding
> > > > > >a *recommended* status. The second is also key. It refers to
> > > > > >a requirement to enable existing solutions such as RosettaNet and
> > > > > >EDI/INT, etc. to interoperate (at least that's how I read it).
> > > > > >This second bullet is called out again in the "General ebXML
> > > > > >Principles" section in the Requirements document. Someone certainly
> > > > > >thinks it s important. I for one concur.
> > > > > >
> > > > > >Another consideration which went into our thinking is the
> > availability
> > > > > >of software to handle the package. HTTP and SMTP clients and
> > > > > >servers already support MIME and are both inexpensive and
> > > > > >widely available if not ubiquitous.
> > > > > >
> > > > > >In the Requirements document, under the TR&P sub-section, #2
> > > > > >     "Leveraging existing technology encompasses both the ability
> to
> > > > > >     interoperate with existing technology as well as the ability
> to
> > > > > >     migrate to the new technology".
> > > > > >
> > > > > >In fact, that whole section pretty much sums it up for me.
> > > > > >
> > > > > >I believe that there is consensus that ultimately, we will
> transition
> > > > > >to an XML-based approach to packaging, but at least for the
> > > > > >first go, MIME is the only solution which satisfies all of the
> > > > > >requirements.
> > > > > >
> > > > > >To my knowledge, the ebXML Requirements document doesn't
> > > > > >say "use XML to the exclusion of any other technology just
> because".
> > > > > >MIME seems to meet our requirements and since the content
> > > > > >of the MIME segments is XML (except in cases where an
> > > > > >"attachment" is of some other type such as image, etc.) we're
> > > > > >also meeting the spirit of the ebXML requirements.
> > > > > >
> > > > > >If you have knowledge of a purely XML-based packaging
> > > > > >solution which meets all of the stated requirements, and which
> > > > > >the packaging sub team has missed in its considerations, I'm
> > > > > >sure that we'd be glad to reconsider.
> > > > > >
> > > > > >Cheers,
> > > > > >
> > > > > >Chris
> > > > > >
> > > > > >"Kit (Christopher) Lueder" wrote:
> > > > > >
> > > > > > > I have a concern with the basic ebXML TRP approach. As I
> indicated
> > > > last
> > > > > > > month, as far as I know, the TRP approach is in conflict with
> the
> > > > ebXML
> > > > > > > Requirements specification. If I understand right, the ebXML TRP
> > > > > > > solution is MIME based only, which is not an XML solution.
> > > > > > >
> > > > > > > I quote the last paragraph from Section 1 Introduction of the
> > ebXML
> > > > > > > Requirements:
> > > > > > > "A key aspect for the success of the ebXML initiative is
> > > > adherence to
> > > > > > > the use of the W3C suite of XML and related Web technical
> > > > > > > specifications.  Although these specifications may not provide
> the
> > > > > > > optimal technical solution, acceptance of ebXML by the business
> > > > > > > community and technical community is tied to XML.  Alternative
> > > > > > > technologies and technical specifications may be
> > > > incorporated as part
> > > > of
> > > > > > > the ebXML solution.  However these alternative technologies and
> > > > > > > specifications will only be provided as an alternative to the
> > > > provided
> > > > > > > XML solution unless the W3C XML and related Web technical
> > > > specifications
> > > > > > > can not accomplish the same business functionality."
> > > > > > >
> > > > > > > Kit.
> > > > > > >
> > > > > > > Todd Boyle wrote:
> > > > > > > >
> > > > > > > > I would appreciate any information or links regarding the
> > > > duplicated
> > > > > > > > or overlapping information in multiple layers of headers and
> > > > wrappers.
> > > > > > > > My understanding is that a typical ebXML message might contain
> > > > > > > >
> > > > > > > >   HTTP/MIME multipart/related header
> > > > > > > >     ebXML header
> > > > > > > >     payload1
> > > > > > > >       Biztalk, or MSMQ/MQseries etc. header
> > > > > > > >       Biztalk, or MSMQ/MQseries etc. header
> > > > > > > >          Rosetta, OAG, CBL2, etc. document
> > > > > > > >              Rosetta, OAG, CBL2, etc. required document header
> > > > > > > >                  The XML message content which would usu.
> > include
> > > > > > > >                  all the parties' identities and reference
> codes
> > > > > > > >     payload2
> > > > > > > >     payload3   etc.
> > > > > > > >
> > > > > > > > No doubt I've got this screwed up someplace.  I imagine for
> the
> > > > coming
> > > > > > > > 12-24 months MOM or MQ servers will be required no matter what
> > > > ebXML
> > > > > > > > comes up with, and accordingly ebXML header and MOM headers
> will
> > > > both
> > > > > > > > be transported?
> > > > > > > >
> > > > > > > > My real question is, how to eliminate all duplication and if
> > that
> > > > is
> > > > > > > > impossible, will there be a need for applications which
> navigate
> > > > > > > > up and down the layers of headers to ensure they are
> consistent?
> > > > > > > >
> > > > > > > > Todd Boyle
> > > > > > > >
> > > > > > > > Christopher Ferris said 4/3
> > > > > > > > > IMHO, our role should be to provide the content for the
> > semantic
> > > > > > > > > meaning of the elements we include in the header, etc.
> > > > as well as
> > > > > > > > > any information related to semantic equivalence with other
> > > > existing
> > > > > > > > > standards such as RosettaNet, EDI/INT, etc.
> > > > > > > >
> > > > > > > > [...]
> > > > > > > > > > 2. namespaces
> > > > > > > > > >
> > > > > > > > > > MILR: Namespace can help avoid element name clashes,
> > > > but IMO it
> > > > > > doesn't
> > > > > > > > > > addresss the equivalence of semantic entities across
> > > > namespaces.
> > > > > > > > > > Each option should be explored for possible appication
> > within
> > > > the
> > > > > > ebXML
> > > > > > > > > > header specification.
> > > > > > > > > > I firmly believe the issues you raise, relative to the
> > actual
> > > > > > business
> > > > > > > > > > transactions, needs to be addressed by the parties
> > responsible
> > > > for
> > > > > > > > > > specifying these standards (e.g. OTA, et al).
> > > > > > > > > >
> > > > > > > > > > MILR:  I believe ebXML must adopt some XML syntax rules
> that
> > > > > > adequately
> > > > > > > > > > address the issue of semantics...
> > > > > > >
> > > > > > > --
> > > > > > >     _/    _/             Kit C. J. Lueder
> > > > > > >    _/   _/         _/   The MITRE Corp.         Tel:
> 703-883-5205
> > > > > > >   _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell:
> 703-577-2463
> > > > > > >  _/   _/   _/    _/   Mailstop W722           FAX:  703-883-7996
> > > > > > > _/    _/  _/    _/   McLean, VA 22102        Mail: kit@mitre.org
> > > > > > > Worse than an unanswered question is an unquestioned answer.
> > > > >
> > > > >
> > > >
> > > >