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 ; 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 ; 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" To: Subject: Compression Order Date: Tue, 5 Mar 2002 11:42:50 -0600 Message-ID: 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: List-ID: List-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 AS3?...
We are beginning to implement the Compression Draft=20 specification:
 
http://www.ietf.org/internet-drafts/draft-ietf-ediint-compressio= n-00.txt
 
and an implementation decision has arisen.  When = Compression is=20 applied in concert with Signatures, which should be applied=20 first?
 
    Compress + = Sign   =20 or
    Sign + = Compress
 
       =20 and
 
    Compress + Sign + = Encrypt  =20 or
    Sign + Compress +=20 Encrypt
 
Different companies have presented valid business cases for = each=20 alternative. 
 
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).
 
The advocates for Compressing first desire performance=20 improvements.  In this case, Compression is compared as just = another=20 encoding scheme so it is really still plain text.
 
Discussions thus far have resulted in a consensus that the = implementors=20 should be able to apply these functions in either order when = sending.  When=20 receiving, the implementations should be able to process either=20 case.
 
We are looking for further discussions. . .
 
Regards,
 
David Fischer
Drummond Group.
------=_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 ; 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 ; 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 Organization: American Coders, LTD X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Fischer CC: ietf-ediint@imc.org Subject: Re: Compression Order References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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 ; 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 ; 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" 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 Subject: Re: Compression Order References: <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: List-ID: List-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 ; 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 ; 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" To: "joe mcverry" Cc: Subject: RE: Compression Order Date: Tue, 5 Mar 2002 14:20:24 -0600 Message-ID: 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: List-ID: List-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 ; 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 ; 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 Subject: Re: Compression Order In-reply-to: X-X-Sender: galvin@three.elistx.com To: David Fischer Cc: ietf-ediint@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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 On Tue, 5 Mar 2002, David Fischer wrote: Date: Tue, 05 Mar 2002 11:42:50 -0600 From: David Fischer 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 ; 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 ; 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 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 CC: ietf-ediint@imc.org Subject: Re: Compression Order References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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 ; 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 ; 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" To: "Kepa Zubeldia" Cc: Subject: RE: Compression Order Date: Wed, 6 Mar 2002 10:04:09 -0600 Message-ID: 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: List-ID: List-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 ; 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 ; 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: From: Christian Putnam To: "'David Fischer'" 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: List-ID: List-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 ; 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 ; 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 ; Wed, 6 Mar 2002 18:52:37 +0000 From: "Carl Hage" To: ietf-ediint@imc.org Date: Wed, 6 Mar 2002 10:52:33 -0800 Subject: RE: Compression Order In-reply-to: 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: List-ID: List-Unsubscribe: From: Christian Putnam > 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 Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 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 ; 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 ; 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" To: Subject: RE: Compression Order Date: Fri, 8 Mar 2002 11:36:53 -0600 Message-ID: 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: List-ID: List-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 > 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 Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 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 ; 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 ; 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 ; Fri, 8 Mar 2002 23:18:09 +0000 From: "Carl Hage" To: ietf-ediint@imc.org Date: Fri, 8 Mar 2002 15:18:05 -0800 Subject: Re: Compression Draft In-reply-to: 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: List-ID: List-Unsubscribe: From: "David Fischer" > 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 Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Fri, 8 Mar 2002 23:18:09 +0000 From: "Carl Hage" To: Date: Fri, 8 Mar 2002 15:18:05 -0800 Subject: Re: Compression Draft In-Reply-To: References: <5575B281AEC6D511A4120008C7F7E9EF0D641C@DFIEXSVR.dficomm.dficom.com> X-Mailer: Pegasus Mail for Win32 (v3.01d) Message-ID: <20020308231809.FDWA2951.rwcrmhc53.attbi.com@sv> List-Archive: List-ID: List-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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit From: "David Fischer" > 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 Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 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 ; 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 ; 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" To: "as1_interop" Cc: 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "The IESG" To: Cc: "RFC Editor" ; "Internet Architecture Board" ; 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' 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 ; 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 ; 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" To: "Carl Hage" , Subject: RE: Compression Draft Date: Mon, 11 Mar 2002 09:45:06 -0700 Message-ID: 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: List-ID: List-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" > > > 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 > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > 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 ; 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 ; 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" To: "Greg Vesper" Cc: "IETF EDIINT" Subject: RE: Compression Draft Date: Mon, 11 Mar 2002 21:47:44 -0600 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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" > > > 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 > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > 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 ; 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 ; 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" To: David Fischer Cc: Greg Vesper , IETF EDIINT Message-id: <01KFMLC0TEXG005S0K@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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" > > > > > 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 > > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > > 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 ; 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 ; 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" To: Cc: "Greg Vesper" , "IETF EDIINT" Subject: RE: Compression Draft Date: Thu, 21 Mar 2002 20:55:51 -0600 Message-ID: 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: List-ID: List-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" > > > > > 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 > > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > > 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 ; 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 ; 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" To: David Fischer Cc: ned.freed@mrochek.com, Greg Vesper , IETF EDIINT 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> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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 ; 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 ; 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 ; Fri, 22 Mar 2002 03:55:26 +0000 From: "Carl Hage" To: ietf-ediint@imc.org Date: Thu, 21 Mar 2002 19:55:21 -0800 Subject: RE: Compression Draft In-reply-to: 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: List-ID: List-Unsubscribe: From: "David Fischer" > 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 Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Fri, 22 Mar 2002 03:55:26 +0000 From: "Carl Hage" To: Date: Thu, 21 Mar 2002 19:55:21 -0800 Subject: RE: Compression Draft In-Reply-To: References: <01KFMLC0TEXG005S0K@mauve.mrochek.com> X-Mailer: Pegasus Mail for Win32 (v3.01d) Message-ID: <20020322035526.PNKS1147.rwcrmhc52.attbi.com@sv> List-Archive: List-ID: List-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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit From: "David Fischer" > 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 Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 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 ; 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 ; 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" To: "Carl Hage" , 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: List-ID: List-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" To: Sent: Thursday, March 21, 2002 8:55 PM Subject: RE: Compression Draft > > From: "David Fischer" > > 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 > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > 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 ; 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 ; 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 Cc: Carl Hage , 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: List-ID: List-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 ; 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 ; 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" To: , "Terry Harding" Cc: "Carl Hage" , , "Rae McQuade" , "Dave Darnell" Subject: RE: Compression Draft Date: Mon, 25 Mar 2002 22:31:54 -0600 Message-ID: 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: List-ID: List-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 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