RE: Compression, encryption and authentication - the way ahead?

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

Compression may be a moot point. For those parties willing to use HTTP,
there is a header, content-coding (ref. section 3.5 of RFC 2616), used to
indicate that a body part has been compressed.

I think we should move on from the compression discussion.


Dick Brooks
http://www.8760.com/

-----Original Message-----
From: owner-ebxml-architecture@lists.oasis-open.org
[mailto:owner-ebxml-architecture@lists.oasis-open.org]On Behalf Of David
RR Webber
Sent: Sunday, March 12, 2000 10:52 AM
To: David Burdett
Cc: ebXML Architecture (E-mail); ebXML Transport (E-mail)
Subject: RE: Compression, encryption and authentication - the way ahead?


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.