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

["Dick Brooks" <dick@8760.com>]

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/


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