RE: Compression (was RE: COMPLEXITY BIG ISSUE)

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

David,

There is no question we must support fragmentation and reassembly, as
pointed out by JFrom owner-ebxml-transport@lists.oasis-open.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 [149.174.217.146])
	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 <david.burdett@commerceone.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: owner-ebxml-transport@lists.oasis-open.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.