Should ebXML standards be based on XML?

["Kit (Christopher) Lueder" <kit@mitre.org>]

There is an active debate currently going on at the ebXML
Transport/Routing/Packaging list about whether the ebXML standards
should be based on XML. The current direction of that group is to use
MIME for the outer envelope, not XML. They are proceeding with a
specification that will be brought forward for vote, but that seems like
a pretty late time to ask for a change in direction, if you disagree
with their approach. If you have any concerns, this may be an opportune
time to express them.
Kit Lueder.
MITRE.

-- 
    _/    _/             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.


Subject: Concern with basic ebXML TRP Syntax/Semantics]
      Date: Thu, 13 Apr 2000 18:16:51 -0700
     From:  Nicholas Kassem <Nick.Kassem@eng.sun.com>
       To: "Kit (Christopher) Lueder" <kit@mitre.org>, Rik Drummond
<drummond@onramp.net>
       CC: ebXML-Transport@lists.oasis-open.org
 
Kit,
With all due respect I simply don't accept your literal interpretation
of 
the recently published requirements document. We are clearly here to
move 
XML into the business mainstream. I don't believe we have an option to 
casually invent stuff on the fly when there are widely accepted and 
credible Internet Standards out there nor can we ignore existing
business 
imperatives. Waiting for an XML packaging scheme sanctioned by w3c is
not 
an option, aligning with such a standard if/when it arrives is an
option. 
We have repeatedly stated that this is our goal. Clearly, we are not
making 
progress on this topic in this working group. So, perhaps the time/place
to 
deal with this is when the requirements document comes up for an ebXML
wide 
vote.

My recommendation is that we inject some clarifying language in the 
requirements document to enable pragmatic interpretation of that
document.

Regards,
Nick

At 11:45 AM 4/13/2000 -0400, Kit (Christopher) Lueder wrote:
>No. Maybe the Requirements group collects requirements from all the
>individual groups, but if there is a conflict in the requirements
>between different groups, the Requirements group (or as a last resort,
>the full ebXML) is the place to resolve them.
>Kit.
>
>Rik Drummond wrote:
> >
> > the requirements roll up from the teams to the requirements group... 
> not the
> > other way around.... rik
> >
> > -----Original Message-----
> > From: owner-ebxml-transport@lists.oasis-open.org
> > [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Dick
> > Brooks
> > Sent: Tuesday, April 11, 2000 9:50 AM
> > To: Kit (Christopher) Lueder
> > Cc: ebXML-Transport@lists.oasis-open.org; Dick Brooks
> > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> >
> > Kit,
> >
> > I agree with you, the issues with ebXML requirements need to be addressed
> > and I believe Rik is aware of this.
> >
> > You referenced BizTalk as a pure XML packaging standard, but as far as I
> > know BizTalk is a Microsoft initiative and the spec is not being developed
> > under a formal standards body (e.g. IETF, W3C). Besides, as far as I'm
> > aware, BizTalk does not define how to package PGP or S/MIME 
> signed/encrypted
> > payloads in XML, which is one of the ebXML TRP requirements.
> >
> > Your question regarding a web server or browsers ability to generate a MIME
> > envelope; actually MIME is the enveloping standard used in HTTP message
> > exchanges. All web forms are packaged in MIME envelopes, all server
> > responses are also, the bottom line is: MIME capability is an inherent part
> > of web browsers/servers. In fact, the current ebXML packaging design is
> > compatible with several transports (SMTP, HTTP, HTTPS, FTP).
> >
> > Dick Brooks
> > http://www.8760.com/
> >
> > -----Original Message-----
> > From: Kit (Christopher) Lueder [mailto:kit@mitre.org]
> > Sent: Tuesday, April 11, 2000 7:45 AM
> > To: Dick Brooks
> > Cc: ebXML-Transport@lists.oasis-open.org
> > Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> >
> > Let's not get too defensive here...I raised the issue of MIME not being
> > a W3C standard a month ago, and when I saw that the group had proceeded
> > with a different design despite that issue, I raised the issue again. If
> > you think the issue was wrong, you should have escallated it to the
> > ebXML Requirements group where it originated, rather than ignoring it.
> >
> > I don't see why "There is no XML based standard for packaging mixed
> > payloads" means you must go with a MIME solution rather than creating an
> > XML packaging standard? Also, I thought BizTalk was a pure XML packaging
> > standard, so this statement wasn't really true?
> >
> > Regarding "MIME is not that difficult to process", how hard is it for a
> > web server to generate MIME envelopes along with the XML content after
> > the user has filled in a web form (or what ever method for triggering
> > the generation of XML content)? (This is a serious question, not a
> > criticism...)
> >
> > Sincerely,
> > Kit.
> >
> > Dick Brooks wrote:
> > > 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.
> > >
> > > 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.
> > >
> > > - 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).
> > >
> > > - 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.
> > >
> > > 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/