From owner-ietf-ediint@mail.imc.org  Tue Mar  5 13:23:40 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14590
	for <ediint-archive@odin.ietf.org>; Tue, 5 Mar 2002 13:23:39 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g25Hot324833
	for ietf-ediint-bks; Tue, 5 Mar 2002 09:50:55 -0800 (PST)
Received: from drummondgroup.com (drummondgroup.com [192.41.39.80])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g25Hos824828
	for <ietf-ediint@imc.org>; Tue, 5 Mar 2002 09:50:54 -0800 (PST)
Received: from David (adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33]) by drummondgroup.com (8.8.5) id KAA24477; Tue, 5 Mar 2002 10:48:27 -0700 (MST)
X-Authentication-Warning: drummondgroup.com: Host adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33] claimed to be David
From: "David Fischer" <david@drummondgroup.com>
To: <ietf-ediint@imc.org>
Subject: Compression Order
Date: Tue, 5 Mar 2002 11:42:50 -0600
Message-ID: <NFBBIIHJIBLCBFENACIJGEIMCEAA.david@drummondgroup.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B1_01C1C43A.E102F820"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <5575B281AEC6D511A4120008C7F7E9EF0D641C@DFIEXSVR.dficomm.dficom.com>
Importance: Normal
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_00B1_01C1C43A.E102F820
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

AS3?...We are beginning to implement the Compression Draft
specification:

http://www.ietf.org/internet-drafts/draft-ietf-ediint-compre
ssion-00.txt

and an implementation decision has arisen.  When Compression
is applied in concert with Signatures, which should be
applied first?

    Compress + Sign    or
    Sign + Compress

        and

    Compress + Sign + Encrypt   or
    Sign + Compress + Encrypt

Different companies have presented valid business cases for
each alternative.

The advocates for Signing first desire the signature to be
over readable text (you know what you are signing -- which
is why we never Sign after Encrypting).

The advocates for Compressing first desire performance
improvements.  In this case, Compression is compared as just
another encoding scheme so it is really still plain text.

Discussions thus far have resulted in a consensus that the
implementors should be able to apply these functions in
either order when sending.  When receiving, the
implementations should be able to process either case.

We are looking for further discussions. . .

Regards,

David Fischer
Drummond Group.

------=_NextPart_000_00B1_01C1C43A.E102F820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>AS3?...</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>We are beginning to implement the Compression Draft=20
specification:</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression=
-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-ediint-compressio=
n-00.txt</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>and an implementation decision has arisen.&nbsp; When =
Compression is=20
applied in concert with Signatures, which should be applied=20
first?</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002>&nbsp;&nbsp;&nbsp; <FONT=20
face=3D"Comic Sans MS" color=3D#0000ff size=3D2>Compress + =
Sign&nbsp;&nbsp;&nbsp;=20
or</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002>&nbsp;&nbsp;&nbsp; <FONT=20
face=3D"Comic Sans MS" color=3D#0000ff size=3D2>Sign + =
Compress</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN =
class=3D700333017-05032002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3D"Comic Sans MS" color=3D#0000ff =
size=3D2>and</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002>&nbsp;&nbsp;&nbsp; <FONT=20
face=3D"Comic Sans MS" color=3D#0000ff size=3D2>Compress + Sign + =
Encrypt&nbsp;&nbsp;=20
or</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002>&nbsp;&nbsp;&nbsp; <FONT=20
face=3D"Comic Sans MS" color=3D#0000ff size=3D2>Sign + Compress +=20
Encrypt</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>Different companies have presented valid business cases for =
each=20
alternative.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>The advocates for Signing first desire the signature to be over =
readable=20
text (you know what you are signing -- which is why we never Sign after=20
Encrypting).</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>The advocates for Compressing first desire performance=20
improvements.&nbsp; In this case, Compression is compared as just =
another=20
encoding scheme so it is really still plain text.</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>Discussions thus far have resulted in a consensus that the =
implementors=20
should be able to apply these functions in either order when =
sending.&nbsp; When=20
receiving, the implementations should be able to process either=20
case.</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>We are looking for further discussions. . .</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>David Fischer</FONT></SPAN></DIV>
<DIV><SPAN class=3D700333017-05032002><FONT face=3D"Comic Sans MS" =
color=3D#0000ff=20
size=3D2>Drummond Group.</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_00B1_01C1C43A.E102F820--



From owner-ietf-ediint@mail.imc.org  Tue Mar  5 14:37:03 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23051
	for <ediint-archive@odin.ietf.org>; Tue, 5 Mar 2002 14:37:02 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g25JBQ728263
	for ietf-ediint-bks; Tue, 5 Mar 2002 11:11:26 -0800 (PST)
Received: from c003.snv.cp.net (c003-h016.c003.snv.cp.net [209.228.32.230])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g25JBP828259
	for <ietf-ediint@imc.org>; Tue, 5 Mar 2002 11:11:25 -0800 (PST)
Received: (cpmta 21932 invoked from network); 5 Mar 2002 11:10:24 -0800
Received: from 64.192.128.225 (HELO americancoders.com)
  by smtp.telocity.com (209.228.32.230) with SMTP; 5 Mar 2002 11:10:24 -0800
X-Sent: 5 Mar 2002 19:10:24 GMT
Message-ID: <3C851813.60AD566C@americancoders.com>
Date: Tue, 05 Mar 2002 14:10:11 -0500
From: joe mcverry <jmcverry@americancoders.com>
Organization: American Coders, LTD
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Fischer <david@drummondgroup.com>
CC: ietf-ediint@imc.org
Subject: Re: Compression Order
References: <NFBBIIHJIBLCBFENACIJGEIMCEAA.david@drummondgroup.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Signatures tend to be small - don't they?


Joe

> David Fischer wrote:
> 
> We are beginning to implement the Compression Draft specification:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> 
> and an implementation decision has arisen.  When Compression is
> applied in concert with Signatures, which should be applied first?
> 
>     Compress + Sign    or
>     Sign + Compress
> 
>         and
> 
>     Compress + Sign + Encrypt   or
>     Sign + Compress + Encrypt
> 
> Different companies have presented valid business cases for each
> alternative.
> 
> The advocates for Signing first desire the signature to be over
> readable text (you know what you are signing -- which is why we never
> Sign after Encrypting).
> 
> The advocates for Compressing first desire performance improvements.
> In this case, Compression is compared as just another encoding scheme
> so it is really still plain text.
> 
> Discussions thus far have resulted in a consensus that the
> implementors should be able to apply these functions in either order
> when sending.  When receiving, the implementations should be able to
> process either case.
> 
> We are looking for further discussions. . .
> 
> Regards,
> 
> David Fischer
> Drummond Group.

-- 
----------- 
Joe McVerry
American Coders Ltd.
POBox 97462
Raleigh, NC   27624  USA
919.846.2014 (voice/fax)
http://www.americancoders.com
Home Of OBOE - an EDI and EDI/XML Translator
    and xBaseJ - xBase Database Engine For Java


From owner-ietf-ediint@mail.imc.org  Tue Mar  5 15:11:48 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24889
	for <ediint-archive@odin.ietf.org>; Tue, 5 Mar 2002 15:11:47 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g25Jl0M29112
	for ietf-ediint-bks; Tue, 5 Mar 2002 11:47:00 -0800 (PST)
Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g25Jkw829106
	for <ietf-ediint@imc.org>; Tue, 5 Mar 2002 11:46:58 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58])
	by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g25Jkt811221;
	Tue, 5 Mar 2002 14:46:55 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31])
	by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g25Jkrk08507;
	Tue, 5 Mar 2002 14:46:53 -0500 (EST)
Received: from dhcp-123-189.mitre.org (128.29.123.189) by mailhub1.mitre.org with SMTP
        id 9396240; Tue, 05 Mar 2002 14:46:24 -0500
Message-ID: <3C8520AB.390F8383@mitre.org>
Date: Tue, 05 Mar 2002 14:46:51 -0500
From: "Kit (Christopher) Lueder" <kit@mitre.org>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.78 [en]C-20010724M  (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ietf-ediint@imc.org
CC: David Fischer <david@drummondgroup.com>
Subject: Re: Compression Order
References: <NFBBIIHJIBLCBFENACIJGEIMCEAA.david@drummondgroup.com> <3C851813.60AD566C@americancoders.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


I think the issue is not the size of the signatures (which may be small), but
the size of the document being signed, which may be enormous. Compressing the
document prior to signing it means less processing overhead when performing the
signature operation. (This is a benefit for compressing first.)

But I lean toward the Signing First approach. Another benefit of that is you can
uncompress it and make it readable and not violate the signature. If you
compress first, uncompressing it means you are no longer looking at a signed
document.

Kit Lueder.
MITRE.

joe mcverry wrote:
> Signatures tend to be small - don't they?
> Joe
> 
> > David Fischer wrote:
> >
> > We are beginning to implement the Compression Draft specification:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> >
> > and an implementation decision has arisen.  When Compression is
> > applied in concert with Signatures, which should be applied first?
> >
> >     Compress + Sign    or
> >     Sign + Compress
> >
> >         and
> >
> >     Compress + Sign + Encrypt   or
> >     Sign + Compress + Encrypt
> >
> > Different companies have presented valid business cases for each
> > alternative.
> >
> > The advocates for Signing first desire the signature to be over
> > readable text (you know what you are signing -- which is why we never
> > Sign after Encrypting).
> >
> > The advocates for Compressing first desire performance improvements.
> > In this case, Compression is compared as just another encoding scheme
> > so it is really still plain text.
> >
> > Discussions thus far have resulted in a consensus that the
> > implementors should be able to apply these functions in either order
> > when sending.  When receiving, the implementations should be able to
> > process either case.
> >
> > We are looking for further discussions. . .
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.

-- 
    _/    _/             Kit C. J. Lueder       
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 7515 Colshire Dr        Cell: 703-577-2463
 _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
_/    _/  _/    _/   McLean, VA 22102-7508   Mail: kit@mitre.org
Worse than an unanswered question is an unquestioned answer.



From owner-ietf-ediint@mail.imc.org  Tue Mar  5 15:46:07 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27492
	for <ediint-archive@odin.ietf.org>; Tue, 5 Mar 2002 15:46:07 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id g25KVqr00367
	for ietf-ediint-bks; Tue, 5 Mar 2002 12:31:52 -0800 (PST)
Received: from drummondgroup.com (drummondgroup.com [192.41.39.80])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g25KVp800363
	for <ietf-ediint@imc.org>; Tue, 5 Mar 2002 12:31:51 -0800 (PST)
Received: from David (adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33]) by drummondgroup.com (8.8.5) id NAA04608; Tue, 5 Mar 2002 13:31:18 -0700 (MST)
X-Authentication-Warning: drummondgroup.com: Host adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33] claimed to be David
From: "David Fischer" <david@drummondgroup.com>
To: "joe mcverry" <jmcverry@americancoders.com>
Cc: <ietf-ediint@imc.org>
Subject: RE: Compression Order
Date: Tue, 5 Mar 2002 14:20:24 -0600
Message-ID: <NFBBIIHJMLEPPLNMNKLGMEIIDFAA.david@drummondgroup.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <3C851813.60AD566C@americancoders.com>
Importance: Normal
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Yes, signatures are small but the effort to create them is directly related to
the size of the file being signed.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: owner-ietf-ediint@mail.imc.org
[mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of joe mcverry
Sent: Tuesday, March 05, 2002 1:10 PM
To: David Fischer
Cc: ietf-ediint@imc.org
Subject: Re: Compression Order



Signatures tend to be small - don't they?


Joe

> David Fischer wrote:
>
> We are beginning to implement the Compression Draft specification:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
>
> and an implementation decision has arisen.  When Compression is
> applied in concert with Signatures, which should be applied first?
>
>     Compress + Sign    or
>     Sign + Compress
>
>         and
>
>     Compress + Sign + Encrypt   or
>     Sign + Compress + Encrypt
>
> Different companies have presented valid business cases for each
> alternative.
>
> The advocates for Signing first desire the signature to be over
> readable text (you know what you are signing -- which is why we never
> Sign after Encrypting).
>
> The advocates for Compressing first desire performance improvements.
> In this case, Compression is compared as just another encoding scheme
> so it is really still plain text.
>
> Discussions thus far have resulted in a consensus that the
> implementors should be able to apply these functions in either order
> when sending.  When receiving, the implementations should be able to
> process either case.
>
> We are looking for further discussions. . .
>
> Regards,
>
> David Fischer
> Drummond Group.

--
-----------
Joe McVerry
American Coders Ltd.
POBox 97462
Raleigh, NC   27624  USA
919.846.2014 (voice/fax)
http://www.americancoders.com
Home Of OBOE - an EDI and EDI/XML Translator
    and xBaseJ - xBase Database Engine For Java



From owner-ietf-ediint@mail.imc.org  Tue Mar  5 17:21:31 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02997
	for <ediint-archive@odin.ietf.org>; Tue, 5 Mar 2002 17:21:30 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g25M3qU03118
	for ietf-ediint-bks; Tue, 5 Mar 2002 14:03:52 -0800 (PST)
Received: from one.elistx.com (one.elistx.com [209.116.252.130])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g25M3p803114
	for <ietf-ediint@imc.org>; Tue, 5 Mar 2002 14:03:51 -0800 (PST)
Received: from isdn1-17.connext.net (isdn1-17.connext.net [216.4.158.177])
 by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GSI00IOVTFKNO@eListX.com>
 for ietf-ediint@imc.org; Tue, 05 Mar 2002 17:06:58 -0500 (EST)
Date: Tue, 05 Mar 2002 17:08:22 -0500 (EST)
From: James M Galvin <galvin@acm.org>
Subject: Re: Compression Order
In-reply-to: <NFBBIIHJIBLCBFENACIJGEIMCEAA.david@drummondgroup.com>
X-X-Sender: galvin@three.elistx.com
To: David Fischer <david@drummondgroup.com>
Cc: ietf-ediint@imc.org
Message-id: <Pine.BSF.4.43.0203051657190.13070-100000@three.elistx.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>


I'm not aware of any technical reason (security-related or otherwise)
why you would have to choose one over the other however, semantically,
the reasoning that applies to sign before encrypting applies here also.

If you sign the compressed (encrypted) form instead of the original
"text", then strictly speaking the only security service available to
you is origin authentication.  It would be *wrong* to associate or infer
or in any way tightly-couple any authorization semantics with the
signature.  It would be *wrong* to associate or infer or in any way
tightly-couple any characteristic or attribute that suggests the entity
that created the signature had any knowledge whatsoever of the actual
content that was signed.

I would expect this to be an issue in most business applications and
contexts.

Jim

--
James M. Galvin <galvin@acm.org>


On Tue, 5 Mar 2002, David Fischer wrote:

    Date: Tue, 05 Mar 2002 11:42:50 -0600
    From: David Fischer <david@drummondgroup.com>
    To: ietf-ediint@imc.org
    Subject: Compression Order

    AS3?...We are beginning to implement the Compression Draft
    specification:

    http://www.ietf.org/internet-drafts/draft-ietf-ediint-compre
    ssion-00.txt

    and an implementation decision has arisen.  When Compression
    is applied in concert with Signatures, which should be
    applied first?

        Compress + Sign    or
        Sign + Compress

            and

        Compress + Sign + Encrypt   or
        Sign + Compress + Encrypt

    Different companies have presented valid business cases for
    each alternative.

    The advocates for Signing first desire the signature to be
    over readable text (you know what you are signing -- which
    is why we never Sign after Encrypting).

    The advocates for Compressing first desire performance
    improvements.  In this case, Compression is compared as just
    another encoding scheme so it is really still plain text.

    Discussions thus far have resulted in a consensus that the
    implementors should be able to apply these functions in
    either order when sending.  When receiving, the
    implementations should be able to process either case.

    We are looking for further discussions. . .

    Regards,

    David Fischer
    Drummond Group.




From owner-ietf-ediint@mail.imc.org  Tue Mar  5 22:52:06 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14634
	for <ediint-archive@odin.ietf.org>; Tue, 5 Mar 2002 22:52:06 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g263ZRj11198
	for ietf-ediint-bks; Tue, 5 Mar 2002 19:35:27 -0800 (PST)
Received: from ns1.claredi.com ([216.219.239.179])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g263ZQ811193
	for <ietf-ediint@imc.org>; Tue, 5 Mar 2002 19:35:26 -0800 (PST)
Received: from claredi.com (slip-12-65-0-238.mis.prserv.net [12.65.0.238])
	by ns1.claredi.com (8.9.3/8.9.3) with ESMTP id UAA19906;
	Tue, 5 Mar 2002 20:35:18 -0700
X-Mozilla-Status: 0801
Message-ID: <3C8588CE.2070502@claredi.com>
Date: Tue, 05 Mar 2002 20:11:10 -0700
From: Kepa Zubeldia <Kepa.Zubeldia@claredi.com>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; VaioUSSum01) Gecko/20010131 Netscape6/6.01
X-Accept-Language: en, es
MIME-Version: 1.0
To: David Fischer <david@drummondgroup.com>
CC: ietf-ediint@imc.org
Subject: Re: Compression Order
References: <NFBBIIHJIBLCBFENACIJGEIMCEAA.david@drummondgroup.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


What if you need more than one signature?  Common situation in 
healthcare.  It would have to be

sign - sign - sign - compress - encrypt

So you know what you are signing at each step, before it turns into "mush".

Kepa


David Fischer wrote:

> We are beginning to implement the Compression Draft specification:
> 
>  
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> 
>  
> 
> and an implementation decision has arisen.  When Compression is applied 
> in concert with Signatures, which should be applied first?
> 
>  
> 
>     Compress + Sign    or
> 
>     Sign + Compress
> 
>  
> 
>         and
> 
>  
> 
>     Compress + Sign + Encrypt   or
> 
>     Sign + Compress + Encrypt
> 
>  
> 
> Different companies have presented valid business cases for each 
> alternative. 
> 
>  
> 
> The advocates for Signing first desire the signature to be over readable 
> text (you know what you are signing -- which is why we never Sign after 
> Encrypting).
> 
>  
> 
> The advocates for Compressing first desire performance improvements.  In 
> this case, Compression is compared as just another encoding scheme so it 
> is really still plain text.
> 
>  
> 
> Discussions thus far have resulted in a consensus that the implementors 
> should be able to apply these functions in either order when sending.  
> When receiving, the implementations should be able to process either case.
> 
>  
> 
> We are looking for further discussions. . .
> 
>  
> 
> Regards,
> 
>  
> 
> David Fischer
> 
> Drummond Group.




From owner-ietf-ediint@mail.imc.org  Wed Mar  6 11:24:02 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15913
	for <ediint-archive@odin.ietf.org>; Wed, 6 Mar 2002 11:24:02 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id g26G41x09824
	for ietf-ediint-bks; Wed, 6 Mar 2002 08:04:01 -0800 (PST)
Received: from drummondgroup.com (drummondgroup.com [192.41.39.80])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g26G40809817
	for <ietf-ediint@imc.org>; Wed, 6 Mar 2002 08:04:00 -0800 (PST)
Received: from David (adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33]) by drummondgroup.com (8.8.5) id JAA24958; Wed, 6 Mar 2002 09:03:35 -0700 (MST)
X-Authentication-Warning: drummondgroup.com: Host adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33] claimed to be David
From: "David Fischer" <david@drummondgroup.com>
To: "Kepa Zubeldia" <Kepa.Zubeldia@claredi.com>
Cc: <ietf-ediint@imc.org>
Subject: RE: Compression Order
Date: Wed, 6 Mar 2002 10:04:09 -0600
Message-ID: <NFBBIIHJMLEPPLNMNKLGEEKADFAA.david@drummondgroup.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3C8588CE.2070502@claredi.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


True, but we don't support multiple signatures.

Serial signatures (signing over the previous signature) are fairly simple, as a
construct.  Parallel signatures are undefined at the moment.  We could easily
support serial signatures in AS2.

A compressed signature is not "mush" any more than receiving a .ZIP attachment
would be.  OTOH, receiving an encrypted object without possessing the
private-key is truly "mush" to the recipient/potential signer.  In the case of
serial signatures and compression, the inner part can be read (decompressed)
without disturbing the signature so I don't know why multiple signatures would
be an argument either way?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com]
Sent: Tuesday, March 05, 2002 9:11 PM
To: David Fischer
Cc: ietf-ediint@imc.org
Subject: Re: Compression Order


What if you need more than one signature?  Common situation in
healthcare.  It would have to be

sign - sign - sign - compress - encrypt

So you know what you are signing at each step, before it turns into "mush".

Kepa


David Fischer wrote:

> We are beginning to implement the Compression Draft specification:
>
>
>
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
>
>
>
> and an implementation decision has arisen.  When Compression is applied
> in concert with Signatures, which should be applied first?
>
>
>
>     Compress + Sign    or
>
>     Sign + Compress
>
>
>
>         and
>
>
>
>     Compress + Sign + Encrypt   or
>
>     Sign + Compress + Encrypt
>
>
>
> Different companies have presented valid business cases for each
> alternative.
>
>
>
> The advocates for Signing first desire the signature to be over readable
> text (you know what you are signing -- which is why we never Sign after
> Encrypting).
>
>
>
> The advocates for Compressing first desire performance improvements.  In
> this case, Compression is compared as just another encoding scheme so it
> is really still plain text.
>
>
>
> Discussions thus far have resulted in a consensus that the implementors
> should be able to apply these functions in either order when sending.
> When receiving, the implementations should be able to process either case.
>
>
>
> We are looking for further discussions. . .
>
>
>
> Regards,
>
>
>
> David Fischer
>
> Drummond Group.





From owner-ietf-ediint@mail.imc.org  Wed Mar  6 13:03:29 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23057
	for <ediint-archive@odin.ietf.org>; Wed, 6 Mar 2002 13:03:28 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g26Hi0715052
	for ietf-ediint-bks; Wed, 6 Mar 2002 09:44:00 -0800 (PST)
Received: from webhub2.idsworld.com ([63.140.159.200])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Hhx815048
	for <ietf-ediint@imc.org>; Wed, 6 Mar 2002 09:43:59 -0800 (PST)
Received: by WEBHUB2 with Internet Mail Service (5.5.2653.19)
	id <1SCC1Y8G>; Wed, 6 Mar 2002 11:41:18 -0600
Message-ID: <E158432678CAD111A25E00805FBEB34621FFEE@WEBHUB2>
From: Christian Putnam <christian@isoft.com>
To: "'David Fischer'" <david@drummondgroup.com>
Cc: ietf-ediint@imc.org
Subject: RE: Compression Order
Date: Wed, 6 Mar 2002 11:41:14 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>


David,

I think this compression discussion is constructive.  However, I believe it
would be utterly foolish to support anything other than "compress first and
then sign" for the AS2 standard.  Why? First, the obvious performance gain.
Signatures might be small but the time it takes to generate them has a
direct corelation to the size of the file.  Two, AS2 is used 99.9999% of the
time in batch mode where there is no user intervention.  How many time can
anyone recall someone opening up a EDI 850 purchase order and reviewing it
and then deciding to sign it.  These systems simply do not work that way.
The typical implementation would send (and sign) everthing in a particular
directory.  AS2 is not similar to PGP mail.  Three, exclusive support of the
"compress then sign" model does not prohibit the user from viewing each
individual file if he/she so wishes and then making the decision to sign the
uncompressed data.  In this rare instance where the user has viewed this
individual file and desires to sign it, he would always be sending the file
after he signs it.  In other words, there would be no case where the user
would sign and then not send to the trading partner.   The decision to sign
is a work process handled in the GUI (or command console).  The user then
passess all the various settings to software module that compresses, signs,
encrypts, computes message digests, encodes, etc.  This software module
receives data passed from the GUI telling it to  sign a individual file or
group of files.  It then compressess the file and then signs it.  Thus,
there is no need in the standard to support signing uncompressed data prior
to compression.  

This particular issue will have a TREMENDOUS impact on performance.  We
should not give our customers the option to sign uncompressed data if they
use compression.  


Regards,


Christian Putnam
iSoft

  

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com] 
Sent: Wednesday, March 06, 2002 10:04 AM
To: Kepa Zubeldia
Cc: ietf-ediint@imc.org
Subject: RE: Compression Order



True, but we don't support multiple signatures.

Serial signatures (signing over the previous signature) are fairly simple,
as a construct.  Parallel signatures are undefined at the moment.  We could
easily support serial signatures in AS2.

A compressed signature is not "mush" any more than receiving a .ZIP
attachment would be.  OTOH, receiving an encrypted object without possessing
the private-key is truly "mush" to the recipient/potential signer.  In the
case of serial signatures and compression, the inner part can be read
(decompressed) without disturbing the signature so I don't know why multiple
signatures would be an argument either way?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Kepa Zubeldia [mailto:Kepa.Zubeldia@claredi.com]
Sent: Tuesday, March 05, 2002 9:11 PM
To: David Fischer
Cc: ietf-ediint@imc.org
Subject: Re: Compression Order


What if you need more than one signature?  Common situation in healthcare.
It would have to be

sign - sign - sign - compress - encrypt

So you know what you are signing at each step, before it turns into "mush".

Kepa


David Fischer wrote:

> We are beginning to implement the Compression Draft specification:
>
>
>
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.t
> xt
>
>
>
> and an implementation decision has arisen.  When Compression is 
> applied in concert with Signatures, which should be applied first?
>
>
>
>     Compress + Sign    or
>
>     Sign + Compress
>
>
>
>         and
>
>
>
>     Compress + Sign + Encrypt   or
>
>     Sign + Compress + Encrypt
>
>
>
> Different companies have presented valid business cases for each 
> alternative.
>
>
>
> The advocates for Signing first desire the signature to be over 
> readable text (you know what you are signing -- which is why we never 
> Sign after Encrypting).
>
>
>
> The advocates for Compressing first desire performance improvements.  
> In this case, Compression is compared as just another encoding scheme 
> so it is really still plain text.
>
>
>
> Discussions thus far have resulted in a consensus that the 
> implementors should be able to apply these functions in either order 
> when sending. When receiving, the implementations should be able to 
> process either case.
>
>
>
> We are looking for further discussions. . .
>
>
>
> Regards,
>
>
>
> David Fischer
>
> Drummond Group.




From owner-ietf-ediint@mail.imc.org  Wed Mar  6 14:12:21 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28513
	for <ediint-archive@odin.ietf.org>; Wed, 6 Mar 2002 14:12:20 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g26Iqfp18772
	for ietf-ediint-bks; Wed, 6 Mar 2002 10:52:41 -0800 (PST)
Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Iqe818768
	for <ietf-ediint@imc.org>; Wed, 6 Mar 2002 10:52:40 -0800 (PST)
Received: from sv ([12.234.202.224]) by rwcrmhc54.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020306185237.GTHK1214.rwcrmhc54.attbi.com@sv>
          for <ietf-ediint@imc.org>; Wed, 6 Mar 2002 18:52:37 +0000
From: "Carl Hage" <carl@chage.com>
To: ietf-ediint@imc.org
Date: Wed, 6 Mar 2002 10:52:33 -0800
Subject: RE: Compression Order
In-reply-to: <E158432678CAD111A25E00805FBEB34621FFEE@WEBHUB2>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <20020306185237.GTHK1214.rwcrmhc54.attbi.com@sv>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>


From:           	Christian Putnam <christian@isoft.com>
> However, I believe it would be utterly foolish to support anything other
> than "compress first and then sign" for the AS2 standard.  Why? First,
> the obvious performance gain. 

I respectfully disagree. I believe compression should be part of the 
encoding and transport process-- added independently of the 
signatures used for non-repudiation. This allows the data to be stored 
in different forms while retaining the signature with data. It might be 
stored compressed, uncompressed, or re-compressed in a different 
format (zip/jar). Signing compressed data prevents people from passing 
around the signatures in back-end applications.

If you sign before compression, you can compress, transmit, copy, 
etc. the data in various formats and places and always retain the ability 
to authenticate a signature. Compressing first, mean you cannot 
maintain other representations and the single compressed form must 
be maintained.

It also makes sense to me people (or a machine) should sign original 
plain-text data, not data after encoding, compressing, etc.

The performance difference is negligible in comparison to compression. 
The compression algorithms thenselves compute a checksum as well 
as compressing the data. Computing an MD5 or SHA hash over 
uncompressed data is fast and insignificant in comparison to the time 
for compression, encryption, RSA operations, etc.

--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086


From owner-ietf-ediint@mail.imc.org  Fri Mar  8 12:55:59 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20549
	for <ediint-archive@odin.ietf.org>; Fri, 8 Mar 2002 12:55:59 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id g28HaML01239
	for ietf-ediint-bks; Fri, 8 Mar 2002 09:36:22 -0800 (PST)
Received: from drummondgroup.com (drummondgroup.com [192.41.39.80])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g28HaL801235
	for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 09:36:21 -0800 (PST)
Received: from David (adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33]) by drummondgroup.com (8.8.5) id KAA10451; Fri, 8 Mar 2002 10:36:19 -0700 (MST)
X-Authentication-Warning: drummondgroup.com: Host adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33] claimed to be David
From: "David Fischer" <david@drummondgroup.com>
To: <ietf-ediint@imc.org>
Subject: RE: Compression Order
Date: Fri, 8 Mar 2002 11:36:53 -0600
Message-ID: <NFBBIIHJIBLCBFENACIJCELBCEAA.david@drummondgroup.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <20020306185237.GTHK1214.rwcrmhc54.attbi.com@sv>
Importance: Normal
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


I am sensing a distinct difference of opinion concern which should come first,
signing or compression.  I am also sensing somewhat of a consensus (not
unanimous) that we could allow vendors to choose which order to apply signing
and compression.  This would require implementations to be able to unpackage in
either order (which should not have a significant impact on code since
unpackaging is done by reading the Content-Type).

Is this essentially the feeling of the group?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: owner-ietf-ediint@mail.imc.org
[mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Carl Hage
Sent: Wednesday, March 06, 2002 12:53 PM
To: ietf-ediint@imc.org
Subject: RE: Compression Order



From:           	Christian Putnam <christian@isoft.com>
> However, I believe it would be utterly foolish to support anything other
> than "compress first and then sign" for the AS2 standard.  Why? First,
> the obvious performance gain.

I respectfully disagree. I believe compression should be part of the
encoding and transport process-- added independently of the
signatures used for non-repudiation. This allows the data to be stored
in different forms while retaining the signature with data. It might be
stored compressed, uncompressed, or re-compressed in a different
format (zip/jar). Signing compressed data prevents people from passing
around the signatures in back-end applications.

If you sign before compression, you can compress, transmit, copy,
etc. the data in various formats and places and always retain the ability
to authenticate a signature. Compressing first, mean you cannot
maintain other representations and the single compressed form must
be maintained.

It also makes sense to me people (or a machine) should sign original
plain-text data, not data after encoding, compressing, etc.

The performance difference is negligible in comparison to compression.
The compression algorithms thenselves compute a checksum as well
as compressing the data. Computing an MD5 or SHA hash over
uncompressed data is fast and insignificant in comparison to the time
for compression, encryption, RSA operations, etc.

--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086



From owner-ietf-ediint@mail.imc.org  Fri Mar  8 18:32:55 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11172
	for <ediint-archive@odin.ietf.org>; Fri, 8 Mar 2002 18:32:55 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g28NIBR11886
	for ietf-ediint-bks; Fri, 8 Mar 2002 15:18:11 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g28NIB811882
	for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 15:18:11 -0800 (PST)
Received: from sv ([12.234.202.224]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020308231809.FDWA2951.rwcrmhc53.attbi.com@sv>
          for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 23:18:09 +0000
From: "Carl Hage" <carl@chage.com>
To: ietf-ediint@imc.org
Date: Fri, 8 Mar 2002 15:18:05 -0800
Subject: Re: Compression Draft
In-reply-to: <NFBBIIHJIBLCBFENACIJGEIMCEAA.david@drummondgroup.com>
References: <5575B281AEC6D511A4120008C7F7E9EF0D641C@DFIEXSVR.dficomm.dficom.com>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <20020308231809.FDWA2951.rwcrmhc53.attbi.com@sv>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>


From:           	"David Fischer" <david@drummondgroup.com>

> We are beginning to implement the Compression Draft
> specification:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt

The use of:

Content-Type: application/pkcs7-mime; smime-type=compressed-data

seems inappropriate.

The application "pkcs-mime" shouldn't be used. PKCS7 is a different
and inconsistent method of doing the same as what MIME does.

It really should be pure MIME, independent of PKCS7.

The original intent in the MIME design was to use Content-Transfer-
Encoding for compression. From RFC2048: "Transfer encodings can 
be used to apply general-purpose non-lossy compression algorithms to 
MIME entities.  "

The intent was for someone to define a new encoding type to include 
compression, e.g. "Content-Transfer-Encoding:gzip" or
"Content-Transfer-Encoding:base64-gzip", which could be equivalent to 
httpd content-encoding, or base64 encoded gzip.

Adding a new content-transfer-encoding would be universally useful
in all MIME messages, and simplify encoding.

Alternatively, a new type, e.g.

"Content-Type: application/mime-gzip" or 
"Content-Type: application/mime-encoded; encoding=gzip"

could be defined to mean an application that decodes, then
processes mime headers. However, it would be better to use:

"Content-Type: encoding/gzip" (already built into Netscape)

Where the media type "encoding" means decode and continue parsing
MIME headers, just like multipart or message.

Shouldn't compression be defined completely independently of 
encryption, signatures, etc.? Then EDIINT can use MIME compression 
with multipart/signed, etc. and other independent MIME standards.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086


From owner-ietf-ediint@mail.imc.org  Fri Mar  8 19:05:39 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12500
	for <ediint-archive@odin.ietf.org>; Fri, 8 Mar 2002 19:05:39 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g28NlWM12396
	for ietf-ediint-bks; Fri, 8 Mar 2002 15:47:32 -0800 (PST)
Received: from smtp2.sandisk.com ([12.146.150.11])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g28NlV812392
	for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 15:47:31 -0800 (PST)
Received: from sandisk.com (watermark.sandisk.com [10.252.5.20])
	by smtp2.sandisk.com (8.9.3/8.9.3) with ESMTP id PAA12652
	for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 15:47:29 -0800
Received: from mail pickup service by sandisk.com with Microsoft SMTPSVC;
	 Fri, 8 Mar 2002 15:45:13 -0800
MIME-Version: 1.0
x-receiver: fgoodrum@sandisk.com
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Received: from smtp2.sandisk.com ([10.252.28.11]) by sandisk.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 8 Mar 2002 15:45:11 -0800
Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp2.sandisk.com (8.9.3/8.9.3) with SMTP id PAA12617 for <fgoodrum@sandisk.com>; Fri, 8 Mar 2002 15:46:55 -0800
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28NIBR11886 for ietf-ediint-bks; Fri, 8 Mar 2002 15:18:11 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28NIB811882 for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 15:18:11 -0800 (PST)
Received: from sv ([12.234.202.224]) by rwcrmhc53.attbi.com          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP          id <20020308231809.FDWA2951.rwcrmhc53.attbi.com@sv>          for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 23:18:09 +0000
From: "Carl Hage" <carl@chage.com>
To: <ietf-ediint@imc.org>
Date: Fri, 8 Mar 2002 15:18:05 -0800
Subject: Re: Compression Draft
In-Reply-To: <NFBBIIHJIBLCBFENACIJGEIMCEAA.david@drummondgroup.com>
References: <5575B281AEC6D511A4120008C7F7E9EF0D641C@DFIEXSVR.dficomm.dficom.com>
X-Mailer: Pegasus Mail for Win32 (v3.01d)
Message-ID: <20020308231809.FDWA2951.rwcrmhc53.attbi.com@sv>
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
X-OriginalArrivalTime: 08 Mar 2002 23:45:11.0250 (UTC) FILETIME=[49554320:01C1C6FB]
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



From:           	"David Fischer" <david@drummondgroup.com>

> We are beginning to implement the Compression Draft
> specification:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt

The use of:

Content-Type: application/pkcs7-mime; smime-type=compressed-data

seems inappropriate.

The application "pkcs-mime" shouldn't be used. PKCS7 is a different
and inconsistent method of doing the same as what MIME does.

It really should be pure MIME, independent of PKCS7.

The original intent in the MIME design was to use Content-Transfer-
Encoding for compression. From RFC2048: "Transfer encodings can 
be used to apply general-purpose non-lossy compression algorithms to 
MIME entities.  "

The intent was for someone to define a new encoding type to include 
compression, e.g. "Content-Transfer-Encoding:gzip" or
"Content-Transfer-Encoding:base64-gzip", which could be equivalent to 
httpd content-encoding, or base64 encoded gzip.

Adding a new content-transfer-encoding would be universally useful
in all MIME messages, and simplify encoding.

Alternatively, a new type, e.g.

"Content-Type: application/mime-gzip" or 
"Content-Type: application/mime-encoded; encoding=gzip"

could be defined to mean an application that decodes, then
processes mime headers. However, it would be better to use:

"Content-Type: encoding/gzip" (already built into Netscape)

Where the media type "encoding" means decode and continue parsing
MIME headers, just like multipart or message.

Shouldn't compression be defined completely independently of 
encryption, signatures, etc.? Then EDIINT can use MIME compression 
with multipart/signed, etc. and other independent MIME standards.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086



From owner-ietf-ediint@mail.imc.org  Fri Mar  8 19:46:28 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13805
	for <ediint-archive@odin.ietf.org>; Fri, 8 Mar 2002 19:46:28 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id g290UAq13246
	for ietf-ediint-bks; Fri, 8 Mar 2002 16:30:10 -0800 (PST)
Received: from sawgrass.cyclonesoftware.com (sawgrass.cyclonesoftware.com [12.34.72.101])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g290U8813240
	for <ietf-ediint@imc.org>; Fri, 8 Mar 2002 16:30:08 -0800 (PST)
Received: from THARDINGLAPTOP (ip68-3-34-197.ph.ph.cox.net [68.3.34.197])
	(authenticated)
	by sawgrass.cyclonesoftware.com (8.11.2/8.11.0) with ESMTP id g290U1d18579;
	Fri, 8 Mar 2002 17:30:01 -0700
Message-ID: <06a601c1c701$8d0e3da0$6401a8c0@cyclonecommerce.com>
From: "Terry Harding" <tharding@cyclonecommerce.com>
To: "as1_interop" <as1_interop@lists.drummondgroup.com>
Cc: <ietf-ediint@imc.org>
Subject: Fw: Protocol Action: Compressed Data Content Type for S/MIME to Proposed Standard
Date: Fri, 8 Mar 2002 17:29:56 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



----- Original Message -----
From: "The IESG" <iesg-secretary@ietf.org>
To: <IETF-Announce:>
Cc: "RFC Editor" <rfc-editor@isi.edu>; "Internet Architecture Board"
<iab@isi.edu>; <ietf-smime@imc.org>
Sent: Friday, March 08, 2002 4:37 PM
Subject: Protocol Action: Compressed Data Content Type for S/MIME to
Proposed Standard


>
>
>
> The IESG has approved the Internet-Draft 'Compressed Data Content Type
> for S/MIME' <draft-ietf-smime-compression-07.txt> as a Proposed
> Standard.  This document is the product of the S/MIME Mail Security
> Working Group.  The IESG contact persons are Jeffrey Schiller and
> Marcus Leech.
>
>
> Technical Summary
>
>   The Cryptographic Message Syntax (CMS) data format which is used by
>   SMIME does not provide for compression of content prior to
>   encryption. Because encrypted data is incompressible, compression
>   applied to an enciphered SMIME message will not prove helpful
>   (whether done at the IP layer, or at a lower layer such as in a
>   modem).
>
>   Compressing data prior to encryption provides two important
>   benefits.
>
>   1) It decreases the size of a message.
>   2) It makes cryptographic analysis of the contained message more
>      difficult for compressed data has less redundancy for the
>      cryptanalyst to exploit.
>
>   This document provide a mechanism for adding compression prior to
>   encryption in SMIME by being applied at the CMS layer.
>
> Working Group Summary
>
>   This document has the consensus of the SMIME Working Group.
>
> Protocol Quality
>
>  This document has been reviewed for the IESG by Jeffrey I. Schiller.



From owner-ietf-ediint@mail.imc.org  Mon Mar 11 12:04:52 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15137
	for <ediint-archive@lists.ietf.org>; Mon, 11 Mar 2002 12:04:52 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id g2BGjYm14444
	for ietf-ediint-bks; Mon, 11 Mar 2002 08:45:34 -0800 (PST)
Received: from sawgrass.cyclonesoftware.com (sawgrass.cyclonesoftware.com [12.34.72.101])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BGjW814439
	for <ietf-ediint@imc.org>; Mon, 11 Mar 2002 08:45:33 -0800 (PST)
Received: from GVESPER2 (gvesper2.cyclonecommerce.com [10.1.2.48])
	(authenticated)
	by sawgrass.cyclonesoftware.com (8.11.2/8.11.0) with ESMTP id g2BGj8d29168;
	Mon, 11 Mar 2002 09:45:08 -0700
From: "Greg Vesper" <gvesper@cyclonecommerce.com>
To: "Carl Hage" <carl@chage.com>, <ietf-ediint@imc.org>
Subject: RE: Compression Draft
Date: Mon, 11 Mar 2002 09:45:06 -0700
Message-ID: <NDBBIALJLKDJFGHBOPBDGEBAEFAA.gvesper@cyclonecommerce.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <20020308231809.FDWA2951.rwcrmhc53.attbi.com@sv>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Well said - I agree entirely with Carl's assessment.  Binding compression at
the crypto layer is inherently more restrictive and less interoperable than
compressing at the MIME layer.

Cheers,
-Greg.

> -----Original Message-----
> From: owner-ietf-ediint@mail.imc.org
> [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Carl Hage
> Sent: Friday, March 08, 2002 4:18 PM
> To: ietf-ediint@imc.org
> Subject: Re: Compression Draft
>
>
>
> From:           	"David Fischer" <david@drummondgroup.com>
>
> > We are beginning to implement the Compression Draft
> > specification:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
>
> The use of:
>
> Content-Type: application/pkcs7-mime; smime-type=compressed-data
>
> seems inappropriate.
>
> The application "pkcs-mime" shouldn't be used. PKCS7 is a different
> and inconsistent method of doing the same as what MIME does.
>
> It really should be pure MIME, independent of PKCS7.
>
> The original intent in the MIME design was to use Content-Transfer-
> Encoding for compression. From RFC2048: "Transfer encodings can
> be used to apply general-purpose non-lossy compression algorithms to
> MIME entities.  "
>
> The intent was for someone to define a new encoding type to include
> compression, e.g. "Content-Transfer-Encoding:gzip" or
> "Content-Transfer-Encoding:base64-gzip", which could be equivalent to
> httpd content-encoding, or base64 encoded gzip.
>
> Adding a new content-transfer-encoding would be universally useful
> in all MIME messages, and simplify encoding.
>
> Alternatively, a new type, e.g.
>
> "Content-Type: application/mime-gzip" or
> "Content-Type: application/mime-encoded; encoding=gzip"
>
> could be defined to mean an application that decodes, then
> processes mime headers. However, it would be better to use:
>
> "Content-Type: encoding/gzip" (already built into Netscape)
>
> Where the media type "encoding" means decode and continue parsing
> MIME headers, just like multipart or message.
>
> Shouldn't compression be defined completely independently of
> encryption, signatures, etc.? Then EDIINT can use MIME compression
> with multipart/signed, etc. and other independent MIME standards.
> --------------------------------------------------------------------------
> Carl Hage                                              C. Hage Associates
> <mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
> <http://www.chage.com/chage/>                          Sunnyvale,
> CA 94086



From owner-ietf-ediint@mail.imc.org  Mon Mar 11 23:02:20 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05924
	for <ediint-archive@lists.ietf.org>; Mon, 11 Mar 2002 23:02:20 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2C3nXH07915
	for ietf-ediint-bks; Mon, 11 Mar 2002 19:49:33 -0800 (PST)
Received: from drummondgroup.com (drummondgroup.com [192.41.39.80])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2C3nW407911
	for <ietf-ediint@imc.org>; Mon, 11 Mar 2002 19:49:32 -0800 (PST)
Received: from David (adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33]) by drummondgroup.com (8.8.5) id UAA18277; Mon, 11 Mar 2002 20:47:04 -0700 (MST)
X-Authentication-Warning: drummondgroup.com: Host adsl-65-64-203-33.dsl.rcsntx.swbell.net [65.64.203.33] claimed to be David
From: "David Fischer" <david@drummondgroup.com>
To: "Greg Vesper" <gvesper@cyclonecommerce.com>
Cc: "IETF EDIINT" <ietf-ediint@imc.org>
Subject: RE: Compression Draft
Date: Mon, 11 Mar 2002 21:47:44 -0600
Message-ID: <NFBBIIHJIBLCBFENACIJKELKCEAA.david@drummondgroup.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <NDBBIALJLKDJFGHBOPBDGEBAEFAA.gvesper@cyclonecommerce.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


This was our first thought too but this method was rejected by the Area
Director.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: owner-ietf-ediint@mail.imc.org
[mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Greg Vesper
Sent: Monday, March 11, 2002 10:45 AM
To: Carl Hage; ietf-ediint@imc.org
Subject: RE: Compression Draft



Well said - I agree entirely with Carl's assessment.  Binding compression at
the crypto layer is inherently more restrictive and less interoperable than
compressing at the MIME layer.

Cheers,
-Greg.

> -----Original Message-----
> From: owner-ietf-ediint@mail.imc.org
> [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Carl Hage
> Sent: Friday, March 08, 2002 4:18 PM
> To: ietf-ediint@imc.org
> Subject: Re: Compression Draft
>
>
>
> From:           	"David Fischer" <david@drummondgroup.com>
>
> > We are beginning to implement the Compression Draft
> > specification:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
>
> The use of:
>
> Content-Type: application/pkcs7-mime; smime-type=compressed-data
>
> seems inappropriate.
>
> The application "pkcs-mime" shouldn't be used. PKCS7 is a different
> and inconsistent method of doing the same as what MIME does.
>
> It really should be pure MIME, independent of PKCS7.
>
> The original intent in the MIME design was to use Content-Transfer-
> Encoding for compression. From RFC2048: "Transfer encodings can
> be used to apply general-purpose non-lossy compression algorithms to
> MIME entities.  "
>
> The intent was for someone to define a new encoding type to include
> compression, e.g. "Content-Transfer-Encoding:gzip" or
> "Content-Transfer-Encoding:base64-gzip", which could be equivalent to
> httpd content-encoding, or base64 encoded gzip.
>
> Adding a new content-transfer-encoding would be universally useful
> in all MIME messages, and simplify encoding.
>
> Alternatively, a new type, e.g.
>
> "Content-Type: application/mime-gzip" or
> "Content-Type: application/mime-encoded; encoding=gzip"
>
> could be defined to mean an application that decodes, then
> processes mime headers. However, it would be better to use:
>
> "Content-Type: encoding/gzip" (already built into Netscape)
>
> Where the media type "encoding" means decode and continue parsing
> MIME headers, just like multipart or message.
>
> Shouldn't compression be defined completely independently of
> encryption, signatures, etc.? Then EDIINT can use MIME compression
> with multipart/signed, etc. and other independent MIME standards.
> --------------------------------------------------------------------------
> Carl Hage                                              C. Hage Associates
> <mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
> <http://www.chage.com/chage/>                          Sunnyvale,
> CA 94086




From owner-ietf-ediint@mail.imc.org  Thu Mar 21 18:45:17 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00278
	for <ediint-archive@lists.ietf.org>; Thu, 21 Mar 2002 18:45:17 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2LNRib08901
	for ietf-ediint-bks; Thu, 21 Mar 2002 15:27:44 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LNRh408897
	for <ietf-ediint@imc.org>; Thu, 21 Mar 2002 15:27:43 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KFMHST5Y34005S0K@mauve.mrochek.com> for ietf-ediint@imc.org; Thu,
 21 Mar 2002 15:27:43 -0800 (PST)
Date: Thu, 21 Mar 2002 15:21:19 -0800 (PST)
From: ned.freed@mrochek.com
Subject: RE: Compression Draft
In-reply-to: "Your message dated Mon, 11 Mar 2002 21:47:44 -0600"
 <NFBBIIHJIBLCBFENACIJKELKCEAA.david@drummondgroup.com>
To: David Fischer <david@drummondgroup.com>
Cc: Greg Vesper <gvesper@cyclonecommerce.com>,
        IETF EDIINT <ietf-ediint@imc.org>
Message-id: <01KFMLC0TEXG005S0K@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <NDBBIALJLKDJFGHBOPBDGEBAEFAA.gvesper@cyclonecommerce.com>
 <NFBBIIHJIBLCBFENACIJKELKCEAA.david@drummondgroup.com>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7BIT


> This was our first thought too but this method was rejected by the Area
> Director.

I'm sorry, but this is flatly wrong. I never rejected the notion of adding
compression at the MIME layer. What I rejected was doing it with a separate
field nobody has ever seen before and no existing agent will know to look for.
Nor is it acceptable for this to be done by using a content-type based
wrapper.

As I pointed out before, the addition of compression to MIME is done by adding
one or more content transfer encodings. The process for defining a new CTE is
laid out in RFC 2048. The process is intentionally a stringent one, but is
isn't impossible.

Adding, say, zlib-base64 or even zlib-base85 would be easy. Adding something
like zlib-binary or zlib-8bit is harder, but still doable.

				Ned


> -----Original Message-----
> From: owner-ietf-ediint@mail.imc.org
> [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Greg Vesper
> Sent: Monday, March 11, 2002 10:45 AM
> To: Carl Hage; ietf-ediint@imc.org
> Subject: RE: Compression Draft



> Well said - I agree entirely with Carl's assessment.  Binding compression at
> the crypto layer is inherently more restrictive and less interoperable than
> compressing at the MIME layer.

> Cheers,
> -Greg.

> > -----Original Message-----
> > From: owner-ietf-ediint@mail.imc.org
> > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Carl Hage
> > Sent: Friday, March 08, 2002 4:18 PM
> > To: ietf-ediint@imc.org
> > Subject: Re: Compression Draft
> >
> >
> >
> > From:           	"David Fischer" <david@drummondgroup.com>
> >
> > > We are beginning to implement the Compression Draft
> > > specification:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> >
> > The use of:
> >
> > Content-Type: application/pkcs7-mime; smime-type=compressed-data
> >
> > seems inappropriate.
> >
> > The application "pkcs-mime" shouldn't be used. PKCS7 is a different
> > and inconsistent method of doing the same as what MIME does.
> >
> > It really should be pure MIME, independent of PKCS7.
> >
> > The original intent in the MIME design was to use Content-Transfer-
> > Encoding for compression. From RFC2048: "Transfer encodings can
> > be used to apply general-purpose non-lossy compression algorithms to
> > MIME entities.  "
> >
> > The intent was for someone to define a new encoding type to include
> > compression, e.g. "Content-Transfer-Encoding:gzip" or
> > "Content-Transfer-Encoding:base64-gzip", which could be equivalent to
> > httpd content-encoding, or base64 encoded gzip.
> >
> > Adding a new content-transfer-encoding would be universally useful
> > in all MIME messages, and simplify encoding.
> >
> > Alternatively, a new type, e.g.
> >
> > "Content-Type: application/mime-gzip" or
> > "Content-Type: application/mime-encoded; encoding=gzip"
> >
> > could be defined to mean an application that decodes, then
> > processes mime headers. However, it would be better to use:
> >
> > "Content-Type: encoding/gzip" (already built into Netscape)
> >
> > Where the media type "encoding" means decode and continue parsing
> > MIME headers, just like multipart or message.
> >
> > Shouldn't compression be defined completely independently of
> > encryption, signatures, etc.? Then EDIINT can use MIME compression
> > with multipart/signed, etc. and other independent MIME standards.
> > --------------------------------------------------------------------------
> > Carl Hage                                              C. Hage Associates
> > <mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
> > <http://www.chage.com/chage/>                          Sunnyvale,
> > CA 94086




From owner-ietf-ediint@mail.imc.org  Thu Mar 21 22:15:18 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05560
	for <ediint-archive@odin.ietf.org>; Thu, 21 Mar 2002 22:15:18 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2M2ukE13119
	for ietf-ediint-bks; Thu, 21 Mar 2002 18:56:46 -0800 (PST)
Received: from drummondgroup.com (drummondgroup.com [192.41.39.80])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M2uj413115
	for <ietf-ediint@imc.org>; Thu, 21 Mar 2002 18:56:45 -0800 (PST)
Received: from David (adsl-65-64-203-230.dsl.rcsntx.swbell.net [65.64.203.230]) by drummondgroup.com (8.8.5) id TAA27563; Thu, 21 Mar 2002 19:56:17 -0700 (MST)
X-Authentication-Warning: drummondgroup.com: Host adsl-65-64-203-230.dsl.rcsntx.swbell.net [65.64.203.230] claimed to be David
From: "David Fischer" <david@drummondgroup.com>
To: <ned.freed@mrochek.com>
Cc: "Greg Vesper" <gvesper@cyclonecommerce.com>,
        "IETF EDIINT" <ietf-ediint@imc.org>
Subject: RE: Compression Draft
Date: Thu, 21 Mar 2002 20:55:51 -0600
Message-ID: <NFBBIIHJMLEPPLNMNKLGIECADHAA.david@drummondgroup.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <01KFMLC0TEXG005S0K@mauve.mrochek.com>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


My apologies, I wasn't clear.

Since we are working with HTTP, we cannot use CTE.  Whatever we use must be the
same for SMTP and HTTP.  I remember that all the options we discussed for
binding at the MIME level were not acceptable.   Was I mistaken?

I have been searching for that thread (between Ned Freed and Terry Harding) and
I can't find it.

David Fischer
Drummond Group.

-----Original Message-----
From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
Sent: Thursday, March 21, 2002 5:21 PM
To: David Fischer
Cc: Greg Vesper; IETF EDIINT
Subject: RE: Compression Draft


> This was our first thought too but this method was rejected by the Area
> Director.

I'm sorry, but this is flatly wrong. I never rejected the notion of adding
compression at the MIME layer. What I rejected was doing it with a separate
field nobody has ever seen before and no existing agent will know to look for.
Nor is it acceptable for this to be done by using a content-type based
wrapper.

As I pointed out before, the addition of compression to MIME is done by adding
one or more content transfer encodings. The process for defining a new CTE is
laid out in RFC 2048. The process is intentionally a stringent one, but is
isn't impossible.

Adding, say, zlib-base64 or even zlib-base85 would be easy. Adding something
like zlib-binary or zlib-8bit is harder, but still doable.

				Ned


> -----Original Message-----
> From: owner-ietf-ediint@mail.imc.org
> [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Greg Vesper
> Sent: Monday, March 11, 2002 10:45 AM
> To: Carl Hage; ietf-ediint@imc.org
> Subject: RE: Compression Draft



> Well said - I agree entirely with Carl's assessment.  Binding compression at
> the crypto layer is inherently more restrictive and less interoperable than
> compressing at the MIME layer.

> Cheers,
> -Greg.

> > -----Original Message-----
> > From: owner-ietf-ediint@mail.imc.org
> > [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Carl Hage
> > Sent: Friday, March 08, 2002 4:18 PM
> > To: ietf-ediint@imc.org
> > Subject: Re: Compression Draft
> >
> >
> >
> > From:           	"David Fischer" <david@drummondgroup.com>
> >
> > > We are beginning to implement the Compression Draft
> > > specification:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> >
> > The use of:
> >
> > Content-Type: application/pkcs7-mime; smime-type=compressed-data
> >
> > seems inappropriate.
> >
> > The application "pkcs-mime" shouldn't be used. PKCS7 is a different
> > and inconsistent method of doing the same as what MIME does.
> >
> > It really should be pure MIME, independent of PKCS7.
> >
> > The original intent in the MIME design was to use Content-Transfer-
> > Encoding for compression. From RFC2048: "Transfer encodings can
> > be used to apply general-purpose non-lossy compression algorithms to
> > MIME entities.  "
> >
> > The intent was for someone to define a new encoding type to include
> > compression, e.g. "Content-Transfer-Encoding:gzip" or
> > "Content-Transfer-Encoding:base64-gzip", which could be equivalent to
> > httpd content-encoding, or base64 encoded gzip.
> >
> > Adding a new content-transfer-encoding would be universally useful
> > in all MIME messages, and simplify encoding.
> >
> > Alternatively, a new type, e.g.
> >
> > "Content-Type: application/mime-gzip" or
> > "Content-Type: application/mime-encoded; encoding=gzip"
> >
> > could be defined to mean an application that decodes, then
> > processes mime headers. However, it would be better to use:
> >
> > "Content-Type: encoding/gzip" (already built into Netscape)
> >
> > Where the media type "encoding" means decode and continue parsing
> > MIME headers, just like multipart or message.
> >
> > Shouldn't compression be defined completely independently of
> > encryption, signatures, etc.? Then EDIINT can use MIME compression
> > with multipart/signed, etc. and other independent MIME standards.
> > --------------------------------------------------------------------------
> > Carl Hage                                              C. Hage Associates
> > <mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
> > <http://www.chage.com/chage/>                          Sunnyvale,
> > CA 94086





From owner-ietf-ediint@mail.imc.org  Thu Mar 21 22:33:25 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06804
	for <ediint-archive@odin.ietf.org>; Thu, 21 Mar 2002 22:33:25 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2M3HdF13573
	for ietf-ediint-bks; Thu, 21 Mar 2002 19:17:39 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M3Hb413569
	for <ietf-ediint@imc.org>; Thu, 21 Mar 2002 19:17:37 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KFMT1C1OU8005S0K@mauve.mrochek.com> for ietf-ediint@imc.org; Thu,
 21 Mar 2002 19:17:37 -0800 (PST)
Date: Thu, 21 Mar 2002 19:08:37 -0800 (PST)
From: ned.freed@mrochek.com
Subject: RE: Compression Draft
In-reply-to: "Your message dated Thu, 21 Mar 2002 20:55:51 -0600"
 <NFBBIIHJMLEPPLNMNKLGIECADHAA.david@drummondgroup.com>
To: David Fischer <david@drummondgroup.com>
Cc: ned.freed@mrochek.com, Greg Vesper <gvesper@cyclonecommerce.com>,
        IETF EDIINT <ietf-ediint@imc.org>
Message-id: <01KFMTD1AG2G005S0K@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <01KFMLC0TEXG005S0K@mauve.mrochek.com>
 <NFBBIIHJMLEPPLNMNKLGIECADHAA.david@drummondgroup.com>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7BIT



> My apologies, I wasn't clear.

> Since we are working with HTTP, we cannot use CTE.  Whatever we use must be
> the same for SMTP and HTTP.

I fail to see any justification for this restriction. Per RFC 2616 section
19.4.5, CTE is indeed not used by HTTP, but all that means is that should you
need to gateway you have to remove the CTE.

You already have to accomodate the base64 and quoted-printable CTEs, so
you have to deal with CTEs regardless of whether or not define a new
compressed one.

> I remember that all the options we discussed for
> binding at the MIME level were not acceptable.   Was I mistaken?

Yes.

> I have been searching for that thread (between Ned Freed and Terry Harding) and
> I can't find it.

I don't recall the conversation.

				Ned


From owner-ietf-ediint@mail.imc.org  Thu Mar 21 23:08:00 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07523
	for <ediint-archive@odin.ietf.org>; Thu, 21 Mar 2002 23:07:59 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2M3tfT14339
	for ietf-ediint-bks; Thu, 21 Mar 2002 19:55:41 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M3te414335
	for <ietf-ediint@imc.org>; Thu, 21 Mar 2002 19:55:40 -0800 (PST)
Received: from sv ([12.234.202.224]) by rwcrmhc52.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020322035526.PNKS1147.rwcrmhc52.attbi.com@sv>
          for <ietf-ediint@imc.org>; Fri, 22 Mar 2002 03:55:26 +0000
From: "Carl Hage" <carl@chage.com>
To: ietf-ediint@imc.org
Date: Thu, 21 Mar 2002 19:55:21 -0800
Subject: RE: Compression Draft
In-reply-to: <NFBBIIHJMLEPPLNMNKLGIECADHAA.david@drummondgroup.com>
References: <01KFMLC0TEXG005S0K@mauve.mrochek.com>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <20020322035526.PNKS1147.rwcrmhc52.attbi.com@sv>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>


From:           	"David Fischer" <david@drummondgroup.com>
> Since we are working with HTTP, we cannot use CTE.  Whatever we use
> must be the same for SMTP and HTTP. 

Well, that makes sense to me, but HTTP already has a specification 
for compression, using Content-Encoding, but does not explicitly 
permit Content-Transfer-Encoding.

For email, a "Content-Transfer-Encoding: zlib-base64" (or gzip-base64)
is equivalent to encoding with the equivalent of HTTP
"Content-Encoding: gzip" then encoded with
"Content-Transfer-Encoding: base64".

If you are using HTTP, you can send binary data and compress using 
the existing "Content-Encoding: gzip" specification defined in the HTTP 
RFC. This would be equivalent to a
"Content-Transfer-Encoding:zlib-binary".

If you are using SMTP, we could define "zlib-base64" Content-Transfer-
Encoding. The software would compress (as when using content-
encoding), then base64 encode. There is no need for "zlib-binary" as 
long as compression is done at the top level.

["zlib-base64" is probably a good name since the RFC defining the   
format calls it zlib.]

Though the headers are a little different when used with HTTP or 
SMTP, the software works pretty much the same. It would be easy to 
write a MIME encoder/decoder that would work with either HTTP or 
SMTP, but adjust the MIME headers as needed.

Adding a new content-transfer-encoding format is useful outside the 
scope of EDI and is a simpler extension than the proposed alteration 
encryption/signature MIME types. It's also explicitly mentioned as the 
strategy intended in the MIME RFCs.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086


From owner-ietf-ediint@mail.imc.org  Thu Mar 21 23:37:36 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08735
	for <ediint-archive@odin.ietf.org>; Thu, 21 Mar 2002 23:37:35 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2M4PXP14967
	for ietf-ediint-bks; Thu, 21 Mar 2002 20:25:33 -0800 (PST)
Received: from smtp2.sandisk.com ([12.146.150.11])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M4PX414963
	for <ietf-ediint@imc.org>; Thu, 21 Mar 2002 20:25:33 -0800 (PST)
Received: from sandisk.com (watermark.sandisk.com [10.252.5.20])
	by smtp2.sandisk.com (8.9.3/8.9.3) with ESMTP id UAA20370
	for <ietf-ediint@imc.org>; Thu, 21 Mar 2002 20:25:27 -0800
Received: from mail pickup service by sandisk.com with Microsoft SMTPSVC;
	 Thu, 21 Mar 2002 20:22:40 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
x-receiver: fgoodrum@sandisk.com
Received: from smtp2.sandisk.com ([10.252.28.11]) by sandisk.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Mar 2002 20:22:37 -0800
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp2.sandisk.com (8.9.3/8.9.3) with SMTP id UAA20353 for <fgoodrum@sandisk.com>; Thu, 21 Mar 2002 20:24:53 -0800
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2M3tfT14339 for ietf-ediint-bks; Thu, 21 Mar 2002 19:55:41 -0800 (PST)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M3te414335 for <ietf-ediint@imc.org>; Thu, 21 Mar 2002 19:55:40 -0800 (PST)
Received: from sv ([12.234.202.224]) by rwcrmhc52.attbi.com          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP          id <20020322035526.PNKS1147.rwcrmhc52.attbi.com@sv>          for <ietf-ediint@imc.org>; Fri, 22 Mar 2002 03:55:26 +0000
From: "Carl Hage" <carl@chage.com>
To: <ietf-ediint@imc.org>
Date: Thu, 21 Mar 2002 19:55:21 -0800
Subject: RE: Compression Draft
In-Reply-To: <NFBBIIHJMLEPPLNMNKLGIECADHAA.david@drummondgroup.com>
References: <01KFMLC0TEXG005S0K@mauve.mrochek.com>
X-Mailer: Pegasus Mail for Win32 (v3.01d)
Message-ID: <20020322035526.PNKS1147.rwcrmhc52.attbi.com@sv>
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
X-OriginalArrivalTime: 22 Mar 2002 04:22:37.0546 (UTC) FILETIME=[32AB34A0:01C1D159]
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



From:           	"David Fischer" <david@drummondgroup.com>
> Since we are working with HTTP, we cannot use CTE.  Whatever we use
> must be the same for SMTP and HTTP. 

Well, that makes sense to me, but HTTP already has a specification 
for compression, using Content-Encoding, but does not explicitly 
permit Content-Transfer-Encoding.

For email, a "Content-Transfer-Encoding: zlib-base64" (or gzip-base64)
is equivalent to encoding with the equivalent of HTTP
"Content-Encoding: gzip" then encoded with
"Content-Transfer-Encoding: base64".

If you are using HTTP, you can send binary data and compress using 
the existing "Content-Encoding: gzip" specification defined in the HTTP 
RFC. This would be equivalent to a
"Content-Transfer-Encoding:zlib-binary".

If you are using SMTP, we could define "zlib-base64" Content-Transfer-
Encoding. The software would compress (as when using content-
encoding), then base64 encode. There is no need for "zlib-binary" as 
long as compression is done at the top level.

["zlib-base64" is probably a good name since the RFC defining the   
format calls it zlib.]

Though the headers are a little different when used with HTTP or 
SMTP, the software works pretty much the same. It would be easy to 
write a MIME encoder/decoder that would work with either HTTP or 
SMTP, but adjust the MIME headers as needed.

Adding a new content-transfer-encoding format is useful outside the 
scope of EDI and is a simpler extension than the proposed alteration 
encryption/signature MIME types. It's also explicitly mentioned as the 
strategy intended in the MIME RFCs.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086



From owner-ietf-ediint@mail.imc.org  Fri Mar 22 11:12:31 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24788
	for <ediint-archive@lists.ietf.org>; Fri, 22 Mar 2002 11:12:31 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2MFohO09207
	for ietf-ediint-bks; Fri, 22 Mar 2002 07:50:43 -0800 (PST)
Received: from sawgrass.cyclonesoftware.com (sawgrass.cyclonesoftware.com [12.34.72.101])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MFof409203
	for <ietf-ediint@imc.org>; Fri, 22 Mar 2002 07:50:41 -0800 (PST)
Received: from THARDINGLAPTOP (ip68-3-34-197.ph.ph.cox.net [68.3.34.197])
	(authenticated)
	by sawgrass.cyclonesoftware.com (8.11.2/8.11.0) with ESMTP id g2MFoQd10812;
	Fri, 22 Mar 2002 08:50:26 -0700
Message-ID: <002701c1d1b9$49908ed0$6401a8c0@cyclonecommerce.com>
From: "Terry Harding" <tharding@cyclonecommerce.com>
To: "Carl Hage" <carl@chage.com>, <ietf-ediint@imc.org>
References: <01KFMLC0TEXG005S0K@mauve.mrochek.com> <20020322035526.PNKS1147.rwcrmhc52.attbi.com@sv>
Subject: Re: Compression Draft
Date: Fri, 22 Mar 2002 08:50:21 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
x-mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Carl, Ned,

Our goal in developing a compression method for AS1 and AS2 was to find
something that already existed and could be used for SMTP and HTTP(s) and
any future transport protocols defined by the EDIINT group.

For HTTP we looked at using Content-Encoding, but since this only applied to
the outermost layer of a message, we would not be able to take advantage of
the benefits of compressing the mime layers inside the message and any
compression applied on the outermost layer would not have any effect
compressing a binary blob of encrypted data.  I also looked at using
Content-Encoding within the inner mime layers, but was informed by Ned that
utilizing Content-Encoding within MIME was not acceptable.  We also
looked at utlizing CTE in the inner most layers, but also received
objections from the AS2 authors that CTE anywhere within the message was not
encouraged. Also the MIME group did not have a CTE defined for compression
and we would have to develop a brand new CTE acceptable to EDIINT players
and the MIME guardians. We also looked at the compression spec from the
S/MIME group, as this is the security mechanism utlized by AS1 and AS2.
Note: the S/MIME group had already developed a compression spec.

For SMTP we looked at using Content-Encoding, but again we were discouraged
from this approach. It was suggested that we use CTE with new encodings
defined for compression.  We also looked at compression developed by the
S/MIME group.

So it came down to utilizing a compression method already defined by a
working group  and having it approved by the EDIINT forks or developing a
new mechanism and having it approved by two working groups. The EDIINT group
on the most part trys to utilize existing methods and explain their usage in
our applicability statements.

So the reasons above led us to utilize the compression method developed by
the S/MIME group. The original EDIINT compression was first released in
September of 2001 to the ediint ietf group for comments and suggestions.  At
that time we were looking for discussion on the selected method.  We
received some suggestions and comments, but nothing close to the remark from
Carl, indicating that the compression method selected was "OVERKILL".

Note: Currently 7 AS1 vendors have implemented the selected compression
method and 5 additional
vendors will be adding compression for AS2..

Terry Harding
Cyclone Commerce











----- Original Message -----
From: "Carl Hage" <carl@chage.com>
To: <ietf-ediint@imc.org>
Sent: Thursday, March 21, 2002 8:55 PM
Subject: RE: Compression Draft


>
> From:           "David Fischer" <david@drummondgroup.com>
> > Since we are working with HTTP, we cannot use CTE.  Whatever we use
> > must be the same for SMTP and HTTP.
>
> Well, that makes sense to me, but HTTP already has a specification
> for compression, using Content-Encoding, but does not explicitly
> permit Content-Transfer-Encoding.
>
> For email, a "Content-Transfer-Encoding: zlib-base64" (or gzip-base64)
> is equivalent to encoding with the equivalent of HTTP
> "Content-Encoding: gzip" then encoded with
> "Content-Transfer-Encoding: base64".
>
> If you are using HTTP, you can send binary data and compress using
> the existing "Content-Encoding: gzip" specification defined in the HTTP
> RFC. This would be equivalent to a
> "Content-Transfer-Encoding:zlib-binary".
>
> If you are using SMTP, we could define "zlib-base64" Content-Transfer-
> Encoding. The software would compress (as when using content-
> encoding), then base64 encode. There is no need for "zlib-binary" as
> long as compression is done at the top level.
>
> ["zlib-base64" is probably a good name since the RFC defining the
> format calls it zlib.]
>
> Though the headers are a little different when used with HTTP or
> SMTP, the software works pretty much the same. It would be easy to
> write a MIME encoder/decoder that would work with either HTTP or
> SMTP, but adjust the MIME headers as needed.
>
> Adding a new content-transfer-encoding format is useful outside the
> scope of EDI and is a simpler extension than the proposed alteration
> encryption/signature MIME types. It's also explicitly mentioned as the
> strategy intended in the MIME RFCs.
> --------------------------------------------------------------------------
> Carl Hage                                              C. Hage Associates
> <mailto:carl@chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
> <http://www.chage.com/chage/>                          Sunnyvale, CA 94086



From owner-ietf-ediint@mail.imc.org  Fri Mar 22 23:23:21 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08573
	for <ediint-archive@lists.ietf.org>; Fri, 22 Mar 2002 23:23:20 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2N42N302573
	for ietf-ediint-bks; Fri, 22 Mar 2002 20:02:23 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2N42L402569
	for <ietf-ediint@imc.org>; Fri, 22 Mar 2002 20:02:22 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KFO5XEI7EO001BE4@mauve.mrochek.com> for ietf-ediint@imc.org; Fri,
 22 Mar 2002 20:02:14 -0800 (PST)
Date: Fri, 22 Mar 2002 19:45:17 -0800 (PST)
From: ned.freed@mrochek.com
Subject: Re: Compression Draft
In-reply-to: "Your message dated Fri, 22 Mar 2002 08:50:21 -0700"
 <002701c1d1b9$49908ed0$6401a8c0@cyclonecommerce.com>
To: Terry Harding <tharding@cyclonecommerce.com>
Cc: Carl Hage <carl@chage.com>, ietf-ediint@imc.org
Message-id: <01KFO97PVWBG001BE4@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <01KFMLC0TEXG005S0K@mauve.mrochek.com>
 <20020322035526.PNKS1147.rwcrmhc52.attbi.com@sv>
 <002701c1d1b9$49908ed0$6401a8c0@cyclonecommerce.com>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7BIT


> Our goal in developing a compression method for AS1 and AS2 was to find
> something that already existed and could be used for SMTP and HTTP(s) and
> any future transport protocols defined by the EDIINT group.

I note in passing that it is extremely unlikely that EDIINT is going to be
around to develop such bindings.

> For HTTP we looked at using Content-Encoding, but since this only applied to
> the outermost layer of a message, we would not be able to take advantage of
> the benefits of compressing the mime layers inside the message and any
> compression applied on the outermost layer would not have any effect
> compressing a binary blob of encrypted data.  I also looked at using
> Content-Encoding within the inner mime layers, but was informed by Ned that
> utilizing Content-Encoding within MIME was not acceptable.  We also
> looked at utlizing CTE in the inner most layers, but also received
> objections from the AS2 authors that CTE anywhere within the message was not
> encouraged.

Then the AS2 authors are in need a reality check. CTEs within messages are not
only encouraged, they are essential. And here is nothing, repeat NOTHING, they
can do about this.

Like it or not, HTTP elected to go one way on this and SMTP elected to
go another. Both approaches have advantages and disadvantages, as you note.
But you cannot change them and you cannot make them compatible. And more to
the point, you cannot get rid of the use of CTEs in SMTP.

> Also the MIME group did not have a CTE defined for compression
> and we would have to develop a brand new CTE acceptable to EDIINT players
> and the MIME guardians. We also looked at the compression spec from the
> S/MIME group, as this is the security mechanism utlized by AS1 and AS2.
> Note: the S/MIME group had already developed a compression spec.

Which offers a third set of tradeoffs.

> For SMTP we looked at using Content-Encoding, but again we were discouraged
> from this approach.

Actually, you were told it is flatly unacceptable on technical grounds, and
why. There's nothing capricious or arbitrary going on here.

> It was suggested that we use CTE with new encodings
> defined for compression.  We also looked at compression developed by the
> S/MIME group.

> So it came down to utilizing a compression method already defined by a
> working group  and having it approved by the EDIINT forks or developing a
> new mechanism and having it approved by two working groups. The EDIINT group
> on the most part trys to utilize existing methods and explain their usage in
> our applicability statements.

And if the WG choses S/MIME compression that's fine. The only reason I jumped
in s the situation in regards to defining new compression services in SMTP had
been, and continues to be, mischaracterized.

				Ned


From owner-ietf-ediint@mail.imc.org  Tue Mar 26 00:00:38 2002
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16152
	for <ediint-archive@odin.ietf.org>; Tue, 26 Mar 2002 00:00:38 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g2Q4SqM04961
	for ietf-ediint-bks; Mon, 25 Mar 2002 20:28:52 -0800 (PST)
Received: from www.tech-comm.com (ns3.tech-comm.com [209.149.125.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g2Q4So404957
	for <ietf-ediint@imc.org>; Mon, 25 Mar 2002 20:28:50 -0800 (PST)
Received: from XMLbridgeDB (216-143-51-185.broadwing.net [216.143.51.185] (may be forged))
	by www.tech-comm.com (8.11.6/8.11.6) with SMTP id g2Q5l2o06822;
	Mon, 25 Mar 2002 23:47:02 -0600
From: "Dick Brooks" <dick@tech-comm.com>
To: <ned.freed@mrochek.com>, "Terry Harding" <tharding@cyclonecommerce.com>
Cc: "Carl Hage" <carl@chage.com>, <ietf-ediint@imc.org>,
        "Rae McQuade" <gisb1@aol.com>, "Dave Darnell" <dave@systrends.com>
Subject: RE: Compression Draft
Date: Mon, 25 Mar 2002 22:31:54 -0600
Message-ID: <GGEDKILGLKJCELNCBGODKEOACNAA.dick@tech-comm.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <01KFO97PVWBG001BE4@mauve.mrochek.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Ned,

Regarding:
>I note in passing that it is extremely unlikely that EDIINT
>is going to be around to develop such bindings.

I wish to express the importance of EDIINT AS2 by pointing out that the Gas
Industry Standards Board, an ANSI SDO, (now the North American Energy
Standards Board),ref: http://www.naesb.org/, references EDIINT AS2 in it's
Internet E-Commerce standard. The Federal Energy Regulatory Commission
(http://www.ferc.gov) within the Department of Energy
(http://www.energy.gov/) has mandated NAESB's Internet E-Commerce/AS2
standard into law and all Interstate Gas pipelines are required to use the
NAESB/AS2 standard for Internet E-Commerce.

Note: The NAESB E-Commerce standard references the portion of AS2 that
complies with RFC 2616, RFC 2617, RFC 2388 for framing and RFC 1847/2015 for
MIME identification of PGP payloads. PGP performs all compression functions
within the NAESB portion of EDIINT AS2 and is therefore not dependent on
CTE's to identify compressed content.

Please do not associate the "compression issue" with all of EDIINT AS2. I
believe the issues raised with compressed content are germane to the UCC
portion of EDIINT AS2 and do not impact the Energy Industry/NAESB "profile"
within the specification. Please contact me (co-chair of NAESB's Internet
E-Commerce standard committee) to discuss the Energy Industry portion of
EDIINT AS2. I want to ensure that the Energy Industry E-Commerce
specifications are aligned with the principles and processes defined by the
Internet Engineering Task Force.


Thank you,

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714


-----Original Message-----
From: owner-ietf-ediint@mail.imc.org
[mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of
ned.freed@mrochek.com
Sent: Friday, March 22, 2002 9:45 PM
To: Terry Harding
Cc: Carl Hage; ietf-ediint@imc.org
Subject: Re: Compression Draft



> Our goal in developing a compression method for AS1 and AS2 was to find
> something that already existed and could be used for SMTP and HTTP(s) and
> any future transport protocols defined by the EDIINT group.

I note in passing that it is extremely unlikely that EDIINT is going to be
around to develop such bindings.

> For HTTP we looked at using Content-Encoding, but since this only applied
to
> the outermost layer of a message, we would not be able to take advantage
of
> the benefits of compressing the mime layers inside the message and any
> compression applied on the outermost layer would not have any effect
> compressing a binary blob of encrypted data.  I also looked at using
> Content-Encoding within the inner mime layers, but was informed by Ned
that
> utilizing Content-Encoding within MIME was not acceptable.  We also
> looked at utlizing CTE in the inner most layers, but also received
> objections from the AS2 authors that CTE anywhere within the message was
not
> encouraged.

Then the AS2 authors are in need a reality check. CTEs within messages are
not
only encouraged, they are essential. And here is nothing, repeat NOTHING,
they
can do about this.

Like it or not, HTTP elected to go one way on this and SMTP elected to
go another. Both approaches have advantages and disadvantages, as you note.
But you cannot change them and you cannot make them compatible. And more to
the point, you cannot get rid of the use of CTEs in SMTP.

> Also the MIME group did not have a CTE defined for compression
> and we would have to develop a brand new CTE acceptable to EDIINT players
> and the MIME guardians. We also looked at the compression spec from the
> S/MIME group, as this is the security mechanism utlized by AS1 and AS2.
> Note: the S/MIME group had already developed a compression spec.

Which offers a third set of tradeoffs.

> For SMTP we looked at using Content-Encoding, but again we were
discouraged
> from this approach.

Actually, you were told it is flatly unacceptable on technical grounds, and
why. There's nothing capricious or arbitrary going on here.

> It was suggested that we use CTE with new encodings
> defined for compression.  We also looked at compression developed by the
> S/MIME group.

> So it came down to utilizing a compression method already defined by a
> working group  and having it approved by the EDIINT forks or developing a
> new mechanism and having it approved by two working groups. The EDIINT
group
> on the most part trys to utilize existing methods and explain their usage
in
> our applicability statements.

And if the WG choses S/MIME compression that's fine. The only reason I
jumped
in s the situation in regards to defining new compression services in SMTP
had
been, and continues to be, mischaracterized.

				Ned