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

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

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

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