[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Compression (was RE: COMPLEXITY BIG ISSUE)
David, There is no question we must support fragmentation and reassembly, as pointed out by JFrom firstname.lastname@example.org Sun Mar 12 12:49:06 2000 Received: (from majordomo@localhost) by oasis.oasis-open.org (8.8.8/8.8.8) id MAA15397 for ebxml-transport-out; Sun, 12 Mar 2000 12:00:49 -0500 (EST) Received: from spamgaac.compuserve.com (as-img-3.compuserve.com [126.96.36.199]) by oasis.oasis-open.org (8.8.8/8.8.8) with ESMTP id LAA15328; Sun, 12 Mar 2000 11:53:09 -0500 (EST) Received: (from mailgate@localhost) by spamgaac.compuserve.com (8.9.3/8.9.3/SUN-1.9) id LAA00462; Sun, 12 Mar 2000 11:52:39 -0500 (EST) Date: Sun, 12 Mar 2000 11:52:13 -0500 From: David RR Webber <Gnosis_@compuserve.com> Subject: RE: Compression, encryption and authentication - the way ahead? To: David Burdett <email@example.com> Cc: "ebXML Architecture (E-mail)" <ebXML-Architecture@lists.oasis-open.org>, "ebXML Transport (E-mail)" <ebXML-Transport@lists.oasis-open.org> Message-ID: <200003121152_MC2-9CC7-C383@compuserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oasis.oasis-open.org id LAA15329 Sender: firstname.lastname@example.org Precedence: bulk Message text written by David Burdett > This thread on compression (and encryption and authentication) has been an exceedingly long and tortuous. So, in an attempt to draw it to a close, I suggest the following: 1. The Transport Group does not address compression in any general sense whilst not precluding its use in specific instances 2. Our specification should permit discrete parts of messages to be compressed using established encryption technology (see note belown on Message Manifest) 3. We similarly do not specifically address encryption but allow the use of existing encryption technologies 4. We do address authentication and security. For eCommerce, it will be essential in many instances that the authenticity of a message can be establised. Specifically the recipient of a message will not know whether to act on or trust the message unless the authenticity of the sender is known. Anyone disagree with this approach? David< >>>>>>>>>>>> More to the point - those in favour - YES. I vote YES and lets move on - quickly! Under item 2. note that use of MIME and CDATA and XLink already allow you to do this, (also note that XMLSolutions already have XMLZip (freeware) available that takes this approach). So W3C/ITEF and XML already have necessary done - at most all we should need to do is reference an implementation example. No formal spec' needed - its already included in the box. This is why it is so important for us to not waste bandwidth talking up things that the XML experts can tell us in a heartbeat is already available. We need to focus on BUSINESS FUNCTIONAL requirements at this point. The nerds and geeks can then find the optimal syntax mechanisms to address and provide the agreed to functionality. DW.
Powered by eList eXpress LLC