From owner-ietf-ediint@mail.imc.org Fri Jan 10 12:49:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06043 for ; Fri, 10 Jan 2003 12:49:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AHbkQ15320 for ietf-ediint-bks; Fri, 10 Jan 2003 09:37:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AHbjo15315 for ; Fri, 10 Jan 2003 09:37:46 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04964; Fri, 10 Jan 2003 12:34:29 -0500 (EST) Message-Id: <200301101734.MAA04964@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ediint@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ediint-as2-12.txt Date: Fri, 10 Jan 2003 12:34:29 -0500 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : HTTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet Author(s) : D. Moberg, R. Drummond Filename : draft-ietf-ediint-as2-12.txt Pages : 28 Date : 2003-1-10 This document describes how to exchange structured business data securely using HTTP transfer for XML, Binary, Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport) or other data describable in MIME used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements make use of multipart/signed repliesto the original HTTP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-as2-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ediint-as2-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10122215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ediint-as2-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ediint-as2-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10122215.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ediint@mail.imc.org Sun Jan 12 16:51:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15453 for ; Sun, 12 Jan 2003 16:51:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0CLa3h10905 for ietf-ediint-bks; Sun, 12 Jan 2003 13:36:03 -0800 (PST) Received: from drummondgroup.com (drummondgroup.com [161.58.166.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0CLa2o10901 for ; Sun, 12 Jan 2003 13:36:02 -0800 (PST) Received: from RIKDGI (c66.169.103.180.ftwrth.tx.charter.com [66.169.103.180]) by drummondgroup.com (8.12.6/8.11.6) with ESMTP id h0CLa4fp072806 for ; Sun, 12 Jan 2003 14:36:04 -0700 (MST) From: "Rik Drummond" To: Subject: test Date: Sun, 12 Jan 2003 15:34:27 -0600 Organization: Drummond Group Inc. Message-ID: <002a01c2ba82$65bc28a0$0200a8c0@RIKDGI> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002B_01C2BA50.1B21B8A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_002B_01C2BA50.1B21B8A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002C_01C2BA50.1B21B8A0" ------=_NextPart_001_002C_01C2BA50.1B21B8A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_001_002C_01C2BA50.1B21B8A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable test


<<...>> =

------=_NextPart_001_002C_01C2BA50.1B21B8A0-- ------=_NextPart_000_002B_01C2BA50.1B21B8A0 Content-Type: text/x-vcard; name="Rik Drummond (rvd2@drummondgroup.com).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Rik Drummond (rvd2@drummondgroup.com).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Drummond;Rik FN:Rik Drummond (rvd2@drummondgroup.com) ORG:Drummond Group Inc. TITLE:CEO & Chief Scientist TEL;WORK;VOICE:817 294 7339 TEL;CELL;VOICE:817 239 1320 TEL;WORK;FAX:817-294-7950 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;4700 Bryant Irving Court, = =3D0D=3D0ASuite 303;Fort Worth;Texas;76107-7645;Unit=3D ed States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:4700 Bryant Irving Court, = =3D0D=3D0ASuite 303=3D0D=3D0AFort Worth, Texas 76107-7645=3D =3D0D=3D0AUnited States of America URL;WORK:http://www.drummondgroup.com EMAIL;PREF;INTERNET:rvd2@drummondgroup.com REV:20020516T153909Z END:VCARD ------=_NextPart_000_002B_01C2BA50.1B21B8A0-- From owner-ietf-ediint@mail.imc.org Tue Jan 14 07:20:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22324 for ; Tue, 14 Jan 2003 07:20:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EC70I15782 for ietf-ediint-bks; Tue, 14 Jan 2003 04:07:00 -0800 (PST) Received: from 21cn.com ([61.140.60.248]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0EC6ro15778 for ; Tue, 14 Jan 2003 04:06:55 -0800 (PST) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm43e23fedc; Tue, 14 Jan 2003 20:05:45 +0800 X-MaxRuleNumber-200: 136619 965345269 X-MatchRuleNumber-200: 75289 592464123 X-Action-200: ,D Received: from 21cn.com([10.2.1.2]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm03e240521; Tue, 14 Jan 2003 20:05:45 +0800 Received: from ran.ietf.org([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jma43e1f7176; Sat, 11 Jan 2003 02:02:20 +0800 X-MaxRuleNumber-200: 134087 1078348429 X-MatchRuleNumber-200: 75289 592464123 X-Action-200: ,D Received: from ran.ietf.org([132.151.6.60]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm463e1f2e15; Sat, 11 Jan 2003 02:02:20 +0800 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18X378-0001mr-00 for ietf-announce-list@ran.ietf.org; Fri, 10 Jan 2003 12:38:38 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18X36M-0001it-00 for all-ietf@ran.ietf.org; Fri, 10 Jan 2003 12:37:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04964; Fri, 10 Jan 2003 12:34:29 -0500 (EST) Message-Id: <200301101734.MAA04964@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ediint@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ediint-as2-12.txt Date: Fri, 10 Jan 2003 12:34:29 -0500 X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-announce@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : HTTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet Author(s) : D. Moberg, R. Drummond Filename : draft-ietf-ediint-as2-12.txt Pages : 28 Date : 2003-1-10 This document describes how to exchange structured business data securely using HTTP transfer for XML, Binary, Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport) or other data describable in MIME used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements make use of multipart/signed repliesto the original HTTP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-as2-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ediint-as2-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10122215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ediint-as2-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ediint-as2-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10122215.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ediint@mail.imc.org Tue Jan 14 16:59:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13259 for ; Tue, 14 Jan 2003 16:59:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ELgRa08388 for ietf-ediint-bks; Tue, 14 Jan 2003 13:42:27 -0800 (PST) Received: from drummondgroup.com (drummondgroup.com [161.58.166.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ELgOo08383 for ; Tue, 14 Jan 2003 13:42:24 -0800 (PST) Received: from RIKDGI (c66.169.103.180.ftwrth.tx.charter.com [66.169.103.180]) by drummondgroup.com (8.12.6/8.11.6) with ESMTP id h0ELgQYt019782 for ; Tue, 14 Jan 2003 14:42:26 -0700 (MST) From: "Rik Drummond" To: Subject: Comments on the recent EDIINT AS2 v12 draft Date: Tue, 14 Jan 2003 15:40:47 -0600 Organization: Drummond Group Inc. Message-ID: <000001c2bc15$9d83c970$0200a8c0@RIKDGI> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C2BBE3.52EAE010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_0001_01C2BBE3.52EAE010 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C2BBE3.52EDED50" ------=_NextPart_001_0002_01C2BBE3.52EDED50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit History of v12 draft: - after the as2 v2 draft we attempted to combine the then current as2 draft with gisb standard used in the energy industry. - during the recent two interop rounds with twenty plus products, implementing the non gisb part, it became apparent that the v11 draft was very confusing because of the attempt to combine the two. - the twenty plus vendors interop testing help make the v12 draft clearer - Dick Brooks called very concerned that I dropped the gisb info from the v12 draft - I asked that he send me the gisb standard and I would append it to the current v12 draft, call it v13, to facilitate discussion, while ensuring the non gisb part has clarity, which it did not have in v11 The suggested process at this time: - please review the contents of the v12 draft for clarity and correctness for the non gisb part - once this is complete we will discuss the gisb part which Dick Brooks will send me and I will include in the next release v13 - Then we will discuss (based on the old v11 draft) if there is a means to combine them in the same draft/document Non technical issue: - the energy industry refers to the gisb spec as as2 - the retail industry and others using the non gisb part of the spec refers to it as as2 - both, in some cases mandate the use of as2 specs.. Which means we have a naming issue if we decide to split them into two specs - fairness is the key to resolving this issue, especially on the use of the as2 name. Please review v12 asap for clarity and correctness. Best regards, Rik Drummond EDIINT Chair ------=_NextPart_001_0002_01C2BBE3.52EDED50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on the recent EDIINT AS2 v12 draft

History of v12 draft:
         &nbs= p;  - after the as2 v2 draft we attempted to combine the then = current as2 draft with
         &nbs= p;    gisb standard used in the energy industry.
        - during the recent two interop rounds with twenty plus = products, implementing
         &nbs= p;    the non gisb part, it became apparent that the v11 = draft was very confusing because
         &nbs= p;    of the attempt to combine the two.
        - the twenty plus vendors interop testing help make the = v12 draft clearer

        - Dick Brooks called very concerned that I dropped the = gisb info from the v12 draft
        - I asked that he send me the gisb standard and I would = append it to the current v12 draft, call it v13,
          to facilitate discussion, while ensuring the non = gisb part has clarity,
         &nbs= p;    which it did not have in v11

The suggested process at this = time:
        - please review the contents of the v12 draft for clarity = and correctness for the non gisb part
        - once this is complete we will discuss the gisb part = which Dick Brooks will send me and I
          will include in the next release v13
        - Then we will discuss (based on the old v11 draft) if = there is a means to combine them
          in the same draft/document

Non technical issue:
        - the energy industry refers to the gisb spec as = as2
        - the retail industry and others using the non gisb part = of the spec refers to it as as2
        - both, in some cases mandate the use of as2 specs.. = Which means we have a naming issue
          if we decide to split them into two specs
        - fairness is the key to resolving this issue, especially = on the use of the as2 name.

Please review v12 asap for clarity and = correctness…

Best regards,
Rik Drummond
EDIINT Chair
       =20





<<...>> =

------=_NextPart_001_0002_01C2BBE3.52EDED50-- ------=_NextPart_000_0001_01C2BBE3.52EAE010 Content-Type: text/x-vcard; name="Rik Drummond (rvd2@drummondgroup.com).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Rik Drummond (rvd2@drummondgroup.com).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Drummond;Rik FN:Rik Drummond (rvd2@drummondgroup.com) ORG:Drummond Group Inc. TITLE:CEO & Chief Scientist TEL;WORK;VOICE:817 294 7339 TEL;CELL;VOICE:817 239 1320 TEL;WORK;FAX:817-294-7950 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;4700 Bryant Irving Court, = =3D0D=3D0ASuite 303;Fort Worth;Texas;76107-7645;Unit=3D ed States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:4700 Bryant Irving Court, = =3D0D=3D0ASuite 303=3D0D=3D0AFort Worth, Texas 76107-7645=3D =3D0D=3D0AUnited States of America URL;WORK:http://www.drummondgroup.com EMAIL;PREF;INTERNET:rvd2@drummondgroup.com REV:20020516T153909Z END:VCARD ------=_NextPart_000_0001_01C2BBE3.52EAE010-- From owner-ietf-ediint@mail.imc.org Tue Jan 14 17:13:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13643 for ; Tue, 14 Jan 2003 17:13:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EM9Jj09082 for ietf-ediint-bks; Tue, 14 Jan 2003 14:09:19 -0800 (PST) Received: from lotus980.ptsupply.com (pnt43p46.ptsupply.com [168.215.137.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EM9Io09076 for ; Tue, 14 Jan 2003 14:09:18 -0800 (PST) Subject: test To: X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Jaime.Zepeda@ptsupply.com Date: Tue, 14 Jan 2003 16:04:03 -0600 X-MIMETrack: Serialize by Router on lotus980/ptsupply(Release 5.0.11 |July 24, 2002) at 01/14/2003 04:04:09 PM 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: test Stay informed. Enroll in Power & Tel's monthly newsletter service by clicking this link: http://www.ptsupply.com/home.nsf/Person?OpenForm This message contains privileged information and is solely for the use of the intended recipient. If you are not the intended recipient, please note that disclosure of this information, electronic or otherwise is prohibited. If you have received this message in error, kindly notify the sender and delete this email. From owner-ietf-ediint@mail.imc.org Tue Jan 14 20:34:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18492 for ; Tue, 14 Jan 2003 20:34:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0F1ASL14102 for ietf-ediint-bks; Tue, 14 Jan 2003 17:10:28 -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 h0F1AQo14094 for ; Tue, 14 Jan 2003 17:10:26 -0800 (PST) Received: from LAW2KN008 (host74.systrends.com [65.244.195.74] (may be forged)) by www.tech-comm.com (8.11.6/8.11.6) with SMTP id h0F2mji04035 for ; Tue, 14 Jan 2003 20:48:46 -0600 From: "Dick Brooks" To: Subject: RE: Comments on the recent EDIINT AS2 v12 draft Date: Tue, 14 Jan 2003 18:10:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C2BBF8.384E6320" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) 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: This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C2BBF8.384E6320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Comments on the recent EDIINT AS2 v12 draft Rik, In the hope that we can reach a reasonable solution to this matter, I will respond to your points. My comments are bounded by and . History of v12 draft: - after the as2 v2 draft we attempted to combine the then current as2 draft with gisb standard used in the energy industry. As I recall, it was both the Energy, represented by NAESB/GISB (http://www.naesb.org) and Automotive industries, represented by AIAG, http://www.aiag.org that contributed the sections in AS2 you are referring to. - during the recent two interop rounds with twenty plus products, implementing the non gisb part, it became apparent that the v11 draft was very confusing because of the attempt to combine the two. The two interop rounds you refer to were sponsored by UCC and facilitated by Drummond Group. These tests were conducted in a closed forum and only those companies that were willing to pay UCC/DGI the entrance fee (originally $15,000 now I believe it's $35,000) are allowed to participate. The test plan, which Drummond Group developed, explicitly excluded certain parts of the AS2 specification (the Energy/AIAG parts) . However the test is marketed/promoted as an "AS2 test" even though significant parts of AS2 are not being tested. To my knowledge, neither the test plan nor any of the testing experiences or results were discussed on the EDIINT WG list before, during or after the tests were conducted. The only public information that I'm aware of regarding these tests is available at www.drummondgroup.com, ref: http://www.drummondgroup.com/html-v2/pr_08-27-02.html I see several issues with the current testing process: 1. The entrance fee is a barrier to entry for some companies 2. The test plan has not approved through the IETF process. 3. The test unfairly excluded important parts of AS2 functionality, which the Energy and Auto industries contributed. Niether were these industry groups given an opportunity to express their opinions, because the work took place outside the IETF process in a private forum. - the twenty plus vendors interop testing help make the v12 draft clearer The twenty plus vendors, operating in private, changed the AS2 specification without so much as consulting the co-authors of the spec. The fact that these vendors aren't implementing certain sections of AS2 does not give them the right to remove them. I know of several AS2 implementations that were negatively affected by this decision. Why weren't these implementers involved in the discussion to make these changes? The answer is because the discussions did not follow the IETF process. None of the proposed changes in V12, including the removal of an AS2 co-author, were discussed on the EDIINT WG list. - Dick Brooks called very concerned that I dropped the gisb info from the v12 draft - I asked that he send me the gisb standard and I would append it to the current v12 draft, call it v13, to facilitate discussion, while ensuring the non gisb part has clarity, which it did not have in v11 You state the v11 spec lacked clarity, I agree it is a bit rough. However this was not a hinderance for numerous implementers of the V11 spec, as indicated by the number of interoperable products listed in your press release, plus the number of production implementations in the Energy industry (over 50), which I'm aware of. Additionally, all of the text you've requested from me is already available to you in the V11 draft of AS2. Simply cut and paste the parts of V11 that were removed in V12 and you will have what you' ve requested. The suggested process at this time: - please review the contents of the v12 draft for clarity and correctness for the non gisb part - once this is complete we will discuss the gisb part which Dick Brooks will send me and I will include in the next release v13 - Then we will discuss (based on the old v11 draft) if there is a means to combine them in the same draft/document I respectfully disagree. I firmly believe it would be less work and more efficient to start with V11. I propose an alternative approach which begins with the V11 spec. Start by incorporating text from V12 into V11 and the resulting V11+ spec be issued as draft V13 to the EDIINT WG for discussion. I also propose the following enhancements to improve the overall process: - Conduct all discussion regarding AS2 spec changes on the EDIINT list server so the entire EDIINT community may participate in the discussion - Seek consensus from the EDIINT community with regard to testing plans. Testing results should also be disclosed/ discussed in the open on the EDIINT WG list -AS2 testing should not be cost prohibitive so that all interested parties may participate - Testing should execrise as much of the AS2 technical specification as possible, ideally this would be 100% of the defined spec, but that may not be achievable. Non technical issue: - the energy industry refers to the gisb spec as as2 - the retail industry and others using the non gisb part of the spec refers to it as as2 - both, in some cases mandate the use of as2 specs.. Which means we have a naming issue if we decide to split them into two specs - fairness is the key to resolving this issue, especially on the use of the as2 name. Please review v12 asap for clarity and correctness. I've worked in the IETF since 1992 and I believe the IETF process is fair and open. We simply need to follow the defined process and use the EDIINT WG list and F2F IETF meetings to hold open discussions on matters pertaining to AS2. This will ensure the broadest exposure to interested parties and provides an opportunity to participate in a fair and open process. I believe there is an opportunity now to take a step in this direction by issuing a V13 draft using the alternative approach described above. Regards, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rik Drummond Sent: Tuesday, January 14, 2003 2:41 PM To: ietf-ediint@imc.org Subject: Comments on the recent EDIINT AS2 v12 draft History of v12 draft: - after the as2 v2 draft we attempted to combine the then current as2 draft with gisb standard used in the energy industry. - during the recent two interop rounds with twenty plus products, implementing the non gisb part, it became apparent that the v11 draft was very confusing because of the attempt to combine the two. - the twenty plus vendors interop testing help make the v12 draft clearer - Dick Brooks called very concerned that I dropped the gisb info from the v12 draft - I asked that he send me the gisb standard and I would append it to the current v12 draft, call it v13, to facilitate discussion, while ensuring the non gisb part has clarity, which it did not have in v11 The suggested process at this time: - please review the contents of the v12 draft for clarity and correctness for the non gisb part - once this is complete we will discuss the gisb part which Dick Brooks will send me and I will include in the next release v13 - Then we will discuss (based on the old v11 draft) if there is a means to combine them in the same draft/document Non technical issue: - the energy industry refers to the gisb spec as as2 - the retail industry and others using the non gisb part of the spec refers to it as as2 - both, in some cases mandate the use of as2 specs.. Which means we have a naming issue if we decide to split them into two specs - fairness is the key to resolving this issue, especially on the use of the as2 name. Please review v12 asap for clarity and correctness. Best regards, Rik Drummond EDIINT Chair <<...>> ------=_NextPart_000_0085_01C2BBF8.384E6320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on the recent EDIINT AS2 v12 draft
  Rik,
 
In the=20 hope that we can reach a reasonable solution to this = matter,=20 I will respond to your points. My comments are bounded by = <db> and=20 </db>.
 

History of v12 draft:
          &nbs= p; -=20 after the as2 v2 draft we attempted to combine the then current as2 = draft with=20
          &nbs= p;  =20 gisb standard used in the energy industry.

<db> As I recall, = it was both=20 the Energy, represented by NAESB/GISB (http://www.naesb.org) and Automotive = industries,=20 represented by AIAG, http://www.aiag.org that = contributed the=20 sections in AS2 you are referring = to.
</db>

        - during the recent = two=20 interop rounds with twenty plus products, implementing=20
           &nb= sp; =20 the non gisb part, it became apparent that the v11 draft was very = confusing=20 because=20
           &nb= sp; =20 of the attempt to combine the two.

<db>The two=20 interop rounds you refer to were sponsored by UCC = and facilitated by=20 Drummond Group. These tests were conducted in a closed forum and only = those=20 companies that were willing to pay UCC/DGI the = entrance fee=20 (originally $15,000 now I believe it's $35,000) are allowed to = participate.=20 The test plan, which Drummond Group developed, explicitly = excluded certain  parts = of the=20 AS2 specification (the Energy/AIAG = parts) . However the test  is marketed/promoted = as an "AS2 test"=20 even though  significant=20 parts of AS2  are not = being=20 tested.   
 
To my=20 knowledge, neither the test plan nor any of the testing  experiences or  results = were=20 discussed on the EDIINT WG list before, during or after the tests were=20 conducted. The only public information that I'm aware=20 of regarding these tests is available at  www.drummondgroup.com,=20 ref:
http://www= .drummondgroup.com/html-v2/pr_08-27-02.html 
 
I=20 see several issues with the  current  testing=20 process:
 
1. The=20 entrance fee is a barrier to entry for some = companies
 
2. The=20 test plan  has  = not=20 approved through the IETF process.
 
3. The test unfairly excluded important parts of AS2 = functionality, which=20 the Energy and Auto industries contributed. Niether were these industry = groups=20 given an opportunity to express their opinions, because the work = took place=20 outside the IETF process in a private forum. 
 </db>

        - the twenty = plus=20 vendors interop testing help make the v12 draft clearer =
<db>The twenty plus vendors, operating in private, = changed the AS2=20 specification without so much as consulting the co-authors of the spec. = The fact=20 that these vendors aren't implementing certain sections of AS2 does = not=20 give them the right to remove them. I know of several AS2 = implementations that=20 were negatively affected by this decision. Why weren't these=20 implementers involved in the discussion to make these changes? = The=20 answer is because the discussions did not follow the IETF = process. None of=20 the proposed changes in V12, including the removal of an=20 AS2 co-author, were discussed on the EDIINT WG list.=20
</db>

        - Dick=20 Brooks called very concerned that I dropped the gisb info from the v12=20 draft
        - I asked that he send me the gisb standard and I would append = it to the=20 current v12 draft, call it v13, to = facilitate=20 discussion, while ensuring the non gisb part has clarity, =
          &nbs= p;  =20 which it did not have in v11=20

<db>You state the v11 spec lacked = clarity,=20 I agree it is a bit rough. However this was not a hinderance for=20 numerous implementers of the V11 spec, as indicated by the number=20 of  interoperable = products=20 listed in your press release, plus the number of  production  implementations = in the=20 Energy industry (over 50), which I'm aware=20 of. 
 
Additionally, all of the text you've = requested from me=20 is already available to you in the V11 draft of AS2. Simply cut and = paste=20 the parts  of V11 that were = removed in=20 V12 and you will = have what=20 you' ve  requested.
</db>

The suggested process at this = time:=20
        - please=20 review the contents of the v12 draft for clarity and correctness for the = non=20 gisb part
        - once this is complete we will discuss the gisb part which = Dick Brooks=20 will send me and I
        =   will include in the next release v13 =
        - Then we=20 will discuss (based on the old v11 draft) if there is a means to combine = them
          in the same draft/document

<db>I respectfully disagree. I firmly believe it = would be less=20 work and more efficient to start with V11.  
 
I=20 propose an alternative approach which begins with the V11=20 spec. Start by incorporating text from V12 into V11 and the=20 resulting V11+ spec be issued as draft V13 to the EDIINT WG = for=20 discussion. 
 
I also=20 propose the following enhancements to improve the=20 overall process:
-=20 Conduct all discussion regarding AS2 spec changes on the EDIINT list = server so=20 the entire EDIINT community may participate in the=20 discussion
 
- Seek=20 consensus from the EDIINT community with regard to testing plans.=20 Testing   =  results=20 should  also =  be  disclosed/ discussed in the = open on=20 the EDIINT WG list 
 
-AS2 testing should not be cost = prohibitive so=20 that all interested parties may participate
 
-=20 Testing should execrise as much of the AS2 technical specification = as=20 possible, ideally this would be 100% of the defined spec, but that may = not be=20 achievable.
</db>

Non technical issue:=20
        - the=20 energy industry refers to the gisb spec as as2=20
        - the=20 retail industry and others using the non gisb part of the spec refers to = it as=20 as2
        - both, in some cases mandate the use of as2 specs.. Which = means we have=20 a naming issue
        =   if we decide to split them into two = specs=20
        -=20 fairness is the key to resolving this issue, especially on the use of = the as2=20 name.

Please review v12 asap for clarity and=20 correctness…

<db>I've worked in the IETF since 1992 = and I=20 believe the IETF process is fair and open. We simply need to follow the = defined=20 process and use the EDIINT WG list and F2F IETF meetings to hold open=20 discussions on matters pertaining to AS2.
 
This will ensure the broadest=20 exposure to interested parties and = provides an opportunity to=20 participate in a fair and open process.
 
I=20 believe there is an opportunity now to take a step in this direction by = issuing=20 a V13 draft using the  alternative=20  approach  described  = above.
</db>

Regards,

Dick Brooks
Systrends, Inc
7855 South River = Parkway,=20 Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mo= bile:602-684-1484,eFax:240-352-0714
 =20
-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On=20 Behalf Of Rik Drummond
Sent: Tuesday, January 14, 2003 = 2:41=20 PM
To: ietf-ediint@imc.org
Subject: Comments on = the recent=20 EDIINT AS2 v12 draft

History of v12 draft:
          &nbs= p; -=20 after the as2 v2 draft we attempted to combine the then current as2 = draft with=20
          &nbs= p;  =20 gisb standard used in the energy industry.=20
        - during the recent two interop rounds with twenty plus = products,=20 implementing
          &nbs= p;  =20 the non gisb part, it became apparent that the v11 draft was very = confusing=20 because
          &nbs= p;  =20 of the attempt to combine the two.=20
        - the=20 twenty plus vendors interop testing help make the v12 draft = clearer=20

        - Dick=20 Brooks called very concerned that I dropped the gisb info from the v12 = draft
        - I asked that he send me the gisb standard and I would = append it to=20 the current v12 draft, call it v13,=20
          to facilitate discussion, while ensuring the non gisb = part has=20 clarity,
          &nbs= p;  =20 which it did not have in v11

The suggested process at this = time:=20
        -=20 please review the contents of the v12 draft for clarity and = correctness for=20 the non gisb part =
        - once this is complete we will discuss the gisb = part which=20 Dick Brooks will send me and I=20
          will include in the next release v13=20
        - Then=20 we will discuss (based on the old v11 draft) if there is a means to = combine=20 them
          in the same draft/document

Non technical issue:=20
        - the=20 energy industry refers to the gisb spec as as2=20
        - the=20 retail industry and others using the non gisb part of the spec refers = to it as=20 as2
        - both, in some cases mandate the use of as2 specs.. Which = means we=20 have a naming issue =
       =20   if we decide to split them into two = specs
        - fairness is the key to resolving this issue, especially on = the use of=20 the as2 name.

Please review v12 asap for clarity and=20 correctness…

Best regards,
Rik Drummond
EDIINT = Chair=20
       





<<...>>=20

------=_NextPart_000_0085_01C2BBF8.384E6320-- From owner-ietf-ediint@mail.imc.org Wed Jan 15 18:05:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13739 for ; Wed, 15 Jan 2003 18:05:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0FMo4g26807 for ietf-ediint-bks; Wed, 15 Jan 2003 14:50:04 -0800 (PST) Received: from drummondgroup.com (drummondgroup.com [161.58.166.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0FMnwo26799 for ; Wed, 15 Jan 2003 14:49:58 -0800 (PST) Received: from RIKDGI (c66.169.103.180.ftwrth.tx.charter.com [66.169.103.180]) by drummondgroup.com (8.12.6/8.11.6) with ESMTP id h0FMnrJk098083; Wed, 15 Jan 2003 15:49:53 -0700 (MST) From: "Rik Drummond" To: Cc: "'Amanda Marholz'" Subject: RE: Comments on the recent EDIINT AS2 v12 draft Date: Wed, 15 Jan 2003 16:50:07 -0600 Organization: Drummond Group Inc. Message-ID: <000d01c2bce8$76a90c60$0200a8c0@RIKDGI> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C2BCB6.2C0E9C60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <071001c2bcaf$6cf6af80$8e97d20c@attbi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_000E_01C2BCB6.2C0E9C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit please note that i am not getting messages from the listserv. this is not an i say you say issue.. i have suggested a process to resolve the clarity issues we have been having in my view this process is .... the only way to solve this is. so my first question to the members of this list is this process approriate from your view? - get the v12 spec straighten out via review on this list - get the e5/gisb spec, but submitting it to this list, reviewed - durring the discussion calling them both as2 - after that happens we can figure out the marketing issue of who, if either gets the as2 title. so lets start with a technical correctness and clarity review of the v12 spec. and then follow it via review of the e5/gisb submission.... best regards, rik ----- Original Message ----- From: Dick Brooks To: ietf-ediint@imc.org Sent: Tuesday, January 14, 2003 7:10 PM Subject: RE: Comments on the recent EDIINT AS2 v12 draft Rik, In the hope that we can reach a reasonable solution to this matter, I will respond to your points. My comments are bounded by and . History of v12 draft: - after the as2 v2 draft we attempted to combine the then current as2 draft with gisb standard used in the energy industry. As I recall, it was both the Energy, represented by NAESB/GISB (http://www.naesb.org) and Automotive industries, represented by AIAG, http://www.aiag.org that contributed the sections in AS2 you are referring to. - during the recent two interop rounds with twenty plus products, implementing the non gisb part, it became apparent that the v11 draft was very confusing because of the attempt to combine the two. The two interop rounds you refer to were sponsored by UCC and facilitated by Drummond Group. These tests were conducted in a closed forum and only those companies that were willing to pay UCC/DGI the entrance fee (originally $15,000 now I believe it's $35,000) are allowed to participate. The test plan, which Drummond Group developed, explicitly excluded certain parts of the AS2 specification (the Energy/AIAG parts) . However the test is marketed/promoted as an "AS2 test" even though significant parts of AS2 are not being tested. To my knowledge, neither the test plan nor any of the testing experiences or results were discussed on the EDIINT WG list before, during or after the tests were conducted. The only public information that I'm aware of regarding these tests is available at www.drummondgroup.com, ref: http://www.drummondgroup.com/html-v2/pr_08-27-02.html I see several issues with the current testing process: 1. The entrance fee is a barrier to entry for some companies 2. The test plan has not approved through the IETF process. 3. The test unfairly excluded important parts of AS2 functionality, which the Energy and Auto industries contributed. Niether were these industry groups given an opportunity to express their opinions, because the work took place outside the IETF process in a private forum. - the twenty plus vendors interop testing help make the v12 draft clearer The twenty plus vendors, operating in private, changed the AS2 specification without so much as consulting the co-authors of the spec. The fact that these vendors aren't implementing certain sections of AS2 does not give them the right to remove them. I know of several AS2 implementations that were negatively affected by this decision. Why weren't these implementers involved in the discussion to make these changes? The answer is because the discussions did not follow the IETF process. None of the proposed changes in V12, including the removal of an AS2 co-author, were discussed on the EDIINT WG list. - Dick Brooks called very concerned that I dropped the gisb info from the v12 draft - I asked that he send me the gisb standard and I would append it to the current v12 draft, call it v13, to facilitate discussion, while ensuring the non gisb part has clarity, which it did not have in v11 You state the v11 spec lacked clarity, I agree it is a bit rough. However this was not a hinderance for numerous implementers of the V11 spec, as indicated by the number of interoperable products listed in your press release, plus the number of production implementations in the Energy industry (over 50), which I'm aware of. Additionally, all of the text you've requested from me is already available to you in the V11 draft of AS2. Simply cut and paste the parts of V11 that were removed in V12 and you will have what you' ve requested. The suggested process at this time: - please review the contents of the v12 draft for clarity and correctness for the non gisb part - once this is complete we will discuss the gisb part which Dick Brooks will send me and I will include in the next release v13 - Then we will discuss (based on the old v11 draft) if there is a means to combine them in the same draft/document I respectfully disagree. I firmly believe it would be less work and more efficient to start with V11. I propose an alternative approach which begins with the V11 spec. Start by incorporating text from V12 into V11 and the resulting V11+ spec be issued as draft V13 to the EDIINT WG for discussion. I also propose the following enhancements to improve the overall process: - Conduct all discussion regarding AS2 spec changes on the EDIINT list server so the entire EDIINT community may participate in the discussion - Seek consensus from the EDIINT community with regard to testing plans. Testing results should also be disclosed/ discussed in the open on the EDIINT WG list -AS2 testing should not be cost prohibitive so that all interested parties may participate - Testing should execrise as much of the AS2 technical specification as possible, ideally this would be 100% of the defined spec, but that may not be achievable. Non technical issue: - the energy industry refers to the gisb spec as as2 - the retail industry and others using the non gisb part of the spec refers to it as as2 - both, in some cases mandate the use of as2 specs.. Which means we have a naming issue if we decide to split them into two specs - fairness is the key to resolving this issue, especially on the use of the as2 name. Please review v12 asap for clarity and correctness. I've worked in the IETF since 1992 and I believe the IETF process is fair and open. We simply need to follow the defined process and use the EDIINT WG list and F2F IETF meetings to hold open discussions on matters pertaining to AS2. This will ensure the broadest exposure to interested parties and provides an opportunity to participate in a fair and open process. I believe there is an opportunity now to take a step in this direction by issuing a V13 draft using the alternative approach described above. Regards, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com > Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rik Drummond Sent: Tuesday, January 14, 2003 2:41 PM To: ietf-ediint@imc.org Subject: Comments on the recent EDIINT AS2 v12 draft History of v12 draft: - after the as2 v2 draft we attempted to combine the then current as2 draft with gisb standard used in the energy industry. - during the recent two interop rounds with twenty plus products, implementing the non gisb part, it became apparent that the v11 draft was very confusing because of the attempt to combine the two. - the twenty plus vendors interop testing help make the v12 draft clearer - Dick Brooks called very concerned that I dropped the gisb info from the v12 draft - I asked that he send me the gisb standard and I would append it to the current v12 draft, call it v13, to facilitate discussion, while ensuring the non gisb part has clarity, which it did not have in v11 The suggested process at this time: - please review the contents of the v12 draft for clarity and correctness for the non gisb part - once this is complete we will discuss the gisb part which Dick Brooks will send me and I will include in the next release v13 - Then we will discuss (based on the old v11 draft) if there is a means to combine them in the same draft/document Non technical issue: - the energy industry refers to the gisb spec as as2 - the retail industry and others using the non gisb part of the spec refers to it as as2 - both, in some cases mandate the use of as2 specs.. Which means we have a naming issue if we decide to split them into two specs - fairness is the key to resolving this issue, especially on the use of the as2 name. Please review v12 asap for clarity and correctness. Best regards, Rik Drummond EDIINT Chair <<...>> ------=_NextPart_000_000E_01C2BCB6.2C0E9C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
please=20 note that i am not getting messages from the = listserv.
 
this = is not an i say=20 you say issue.. i have suggested a process to resolve the clarity issues = we have=20 been having
 
in my = view this=20 process is .... the only way to solve this is.
 
so my = first question=20 to the members of this list is this process approriate from your=20 view?
 
- get = the v12 spec=20 straighten out via review on this list
- get = the e5/gisb=20 spec, but submitting it to this list, reviewed
- = durring the=20 discussion calling them both as2
- = after that happens=20 we can figure out the marketing issue of who, if either gets the as2=20 title.
 
so = lets start with a=20 technical correctness and clarity review of the v12 = spec.
and = then follow it=20 via review of the e5/gisb submission.... best regards, = rik
----- Original Message -----=20
From: Dick = Brooks=20
Sent: Tuesday, January 14, 2003 7:10 PM
Subject: RE: Comments on the recent EDIINT AS2 v12=20 draft

  Rik,
 
In=20 the hope that we can reach a reasonable solution to = this=20 matter, I will respond to your points. My comments = are bounded by=20 <db> and </db>.
 

History of v12 draft:
          &nbs= p; -=20 after the as2 v2 draft we attempted to combine the then current as2 = draft with=20
          &nbs= p;  =20 gisb standard used in the energy industry.

<db> As I = recall, it was=20 both the Energy, represented by NAESB/GISB (http://www.naesb.org) and Automotive = industries, represented by AIAG, http://www.aiag.org that = contributed the=20 sections in AS2 you are referring = to.
</db>

        - during the = recent two=20 interop rounds with twenty plus products, implementing=20 =
           &nb= sp; =20 the non gisb part, it became apparent that the v11 draft was very = confusing=20 because=20 =
           &nb= sp; =20 of the attempt to combine the two.

<db>The two=20 interop rounds you refer to were sponsored by UCC = and facilitated by=20 Drummond Group. These tests were conducted in a closed forum and only = those=20 companies that were willing to pay UCC/DGI the = entrance fee=20 (originally $15,000 now I believe it's $35,000) are allowed to=20 participate. The test plan, which Drummond = Group developed,=20 explicitly excluded certain  parts=20 of the AS2 specification (the=20 Energy/AIAG parts) . However the test  is marketed/promoted = as an "AS2=20 test" even though  significant parts of = AS2  are not being = tested.   
 
To=20 my knowledge, neither the test plan nor any of the testing  experiences or  results = were=20 discussed on the EDIINT WG list before, during or after the tests were = conducted. The only public information that I'm aware=20 of regarding these tests is available at  www.drummondgroup.com,=20 ref:
http://www= .drummondgroup.com/html-v2/pr_08-27-02.html 
 
I=20 see several issues with the  current  testing=20 process:
 
1.=20 The entrance fee is a barrier to entry for some = companies
 
2.=20 The test plan  has  not=20 approved through the IETF process.
 
3. The test unfairly excluded important parts of AS2 = functionality,=20 which the Energy and Auto industries contributed. Niether were these = industry=20 groups given an opportunity to express their opinions, because = the work=20 took place outside the IETF process in a private forum. 
 </db>

        - the = twenty plus=20 vendors interop testing help make the v12 draft clearer =
<db>The twenty plus vendors, operating in private, = changed the=20 AS2 specification without so much as consulting the co-authors of the = spec.=20 The fact that these vendors aren't implementing certain sections = of AS2=20 does not give them the right to remove them. I know of several AS2=20 implementations that were negatively affected by this decision. Why = weren't=20 these implementers involved in the discussion to make these = changes?=20 The answer is because the discussions did not follow the IETF=20 process. None of the proposed changes in V12, including the = removal of an=20 AS2 co-author, were discussed on the EDIINT WG list.=20
</db>

        - Dick=20 Brooks called very concerned that I dropped the gisb info from the v12 = draft
        - I asked that he send me the gisb standard and I would = append it to=20 the current v12 draft, call it v13, to facilitate=20 discussion, while ensuring the non gisb part has clarity, =
          &nbs= p;  =20 which it did not have in v11=20

<db>You state the v11 spec = lacked=20 clarity, I agree it is a bit rough. However this was not a = hinderance for=20 numerous implementers of the V11 spec, as indicated by the number = of  interoperable = products=20 listed in your press release, plus the number of  production =  implementations in the=20 Energy industry (over 50), which I'm aware=20 of. 
 
Additionally, all of the text you've = requested from=20 me is already available to you in the V11 draft of AS2. Simply = cut and=20 paste the parts  of V11 = that were=20 removed in V12 and = you will=20 have what you' ve  requested. =
</db>

The suggested process at this = time:=20
        -=20 please review the contents of the v12 draft for clarity and = correctness for=20 the non gisb part =
        - once this is complete we will discuss the gisb = part which=20 Dick Brooks will send me and I=20
          will include in the next release v13=20
        - Then=20 we will discuss (based on the old v11 draft) if there is a means to = combine=20 them
          in the same draft/document

<db>I respectfully disagree. I firmly believe it = would be=20 less work and more efficient to start with V11.  
 
I=20 propose an alternative approach which begins with the V11=20 spec. Start by incorporating text from V12 into V11 and the=20 resulting V11+ spec be issued as draft V13 to the EDIINT WG = for=20 discussion. 
 
I=20 also propose the following enhancements to improve the=20 overall process:
-=20 Conduct all discussion regarding AS2 spec changes on the EDIINT list = server so=20 the entire EDIINT community may participate in the=20 discussion
 
-=20 Seek consensus from the EDIINT community with regard to testing plans. = Testing   =  results=20 should  also=20  be  disclosed/ discussed in = the open on=20 the EDIINT WG list 
 
-AS2 testing should = not be cost=20 prohibitive so that all interested parties may = participate
 
-=20 Testing should execrise as much of the AS2 technical = specification as=20 possible, ideally this would be 100% of the defined spec, but that may = not be=20 achievable.
</db>

Non technical issue:=20
        - the=20 energy industry refers to the gisb spec as as2=20
        - the=20 retail industry and others using the non gisb part of the spec refers = to it as=20 as2
        - both, in some cases mandate the use of as2 specs.. Which = means we=20 have a naming issue =
       =20   if we decide to split them into two = specs
        - fairness is the key to resolving this issue, especially on = the use of=20 the as2 name.

Please review v12 asap for clarity and=20 correctness…

<db>I've worked in the IETF since = 1992 and I=20 believe the IETF process is fair and open. We simply need to follow = the=20 defined process and use the EDIINT WG list and F2F IETF meetings to = hold open=20 discussions on matters pertaining to AS2.
 
This will ensure the = broadest=20 exposure to interested parties and = provides an opportunity to=20 participate in a fair and open process.
 
I=20 believe there is an opportunity now to take a step in this direction = by=20 issuing a V13 draft using the  alternative =  approach  described =20 above.
</db>

Regards,

Dick Brooks
Systrends, Inc
7855 South River = Parkway,=20 Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mo= bile:602-684-1484,eFax:240-352-0714
 =20
-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On=20 Behalf Of Rik Drummond
Sent: Tuesday, January 14, 2003 = 2:41=20 PM
To: ietf-ediint@imc.org
Subject: Comments on = the=20 recent EDIINT AS2 v12 draft

History of v12 draft: =
          &nbs= p; -=20 after the as2 v2 draft we attempted to combine the then current as2 = draft=20 with
          &nbs= p;  =20 gisb standard used in the energy industry.=20
        - during the recent two interop rounds with twenty plus = products,=20 implementing
          &nbs= p;  =20 the non gisb part, it became apparent that the v11 draft was very = confusing=20 because
          &nbs= p;  =20 of the attempt to combine the two.=20
        - the=20 twenty plus vendors interop testing help make the v12 draft = clearer=20

        - Dick=20 Brooks called very concerned that I dropped the gisb info from the = v12=20 draft
        - I asked that he send me the gisb standard and I would = append it to=20 the current v12 draft, call it v13,=20
          to facilitate discussion, while ensuring the non = gisb part has=20 clarity,
          &nbs= p;  =20 which it did not have in v11

The suggested process at this = time:=20
        -=20 please review the contents of the v12 draft for clarity and = correctness for=20 the non gisb part =
       =20 - once this is complete we will discuss = the gisb=20 part which Dick Brooks will send me and I=20
          will include in the next release v13=20
        -=20 Then we will discuss (based on the old v11 draft) if there is a = means to=20 combine them
        =   in the same draft/document

Non technical issue:=20
        - the=20 energy industry refers to the gisb spec as as2=20
        - the=20 retail industry and others using the non gisb part of the spec = refers to it=20 as as2
        - both, in some cases mandate the use of as2 = specs.. Which=20 means we have a naming issue=20
          if we decide to split them into two specs=20
        -=20 fairness is the key to resolving this issue, especially on the use = of the=20 as2 name.

Please review v12 asap for clarity = and=20 correctness…

Best regards,
Rik Drummond
EDIINT = Chair=20
       





<<...>>=20

------=_NextPart_000_000E_01C2BCB6.2C0E9C60-- From owner-ietf-ediint@mail.imc.org Wed Jan 15 20:45:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17544 for ; Wed, 15 Jan 2003 20:45:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0G1SuT01505 for ietf-ediint-bks; Wed, 15 Jan 2003 17:28:56 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0G1Sto01500 for ; Wed, 15 Jan 2003 17:28:55 -0800 (PST) Received: from SEMINOLEVS1.cyclonecommerce.com ([10.1.0.21]) by spyglass.cyclonecommerce.com (NAVGW 2.5.1.13) with SMTP id M2003011518284804275 for ; Wed, 15 Jan 2003 18:28:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCFE.9E4976FC" Subject: RE: Comments on the recent EDIINT AS2 v12 draft Date: Wed, 15 Jan 2003 18:28:48 -0700 Message-ID: <765F034A849AF4489B7E313759AB242901958953@SEMINOLEVS1.cyclonecommerce.com> Thread-Topic: Comments on the recent EDIINT AS2 v12 draft Thread-Index: AcK87ZCUytjMV1nlTEaXglNkEvXprwABg4eQ From: "Gary Crough" To: 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_001_01C2BCFE.9E4976FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, There is a subset of AS2 which has gone through formal = interoperability trials. These trails are currently sponsored by the = UCC (packaged goods industry) and UCC member companies are major = consumers of this software. There is also a subset of AS2 (v11 specification) used within the = Energy industry. =20 My belief is: software supporting one AS2 subset is NOT = interoperable with software supporting the other subset. The packaged = goods industry and the Energy industry have standardized on different = subsets of the "AS2 specification". The planned EDIINT/HL7/GISB/AIAG = convergence did not happen. =20 If we agree on this, the most important thing is to avoid confusing = end users. =20 The move Rik made to "clean up" the subset of the AS2 specification = used by the UCC was appropriate for that community. There was pressure = from end users to move in this direction. But this "AS2 cleanup" = removed portions of the specification critical to the Energy industry. = Ideally, a parallel AS2 cleanup for the Energy industry would have = happened at the same time. I know this is an oversimplification but = perhaps Rik should have created an EDIINT(S/MIME) and an = EDIINT(PGP/MIME) as children of EDIINT AS2. =20 =20 I favor splitting the old AS2 specification into two separate = specifications and accept the v12 draft as one of the specifications. =20 Dick's insinuation that Drummond Test Plans become de-facto = standards is correct. Further, the v12 draft modifies the AS2 = specification around that test plan. As Dick stated these changes were = outside of IETF process. Still, I have no problem with them ... my goal = is to meet end user needs and I think the v12 draft is a move in the = right direction. It's NOT to late to go through the IETF process?? = Let's just view the v12 (Drummond) draft as a proposal and get some = input. Those most interested in a v12(GISB) draft should take the lead = in its creation ... maybe they keep the v11 draft and require PGP/MIME = and S/MIME or maybe they throw out S/MIME. =20 Hopefully, EDIINT members will weigh in on: 1 Do you support the spin-off of the AS2 v11 specification into a = version focused on UCC (packaged goods) requirements? 2 Should the Energy industry stick with the v11 base or do its own = clean up? 3 Do you have an opinion on the names which should be assigned? =20 -----Original Message----- From: Rik Drummond [mailto:rvd2@drummondgroup.com] Sent: Wednesday, January 15, 2003 3:50 PM To: ietf-ediint@imc.org Cc: 'Amanda Marholz' Subject: RE: Comments on the recent EDIINT AS2 v12 draft please note that i am not getting messages from the listserv. =20 this is not an i say you say issue.. i have suggested a process to = resolve the clarity issues we have been having =20 in my view this process is .... the only way to solve this is. =20 so my first question to the members of this list is this process = approriate from your view? =20 - get the v12 spec straighten out via review on this list - get the e5/gisb spec, but submitting it to this list, reviewed - durring the discussion calling them both as2 - after that happens we can figure out the marketing issue of who, if = either gets the as2 title. =20 so lets start with a technical correctness and clarity review of the v12 = spec. and then follow it via review of the e5/gisb submission.... best = regards, rik ----- Original Message -----=20 From: Dick Brooks =20 To: ietf-ediint@imc.org=20 Sent: Tuesday, January 14, 2003 7:10 PM Subject: RE: Comments on the recent EDIINT AS2 v12 draft Rik, =20 In the hope that we can reach a reasonable solution to this matter, I = will respond to your points. My comments are bounded by and . =20 History of v12 draft:=20 - after the as2 v2 draft we attempted to combine the then = current as2 draft with=20 gisb standard used in the energy industry.=20 As I recall, it was both the Energy, represented by NAESB/GISB ( = http://www.naesb.org) and Automotive industries, represented by AIAG, = http://www.aiag.org that contributed the sections in AS2 you are = referring to. - during the recent two interop rounds with twenty plus = products, implementing=20 the non gisb part, it became apparent that the v11 draft = was very confusing because=20 of the attempt to combine the two.=20 The two interop rounds you refer to were sponsored by UCC and = facilitated by Drummond Group. These tests were conducted in a closed = forum and only those companies that were willing to pay UCC/DGI the = entrance fee (originally $15,000 now I believe it's $35,000) are allowed = to participate. The test plan, which Drummond Group developed, = explicitly excluded certain parts of the AS2 specification (the = Energy/AIAG parts) . However the test is marketed/promoted as an "AS2 = test" even though significant parts of AS2 are not being tested. =20 =20 To my knowledge, neither the test plan nor any of the testing = experiences or results were discussed on the EDIINT WG list before, = during or after the tests were conducted. The only public information = that I'm aware of regarding these tests is available at = www.drummondgroup.com, ref: http://www.drummondgroup.com/html-v2/pr_08-27-02.html=20 =20 I see several issues with the current testing process: =20 1. The entrance fee is a barrier to entry for some companies =20 2. The test plan has not approved through the IETF process. =20 3. The test unfairly excluded important parts of AS2 functionality, = which the Energy and Auto industries contributed. Niether were these = industry groups given an opportunity to express their opinions, because = the work took place outside the IETF process in a private forum.=20 - the twenty plus vendors interop testing help make the v12 = draft clearer=20 The twenty plus vendors, operating in private, changed the AS2 = specification without so much as consulting the co-authors of the spec. = The fact that these vendors aren't implementing certain sections of AS2 = does not give them the right to remove them. I know of several AS2 = implementations that were negatively affected by this decision. Why = weren't these implementers involved in the discussion to make these = changes? The answer is because the discussions did not follow the IETF = process. None of the proposed changes in V12, including the removal of = an AS2 co-author, were discussed on the EDIINT WG list.=20 - Dick Brooks called very concerned that I dropped the gisb info = from the v12 draft=20 - I asked that he send me the gisb standard and I would append = it to the current v12 draft, call it v13, to facilitate discussion, = while ensuring the non gisb part has clarity,=20 which it did not have in v11=20 You state the v11 spec lacked clarity, I agree it is a bit rough. = However this was not a hinderance for numerous implementers of the V11 = spec, as indicated by the number of interoperable products listed in = your press release, plus the number of production implementations in = the Energy industry (over 50), which I'm aware of.=20 =20 Additionally, all of the text you've requested from me is already = available to you in the V11 draft of AS2. Simply cut and paste the parts = of V11 that were removed in V12 and you will have what you' ve = requested.=20 The suggested process at this time:=20 - please review the contents of the v12 draft for clarity and = correctness for the non gisb part=20 - once this is complete we will discuss the gisb part which Dick = Brooks will send me and I=20 will include in the next release v13=20 - Then we will discuss (based on the old v11 draft) if there is = a means to combine them=20 in the same draft/document=20 I respectfully disagree. I firmly believe it would be less work and = more efficient to start with V11. =20 =20 I propose an alternative approach which begins with the V11 spec. Start = by incorporating text from V12 into V11 and the resulting V11+ spec be = issued as draft V13 to the EDIINT WG for discussion.=20 =20 I also propose the following enhancements to improve the overall = process: - Conduct all discussion regarding AS2 spec changes on the EDIINT list = server so the entire EDIINT community may participate in the discussion =20 - Seek consensus from the EDIINT community with regard to testing plans. = Testing results should also be disclosed/ discussed in the open on = the EDIINT WG list=20 =20 -AS2 testing should not be cost prohibitive so that all interested = parties may participate =20 - Testing should execrise as much of the AS2 technical specification as = possible, ideally this would be 100% of the defined spec, but that may = not be achievable. Non technical issue:=20 - the energy industry refers to the gisb spec as as2=20 - the retail industry and others using the non gisb part of the = spec refers to it as as2=20 - both, in some cases mandate the use of as2 specs.. Which means = we have a naming issue=20 if we decide to split them into two specs=20 - fairness is the key to resolving this issue, especially on the = use of the as2 name.=20 Please review v12 asap for clarity and correctness...=20 I've worked in the IETF since 1992 and I believe the IETF process is = fair and open. We simply need to follow the defined process and use the = EDIINT WG list and F2F IETF meetings to hold open discussions on matters = pertaining to AS2. =20 This will ensure the broadest exposure to interested parties and = provides an opportunity to participate in a fair and open process. =20 I believe there is an opportunity now to take a step in this direction = by issuing a V13 draft using the alternative approach described = above. Regards, 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:602-684-1484,eFax:240-352-0714 =20 -----Original Message----- From: owner-ietf-ediint@mail.imc.org = [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rik Drummond Sent: Tuesday, January 14, 2003 2:41 PM To: ietf-ediint@imc.org Subject: Comments on the recent EDIINT AS2 v12 draft History of v12 draft:=20 - after the as2 v2 draft we attempted to combine the then = current as2 draft with=20 gisb standard used in the energy industry.=20 - during the recent two interop rounds with twenty plus = products, implementing=20 the non gisb part, it became apparent that the v11 draft = was very confusing because=20 of the attempt to combine the two.=20 - the twenty plus vendors interop testing help make the v12 = draft clearer=20 - Dick Brooks called very concerned that I dropped the gisb info = from the v12 draft=20 - I asked that he send me the gisb standard and I would append = it to the current v12 draft, call it v13,=20 to facilitate discussion, while ensuring the non gisb part has = clarity,=20 which it did not have in v11=20 The suggested process at this time:=20 - please review the contents of the v12 draft for clarity and = correctness for the non gisb part=20 - once this is complete we will discuss the gisb part which Dick = Brooks will send me and I=20 will include in the next release v13=20 - Then we will discuss (based on the old v11 draft) if there is = a means to combine them=20 in the same draft/document=20 Non technical issue:=20 - the energy industry refers to the gisb spec as as2=20 - the retail industry and others using the non gisb part of the = spec refers to it as as2=20 - both, in some cases mandate the use of as2 specs.. Which means = we have a naming issue=20 if we decide to split them into two specs=20 - fairness is the key to resolving this issue, especially on the = use of the as2 name.=20 Please review v12 asap for clarity and correctness...=20 Best regards,=20 Rik Drummond=20 EDIINT Chair=20 =20 <<...>>=20 ------_=_NextPart_001_01C2BCFE.9E4976FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
All,
    There is a subset of AS2 = which has=20 gone through formal interoperability trials.  These trails are = currently=20 sponsored by the UCC (packaged goods industry) and UCC member companies=20 are major consumers of this software.
    There is also a subset of = AS2 (v11=20 specification) used within the Energy industry.
 
    My belief is: software = supporting=20 one AS2 subset is NOT interoperable with software supporting the = other=20 subset.  The packaged goods industry and the Energy industry have=20 standardized on different subsets of the "AS2 specification".  The = planned=20 EDIINT/HL7/GISB/AIAG convergence did not happen.  =
    If we agree on this, = the=20 most important thing is to avoid confusing end=20 users.
 
    The move Rik made to = "clean up" the=20 subset of the AS2 specification used by the UCC was appropriate for = that=20 community.  There was pressure from end users to move in this=20 direction.  But this "AS2 cleanup" removed portions of the=20 specification critical to the Energy industry.  Ideally, a parallel = AS2=20 cleanup for the Energy industry would have happened at the same = time.  I=20 know this is an oversimplification but perhaps Rik should have = created an=20 EDIINT(S/MIME) and an EDIINT(PGP/MIME) as children of EDIINT AS2. =20
 
    I favor splitting the old = AS2=20 specification into two separate specifications and accept the v12 draft = as one=20 of the specifications. 
   =20 Dick's insinuation that Drummond Test=20 Plans become de-facto standards is correct.  = Further, the=20 v12 draft modifies the AS2 specification around that test plan.  As = Dick=20 stated these changes were outside of IETF process.  = Still, I have=20 no problem with them ... my goal is to meet end user needs and I = think the=20 v12 draft is a move in the right direction.  It's NOT to late = to go=20 through the IETF process??   Let's just view the v12 = (Drummond) draft=20 as a proposal and get some input.  Those most interested in a = v12(GISB)=20 draft should take the lead in its creation ... maybe they keep the v11 = draft and=20 require PGP/MIME and S/MIME or maybe they throw out = S/MIME.
 
    Hopefully, EDIINT members = will weigh=20 in on:
1    Do you support the = spin-off of the=20 AS2 v11 specification into a version focused on UCC (packaged = goods)=20 requirements?
2    Should the Energy = industry=20 stick with the v11 base or do its own clean up?
3    Do you have an opinion on = the names=20 which should be assigned?
 
-----Original Message-----
From: Rik Drummond=20 [mailto:rvd2@drummondgroup.com]
Sent: Wednesday, January 15, = 2003=20 3:50 PM
To: ietf-ediint@imc.org
Cc: 'Amanda=20 Marholz'
Subject: RE: Comments on the recent EDIINT AS2 v12=20 draft

please note that i am not getting messages from the=20 listserv.
 
this = is not an i=20 say you say issue.. i have suggested a process to resolve the clarity = issues=20 we have been having
 
in = my view this=20 process is .... the only way to solve this is.
 
so = my first=20 question to the members of this list is this process approriate from = your=20 view?
 
- = get the v12 spec=20 straighten out via review on this list
- = get the e5/gisb=20 spec, but submitting it to this list, reviewed
- = durring the=20 discussion calling them both as2
- = after that=20 happens we can figure out the marketing issue of who, if either gets = the as2=20 title.
 
so = lets start with=20 a technical correctness and clarity review of the v12=20 spec.
and = then follow it=20 via review of the e5/gisb submission.... best regards, = rik
----- Original Message -----=20
From: = Dick = Brooks=20
Sent: Tuesday, January 14, 2003 7:10 PM
Subject: RE: Comments on the recent EDIINT AS2 v12=20 draft

  Rik,
 
In=20 the hope that we can reach a reasonable solution to = this=20 matter, I will respond to your points. My comments = are bounded=20 by <db> and </db>.
 

History of v12 draft: =
          &nbs= p; -=20 after the as2 v2 draft we attempted to combine the then current as2 = draft=20 with
          &nbs= p;  =20 gisb standard used in the energy industry.

<db> As I=20 recall, it was both the Energy, represented by = NAESB/GISB (http://www.naesb.org) and = Automotive=20 industries, represented by AIAG, http://www.aiag.org that = contributed the=20 sections in AS2 you are referring = to.
</db>

        - during the = recent two=20 interop rounds with twenty plus products, implementing=20 =
           &nb= sp; =20 the non gisb part, it became apparent that the v11 draft was very = confusing=20 because=20 =
           &nb= sp; =20 of the attempt to combine the two.

<db>The two=20 interop rounds you refer to were sponsored by UCC = and facilitated=20 by Drummond Group. These tests were conducted in a closed forum and = only=20 those companies that were willing to pay UCC/DGI the=20 entrance fee (originally $15,000 now I believe it's = $35,000) are=20 allowed to participate. The test plan, which Drummond=20 Group developed, explicitly excluded certain  parts of the AS2 = specification (the Energy/AIAG=20 parts) . However the test  is marketed/promoted=20 as an "AS2 test" even though  significant parts of = AS2  are not being = tested.   
 
To=20 my knowledge, neither the test plan nor any of the = testing  experiences or  results = were=20 discussed on the EDIINT WG list before, during or after the tests = were=20 conducted. The only public information that I'm aware=20 of regarding these tests is available at  www.drummondgroup.com,=20 ref:
http://www= .drummondgroup.com/html-v2/pr_08-27-02.html 
 
I=20 see several issues with the  current  testing=20 process:
 
1.=20 The entrance fee is a barrier to entry for some=20 companies
 
2.=20 The test plan  has  not=20 approved through the IETF process.
 
3. The test unfairly excluded = important parts of=20 AS2 functionality, which the Energy and Auto industries contributed. = Niether=20 were these industry groups given an opportunity to express=20 their opinions, because the work took place outside the IETF = process in=20 a private forum. 
 </db>

        - the = twenty plus=20 vendors interop testing help make the v12 draft clearer =
<db>The twenty plus vendors, operating in private, = changed the=20 AS2 specification without so much as consulting the co-authors of = the spec.=20 The fact that these vendors aren't implementing certain = sections of AS2=20 does not give them the right to remove them. I know of several AS2=20 implementations that were negatively affected by this decision. Why = weren't=20 these implementers involved in the discussion to make = these=20 changes? The answer is because the discussions did not follow the = IETF=20 process. None of the proposed changes in V12, including the = removal of=20 an AS2 co-author, were discussed on the EDIINT WG = list.=20
</db>

        - Dick=20 Brooks called very concerned that I dropped the gisb info from the = v12=20 draft
        - I asked that he send me the gisb standard and I would = append it to=20 the current v12 draft, call it v13, to=20 facilitate discussion, while ensuring the non gisb part has clarity, =
          &nbs= p;  =20 which it did not have in v11=20

<db>You state the v11 spec = lacked=20 clarity, I agree it is a bit rough. However this was not a = hinderance=20 for numerous implementers of the V11 spec, as indicated by the = number=20 of  interoperable = products=20 listed in your press release, plus the number of  production =  implementations in=20 the Energy industry (over 50), which I'm aware=20 of. 
 
Additionally, all of the text you've = requested from=20 me is already available to you in the V11 draft of AS2. Simply = cut and=20 paste the parts  of V11 = that were=20 removed in V12 and you=20 will have what you' ve  requested. =
</db>

The suggested process at this = time:=20
        -=20 please review the contents of the v12 draft for clarity and = correctness for=20 the non gisb part =
       =20 - once this is complete we will discuss = the gisb=20 part which Dick Brooks will send me and I=20
          will include in the next release v13=20
        -=20 Then we will discuss (based on the old v11 draft) if there is a = means to=20 combine them
        =   in the same draft/document =

<db>I respectfully disagree. I firmly believe it = would be=20 less work and more efficient to start with V11.  
 
I=20 propose an alternative approach which begins with the V11=20 spec. Start by incorporating text from V12 into V11 and = the=20 resulting V11+ spec be issued as draft V13 to the EDIINT = WG for=20 discussion. 
 
I=20 also propose the following enhancements to improve the=20 overall process:
-=20 Conduct all discussion regarding AS2 spec changes on the EDIINT list = server=20 so the entire EDIINT community may participate in the=20 discussion
 
-=20 Seek consensus from the EDIINT community with regard to testing = plans.=20 Testing   =  results=20 should  also=20  be  disclosed/ discussed in = the open=20 on the EDIINT WG list 
 
-AS2 testing should = not be cost=20 prohibitive so that all interested parties may=20 participate
 
-=20 Testing should execrise as much of the AS2 technical = specification as=20 possible, ideally this would be 100% of the defined spec, but that = may not=20 be achievable.
</db>

Non technical issue:=20
        - the=20 energy industry refers to the gisb spec as as2=20
        - the=20 retail industry and others using the non gisb part of the spec = refers to it=20 as as2
        - both, in some cases mandate the use of as2 = specs.. Which=20 means we have a naming issue=20
          if we decide to split them into two specs=20
        -=20 fairness is the key to resolving this issue, especially on the use = of the=20 as2 name.

Please review v12 asap for clarity = and=20 correctness…

<db>I've worked in the IETF since = 1992 and I=20 believe the IETF process is fair and open. We simply need to follow = the=20 defined process and use the EDIINT WG list and F2F IETF meetings to = hold=20 open discussions on matters pertaining to AS2.
 
This will ensure the = broadest=20 exposure to interested parties and = provides an opportunity to=20 participate in a fair and = open process.
 
I=20 believe there is an opportunity now to take a step in this direction = by=20 issuing a V13 draft using the  alternative =  approach  described =20 above.
</db>

Regards,

Dick Brooks
Systrends, Inc
7855 South = River Parkway,=20 Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Ph= one:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714
 =20
-----Original Message-----
From:=20 owner-ietf-ediint@mail.imc.org=20 [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Rik=20 Drummond
Sent: Tuesday, January 14, 2003 2:41 = PM
To:=20 ietf-ediint@imc.org
Subject: Comments on the recent = EDIINT AS2=20 v12 draft

History of v12 draft: =
          &nbs= p;=20 - after the as2 v2 draft we attempted to combine the then current = as2=20 draft with
          &nbs= p;  =20 gisb standard used in the energy industry.=20
        - during the recent two interop rounds with twenty plus = products,=20 implementing
          &nbs= p;  =20 the non gisb part, it became apparent that the v11 draft was very=20 confusing because
          &nbs= p;  =20 of the attempt to combine the two.=20
        -=20 the twenty plus vendors interop testing help make the v12 draft=20 clearer

        -=20 Dick Brooks called very concerned that I dropped the gisb info = from the=20 v12 draft
        = - I asked that he send me the gisb standard = and I would=20 append it to the current v12 draft, call it v13,=20
          to facilitate discussion, while ensuring the non = gisb part=20 has clarity,
          &nbs= p;  =20 which it did not have in v11

The suggested process at this = time:=20
        -=20 please review the contents of the v12 draft for clarity and = correctness=20 for the non gisb part=20
        -=20 once this is complete we will discuss the gisb part which Dick = Brooks will=20 send me and I =
          will include in the next release = v13=20
        -=20 Then we will discuss (based on the old v11 draft) if there is a = means to=20 combine them
        =   in the same draft/document =

Non technical issue:=20
        -=20 the energy industry refers to the gisb spec as as2=20
        -=20 the retail industry and others using the non gisb part of the spec = refers=20 to it as as2
        = - both, in some cases mandate the use of as2 = specs..=20 Which means we have a naming issue=20
          if we decide to split them into two specs=20
        -=20 fairness is the key to resolving this issue, especially on the use = of the=20 as2 name.

Please review v12 asap for clarity = and=20 correctness…

Best regards,
Rik Drummond
EDIINT Chair=20
        =





<<...>> =

------_=_NextPart_001_01C2BCFE.9E4976FC-- From owner-ietf-ediint@mail.imc.org Thu Jan 16 00:12:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21173 for ; Thu, 16 Jan 2003 00:12:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0G50Jr05587 for ietf-ediint-bks; Wed, 15 Jan 2003 21:00:19 -0800 (PST) Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0G509o05578 for ; Wed, 15 Jan 2003 21:00:09 -0800 (PST) Received: from dialup-64.157.22.219.dial1.saltlakecity1.level3.net ([64.157.22.219] helo=LAW2KN008) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18Z28L-000692-00; Wed, 15 Jan 2003 21:00:06 -0800 Reply-To: From: "Dick Brooks" To: "Gary Crough" , Subject: RE: Comments on the recent EDIINT AS2 v12 draft Date: Wed, 15 Jan 2003 21:59:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C2BCE1.7058DA90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <765F034A849AF4489B7E313759AB242901958953@SEMINOLEVS1.cyclonecommerce.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: This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C2BCE1.7058DA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MessageGary, my comments are inline bounded by and . All, There is a subset of AS2 which has gone through formal interoperability trials. These trails are currently sponsored by the UCC (packaged goods industry) and UCC member companies are major consumers of this software. There is also a subset of AS2 (v11 specification) used within the Energy industry. The above statements may lead one to believe that formal interoperability testing has occurred on the UCC subset of AS2 but no interoperability testing, formal or informal, has occurred on the Energy industry's use of AS2. Quite the contrary, there are hundreds of interoperable implementations of AS2 operating in production systems within the Energy industry. There are tens of thousands of transactions exchanged daily. These transactions are mission critical, and are considered part of the critical infrastructure by the United States Federal Government. I don't know what more proof is needed to demonstrate interoperability of AS2 in the Energy industry than the fact that thousands of transactions are being exchanged daily. .If your gas stove is working and your lights turn on, chances are good the Energy industries use of AS2 is "interoperating" properly. My belief is: software supporting one AS2 subset is NOT interoperable with software supporting the other subset. The packaged goods industry and the Energy industry have standardized on different subsets of the "AS2 specification". The planned EDIINT/HL7/GISB/AIAG convergence did not happen. If we agree on this, the most important thing is to avoid confusing end users. I'm afraid this latest "change" to AS2 has done more to confuse end users than anything in the recent past. I've had several conversations with people from around the Energy industry regarding this situation, trust me - they are confused by this latest action. It's also worth noting that software vendors can reasonably implement the full range of functionality defined in AS2 to support the UCC and Energy industries. There is nothing preventing vendors from supporting OpenPGP and S/MIME crypto and RFC2388 and AS2/e-mail packaging (using the AS2-From and AS2-To HTTP headers) and the multipart report types defined in MDN and the generalized receipt delivery type defined in AS2. The interoperability issue you describe is "self inflicted" by certain parties that have misled vendors into believing that they only have to support a subset of AS2 to be "certified". The moves by Rik to "clean up" the subset of the AS2 specification used by the UCC was appropriate for that community. There was pressure from end users to move in this direction. So, you're saying it was the UCC end users that wanted the Energy industry portions of AS2 removed. Would it have been acceptable if the Energy industry end users changed AS2 to remove the UCC portions? IMO, Rik did not "clean up" the AS2 specification. He has created a bifurcation of AS2 that virtually guarantees the propagation of interoperability issues. If allowed to continue this will result in separate "specifications", possibly one spec per industry group. If UCC wants to have it's own separate spec then it should consider developing one under it's own process. The IETF process is all about consensus. The Energy and Automotive industries joined in the IETF effort in good faith with the belief that the open consensus process would produce a result that could benefit many parties. But this "AS2 cleanup" removed portions of the specification critical to the Energy industry. Ideally, a parallel AS2 cleanup for the Energy industry would have happened at the same time. I know this is an oversimplification but perhaps Rik should have created an EDIINT(S/MIME) and an EDIINT(PGP/MIME) as children of EDIINT AS2. I favor splitting the old AS2 specification into two separate specifications and accept the v12 draft as one of the specifications. Dick's insinuation that Drummond Test Plans become de-facto standards is correct. Further, the v12 draft modifies the AS2 specification around that test plan. As Dick stated these changes were outside of IETF process. Still, I have no problem with them ... my goal is to meet end user needs and I think the v12 draft is a move in the right direction. It's NOT to late to go through the IETF process?? Let's just view the v12 (Drummond) draft as a proposal and get some input. Those most interested in a v12(GISB) draft should take the lead in its creation ... maybe they keep the v11 draft and require PGP/MIME and S/MIME or maybe they throw out S/MIME. This proposed solution, where two separate specs are created to serve the same purpose, is what you are suggesting to ensure interoperability. I fail to see the logic in this proposal. As I see it your proposal will result in the creation of one specification for the retail industry and another for the energy industry. If Dave Crocker and Jonathan Postel had used this rational back in the 80's when they were working on e-mail you would need to use different e-mail implementations to communicate with different industries today. I for one am glad that there is only one SMTP and addressing standard. I hope others in this community see the same longer term flaws in this proposed "splitting off" of AS2 that I see. Hopefully, EDIINT members will weigh in on: 1 Do you support the spin-off of the AS2 v11 specification into a version focused on UCC (packaged goods) requirements? 2 Should the Energy industry stick with the v11 base or do its own clean up? 3 Do you have an opinion on the names which should be assigned? I believe it would also be beneficial to hear from some experienced IETF folks regarding this proposed split up. Is there a precedence for efforts that split midway through development. If so, what was the outcome? What is the IETF position regarding competing specifications that perform the same function using two different (non-interoperable) approaches? Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 ------=_NextPart_000_001E_01C2BCE1.7058DA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Gary,=20 my comments are inline bounded by <db> and=20 </db>.
 
All,
    There is a subset of AS2 = which has=20 gone through formal interoperability trials.  These trails are = currently=20 sponsored by the UCC (packaged goods industry) and UCC member companies=20 are major consumers of this software.
    There is also a subset of = AS2 (v11=20 specification) used within the Energy industry.
 
<db> The above statements may lead one = to believe=20 that formal interoperability testing has occurred on the UCC subset of = AS2 but=20 no interoperability testing, formal or informal, has = occurred on the=20 Energy industry's use of AS2. 
Quite the contrary, there are hundreds of = interoperable=20 implementations of AS2 operating in production systems within the Energy = industry. There are tens of thousands of transactions = exchanged=20 daily. These transactions are mission critical,  and are=20 considered part of the critical infrastructure by the United States = Federal=20 Government. I don't know what more proof  is needed to = demonstrate=20 interoperability of AS2 in the Energy industry than the fact that = thousands of=20 transactions are being exchanged daily. .If your gas stove is = working and=20 your lights turn on, chances are good the Energy industries use of = AS2 is=20 "interoperating" properly.
</db>
 
 
    My belief is: software = supporting=20 one AS2 subset is NOT interoperable with software supporting the = other=20 subset.  The packaged goods industry and the Energy industry have=20 standardized on different subsets of the "AS2 specification".  The = planned=20 EDIINT/HL7/GISB/AIAG convergence did not happen.  =
    If we agree on this, = the=20 most important thing is to avoid confusing end=20 users.
 
<db>I'm afraid this latest "change" to = AS2 has=20 done more to confuse end users than anything in the recent past. I've = had=20 several conversations with people from around the Energy industry = regarding this=20 situation, trust me - they are confused by this latest=20 action.
It's also worth noting that software vendors = can=20 reasonably implement the full range of functionality defined in AS2 to = support=20 the UCC and Energy industries.  There is nothing preventing vendors = from=20 supporting OpenPGP and S/MIME crypto and RFC2388 and AS2/e-mail = packaging (using=20 the AS2-From and AS2-To HTTP headers) and the multipart report types = defined in=20 MDN and the generalized receipt delivery type defined in=20 AS2.
The interoperability issue you describe is = "self=20 inflicted" by certain parties that have misled vendors into believing = that they=20 only have to support a subset of  AS2 to be=20 "certified".
</db>
 
 
    The moves by Rik to "clean up" the subset of = the AS2=20 specification used by the UCC was appropriate for that=20 community.  There was pressure from end users to move in this=20 direction. 
 
<db>So, you're saying it was the UCC = end users=20 that wanted the Energy industry portions of AS2 removed. Would it have=20 been acceptable if the Energy industry end users changed AS2 to = remove the=20 UCC portions? 
 
IMO, Rik did not "clean up" the AS2 = specification. He=20 has created a bifurcation of AS2 that virtually guarantees the = propagation of=20 interoperability issues. If allowed to continue this will result in = separate "specifications", possibly one spec per industry=20 group. 
 
If UCC wants to have it's own separate spec = then it=20 should consider developing one under it's own process. = The IETF=20 process is all about consensus. The Energy and Automotive=20 industries joined in the IETF effort in good faith with the belief = that the=20 open consensus process would produce a result that could benefit = many=20 parties.    
</db>
 
 But this "AS2 cleanup" removed = portions of=20 the specification critical to the Energy industry.  Ideally, a = parallel AS2=20 cleanup for the Energy industry would have happened at the same = time.  I=20 know this is an oversimplification but perhaps Rik should have = created an=20 EDIINT(S/MIME) and an EDIINT(PGP/MIME) as children of EDIINT AS2. =20
 
    I favor splitting the old = AS2=20 specification into two separate specifications and accept the v12 draft = as one=20 of the specifications. 
   =20 Dick's insinuation that Drummond Test=20 Plans become de-facto standards is correct.  = Further, the=20 v12 draft modifies the AS2 specification around that test plan.  As = Dick=20 stated these changes were outside of IETF process.  = Still, I have=20 no problem with them ... my goal is to meet end user needs and I = think the=20 v12 draft is a move in the right direction.  It's NOT to late = to go=20 through the IETF process??   Let's just view the v12 = (Drummond) draft=20 as a proposal and get some input.  Those most interested in a = v12(GISB)=20 draft should take the lead in its creation ... maybe they keep the v11 = draft and=20 require PGP/MIME and S/MIME or maybe they throw out = S/MIME.
 
<db>This proposed solution, where two = separate=20 specs are created to serve the same purpose, is what you are=20 suggesting to ensure interoperability. I fail to see the logic in = this=20 proposal. 
As I see it your proposal will result in = the=20 creation of  one specification for the retail industry and another = for the=20 energy industry. If Dave Crocker and Jonathan Postel had used this = rational back=20 in the 80's when they were working on e-mail you would need to use=20 different e-mail implementations to communicate with different = industries today. I for one am glad that there is only one SMTP and = addressing=20 standard.
 
I hope others in this community see = the same=20 longer term flaws in this proposed "splitting off" of AS2 that I see.=20  
</db>
 
   
    Hopefully, EDIINT members = will weigh=20 in on:
1    Do you support the = spin-off of the=20 AS2 v11 specification into a version focused on UCC (packaged = goods)=20 requirements?
2    Should the Energy = industry=20 stick with the v11 base or do its own clean up?
3    Do you have an opinion on = the names=20 which should be assigned?

<db>I believe = it would also=20 be beneficial to hear from some experienced IETF folks regarding = this=20 proposed split up. Is there a precedence for efforts that split midway = through=20 development. If so, what was the outcome? What is the IETF position = regarding=20 competing specifications that perform the same function using two = different=20 (non-interoperable) approaches?

</db>

 

Dick Brooks
Systrends, Inc
7855 South River = Parkway, Suite=20 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mo= bile:602-684-1484,eFax:240-352-0714
 =20

------=_NextPart_000_001E_01C2BCE1.7058DA90-- From owner-ietf-ediint@mail.imc.org Thu Jan 16 06:25:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07361 for ; Thu, 16 Jan 2003 06:25:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GBAhR11830 for ietf-ediint-bks; Thu, 16 Jan 2003 03:10:43 -0800 (PST) Received: from FENCE4.perwill.com (firewall-user@[193.130.63.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0GBAfo11826 for ; Thu, 16 Jan 2003 03:10:42 -0800 (PST) Received: (from uucp@localhost) by FENCE4.perwill.com (8.10.2+Sun/8.10.2) id h0GBBRs29086 for ; Thu, 16 Jan 2003 11:11:27 GMT Received: from unknown(192.168.101.101) by FENCE4.perwill.com via csmap (V6.0) id srcAAAx1aOZ4; Thu, 16 Jan 03 11:11:27 GMT Received: by exchange.perwill.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 11:10:35 -0000 Message-ID: From: Andrew Stickland To: ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft Date: Thu, 16 Jan 2003 11:10:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD4F.E2DFD0A0" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BD4F.E2DFD0A0 Content-Type: text/plain; charset="iso-8859-1" All, I've long been a participant of this group and rarely provided any input but I have to say that I am deeply concerned about the rift that has just appeared. One could ask what is the point of a independent and global standards body that defines industry centric 'standards'. We certainly have companies that talk across industries (including retail and energy) and to have to use two different standards would be nothing less than ludicrous. Any moves away from a 'global' strategy will surely lay the foundations for failure of EDIINT as a broadly accepted standard. While certain industries have implemented EDIINT already, as they need to expand their data exchange capabilities, they are likely to turn away from anything that does not give them flexibility. All that aside, we tend to consider EDIINT (AS1 & 2) as one package so we might have a competitive edge over suppliers who narrow their options. Regards Andrew -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: 16 January 2003 05:00 To: Gary Crough; ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft Gary, my comments are inline bounded by and . All, There is a subset of AS2 which has gone through formal interoperability trials. These trails are currently sponsored by the UCC (packaged goods industry) and UCC member companies are major consumers of this software. There is also a subset of AS2 (v11 specification) used within the Energy industry. The above statements may lead one to believe that formal interoperability testing has occurred on the UCC subset of AS2 but no interoperability testing, formal or informal, has occurred on the Energy industry's use of AS2. Quite the contrary, there are hundreds of interoperable implementations of AS2 operating in production systems within the Energy industry. There are tens of thousands of transactions exchanged daily. These transactions are mission critical, and are considered part of the critical infrastructure by the United States Federal Government. I don't know what more proof is needed to demonstrate interoperability of AS2 in the Energy industry than the fact that thousands of transactions are being exchanged daily. .If your gas stove is working and your lights turn on, chances are good the Energy industries use of AS2 is "interoperating" properly. My belief is: software supporting one AS2 subset is NOT interoperable with software supporting the other subset. The packaged goods industry and the Energy industry have standardized on different subsets of the "AS2 specification". The planned EDIINT/HL7/GISB/AIAG convergence did not happen. If we agree on this, the most important thing is to avoid confusing end users. I'm afraid this latest "change" to AS2 has done more to confuse end users than anything in the recent past. I've had several conversations with people from around the Energy industry regarding this situation, trust me - they are confused by this latest action. It's also worth noting that software vendors can reasonably implement the full range of functionality defined in AS2 to support the UCC and Energy industries. There is nothing preventing vendors from supporting OpenPGP and S/MIME crypto and RFC2388 and AS2/e-mail packaging (using the AS2-From and AS2-To HTTP headers) and the multipart report types defined in MDN and the generalized receipt delivery type defined in AS2. The interoperability issue you describe is "self inflicted" by certain parties that have misled vendors into believing that they only have to support a subset of AS2 to be "certified". The moves by Rik to "clean up" the subset of the AS2 specification used by the UCC was appropriate for that community. There was pressure from end users to move in this direction. So, you're saying it was the UCC end users that wanted the Energy industry portions of AS2 removed. Would it have been acceptable if the Energy industry end users changed AS2 to remove the UCC portions? IMO, Rik did not "clean up" the AS2 specification. He has created a bifurcation of AS2 that virtually guarantees the propagation of interoperability issues. If allowed to continue this will result in separate "specifications", possibly one spec per industry group. If UCC wants to have it's own separate spec then it should consider developing one under it's own process. The IETF process is all about consensus. The Energy and Automotive industries joined in the IETF effort in good faith with the belief that the open consensus process would produce a result that could benefit many parties. But this "AS2 cleanup" removed portions of the specification critical to the Energy industry. Ideally, a parallel AS2 cleanup for the Energy industry would have happened at the same time. I know this is an oversimplification but perhaps Rik should have created an EDIINT(S/MIME) and an EDIINT(PGP/MIME) as children of EDIINT AS2. I favor splitting the old AS2 specification into two separate specifications and accept the v12 draft as one of the specifications. Dick's insinuation that Drummond Test Plans become de-facto standards is correct. Further, the v12 draft modifies the AS2 specification around that test plan. As Dick stated these changes were outside of IETF process. Still, I have no problem with them ... my goal is to meet end user needs and I think the v12 draft is a move in the right direction. It's NOT to late to go through the IETF process?? Let's just view the v12 (Drummond) draft as a proposal and get some input. Those most interested in a v12(GISB) draft should take the lead in its creation ... maybe they keep the v11 draft and require PGP/MIME and S/MIME or maybe they throw out S/MIME. This proposed solution, where two separate specs are created to serve the same purpose, is what you are suggesting to ensure interoperability. I fail to see the logic in this proposal. As I see it your proposal will result in the creation of one specification for the retail industry and another for the energy industry. If Dave Crocker and Jonathan Postel had used this rational back in the 80's when they were working on e-mail you would need to use different e-mail implementations to communicate with different industries today. I for one am glad that there is only one SMTP and addressing standard. I hope others in this community see the same longer term flaws in this proposed "splitting off" of AS2 that I see. Hopefully, EDIINT members will weigh in on: 1 Do you support the spin-off of the AS2 v11 specification into a version focused on UCC (packaged goods) requirements? 2 Should the Energy industry stick with the v11 base or do its own clean up? 3 Do you have an opinion on the names which should be assigned? I believe it would also be beneficial to hear from some experienced IETF folks regarding this proposed split up. Is there a precedence for efforts that split midway through development. If so, what was the outcome? What is the IETF position regarding competing specifications that perform the same function using two different (non-interoperable) approaches? 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:602-684-1484,eFax:240-352-0714 ******************************************************* This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com ******************************************************* Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. ******************************************************* Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. ******************************************************* This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a ******************************************************* ------_=_NextPart_001_01C2BD4F.E2DFD0A0 Content-Type: text/html; charset="iso-8859-1" Message
All,
 
I've long been a participant of this group and rarely provided any input but I have to say that I am deeply concerned about the rift that has just appeared.
 
One could ask what is the point of a independent and global standards body that defines industry centric 'standards'.
 
We certainly have companies that talk across industries (including retail and energy) and to have to use two different standards would be nothing less than ludicrous.
 
Any moves away from a 'global' strategy will surely lay the foundations for failure of EDIINT as a broadly accepted standard. While certain industries have implemented EDIINT already, as they need to expand their data exchange capabilities, they are likely to turn away from anything that does not give them flexibility.
 
All that aside, we tend to consider EDIINT (AS1 & 2) as one package so we might have a competitive edge over suppliers who narrow their options.
 
Regards
Andrew
 
-----Original Message-----
From: Dick Brooks [mailto:dick@tech-comm.com]
Sent: 16 January 2003 05:00
To: Gary Crough; ietf-ediint@imc.org
Subject: RE: Comments on the recent EDIINT AS2 v12 draft

Gary, my comments are inline bounded by <db> and </db>.
 
All,
    There is a subset of AS2 which has gone through formal interoperability trials.  These trails are currently sponsored by the UCC (packaged goods industry) and UCC member companies are major consumers of this software.
    There is also a subset of AS2 (v11 specification) used within the Energy industry.
 
<db> The above statements may lead one to believe that formal interoperability testing has occurred on the UCC subset of AS2 but no interoperability testing, formal or informal, has occurred on the Energy industry's use of AS2. 
Quite the contrary, there are hundreds of interoperable implementations of AS2 operating in production systems within the Energy industry. There are tens of thousands of transactions exchanged daily. These transactions are mission critical,  and are considered part of the critical infrastructure by the United States Federal Government. I don't know what more proof  is needed to demonstrate interoperability of AS2 in the Energy industry than the fact that thousands of transactions are being exchanged daily. .If your gas stove is working and your lights turn on, chances are good the Energy industries use of AS2 is "interoperating" properly.
</db>
 
 
    My belief is: software supporting one AS2 subset is NOT interoperable with software supporting the other subset.  The packaged goods industry and the Energy industry have standardized on different subsets of the "AS2 specification".  The planned EDIINT/HL7/GISB/AIAG convergence did not happen. 
    If we agree on this, the most important thing is to avoid confusing end users.
 
<db>I'm afraid this latest "change" to AS2 has done more to confuse end users than anything in the recent past. I've had several conversations with people from around the Energy industry regarding this situation, trust me - they are confused by this latest action.
It's also worth noting that software vendors can reasonably implement the full range of functionality defined in AS2 to support the UCC and Energy industries.  There is nothing preventing vendors from supporting OpenPGP and S/MIME crypto and RFC2388 and AS2/e-mail packaging (using the AS2-From and AS2-To HTTP headers) and the multipart report types defined in MDN and the generalized receipt delivery type defined in AS2.
The interoperability issue you describe is "self inflicted" by certain parties that have misled vendors into believing that they only have to support a subset of  AS2 to be "certified".
</db>
 
 
    The moves by Rik to "clean up" the subset of the AS2 specification used by the UCC was appropriate for that community.  There was pressure from end users to move in this direction. 
 
<db>So, you're saying it was the UCC end users that wanted the Energy industry portions of AS2 removed. Would it have been acceptable if the Energy industry end users changed AS2 to remove the UCC portions? 
 
IMO, Rik did not "clean up" the AS2 specification. He has created a bifurcation of AS2 that virtually guarantees the propagation of interoperability issues. If allowed to continue this will result in separate "specifications", possibly one spec per industry group. 
 
If UCC wants to have it's own separate spec then it should consider developing one under it's own process. The IETF process is all about consensus. The Energy and Automotive industries joined in the IETF effort in good faith with the belief that the open consensus process would produce a result that could benefit many parties.    
</db>
 
 But this "AS2 cleanup" removed portions of the specification critical to the Energy industry.  Ideally, a parallel AS2 cleanup for the Energy industry would have happened at the same time.  I know this is an oversimplification but perhaps Rik should have created an EDIINT(S/MIME) and an EDIINT(PGP/MIME) as children of EDIINT AS2. 
 
    I favor splitting the old AS2 specification into two separate specifications and accept the v12 draft as one of the specifications. 
    Dick's insinuation that Drummond Test Plans become de-facto standards is correct.  Further, the v12 draft modifies the AS2 specification around that test plan.  As Dick stated these changes were outside of IETF process.  Still, I have no problem with them ... my goal is to meet end user needs and I think the v12 draft is a move in the right direction.  It's NOT to late to go through the IETF process??   Let's just view the v12 (Drummond) draft as a proposal and get some input.  Those most interested in a v12(GISB) draft should take the lead in its creation ... maybe they keep the v11 draft and require PGP/MIME and S/MIME or maybe they throw out S/MIME.
 
<db>This proposed solution, where two separate specs are created to serve the same purpose, is what you are suggesting to ensure interoperability. I fail to see the logic in this proposal. 
As I see it your proposal will result in the creation of  one specification for the retail industry and another for the energy industry. If Dave Crocker and Jonathan Postel had used this rational back in the 80's when they were working on e-mail you would need to use different e-mail implementations to communicate with different industries today. I for one am glad that there is only one SMTP and addressing standard.
 
I hope others in this community see the same longer term flaws in this proposed "splitting off" of AS2 that I see.  
</db>
 
   
    Hopefully, EDIINT members will weigh in on:
1    Do you support the spin-off of the AS2 v11 specification into a version focused on UCC (packaged goods) requirements?
2    Should the Energy industry stick with the v11 base or do its own clean up?
3    Do you have an opinion on the names which should be assigned?

<db>I believe it would also be beneficial to hear from some experienced IETF folks regarding this proposed split up. Is there a precedence for efforts that split midway through development. If so, what was the outcome? What is the IETF position regarding competing specifications that perform the same function using two different (non-interoperable) approaches?

</db>

 

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:602-684-1484,eFax:240-352-0714
 


*******************************************************

This email has originated from Perwill plc (Registration No. 1906964)

Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK

Tel: +44 (0)1420 545000

Fax: +44 (0)1420 545001

www.perwill.com

*******************************************************

Privileged, confidential and/or copyright information may be contained

in this email, and is only for the use of the intended addressee.

To copy, forward, disclose or otherwise use it in any way if you are not

the intended recipient or responsible for delivering to him/her is prohibited.

If you receive this email by mistake, please advise the sender immediately,

by using the reply facility in your email software.


We may monitor the content of emails sent and received via our network

for the purposes of ensuring compliance with policies and procedures.

This message is subject to and does not create or vary any contractual

relationships between Perwill plc and the recipient.

*******************************************************

Any opinions expressed in the email are those of the sender and not

necessarily of Perwill plc.

*******************************************************

This email has been scanned for known viruses using

McAfee WebShield 4.5 MR1a

*******************************************************



------_=_NextPart_001_01C2BD4F.E2DFD0A0-- From owner-ietf-ediint@mail.imc.org Thu Jan 16 09:04:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11305 for ; Thu, 16 Jan 2003 09:04:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GDqJS22570 for ietf-ediint-bks; Thu, 16 Jan 2003 05:52:19 -0800 (PST) Received: from localhost.conedmtce.com (localhost.conedmtce.com [158.57.150.68] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h0GDqHo22565 for ; Thu, 16 Jan 2003 05:52:18 -0800 (PST) Received: from no.name.available by localhost.conedmtce.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Jan 2003 13:52:19 UT Received: from M020EX11.conedison.net ([158.57.159.124]) by m020exg2.conedison.net with Microsoft SMTPSVC(5.0.2195.3779); Thu, 16 Jan 2003 08:52:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD66.7B762091" Subject: RE: Comments on the recent EDIINT AS2 v12 draft Date: Thu, 16 Jan 2003 08:52:17 -0500 Message-ID: <790BF29993CD42498A0015E82F1E3C426E2250@M020EX11.conedison.net> Thread-Topic: Comments on the recent EDIINT AS2 v12 draft Thread-Index: AcK9VScY+uHJ2iBMSjKkk64uCXbG0QADzgZQ From: "Costa, Michael J." To: "Andrew Stickland" , X-OriginalArrivalTime: 16 Jan 2003 13:52:18.0328 (UTC) FILETIME=[7BEDA180:01C2BD66] 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_001_01C2BD66.7B762091 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 Mr.. Strickland makes the following point is his note. =20 "We certainly have companies that talk across industries (including = retail and energy) and to have to use two different standards would be = nothing less than ludicrous." =20 A very accurate point. As I utility I exchange data with retail chains, = educational institutions, government agencies, etc. By definition = doesn't a standard imply that we "should" all operate the same way? I do = not in anyway want to support two differing standards to accomplish the = same end result.=20 =20 Dick's comment that the energy industry is confused is a little bit of = an understatement. To be somewhat more accurate, we are confused and = angry! We are all spending a great deal of money to comply with orders = from our local commissions and we wonder how much of that money will = need to be spent again? =20 We need to find a middle ground and we need to find it soon. =20 My humble opinion for what it is worth... =20 ____________________________________________________=20 Michael Costa=20 Systems Specialist=20 IR -Network Systems=20 Mail To: costam@coned.com=20 Voice Mail: 212.460.2994=20 Pager: 917.360.3197=20 =20 =20 =20 =20 -----Original Message----- From: Andrew Stickland [mailto:Andrew.Stickland@perwill.com] Sent: Thursday, January 16, 2003 6:11 AM To: ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft All, =20 I've long been a participant of this group and rarely provided any input = but I have to say that I am deeply concerned about the rift that has = just appeared.=20 =20 One could ask what is the point of a independent and global standards = body that defines industry centric 'standards'.=20 =20 We certainly have companies that talk across industries (including = retail and energy) and to have to use two different standards would be = nothing less than ludicrous. =20 Any moves away from a 'global' strategy will surely lay the foundations = for failure of EDIINT as a broadly accepted standard. While certain = industries have implemented EDIINT already, as they need to expand their = data exchange capabilities, they are likely to turn away from anything = that does not give them flexibility. =20 All that aside, we tend to consider EDIINT (AS1 & 2) as one package so = we might have a competitive edge over suppliers who narrow their = options. =20 Regards=20 Andrew=20 =20 -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: 16 January 2003 05:00 To: Gary Crough; ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft Gary, my comments are inline bounded by and . =20 All, There is a subset of AS2 which has gone through formal = interoperability trials. These trails are currently sponsored by the = UCC (packaged goods industry) and UCC member companies are major = consumers of this software. There is also a subset of AS2 (v11 specification) used within the = Energy industry. =20 The above statements may lead one to believe that formal = interoperability testing has occurred on the UCC subset of AS2 but no = interoperability testing, formal or informal, has occurred on the Energy = industry's use of AS2.=20 Quite the contrary, there are hundreds of interoperable implementations = of AS2 operating in production systems within the Energy industry. There = are tens of thousands of transactions exchanged daily. These = transactions are mission critical, and are considered part of the = critical infrastructure by the United States Federal Government. I don't = know what more proof is needed to demonstrate interoperability of AS2 = in the Energy industry than the fact that thousands of transactions are = being exchanged daily. .If your gas stove is working and your lights = turn on, chances are good the Energy industries use of AS2 is = "interoperating" properly. =20 =20 My belief is: software supporting one AS2 subset is NOT = interoperable with software supporting the other subset. The packaged = goods industry and the Energy industry have standardized on different = subsets of the "AS2 specification". The planned EDIINT/HL7/GISB/AIAG = convergence did not happen. =20 If we agree on this, the most important thing is to avoid confusing = end users. =20 I'm afraid this latest "change" to AS2 has done more to confuse end = users than anything in the recent past. I've had several conversations = with people from around the Energy industry regarding this situation, = trust me - they are confused by this latest action. It's also worth noting that software vendors can reasonably implement = the full range of functionality defined in AS2 to support the UCC and = Energy industries. There is nothing preventing vendors from supporting = OpenPGP and S/MIME crypto and RFC2388 and AS2/e-mail packaging (using = the AS2-From and AS2-To HTTP headers) and the multipart report types = defined in MDN and the generalized receipt delivery type defined in AS2. The interoperability issue you describe is "self inflicted" by certain = parties that have misled vendors into believing that they only have to = support a subset of AS2 to be "certified". =20 =20 The moves by Rik to "clean up" the subset of the AS2 specification = used by the UCC was appropriate for that community. There was pressure = from end users to move in this direction.=20 =20 So, you're saying it was the UCC end users that wanted the Energy = industry portions of AS2 removed. Would it have been acceptable if the = Energy industry end users changed AS2 to remove the UCC portions?=20 =20 IMO, Rik did not "clean up" the AS2 specification. He has created a = bifurcation of AS2 that virtually guarantees the propagation of = interoperability issues. If allowed to continue this will result in = separate "specifications", possibly one spec per industry group.=20 =20 If UCC wants to have it's own separate spec then it should consider = developing one under it's own process. The IETF process is all about = consensus. The Energy and Automotive industries joined in the IETF = effort in good faith with the belief that the open consensus process = would produce a result that could benefit many parties. =20 =20 But this "AS2 cleanup" removed portions of the specification critical = to the Energy industry. Ideally, a parallel AS2 cleanup for the Energy = industry would have happened at the same time. I know this is an = oversimplification but perhaps Rik should have created an EDIINT(S/MIME) = and an EDIINT(PGP/MIME) as children of EDIINT AS2. =20 =20 I favor splitting the old AS2 specification into two separate = specifications and accept the v12 draft as one of the specifications. =20 Dick's insinuation that Drummond Test Plans become de-facto = standards is correct. Further, the v12 draft modifies the AS2 = specification around that test plan. As Dick stated these changes were = outside of IETF process. Still, I have no problem with them ... my goal = is to meet end user needs and I think the v12 draft is a move in the = right direction. It's NOT to late to go through the IETF process?? = Let's just view the v12 (Drummond) draft as a proposal and get some = input. Those most interested in a v12(GISB) draft should take the lead = in its creation ... maybe they keep the v11 draft and require PGP/MIME = and S/MIME or maybe they throw out S/MIME. =20 This proposed solution, where two separate specs are created to = serve the same purpose, is what you are suggesting to ensure = interoperability. I fail to see the logic in this proposal.=20 As I see it your proposal will result in the creation of one = specification for the retail industry and another for the energy = industry. If Dave Crocker and Jonathan Postel had used this rational = back in the 80's when they were working on e-mail you would need to use = different e-mail implementations to communicate with different = industries today. I for one am glad that there is only one SMTP and = addressing standard. =20 I hope others in this community see the same longer term flaws in this = proposed "splitting off" of AS2 that I see. =20 =20 =20 Hopefully, EDIINT members will weigh in on: 1 Do you support the spin-off of the AS2 v11 specification into a = version focused on UCC (packaged goods) requirements? 2 Should the Energy industry stick with the v11 base or do its own = clean up? 3 Do you have an opinion on the names which should be assigned? I believe it would also be beneficial to hear from some experienced = IETF folks regarding this proposed split up. Is there a precedence for = efforts that split midway through development. If so, what was the = outcome? What is the IETF position regarding competing specifications = that perform the same function using two different (non-interoperable) = approaches?=20 =20 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:602-684-1484,eFax:240-352-0714 =20 *******************************************************=20 This email has originated from Perwill plc (Registration No. 1906964)=20 Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK=20 Tel: +44 (0)1420 545000=20 Fax: +44 (0)1420 545001=20 www.perwill.com=20 *******************************************************=20 Privileged, confidential and/or copyright information may be contained=20 in this email, and is only for the use of the intended addressee.=20 To copy, forward, disclose or otherwise use it in any way if you are not = the intended recipient or responsible for delivering to him/her is = prohibited. If you receive this email by mistake, please advise the sender = immediately,=20 by using the reply facility in your email software. We may monitor the content of emails sent and received via our network=20 for the purposes of ensuring compliance with policies and procedures.=20 This message is subject to and does not create or vary any contractual=20 relationships between Perwill plc and the recipient.=20 *******************************************************=20 Any opinions expressed in the email are those of the sender and not=20 necessarily of Perwill plc. *******************************************************=20 This email has been scanned for known viruses using=20 McAfee WebShield 4.5 MR1a=20 *******************************************************=20 ------_=_NextPart_001_01C2BD66.7B762091 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Message
 
Mr..=20 Strickland makes the following point is his note.
 
"We certainly have companies that talk = across=20 industries (including retail and energy) and to have to use two = different=20 standards would be nothing less than ludicrous."
 
A very accurate point. As I utility I = exchange data=20 with retail chains, educational institutions, government agencies, etc. = By=20 definition doesn't a standard imply that we "should" all operate the = same way? I=20 do not in anyway want to support two differing standards to accomplish = the same=20 end result.
 
Dick's comment that the energy industry is = confused is=20 a little bit of an understatement. To be somewhat more accurate, we are = confused=20 and angry!  We are all spending a great deal of money to comply = with orders=20 from our local commissions and we wonder how much of that money will = need to be=20 spent again?
 
We need to find a middle ground and we need = to find it=20 soon.
 
My humble opinion for what it is=20 worth...
 

____________________________________________________ =
Michael Costa
Systems Specialist =
IR -Network = Systems

Mail To: costam@coned.com =
Voice Mail: 212.460.2994
Pager: 917.360.3197=20

 
 
 
 
-----Original Message-----
From: Andrew Stickland=20 [mailto:Andrew.Stickland@perwill.com]
Sent: Thursday, = January 16,=20 2003 6:11 AM
To: ietf-ediint@imc.org
Subject: RE: = Comments=20 on the recent EDIINT AS2 v12 draft

All,
 
I've = long been a=20 participant of this group and rarely provided any input but I have to = say that=20 I am=20 deeply concerned about the rift that has just appeared. =
 
One = could ask what=20 is the point of a independent and global standards body that defines = industry=20 centric 'standards'.
 
We = certainly have=20 companies that talk across industries (including retail and energy) = and to=20 have to use two different standards would be nothing less than=20 ludicrous.
 
Any = moves away=20 from a 'global' strategy will surely lay the foundations for failure = of EDIINT=20 as a broadly accepted standard. While certain industries have = implemented=20 EDIINT already, as they need to expand their data exchange = capabilities, they=20 are likely to turn away from anything that does not give them=20 flexibility.
 
All = that aside, we=20 tend to consider EDIINT (AS1 & 2) as one package so we might have = a=20 competitive edge over suppliers who narrow their = options.
 
Regards=20
Andrew
 
-----Original Message-----
From: Dick Brooks=20 [mailto:dick@tech-comm.com]
Sent: 16 January 2003=20 05:00
To: Gary Crough; = ietf-ediint@imc.org
Subject: RE:=20 Comments on the recent EDIINT AS2 v12 draft

Gary, my comments are inline bounded by <db> and=20 </db>.
 
All,
    There is a subset of AS2 = which has=20 gone through formal interoperability trials.  These trails are = currently=20 sponsored by the UCC (packaged goods industry) and UCC member = companies=20 are major consumers of this software.
    There is also a subset = of AS2 (v11=20 specification) used within the Energy = industry.
 
<db> = The above=20 statements may lead one to believe that formal interoperability = testing has=20 occurred on the UCC subset of AS2 but no interoperability testing, = formal or=20 informal, has occurred on the Energy industry's use of=20 AS2. 
Quite the = contrary,=20 there are hundreds of interoperable implementations of AS2 operating = in=20 production systems within the Energy industry. There are = tens of=20 thousands of transactions exchanged daily. These = transactions are=20 mission critical,  and are considered part of the critical=20 infrastructure by the United States Federal Government. I don't = know=20 what more proof  is needed to demonstrate interoperability = of AS2 in=20 the Energy industry than the fact that thousands of transactions are = being=20 exchanged daily. .If your gas stove is working and = your lights turn=20 on, chances are good the Energy industries use of AS2 is = "interoperating"=20 properly.
</db>
 
 
    My belief is: software = supporting=20 one AS2 subset is NOT interoperable with software supporting the = other=20 subset.  The packaged goods industry and the Energy industry have = standardized on different subsets of the "AS2 specification".  = The=20 planned EDIINT/HL7/GISB/AIAG convergence did not happen. =20
    If we agree on this,=20 the most important thing is to avoid confusing end=20 users.
 
<db>I'm afraid=20 this latest "change" to AS2 has done more to confuse end users than = anything=20 in the recent past. I've had several conversations with people from = around the=20 Energy industry regarding this situation, trust me - they are confused = by this=20 latest action.
It's also = worth noting=20 that software vendors can reasonably implement the full range of = functionality=20 defined in AS2 to support the UCC and Energy industries.  There = is=20 nothing preventing vendors from supporting OpenPGP and S/MIME crypto = and=20 RFC2388 and AS2/e-mail packaging (using the AS2-From and AS2-To HTTP = headers)=20 and the multipart report types defined in MDN and the generalized = receipt=20 delivery type defined in AS2.
The = interoperability=20 issue you describe is "self inflicted" by certain parties that have = misled=20 vendors into believing that they only have to support a subset of =  AS2 to be "certified".
</db>
 
 
    The moves by Rik to "clean up" the = subset of the AS2=20 specification used by the UCC was appropriate for that=20 community.  There was pressure from end users to move in = this=20 direction. 
 
<db>So, you're=20 saying it was the UCC end users that wanted the Energy industry = portions of=20 AS2 removed. Would it have been acceptable if the Energy industry = end=20 users changed AS2 to remove the UCC = portions? 
 
IMO, Rik = did not=20 "clean up" the AS2 specification. He has created a bifurcation of AS2 = that=20 virtually guarantees the propagation of interoperability = issues. If=20 allowed to continue this will result in separate "specifications", = possibly=20 one spec per industry group. 
 
If UCC = wants to have=20 it's own separate spec then it should consider developing one = under it's=20 own process. The IETF process is all about = consensus. The=20 Energy and Automotive industries joined in the IETF effort in = good faith=20 with the belief that the open consensus process would produce a result = that could benefit many=20 parties.    
</db>
 
 But this "AS2 cleanup" removed = portions of=20 the specification critical to the Energy industry.  Ideally, a = parallel=20 AS2 cleanup for the Energy industry would have happened at the same=20 time.  I know this is an oversimplification but perhaps Rik=20 should have created an EDIINT(S/MIME) and an EDIINT(PGP/MIME) as = children=20 of EDIINT AS2. 
 
    I favor splitting the = old AS2=20 specification into two separate specifications and accept the v12 = draft as one=20 of the specifications. 
   =20 Dick's insinuation that Drummond Test=20 Plans become de-facto standards is correct.  = Further, the=20 v12 draft modifies the AS2 specification around that test plan.  = As Dick=20 stated these changes were outside of IETF process.  = Still, I=20 have no problem with them ... my goal is to meet end user needs = and I=20 think the v12 draft is a move in the right direction.  = It's NOT to=20 late to go through the IETF process??   Let's just view the = v12=20 (Drummond) draft as a proposal and get some input.  Those most = interested=20 in a v12(GISB) draft should take the lead in its creation ... maybe = they keep=20 the v11 draft and require PGP/MIME and S/MIME or maybe they throw out=20 S/MIME.
 
<db>This=20 proposed solution, where two separate specs are created to serve=20 the same purpose, is what you are suggesting to ensure=20 interoperability. I fail to see the logic in this=20 proposal. 
As I see = it your=20 proposal will result in the creation of  one specification = for the=20 retail industry and another for the energy industry. If Dave Crocker = and=20 Jonathan Postel had used this rational back in the 80's when they = were=20 working on e-mail you would need to use different e-mail = implementations=20 to communicate with different industries today. I for one am = glad=20 that there is only one SMTP and addressing=20 standard.
 
I = hope others in=20 this community see the same longer term flaws in this proposed = "splitting=20 off" of AS2 that I see.  
</db>
 
   
    Hopefully, EDIINT = members will=20 weigh in on:
1    Do you support the = spin-off of=20 the AS2 v11 specification into a version focused on UCC (packaged = goods)=20 requirements?
2    Should the Energy = industry=20 stick with the v11 base or do its own clean up?
3    Do you have an opinion = on the=20 names which should be assigned?

<db>I believe = it would=20 also be beneficial to hear from some experienced IETF folks = regarding=20 this proposed split up. Is there a precedence for efforts that split = midway=20 through development. If so, what was the outcome? What is the IETF = position=20 regarding competing specifications that perform the same function = using two=20 different (non-interoperable) approaches?

</db>

 

Dick Brooks
Systrends, Inc
7855 South River = Parkway,=20 Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mo= bile:602-684-1484,eFax:240-352-0714
 =20


******************************************************* =

This email has originated from Perwill = plc=20 (Registration No. 1906964)

Office registered at: 13A Market = Square, Alton,=20 Hampshire, GU34 1UR, UK

Tel: +44 (0)1420 545000

Fax: +44 (0)1420 545001

www.perwill.com

******************************************************* =

Privileged, confidential and/or = copyright=20 information may be contained

in this email, and is only for the use = of the=20 intended addressee.

To copy, forward, disclose or otherwise = use it in=20 any way if you are not

the intended recipient or responsible = for=20 delivering to him/her is prohibited.

If you receive this email by mistake, = please advise=20 the sender immediately,

by using the reply facility in your = email=20 software.


We may monitor the content of emails = sent and=20 received via our network

for the purposes of ensuring compliance = with=20 policies and procedures.

This message is subject to and does not = create or=20 vary any contractual

relationships between Perwill plc and = the=20 recipient.

******************************************************* =

Any opinions expressed in the email are = those of=20 the sender and not

necessarily of Perwill plc.

******************************************************* =

This email has been scanned for known = viruses using=20

McAfee WebShield 4.5 MR1a

*******************************************************=20



------_=_NextPart_001_01C2BD66.7B762091-- From owner-ietf-ediint@mail.imc.org Thu Jan 16 10:07:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13274 for ; Thu, 16 Jan 2003 10:07:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GEqGA26862 for ietf-ediint-bks; Thu, 16 Jan 2003 06:52:16 -0800 (PST) Received: from mail.meijer.com (mail.meijer.com [204.74.160.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0GEqEo26858 for ; Thu, 16 Jan 2003 06:52:14 -0800 (PST) Received: from meijer-fw1 (meijer-fw1 [204.74.160.249]) by mail.meijer.com (8.11.6/8.11.4) with SMTP id h0GEqAR232590 for ; Thu, 16 Jan 2003 09:52:10 -0500 Received: from ngwias01 ([10.1.202.45]) by meijer-fw1; Thu, 16 Jan 2003 09:48:28 -0500 (EST) Received: from MJR_Route-Message_Server by meijer.com with Novell_GroupWise; Thu, 16 Jan 2003 09:52:09 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 16 Jan 2003 09:51:58 -0500 From: "Steve Lowery" To: , , Subject: RE: Comments on the recent EDIINT AS2 v12 draft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0GEqFo26859 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I have to agree with Michael and Andrew on this point. Having "standards" split into 2 or 3 different subsets gets confusing and messy and costly. Working in the retail industry and EDI I see this mess with X12 standards and it's children VICS and UCS. We have to use UCS for our grocery suppliers, VICS for general merch and X12 for carriers Having to maintain multiple sets of standards is very messy and costly >>> "Costa, Michael J." 01/16/03 08:52AM >>> Mr.. Strickland makes the following point is his note. "We certainly have companies that talk across industries (including retail and energy) and to have to use two different standards would be nothing less than ludicrous." A very accurate point. As I utility I exchange data with retail chains, educational institutions, government agencies, etc. By definition doesn't a standard imply that we "should" all operate the same way? I do not in anyway want to support two differing standards to accomplish the same end result. Dick's comment that the energy industry is confused is a little bit of an understatement. To be somewhat more accurate, we are confused and angry! We are all spending a great deal of money to comply with orders from our local commissions and we wonder how much of that money will need to be spent again? We need to find a middle ground and we need to find it soon. My humble opinion for what it is worth... ____________________________________________________ Michael Costa Systems Specialist IR -Network Systems Mail To: costam@coned.com Voice Mail: 212.460.2994 Pager: 917.360.3197 -----Original Message----- From: Andrew Stickland [mailto:Andrew.Stickland@perwill.com] Sent: Thursday, January 16, 2003 6:11 AM To: ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft All, I've long been a participant of this group and rarely provided any input but I have to say that I am deeply concerned about the rift that has just appeared. One could ask what is the point of a independent and global standards body that defines industry centric 'standards'. We certainly have companies that talk across industries (including retail and energy) and to have to use two different standards would be nothing less than ludicrous. Any moves away from a 'global' strategy will surely lay the foundations for failure of EDIINT as a broadly accepted standard. While certain industries have implemented EDIINT already, as they need to expand their data exchange capabilities, they are likely to turn away from anything that does not give them flexibility. All that aside, we tend to consider EDIINT (AS1 & 2) as one package so we might have a competitive edge over suppliers who narrow their options. Regards Andrew -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: 16 January 2003 05:00 To: Gary Crough; ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft Gary, my comments are inline bounded by and . All, There is a subset of AS2 which has gone through formal interoperability trials. These trails are currently sponsored by the UCC (packaged goods industry) and UCC member companies are major consumers of this software. There is also a subset of AS2 (v11 specification) used within the Energy industry. The above statements may lead one to believe that formal interoperability testing has occurred on the UCC subset of AS2 but no interoperability testing, formal or informal, has occurred on the Energy industry's use of AS2. Quite the contrary, there are hundreds of interoperable implementations of AS2 operating in production systems within the Energy industry. There are tens of thousands of transactions exchanged daily. These transactions are mission critical, and are considered part of the critical infrastructure by the United States Federal Government. I don't know what more proof is needed to demonstrate interoperability of AS2 in the Energy industry than the fact that thousands of transactions are being exchanged daily. .If your gas stove is working and your lights turn on, chances are good the Energy industries use of AS2 is "interoperating" properly. My belief is: software supporting one AS2 subset is NOT interoperable with software supporting the other subset. The packaged goods industry and the Energy industry have standardized on different subsets of the "AS2 specification". The planned EDIINT/HL7/GISB/AIAG convergence did not happen. If we agree on this, the most important thing is to avoid confusing end users. I'm afraid this latest "change" to AS2 has done more to confuse end users than anything in the recent past. I've had several conversations with people from around the Energy industry regarding this situation, trust me - they are confused by this latest action. It's also worth noting that software vendors can reasonably implement the full range of functionality defined in AS2 to support the UCC and Energy industries. There is nothing preventing vendors from supporting OpenPGP and S/MIME crypto and RFC2388 and AS2/e-mail packaging (using the AS2-From and AS2-To HTTP headers) and the multipart report types defined in MDN and the generalized receipt delivery type defined in AS2. The interoperability issue you describe is "self inflicted" by certain parties that have misled vendors into believing that they only have to support a subset of AS2 to be "certified". The moves by Rik to "clean up" the subset of the AS2 specification used by the UCC was appropriate for that community. There was pressure from end users to move in this direction. So, you're saying it was the UCC end users that wanted the Energy industry portions of AS2 removed. Would it have been acceptable if the Energy industry end users changed AS2 to remove the UCC portions? IMO, Rik did not "clean up" the AS2 specification. He has created a bifurcation of AS2 that virtually guarantees the propagation of interoperability issues. If allowed to continue this will result in separate "specifications", possibly one spec per industry group. If UCC wants to have it's own separate spec then it should consider developing one under it's own process. The IETF process is all about consensus. The Energy and Automotive industries joined in the IETF effort in good faith with the belief that the open consensus process would produce a result that could benefit many parties. But this "AS2 cleanup" removed portions of the specification critical to the Energy industry. Ideally, a parallel AS2 cleanup for the Energy industry would have happened at the same time. I know this is an oversimplification but perhaps Rik should have created an EDIINT(S/MIME) and an EDIINT(PGP/MIME) as children of EDIINT AS2. I favor splitting the old AS2 specification into two separate specifications and accept the v12 draft as one of the specifications. Dick's insinuation that Drummond Test Plans become de-facto standards is correct. Further, the v12 draft modifies the AS2 specification around that test plan. As Dick stated these changes were outside of IETF process. Still, I have no problem with them ... my goal is to meet end user needs and I think the v12 draft is a move in the right direction. It's NOT to late to go through the IETF process?? Let's just view the v12 (Drummond) draft as a proposal and get some input. Those most interested in a v12(GISB) draft should take the lead in its creation ... maybe they keep the v11 draft and require PGP/MIME and S/MIME or maybe they throw out S/MIME. This proposed solution, where two separate specs are created to serve the same purpose, is what you are suggesting to ensure interoperability. I fail to see the logic in this proposal. As I see it your proposal will result in the creation of one specification for the retail industry and another for the energy industry. If Dave Crocker and Jonathan Postel had used this rational back in the 80's when they were working on e-mail you would need to use different e-mail implementations to communicate with different industries today. I for one am glad that there is only one SMTP and addressing standard. I hope others in this community see the same longer term flaws in this proposed "splitting off" of AS2 that I see. Hopefully, EDIINT members will weigh in on: 1 Do you support the spin-off of the AS2 v11 specification into a version focused on UCC (packaged goods) requirements? 2 Should the Energy industry stick with the v11 base or do its own clean up? 3 Do you have an opinion on the names which should be assigned? I believe it would also be beneficial to hear from some experienced IETF folks regarding this proposed split up. Is there a precedence for efforts that split midway through development. If so, what was the outcome? What is the IETF position regarding competing specifications that perform the same function using two different (non-interoperable) approaches? 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:602-684-1484,eFax:240-352-0714 ******************************************************* This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com ******************************************************* Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. ******************************************************* Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. ******************************************************* This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a ******************************************************* From owner-ietf-ediint@mail.imc.org Thu Jan 16 11:38:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15603 for ; Thu, 16 Jan 2003 11:38:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GGSeQ01661 for ietf-ediint-bks; Thu, 16 Jan 2003 08:28:40 -0800 (PST) Received: from smtp01.ibpmail.net (smtp01.ibpmail.net [194.151.203.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0GGSco01657 for ; Thu, 16 Jan 2003 08:28:38 -0800 (PST) Received: from ibp-nplex.ibpmail.net (194.151.203.161) by smtp01.ibpmail.net (6.7.015) id 3E06FDC0002A29B9; Thu, 16 Jan 2003 17:28:10 +0100 Received: from TORZEWW02 (65.204.33.254) by ibp-nplex.ibpmail.net (6.7.014) id 3DE9F2810060DA06; Thu, 16 Jan 2003 17:28:12 +0100 Reply-To: From: "wayne mackintosh" To: "'Steve Lowery'" , Subject: RE: Comments on the recent EDIINT AS2 v12 draft Date: Thu, 16 Jan 2003 11:27:59 -0500 Message-ID: <000c01c2bd7c$3c7e9c00$b714030a@TORZEWW02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit As a third party logistics provider, we also have to support multiple standards. this is indeed most complex at the best of times. An all-inclusive format, as opposed to industry-specific, would be far more desirable and attractive to prospectives when entering into discussions of migration. Wayne Mackintosh Systems Specialist/EDI Information Systems Group KN Logistics - Brampton ------------------------------- Direct Dial: 905.799.5605 Switchboard: 905.791.6661 #2905 Facsimile: 905.791.4436 Please note new e-mail address: ------------------------------------------------------- mailto:wayne.mackintosh@kuehne-nagel.com ------------------------------------------------------- Thank-You. -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Steve Lowery Sent: January 16, 2003 09:52 To: CostaM@coned.com; ietf-ediint@imc.org; Andrew.Stickland@perwill.com Subject: RE: Comments on the recent EDIINT AS2 v12 draft I have to agree with Michael and Andrew on this point. Having "standards" split into 2 or 3 different subsets gets confusing and messy and costly. Working in the retail industry and EDI I see this mess with X12 standards and it's children VICS and UCS. We have to use UCS for our grocery suppliers, VICS for general merch and X12 for carriers Having to maintain multiple sets of standards is very messy and costly >>> "Costa, Michael J." 01/16/03 08:52AM >>> Mr.. Strickland makes the following point is his note. "We certainly have companies that talk across industries (including retail and energy) and to have to use two different standards would be nothing less than ludicrous." A very accurate point. As I utility I exchange data with retail chains, educational institutions, government agencies, etc. By definition doesn't a standard imply that we "should" all operate the same way? I do not in anyway want to support two differing standards to accomplish the same end result. Dick's comment that the energy industry is confused is a little bit of an understatement. To be somewhat more accurate, we are confused and angry! We are all spending a great deal of money to comply with orders from our local commissions and we wonder how much of that money will need to be spent again? We need to find a middle ground and we need to find it soon. My humble opinion for what it is worth... ____________________________________________________ Michael Costa Systems Specialist IR -Network Systems Mail To: costam@coned.com Voice Mail: 212.460.2994 Pager: 917.360.3197 -----Original Message----- From: Andrew Stickland [mailto:Andrew.Stickland@perwill.com] Sent: Thursday, January 16, 2003 6:11 AM To: ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft All, I've long been a participant of this group and rarely provided any input but I have to say that I am deeply concerned about the rift that has just appeared. One could ask what is the point of a independent and global standards body that defines industry centric 'standards'. We certainly have companies that talk across industries (including retail and energy) and to have to use two different standards would be nothing less than ludicrous. Any moves away from a 'global' strategy will surely lay the foundations for failure of EDIINT as a broadly accepted standard. While certain industries have implemented EDIINT already, as they need to expand their data exchange capabilities, they are likely to turn away from anything that does not give them flexibility. All that aside, we tend to consider EDIINT (AS1 & 2) as one package so we might have a competitive edge over suppliers who narrow their options. Regards Andrew -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: 16 January 2003 05:00 To: Gary Crough; ietf-ediint@imc.org Subject: RE: Comments on the recent EDIINT AS2 v12 draft Gary, my comments are inline bounded by and . All, There is a subset of AS2 which has gone through formal interoperability trials. These trails are currently sponsored by the UCC (packaged goods industry) and UCC member companies are major consumers of this software. There is also a subset of AS2 (v11 specification) used within the Energy industry. The above statements may lead one to believe that formal interoperability testing has occurred on the UCC subset of AS2 but no interoperability testing, formal or informal, has occurred on the Energy industry's use of AS2. Quite the contrary, there are hundreds of interoperable implementations of AS2 operating in production systems within the Energy industry. There are tens of thousands of transactions exchanged daily. These transactions are mission critical, and are considered part of the critical infrastructure by the United States Federal Government. I don't know what more proof is needed to demonstrate interoperability of AS2 in the Energy industry than the fact that thousands of transactions are being exchanged daily. .If your gas stove is working and your lights turn on, chances are good the Energy industries use of AS2 is "interoperating" properly. My belief is: software supporting one AS2 subset is NOT interoperable with software supporting the other subset. The packaged goods industry and the Energy industry have standardized on different subsets of the "AS2 specification". The planned EDIINT/HL7/GISB/AIAG convergence did not happen. If we agree on this, the most important thing is to avoid confusing end users. I'm afraid this latest "change" to AS2 has done more to confuse end users than anything in the recent past. I've had several conversations with people from around the Energy industry regarding this situation, trust me - they are confused by this latest action. It's also worth noting that software vendors can reasonably implement the full range of functionality defined in AS2 to support the UCC and Energy industries. There is nothing preventing vendors from supporting OpenPGP and S/MIME crypto and RFC2388 and AS2/e-mail packaging (using the AS2-From and AS2-To HTTP headers) and the multipart report types defined in MDN and the generalized receipt delivery type defined in AS2. The interoperability issue you describe is "self inflicted" by certain parties that have misled vendors into believing that they only have to support a subset of AS2 to be "certified". The moves by Rik to "clean up" the subset of the AS2 specification used by the UCC was appropriate for that community. There was pressure from end users to move in this direction. So, you're saying it was the UCC end users that wanted the Energy industry portions of AS2 removed. Would it have been acceptable if the Energy industry end users changed AS2 to remove the UCC portions? IMO, Rik did not "clean up" the AS2 specification. He has created a bifurcation of AS2 that virtually guarantees the propagation of interoperability issues. If allowed to continue this will result in separate "specifications", possibly one spec per industry group. If UCC wants to have it's own separate spec then it should consider developing one under it's own process. The IETF process is all about consensus. The Energy and Automotive industries joined in the IETF effort in good faith with the belief that the open consensus process would produce a result that could benefit many parties. But this "AS2 cleanup" removed portions of the specification critical to the Energy industry. Ideally, a parallel AS2 cleanup for the Energy industry would have happened at the same time. I know this is an oversimplification but perhaps Rik should have created an EDIINT(S/MIME) and an EDIINT(PGP/MIME) as children of EDIINT AS2. I favor splitting the old AS2 specification into two separate specifications and accept the v12 draft as one of the specifications. Dick's insinuation that Drummond Test Plans become de-facto standards is correct. Further, the v12 draft modifies the AS2 specification around that test plan. As Dick stated these changes were outside of IETF process. Still, I have no problem with them ... my goal is to meet end user needs and I think the v12 draft is a move in the right direction. It's NOT to late to go through the IETF process?? Let's just view the v12 (Drummond) draft as a proposal and get some input. Those most interested in a v12(GISB) draft should take the lead in its creation ... maybe they keep the v11 draft and require PGP/MIME and S/MIME or maybe they throw out S/MIME. This proposed solution, where two separate specs are created to serve the same purpose, is what you are suggesting to ensure interoperability. I fail to see the logic in this proposal. As I see it your proposal will result in the creation of one specification for the retail industry and another for the energy industry. If Dave Crocker and Jonathan Postel had used this rational back in the 80's when they were working on e-mail you would need to use different e-mail implementations to communicate with different industries today. I for one am glad that there is only one SMTP and addressing standard. I hope others in this community see the same longer term flaws in this proposed "splitting off" of AS2 that I see. Hopefully, EDIINT members will weigh in on: 1 Do you support the spin-off of the AS2 v11 specification into a version focused on UCC (packaged goods) requirements? 2 Should the Energy industry stick with the v11 base or do its own clean up? 3 Do you have an opinion on the names which should be assigned? I believe it would also be beneficial to hear from some experienced IETF folks regarding this proposed split up. Is there a precedence for efforts that split midway through development. If so, what was the outcome? What is the IETF position regarding competing specifications that perform the same function using two different (non-interoperable) approaches? 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:602-684-1484,eFax:240-352-0714 ******************************************************* This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com ******************************************************* Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. ******************************************************* Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. ******************************************************* This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a ******************************************************* From owner-ietf-ediint@mail.imc.org Thu Jan 16 12:18:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16662 for ; Thu, 16 Jan 2003 12:18:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GHA2l03993 for ietf-ediint-bks; Thu, 16 Jan 2003 09:10:02 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0GHA1o03988 for ; Thu, 16 Jan 2003 09:10:02 -0800 (PST) Received: from SEMINOLEVS2.cyclonecommerce.com ([10.1.0.20]) by spyglass.cyclonecommerce.com (NAVGW 2.5.1.13) with SMTP id M2003011610095819974 for ; Thu, 16 Jan 2003 10:09:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Comments on the comments on the recent EDIINT AS2 v12 draft Date: Thu, 16 Jan 2003 10:09:58 -0700 Message-ID: <9551E76040A2604BBD331F3024BFEA48EF61DE@SEMINOLEVS2.cyclonecommerce.com> Thread-Topic: Comments on the comments on the recent EDIINT AS2 v12 draft Thread-Index: AcK9f2y+2iPtgMPUSfSmdoyFJo369AAAOYoA From: "Dale Moberg" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0GHA2o03989 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit My preferences for EDIINT document organization: 1. AS1 remains as its own document. 2. AS2 reverts to its original state, but excludes PGP formats. 3. ASx is produced as a new document, and contains use of multipart/form-data for metainformation (and payload), use of a special "GISB" form of multipart/report for its acknowledgement (with its own distinctive values in the report type), and PGP is used for its security formats. [I prefer calling ASx, AS3.] 4. We make no attempt to document an extension framework for AS2 and AS3 with respect to metainformation, receipt formats, or security formats. Rationale: Item 4: Some developers looking for a straightforward implementation recipe noted that the complexity of the merged AS2 and GISB document was a barrier to understanding or, equivalently, made the specification unclear. A lot of this complexity arose from the fact that GISB had made quite different choices in how to do things from the original AS2 approach. For example, the original AS2 stuck metainformation in the message headers, but GISB spread metainformation across bodyparts in a multipart/form-data. GISB receipts included some industry specific values not present in the basic MDN style receipt of the original AS2. We have tried for several years to figure out ways to simplify the documents, make the implementers' lives simpler, and arrive at a basis for interoperability. In my opinion, the rough consensus overwhelmingly expressed by implementers with working code was to skip the multipart/form-data option, skip the GISB receipt option, and even skip the PGP option. The reason for this is that if you had AS1 support of the kind that had passed AS1 interop tests, the easiest way to move to AS2 support was to omit PGP support, multipart/form-data support, and either GISB receipt or generalized receipt support. Item 3: Once we remove 4 (and some other stuff that mentioned what implementers could do that early list members had mentioned), there are two unconnected implementations of secure acknowledged messaging for business data: a GISB flavor and the original AS2 flavor. Each one of these implementation approaches will not interoperate with the other. It therefore makes sense to put each into its own document. Item 2: In order to remove overlaps in implementation options, PGP support can be found in ASx and removed from AS2. Ironically, over time CMS/SMIME has both become more widely implemented, and its IPR situation has become stable. There is, on the other hand, only one major commercial vendor for PGP and the royalty situation there is not favorable for developers. General remark: Vendors can implement AS1, AS2, or AS3 separately or together. Clearly, AS1 only vendors won't interoperate with AS2 only products, nor will AS3 only products interoperate with AS2 or AS1 only products. If there is an integrated AS1, AS2 and AS3 product let us hope it could interoperate with AS1 only, AS2 only and AS3 only products. The question of what products will implement what flavors of EDIINT should, in my opinion, not influence our decisions on how to break up the documents we produce in this group. We need to have understandable useful specs, each showing a way to realize the original EDIINT requirements for secure and acknowledged transfer of business data. This goal, together with the IETF "rough-consensus andworking-code" principle, is what leads me to the preferences I endorsed. I do not see this as any real change in the true interoperability story, except we will now have three flavors to keep track of, and products can be interoperable in all flavors or just one. This will clarify product interoperability claims and help customers choose the products they need for their communities. From owner-ietf-ediint@mail.imc.org Thu Jan 16 15:22:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22976 for ; Thu, 16 Jan 2003 15:22:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GK9Xo08806 for ietf-ediint-bks; Thu, 16 Jan 2003 12:09:33 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0GK9Wo08802 for ; Thu, 16 Jan 2003 12:09:32 -0800 (PST) Received: from SEMINOLEVS1.cyclonecommerce.com ([10.1.0.21]) by spyglass.cyclonecommerce.com (NAVGW 2.5.1.13) with SMTP id M2003011613092924709 for ; Thu, 16 Jan 2003 13:09:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Split within EDIINT: Multiple versions of AS2 Date: Thu, 16 Jan 2003 13:09:29 -0700 Message-ID: <765F034A849AF4489B7E313759AB242901958956@SEMINOLEVS1.cyclonecommerce.com> Thread-Topic: Split within EDIINT: Multiple versions of AS2 Thread-Index: AcK9my0cvrZi1IJKQBuk5QjfnGTbbg== From: "Gary Crough" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0GK9Wo08803 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, For some time now EDIINT has been split into AS1 and AS2. These "subsets" did not upset anyone. Why the uproar over a suggestion to create another subset? When UCC companies demand trading partners use EDIINT AS2 (and many do) they mean the EDIINT "AS2" subset certified by the UCC ... AS2 using S/MIME and compression options. But within the energy industry "AS2" means PGP/MIME not S/MIME. AS2 subsets already exist. The Energy industry (> 100 installations) uses one subset of EDIINT AS2 and the packaged goods, healthcare, financial, high technology and transportation industries (> 1000 installations) uses another; currently the two AS2 subsets are incompatible. Pretending otherwise is creating considerable confusion in the user community. Using Dale Moberg's proposed terms ...AS1, AS2 (UCC certified) and ASx (PGP version): there is no reason a vendor can't support EDIINT AS1, AS2 and ASx. Such a vendor could claim to support all major subsets of EDIINT. Further, such a vendor would create convergence ... enabling trading between industries which standardized on different subsets. With clear subsets within the EDIINT specification, there is no requirement for a small company like iSoft, the WalMart AS2 vendor, to support AS1 or ASx since WalMart dictates UCC-certified AS2 interfaces. Gary Crough Cyclone Commerce, Inc. 8388 E. Hartford Drive, Scottsdale, AZ 85255 Office: 480-627-8780 Cell: 602-885-9010 From owner-ietf-ediint@mail.imc.org Fri Jan 17 00:17:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02813 for ; Fri, 17 Jan 2003 00:17:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H58Xq21500 for ietf-ediint-bks; Thu, 16 Jan 2003 21:08:33 -0800 (PST) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0H58Ro21495 for ; Thu, 16 Jan 2003 21:08:27 -0800 (PST) Received: from dialup-64.157.21.102.dial1.saltlakecity1.level3.net ([64.157.21.102] helo=LAW2KN008) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZOk2-0006y8-00 for ietf-ediint@imc.org; Thu, 16 Jan 2003 21:08:31 -0800 Reply-To: From: "Dick Brooks" To: Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Thu, 16 Jan 2003 22:08:22 -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.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <765F034A849AF4489B7E313759AB242901958956@SEMINOLEVS1.cyclonecommerce.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It seems clear from the comments provided that Cyclone Software (represented by Dale Moberg and Gary Crough) and Rik Drummond oppose a single AS2 standard for exchanging EDI/XML data. On the other hand we've heard from Andrew Strickland, Mike Costa, Steve Lowery, Wayne Mackintosh, and myself who appear in favor of developing a single AS2 standard for exchanging EDI/XML data. I believe we must resolve this issue before we can move on and address the deeper technical issues. Based on the comments provided thus far, there appears to be more support behind developing a single AS2 standard. However we've only heard from a relatively small subset of the EDIINT community. I believe more community input is needed to help the EDIINT workgroup decide how to proceed - should the group develop one standard or multiple standards to exchange EDI/XML data over HTTP? Your opinions are important, please give the group the help it needs to make the proper decision going forward. Thanks, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Gary Crough Sent: Thursday, January 16, 2003 1:09 PM To: ietf-ediint@imc.org Subject: Split within EDIINT: Multiple versions of AS2 All, For some time now EDIINT has been split into AS1 and AS2. These "subsets" did not upset anyone. Why the uproar over a suggestion to create another subset? When UCC companies demand trading partners use EDIINT AS2 (and many do) they mean the EDIINT "AS2" subset certified by the UCC ... AS2 using S/MIME and compression options. But within the energy industry "AS2" means PGP/MIME not S/MIME. AS2 subsets already exist. The Energy industry (> 100 installations) uses one subset of EDIINT AS2 and the packaged goods, healthcare, financial, high technology and transportation industries (> 1000 installations) uses another; currently the two AS2 subsets are incompatible. Pretending otherwise is creating considerable confusion in the user community. Using Dale Moberg's proposed terms ...AS1, AS2 (UCC certified) and ASx (PGP version): there is no reason a vendor can't support EDIINT AS1, AS2 and ASx. Such a vendor could claim to support all major subsets of EDIINT. Further, such a vendor would create convergence ... enabling trading between industries which standardized on different subsets. With clear subsets within the EDIINT specification, there is no requirement for a small company like iSoft, the WalMart AS2 vendor, to support AS1 or ASx since WalMart dictates UCC-certified AS2 interfaces. Gary Crough Cyclone Commerce, Inc. 8388 E. Hartford Drive, Scottsdale, AZ 85255 Office: 480-627-8780 Cell: 602-885-9010 From owner-ietf-ediint@mail.imc.org Fri Jan 17 06:17:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18155 for ; Fri, 17 Jan 2003 06:17:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HB8Dk29919 for ietf-ediint-bks; Fri, 17 Jan 2003 03:08:13 -0800 (PST) Received: from anchor-post-39.mail.demon.net (anchor-post-39.mail.demon.net [194.217.242.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HB8Bo29911 for ; Fri, 17 Jan 2003 03:08:12 -0800 (PST) Received: from dcsnet.demon.co.uk ([194.222.162.207]) by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2) id 18ZUM1-0003TC-0U; Fri, 17 Jan 2003 11:08:05 +0000 Message-ID: Date: Fri, 17 Jan 2003 11:05:46 +0000 To: dick@tech-comm.com Cc: ietf-ediint@imc.org From: Chris Davenport Subject: Re: Split within EDIINT: Multiple versions of AS2 References: <765F034A849AF4489B7E313759AB242901958956@SEMINOLEVS1.cyclonecommerce.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.02-U (<79LPaGjMGdSiFHu1Y17KXWm8Gj>) Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In message , Dick Brooks writes > >It seems clear from the comments provided that Cyclone Software (represented >by Dale Moberg and Gary Crough) and Rik Drummond oppose a single AS2 >standard for exchanging EDI/XML data. > >On the other hand we've heard from Andrew Strickland, Mike Costa, Steve >Lowery, Wayne Mackintosh, and myself who appear in favor of developing a >single AS2 standard for exchanging EDI/XML data. For what it's worth I would tend to agree, but... >I believe we must resolve this issue before we can move on and address the >deeper technical issues. What I'm not clear about is just how incompatible the two "subsets" are. Are we talking fundamental, irreconcilable differences here? Or is it just a matter of tweaking a few bits and pieces of one or other subset to bring them together? [Snip] I realise that we have two very substantial groups of users who will each support their own particular variant and will be loath to go to the time, trouble and expense of making alterations since they have production systems already in the field. But I would point out that both groups have "jumped the gun" and based their implementations on what is still only a draft. This sad situation has been brought about because there is a clear need for an EDIINT standard but the path to RFC status has been long-winded. Issues such as these will presumably only serve to delay it still further. I think that we should establish AS2 as a strong technical standard that does not pander to either group. After all, their applications will not suddenly stop working just because they can no longer call their software "AS2-compliant". In reply to Gary Crough's comment that we already have a split between AS1 and AS2, I would say that in this case there is a clear technical requirement for a split because of the differing requirements of SMTP vs. HTTP and the fact that HTTP is not fully MIME-compliant. In an ideal world we would not need the AS1(RFC3335)/AS2 split either but history has meant that this split was the starting point for the EDIINT effort. It is something that EDIINT had no control over. The split within AS2 is different: I don't think there is a fundamental technical need for it and we are at the cusp in history where we can avoid it if we so wish. Chris. -- Chris Davenport Davros Computer Systems From owner-ietf-ediint@mail.imc.org Fri Jan 17 12:24:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29242 for ; Fri, 17 Jan 2003 12:24:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HHF6I22495 for ietf-ediint-bks; Fri, 17 Jan 2003 09:15:06 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0HHF5o22490 for ; Fri, 17 Jan 2003 09:15:05 -0800 (PST) Received: from SEMINOLEVS2.cyclonecommerce.com ([10.1.0.20]) by spyglass.cyclonecommerce.com (NAVGW 2.5.1.13) with SMTP id M2003011710144209282 ; Fri, 17 Jan 2003 10:14:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Document reorganization RE: Split within EDIINT: Multiple versions of AS2 Date: Fri, 17 Jan 2003 10:14:42 -0700 Message-ID: <9551E76040A2604BBD331F3024BFEA48EF61E2@SEMINOLEVS2.cyclonecommerce.com> Thread-Topic: Document reorganization RE: Split within EDIINT: Multiple versions of AS2 Thread-Index: AcK+G2dBYU+nfXs0SfWn7GobbJm3WgAKo42A From: "Dale Moberg" To: "Chris Davenport" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0HHF6o22492 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit From: Chris Davenport [mailto:chris@dcsnet.demon.co.uk] In message , Dick Brooks writes > >It seems clear from the comments provided that Cyclone Software (represented >by Dale Moberg and Gary Crough) and Rik Drummond oppose a single AS2 >standard for exchanging EDI/XML data. > >On the other hand we've heard from Andrew Strickland, Mike Costa, Steve >Lowery, Wayne Mackintosh, and myself who appear in favor of developing a >single AS2 standard for exchanging EDI/XML data. For what it's worth I would tend to agree, but... >I believe we must resolve this issue before we can move on and address the >deeper technical issues. What I'm not clear about is just how incompatible the two "subsets" are. Are we talking fundamental, irreconcilable differences here? Or is it just a matter of tweaking a few bits and pieces of one or other subset to bring them together? Dale Moberg>> The subsets were "unified" after a 1999 meeting. The unification in one document resulted in a document that was confusing to readers. Also, the unification did not end up promoting interoperability or in encouraging developers to implement both subsets in their products. Products tended to be one or the other subset. And there is no interoperability between a GISB=PGP style AS2 and a SMIME-MDN style AS2. There have always been the two subsets, and the proposed documentation change is partly to remove the confusion that there is just one. I favor trying to reduce confusion by removing the unification framework. It did not work in practice and I think we should just recognize that fact. You ask how fundamental the differences are. One subset uses PGP for security formats. The other uses SMIME. These formats are basically noninteroperable security formats that differ in use of ASN.1, BER, DER, X.509, CRLs, keyrings and on and on. The differences run deep and are pervasive. Are there any similarities? Yes, of course, but not enough to support interoperability without implementing both security formats and their differing approaches to PKI. How about receipts? GISB has different values and does not use the MDN report type in its multipart/report; AS2 does. How about metadata? GISB puts metadata into separate body parts of a multipart/form-data. AS2 follows a standard practice within IETF specifications by putting this metadata in body part or transport level headers. I originally believed that these differences were just different specializations of the same functionality. To lapse into programming Language metaphors, a receipt object could have abstract methods for createReceipt or reconcileReceipt, and the GISB specialization could create a GISB style receipt while a AS2 specialization could create a MDN style receipt. From this perspective, you could view the difference as "implementation details". Unfortunately these details are deep and for a variety of reasons, developers have _not_ chosen to implement both profiles. [Please note that with a documentation split, vendors still could choose to have a unified product that does all subsets, including AS1.] I believe the documentation readability would be enhanced by splitting the documents. As I mentioned earlier, besides jettisoning the extension framework, nothing substantive is changed by this document reorganization. Vendors have already picked parts of the document to implement along the lines that the new documents have been proposed to follow. I also believe that the user community will be better served by having 3 precise flavors of EDIINT functionality: AS1, AS2 and AS3. That way, they can pick the products that support the flavor(s) they need for communication with their trading communities with far less ambiguity than currently exist. Sharp interoperability tests for each of the 3 flavors can then exist, and products can test for the flavors they support. So I think there are advantages beyond better documentation. And I also think that both customers and developers can unambiguously describe what flavors they support and what interoperability they have tested. Over the last couple of years, there has been some exploitation of vagueness about what AS2 interoperability means. This can be eliminated going forward. From owner-ietf-ediint@mail.imc.org Fri Jan 17 13:13:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00562 for ; Fri, 17 Jan 2003 13:13:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HI1a023559 for ietf-ediint-bks; Fri, 17 Jan 2003 10:01:36 -0800 (PST) Received: from ns0.raydiate.net ([207.207.190.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HI1Zo23555 for ; Fri, 17 Jan 2003 10:01:35 -0800 (PST) Received: (from root@localhost) by ns0.raydiate.net (8.10.2/8.10.2) id h0HHxux25641; Fri, 17 Jan 2003 12:59:56 -0500 Received: from earth (adsl-64-175-47-45.dsl.pltn13.pacbell.net [64.175.47.45]) by ableserve.com (8.10.2/8.10.2) with SMTP id h0HHxsV25632; Fri, 17 Jan 2003 12:59:54 -0500 Message-ID: <000c01c2be52$6944afa0$0201a8c0@sbcglobal.net> From: "Robert E. Frank" To: Cc: , "Chris Davenport" References: <765F034A849AF4489B7E313759AB242901958956@SEMINOLEVS1.cyclonecommerce.com> Subject: Re: Split within EDIINT: Multiple versions of AS2 Date: Fri, 17 Jan 2003 10:01:00 -0800 Organization: Open Commerce, Inc. 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Chris Davenport" To: Cc: Sent: Friday, January 17, 2003 3:05 AM Subject: Re: Split within EDIINT: Multiple versions of AS2 --------snip-------- > I think that we should establish AS2 as a strong technical standard that > does not pander to either group. After all, their applications will not > suddenly stop working just because they can no longer call their > software "AS2-compliant". > > In reply to Gary Crough's comment that we already have a split between > AS1 and AS2, I would say that in this case there is a clear technical > requirement for a split because of the differing requirements of SMTP > vs. HTTP and the fact that HTTP is not fully MIME-compliant. In an > ideal world we would not need the AS1(RFC3335)/AS2 split either but > history has meant that this split was the starting point for the EDIINT > effort. It is something that EDIINT had no control over. The split > within AS2 is different: I don't think there is a fundamental technical > need for it and we are at the cusp in history where we can avoid it if > we so wish. > Chris Davenport > Davros Computer Systems --------snip-------- Well said, Chris! This approach sustains the historic spirit of the Internet. We should stay the course. Robert Frank Open Commerce, Inc. From owner-ietf-ediint@mail.imc.org Fri Jan 17 14:43:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02726 for ; Fri, 17 Jan 2003 14:43:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HJXdp26069 for ietf-ediint-bks; Fri, 17 Jan 2003 11:33:39 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0HJXco26064 for ; Fri, 17 Jan 2003 11:33:38 -0800 (PST) Received: from SEMINOLEVS1.cyclonecommerce.com ([10.1.0.21]) by spyglass.cyclonecommerce.com (NAVGW 2.5.1.13) with SMTP id M2003011712333405315 ; Fri, 17 Jan 2003 12:33:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Fri, 17 Jan 2003 12:33:34 -0700 Message-ID: <765F034A849AF4489B7E313759AB24290195895B@SEMINOLEVS1.cyclonecommerce.com> Thread-Topic: Split within EDIINT: Multiple versions of AS2 Thread-Index: AcK96Y97HXfUJJ4nToaub0VckMJ6mwAa7j2A From: "Gary Crough" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0HJXdo26065 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dick, This is starting to remind me of a Pro-Life vs Anti-Abortion debate. No one is anti-life or pro-abortion. I, along with everyone else, favor of a single EDIINT standard ... and am opposed to gravity! But a single AS2 standard does NOT exist and gravity does. I choose to face reality. AS2(UCC) and AS2(GISB) are very different things using the same name. As you know, Dale M (and Terry H) participated on the GISB/HL7/EDIINT/AIAG convergence team ... their goal was to converge the various standards. Over 3 years later the EDIINT task force is not much closer to converging GISB into the original AS2 than they were on day 1. The two specifications were placed in a single document but little other "convergence" took place. The differences between AS2(GISB) and AS2(S/MIME) are substantial. So much so, that any vendor choosing to offer both would implement the two separately and allow trading partners to be configured to use one or the other. That is how convergence is going to happen. Do you disagree???? The demand for secure Internet trading was such that it did not wait on the slow-moving EDIINT AS2 conversion effort. Last year, several hundred AS2 installations went into the packaged goods, healthcare, financial and transportation industries. In the packaged goods industry alone several thousand AS2 installations are anticipated this year. In all cases these installations will be incompatible with hundreds of AS2 installations within the Energy industry and vice versa. Why pretend otherwise? Most interested parties are yet to be heard from. The EDIINT workgroup has been quite for some time. Let's give people a couple of weeks to wake up and chime in. And there is now a more important interest group: users. Maybe we can get some input from them. -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: Thursday, January 16, 2003 10:08 PM To: ietf-ediint@imc.org Subject: RE: Split within EDIINT: Multiple versions of AS2 It seems clear from the comments provided that Cyclone Software (represented by Dale Moberg and Gary Crough) and Rik Drummond oppose a single AS2 standard for exchanging EDI/XML data. On the other hand we've heard from Andrew Strickland, Mike Costa, Steve Lowery, Wayne Mackintosh, and myself who appear in favor of developing a single AS2 standard for exchanging EDI/XML data. I believe we must resolve this issue before we can move on and address the deeper technical issues. Based on the comments provided thus far, there appears to be more support behind developing a single AS2 standard. However we've only heard from a relatively small subset of the EDIINT community. I believe more community input is needed to help the EDIINT workgroup decide how to proceed - should the group develop one standard or multiple standards to exchange EDI/XML data over HTTP? Your opinions are important, please give the group the help it needs to make the proper decision going forward. Thanks, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Gary Crough Sent: Thursday, January 16, 2003 1:09 PM To: ietf-ediint@imc.org Subject: Split within EDIINT: Multiple versions of AS2 All, For some time now EDIINT has been split into AS1 and AS2. These "subsets" did not upset anyone. Why the uproar over a suggestion to create another subset? When UCC companies demand trading partners use EDIINT AS2 (and many do) they mean the EDIINT "AS2" subset certified by the UCC ... AS2 using S/MIME and compression options. But within the energy industry "AS2" means PGP/MIME not S/MIME. AS2 subsets already exist. The Energy industry (> 100 installations) uses one subset of EDIINT AS2 and the packaged goods, healthcare, financial, high technology and transportation industries (> 1000 installations) uses another; currently the two AS2 subsets are incompatible. Pretending otherwise is creating considerable confusion in the user community. Using Dale Moberg's proposed terms ...AS1, AS2 (UCC certified) and ASx (PGP version): there is no reason a vendor can't support EDIINT AS1, AS2 and ASx. Such a vendor could claim to support all major subsets of EDIINT. Further, such a vendor would create convergence ... enabling trading between industries which standardized on different subsets. With clear subsets within the EDIINT specification, there is no requirement for a small company like iSoft, the WalMart AS2 vendor, to support AS1 or ASx since WalMart dictates UCC-certified AS2 interfaces. Gary Crough Cyclone Commerce, Inc. 8388 E. Hartford Drive, Scottsdale, AZ 85255 Office: 480-627-8780 Cell: 602-885-9010 From owner-ietf-ediint@mail.imc.org Mon Jan 20 11:17:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23042 for ; Mon, 20 Jan 2003 11:17:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KG5Tk16206 for ietf-ediint-bks; Mon, 20 Jan 2003 08:05:29 -0800 (PST) Received: from smtp.dakotagrowers.com (smtp.dakotagrowers.com [12.40.187.30]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0KG5Ro16202 for ; Mon, 20 Jan 2003 08:05:27 -0800 (PST) Received: from DGPDOM-Message_Server by smtp.dakotagrowers.com with Novell_GroupWise; Mon, 20 Jan 2003 10:00:35 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.7.1 Date: Mon, 20 Jan 2003 10:00:15 -0600 From: "Terry Vaughn" To: Subject: RE: Split within EDIINT: Multiple versions of AS2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0KG5So16203 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello. I am following this discussion thread with interest. Although I am not fully versed in the difficulties of merging AS2(ucc) with AS2(other), I am nevertheless an advocate of unification efforts. I believe if it's remotely "feasible" to achieve a single standard, then the responsible community should proactively strive for that standard. The current state of internet technologies has enough entropy without contributing to the forward momentum by NOT making an effort to consolidate standards. Terry Vaughn Interested Party >>> "Gary Crough" 01/17/03 01:33PM >>> Dick, This is starting to remind me of a Pro-Life vs Anti-Abortion debate. No one is anti-life or pro-abortion. I, along with everyone else, favor of a single EDIINT standard ... and am opposed to gravity! But a single AS2 standard does NOT exist and gravity does. I choose to face reality. AS2(UCC) and AS2(GISB) are very different things using the same name. As you know, Dale M (and Terry H) participated on the GISB/HL7/EDIINT/AIAG convergence team ... their goal was to converge the various standards. Over 3 years later the EDIINT task force is not much closer to converging GISB into the original AS2 than they were on day 1. The two specifications were placed in a single document but little other "convergence" took place. The differences between AS2(GISB) and AS2(S/MIME) are substantial. So much so, that any vendor choosing to offer both would implement the two separately and allow trading partners to be configured to use one or the other. That is how convergence is going to happen. Do you disagree???? The demand for secure Internet trading was such that it did not wait on the slow-moving EDIINT AS2 conversion effort. Last year, several hundred AS2 installations went into the packaged goods, healthcare, financial and transportation industries. In the packaged goods industry alone several thousand AS2 installations are anticipated this year. In all cases these installations will be incompatible with hundreds of AS2 installations within the Energy industry and vice versa. Why pretend otherwise? Most interested parties are yet to be heard from. The EDIINT workgroup has been quite for some time. Let's give people a couple of weeks to wake up and chime in. And there is now a more important interest group: users. Maybe we can get some input from them. -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: Thursday, January 16, 2003 10:08 PM To: ietf-ediint@imc.org Subject: RE: Split within EDIINT: Multiple versions of AS2 It seems clear from the comments provided that Cyclone Software (represented by Dale Moberg and Gary Crough) and Rik Drummond oppose a single AS2 standard for exchanging EDI/XML data. On the other hand we've heard from Andrew Strickland, Mike Costa, Steve Lowery, Wayne Mackintosh, and myself who appear in favor of developing a single AS2 standard for exchanging EDI/XML data. I believe we must resolve this issue before we can move on and address the deeper technical issues. Based on the comments provided thus far, there appears to be more support behind developing a single AS2 standard. However we've only heard from a relatively small subset of the EDIINT community. I believe more community input is needed to help the EDIINT workgroup decide how to proceed - should the group develop one standard or multiple standards to exchange EDI/XML data over HTTP? Your opinions are important, please give the group the help it needs to make the proper decision going forward. Thanks, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Gary Crough Sent: Thursday, January 16, 2003 1:09 PM To: ietf-ediint@imc.org Subject: Split within EDIINT: Multiple versions of AS2 All, For some time now EDIINT has been split into AS1 and AS2. These "subsets" did not upset anyone. Why the uproar over a suggestion to create another subset? When UCC companies demand trading partners use EDIINT AS2 (and many do) they mean the EDIINT "AS2" subset certified by the UCC ... AS2 using S/MIME and compression options. But within the energy industry "AS2" means PGP/MIME not S/MIME. AS2 subsets already exist. The Energy industry (> 100 installations) uses one subset of EDIINT AS2 and the packaged goods, healthcare, financial, high technology and transportation industries (> 1000 installations) uses another; currently the two AS2 subsets are incompatible. Pretending otherwise is creating considerable confusion in the user community. Using Dale Moberg's proposed terms ...AS1, AS2 (UCC certified) and ASx (PGP version): there is no reason a vendor can't support EDIINT AS1, AS2 and ASx. Such a vendor could claim to support all major subsets of EDIINT. Further, such a vendor would create convergence ... enabling trading between industries which standardized on different subsets. With clear subsets within the EDIINT specification, there is no requirement for a small company like iSoft, the WalMart AS2 vendor, to support AS1 or ASx since WalMart dictates UCC-certified AS2 interfaces. Gary Crough Cyclone Commerce, Inc. 8388 E. Hartford Drive, Scottsdale, AZ 85255 Office: 480-627-8780 Cell: 602-885-9010 From owner-ietf-ediint@mail.imc.org Mon Jan 20 12:28:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24813 for ; Mon, 20 Jan 2003 12:28:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KHFLR20568 for ietf-ediint-bks; Mon, 20 Jan 2003 09:15:21 -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 h0KHFKo20563 for ; Mon, 20 Jan 2003 09:15:20 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KRF2GA9OB4002DEU@mauve.mrochek.com> for ietf-ediint@imc.org; Mon, 20 Jan 2003 09:15:18 -0800 (PST) Date: Mon, 20 Jan 2003 08:38:11 -0800 (PST) From: ned.freed@mrochek.com Subject: RE: Split within EDIINT: Multiple versions of AS2 In-reply-to: "Your message dated Mon, 20 Jan 2003 10:00:15 -0600" To: ietf-ediint@imc.org, paf@cisco.com, ned.freed@mrochek.com Message-id: <01KRGB7MQXUM002DEU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Area Director hat on... I've been reading the comments on this issue with considerable interest. At this point I think it is important to point out that at least two entirely issues are being conflated here. Specifically, splitting something into two documents doesn't mean that the two documents comprise separate specifiations. Nor, for that matter, does having a single document mean that there wouldn't or couldn't be two conformance levels to AS2. There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049. I'm not aware of any case where this has caused problems: You frequently hear people refer to "MIME conformance", but not "RFC 2045 conformance". SNMP is an even better example. Here we have multiple specification versions, each split up into who knows how many base documents. Yet again, I've never heard of there being a problem with peoeple claiming selective conformace to a specific documents within an SMNP version. (Conformance to different SNMP versions is another matter, but we really don't want to go there...) When I hear claims that there's a problem of clarity in the single document -- a claim I don't think has been contested -- I start to think that splitting things into multiple documents is worth considering. I therefore suggest that this issue be dealt with indepenently of what it means to conform to AS2. If splitting the material into two documents makes it clearer it is something that should be done. If not, it shouldn't. In regards to specification conformance and assuming AS2 is split into two documents, there are all sorts of ways this could be handled: (1) (MIME approach) Everybody has to support both documents in order to claim conformance to AS2. (2) (PL/I approach) You can support what you want and claim conformance to AS2(1) or AS2(2), but you cannot claim to conform to AS2 without supporting both. (3) (PostScript approach) There's no such thing as conformance to AS2 as a whole, you implement and claim conformance to either part independently. (4) The issue is left to other groups to address. Of these the only one I'd have issues with is (4). The goal of IETF specifications is interoperability. And one of the tools that's been effective in achieving interoperability has been conformance criteria. Therefore the decision to abandon this tool should not be taken lightly. I'm well aware, however, that this is a case where various other groups will likely profile anything the IETF produces. So what the IETF says constitutes conformance may not end up being what matters to vendors. But that's not an excuse for not doing our jobs. In any case, I do think that the two issues should be dealt with independently and the document structure issue needs to be addressed first. If nothing else, it would help to make it clear to everyone what's in each part. Ned P.S. I've used the term "conformance" rather than "compliance" throughout this message. This was an intentional choice: To me, compliance tends to imply measurement or testing will be done to insure things work as intended. But this is not something the IETF does, at least not directly. From owner-ietf-ediint@mail.imc.org Tue Jan 21 04:09:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24107 for ; Tue, 21 Jan 2003 04:09:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0L91JZ04237 for ietf-ediint-bks; Tue, 21 Jan 2003 01:01:19 -0800 (PST) Received: from FENCE4.perwill.com (firewall-user@[193.130.63.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0L91Ho04228 for ; Tue, 21 Jan 2003 01:01:18 -0800 (PST) Received: (from uucp@localhost) by FENCE4.perwill.com (8.10.2+Sun/8.10.2) id h0L91xH13913 for ; Tue, 21 Jan 2003 09:01:59 GMT Received: from unknown(192.168.101.101) by FENCE4.perwill.com via csmap (V6.0) id srcAAA29a4kB; Tue, 21 Jan 03 09:01:59 GMT Received: by exchange.perwill.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 09:01:06 -0000 Message-ID: From: Andrew Stickland To: ietf-ediint@imc.org Cc: "'ned.freed@mrochek.com'" , paf@cisco.com Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Tue, 21 Jan 2003 09:01:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Since throwing in my own comments a few days ago, I have been watching developments with interest. So far, it would seem that the split is fairly even between those advocating the splitting and those for keeping the merge but Ned now raises some interesting points. From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. Personally, I found the splitting of the MIME specification over multiple documents to be a real pain when we first started doing some work in this area. I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be. This would therefore suggest that it may be time to take a step back from AS2 and re-think the definition of EDIINT as a whole. It would seem to me that a possible rework of the specifications would be... Doc 1 - Delivery mechanisms (SMTP/POP3 and HTTP) Doc 2 - Enveloping (S/MIME and PGP) There is a lot I could say on the matter but I think I'll leave it there for initial comments. Regards Andrew Stickland Manager, Technical Services mailto:andrew.stickland@perwill.com -----Original Message----- From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] Sent: 20 January 2003 16:38 To: ietf-ediint@imc.org; paf@cisco.com; ned.freed@mrochek.com Subject: RE: Split within EDIINT: Multiple versions of AS2 Area Director hat on... I've been reading the comments on this issue with considerable interest. At this point I think it is important to point out that at least two entirely issues are being conflated here. Specifically, splitting something into two documents doesn't mean that the two documents comprise separate specifiations. Nor, for that matter, does having a single document mean that there wouldn't or couldn't be two conformance levels to AS2. There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049. I'm not aware of any case where this has caused problems: You frequently hear people refer to "MIME conformance", but not "RFC 2045 conformance". SNMP is an even better example. Here we have multiple specification versions, each split up into who knows how many base documents. Yet again, I've never heard of there being a problem with peoeple claiming selective conformace to a specific documents within an SMNP version. (Conformance to different SNMP versions is another matter, but we really don't want to go there...) When I hear claims that there's a problem of clarity in the single document -- a claim I don't think has been contested -- I start to think that splitting things into multiple documents is worth considering. I therefore suggest that this issue be dealt with indepenently of what it means to conform to AS2. If splitting the material into two documents makes it clearer it is something that should be done. If not, it shouldn't. In regards to specification conformance and assuming AS2 is split into two documents, there are all sorts of ways this could be handled: (1) (MIME approach) Everybody has to support both documents in order to claim conformance to AS2. (2) (PL/I approach) You can support what you want and claim conformance to AS2(1) or AS2(2), but you cannot claim to conform to AS2 without supporting both. (3) (PostScript approach) There's no such thing as conformance to AS2 as a whole, you implement and claim conformance to either part independently. (4) The issue is left to other groups to address. Of these the only one I'd have issues with is (4). The goal of IETF specifications is interoperability. And one of the tools that's been effective in achieving interoperability has been conformance criteria. Therefore the decision to abandon this tool should not be taken lightly. I'm well aware, however, that this is a case where various other groups will likely profile anything the IETF produces. So what the IETF says constitutes conformance may not end up being what matters to vendors. But that's not an excuse for not doing our jobs. In any case, I do think that the two issues should be dealt with independently and the document structure issue needs to be addressed first. If nothing else, it would help to make it clear to everyone what's in each part. Ned P.S. I've used the term "conformance" rather than "compliance" throughout this message. This was an intentional choice: To me, compliance tends to imply measurement or testing will be done to insure things work as intended. But this is not something the IETF does, at least not directly. ******************************************************* This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com ******************************************************* Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. ******************************************************* Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. ******************************************************* This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a ******************************************************* From owner-ietf-ediint@mail.imc.org Tue Jan 21 14:19:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09355 for ; Tue, 21 Jan 2003 14:19:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LJ1hk08193 for ietf-ediint-bks; Tue, 21 Jan 2003 11:01:43 -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 h0LJ1fo08189 for ; Tue, 21 Jan 2003 11:01:42 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KRHRDV66JK009UB3@mauve.mrochek.com> for ietf-ediint@imc.org; Tue, 21 Jan 2003 11:01:42 -0800 (PST) Date: Tue, 21 Jan 2003 10:57:31 -0800 (PST) From: ned.freed@mrochek.com Subject: RE: Split within EDIINT: Multiple versions of AS2 In-reply-to: "Your message dated Tue, 21 Jan 2003 09:01:05 +0000" To: Andrew Stickland Cc: ietf-ediint@imc.org, "'ned.freed@mrochek.com'" , paf@cisco.com Message-id: <01KRHT7VQ3X2009UB3@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 > From my own point of view, I don't see that creating two documents really > solve the clarity issue when a single document can be restructured to > achieve the same effect. Personally, I found the splitting of the MIME > specification over multiple documents to be a real pain when we first > started doing some work in this area. FWIW, I didn't particularly like having to make the split, but the AD at the time (John Klensin) insisted. Since then I've received a fair number of comments about it. I'd have to say that those who liked the split exceeded those who didn't like it by about 4 to 1. So it seems it was the right answer for MIME at least. I certainly wouldn't want to undo it at this late date... But what's arguably appropriate for MIME may not be appropriate for this material. My point was that document structure doesn't have to align with conformance in any obvious way. Ned From owner-ietf-ediint@mail.imc.org Tue Jan 21 14:44:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10131 for ; Tue, 21 Jan 2003 14:44:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LJXfr08909 for ietf-ediint-bks; Tue, 21 Jan 2003 11:33:41 -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 h0LJXeo08905 for ; Tue, 21 Jan 2003 11:33:40 -0800 (PST) Received: from LAW2KN008 (host117.systrends.com [65.244.195.117] (may be forged)) by www.tech-comm.com (8.11.6/8.11.6) with SMTP id h0LLBir23790; Tue, 21 Jan 2003 15:11:45 -0600 From: "Dick Brooks" To: Cc: , Subject: To Split or not to Split - that is the question. Date: Tue, 21 Jan 2003 12:33:37 -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.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Perhaps it's time to examine the clarity issue a bit further, and this may help us decide whether to split the spec or not. I'll begin by providing a little background on the original GISB standard. This will be followed by a description of the GISB/AIAG AS2 profile and, lastly, I'll compare the GISB/AIAG and UCC AS2 profiles (at a very high level). In 1996 the Energy industry needed a secure, reliable means to transport EDI documents over the Internet. A relatively new specification was emerging from the IETF that would permit file exchanges using web browsers/HTTP, the spec eventually became known as RFC 1867. RFC 1867 has been updated/replaced by RFC 2388. If you've ever uploaded a file using a web browser to Yahoo, E-Bay or one of the picture sharing sites chances are good you've used the RFC 2388 standard. If you would like to see a GISB standard upload in action simply go to http://www.tech-comm.com/gisbupload.html and send a file to the server. The information you send will be "mirrored" back to your browser so that you can see what data was sent. You don't have to encrypt the data to see how this works, but feel free to do so if you wish. To send a file, click the browse button, pick a file, then send it using the submit button. I've limited the amount of data allowed so please pick a small file to send. *IMPORTANT NOTE FOR CLARITY* The example above uses an interactive web browser to demonstrate a GISB standard upload, however this DOES NOT mean users must use interactive browsers to send files. There are numerous, automated scripting tools available which implement this same functionality that run in an unattended manner. In fact, the majority of implementations in the Energy industry use automated tools to encrypt/decrypt and send/receive files using the GISB standard. Also, the standard response to a file upload, as defined by GISB,is an acknowledgement timestamp, which is not shown in the example above. In an attempt to help people understand how this works I've chosen to display the data that was received by the server so that you may see what a GISB standard message looks like. *END NOTE* As you can see by this example the GISB standard upload procedure is relatively simple to understand, there are 4 identification elements: FROM: Duns number of sender TO: Duns number of recipient INPUT-FORMAT: Describes the type of data being sent (X12) TRANSACTION-SET: Specific identifier for the type of data in the encrypted payload INPUT-DATA: This is the actual file being sent. The message packaging is entirely based on RFC 2388, which is well documented and very easy to understand. All a developer needs to do is view the output from any browser using the HTML form above to see a GISB standard message. The GISB standard for crypto is PGP, and all senders are expected to encrypt their business data before sending it to the server. This approach was fairly easy for people to understand and explicit command line examples using PGP to encrypt files are available for those needing assistance, e.g. pgp -esa foo.bar receiver-pubkey -u signer-key After completing the encryption step, a sender can use a simple web form, like the one above, to upload the encrypted data. One of the benefits of the GISB approach is that an end user doesn't need expensive or complex software to send a file. All that's needed is a web browser and PGP. In 1999, the decision was made to converge the functionality defined by GISB and AIAG into the IETF AS2 effort. The result of this convergence may be seen in another AS2 compliant html form, http://www.tech-comm.com/as2upload.html This AS2 conformant approach was adopted by GISB in 2000 and is now an official standard of the Energy industry. As you can see by the as2upload form there are many more identification elements available than with the original GISB standard. These are all part of what people refer to as the GISB/AIAG AS2 profile. Some of these elements are specifically related to AS2's mechanism for receipt delivery, and security options. In this sense the UCC profile and GISB/AIAG profile are alike and use the same element names to request receipts. So how do the UCC and GISB/AIAG approach's differ within AS2? At a high level, and at the risk of oversimplifying... The UCC approach defines HTTP extension headers to convey similar information to the "identification elements" used by GISB and AIAG, which you can see the as2upload.html form above. Instead of using the element names "FROM" and "TO" to identify sender/receiver the UCC profile uses "AS2-From" and "AS2-To". Additionally, the UCC profile specifies the use of S/MIME version 2 for all crypto functions. The GISB/AIAG AS2 profile specifies OpenPGP. Lastly, the UCC profile uses MDN's for receipt acknowledgements, whereas GISB uses a generic "multipart/report" containing tracking identifiers and timestamps. In terms of function the two profiles are virtually identical; to provide reliable, secure delivery of business data. I hope this helps. Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Andrew Stickland Sent: Tuesday, January 21, 2003 2:01 AM To: ietf-ediint@imc.org Cc: 'ned.freed@mrochek.com'; paf@cisco.com Subject: RE: Split within EDIINT: Multiple versions of AS2 All, Since throwing in my own comments a few days ago, I have been watching developments with interest. So far, it would seem that the split is fairly even between those advocating the splitting and those for keeping the merge but Ned now raises some interesting points. >From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. Personally, I found the splitting of the MIME specification over multiple documents to be a real pain when we first started doing some work in this area. I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be. This would therefore suggest that it may be time to take a step back from AS2 and re-think the definition of EDIINT as a whole. It would seem to me that a possible rework of the specifications would be... Doc 1 - Delivery mechanisms (SMTP/POP3 and HTTP) Doc 2 - Enveloping (S/MIME and PGP) There is a lot I could say on the matter but I think I'll leave it there for initial comments. Regards Andrew Stickland Manager, Technical Services mailto:andrew.stickland@perwill.com -----Original Message----- From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] Sent: 20 January 2003 16:38 To: ietf-ediint@imc.org; paf@cisco.com; ned.freed@mrochek.com Subject: RE: Split within EDIINT: Multiple versions of AS2 Area Director hat on... I've been reading the comments on this issue with considerable interest. At this point I think it is important to point out that at least two entirely issues are being conflated here. Specifically, splitting something into two documents doesn't mean that the two documents comprise separate specifiations. Nor, for that matter, does having a single document mean that there wouldn't or couldn't be two conformance levels to AS2. There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049. I'm not aware of any case where this has caused problems: You frequently hear people refer to "MIME conformance", but not "RFC 2045 conformance". SNMP is an even better example. Here we have multiple specification versions, each split up into who knows how many base documents. Yet again, I've never heard of there being a problem with peoeple claiming selective conformace to a specific documents within an SMNP version. (Conformance to different SNMP versions is another matter, but we really don't want to go there...) When I hear claims that there's a problem of clarity in the single document -- a claim I don't think has been contested -- I start to think that splitting things into multiple documents is worth considering. I therefore suggest that this issue be dealt with indepenently of what it means to conform to AS2. If splitting the material into two documents makes it clearer it is something that should be done. If not, it shouldn't. In regards to specification conformance and assuming AS2 is split into two documents, there are all sorts of ways this could be handled: (1) (MIME approach) Everybody has to support both documents in order to claim conformance to AS2. (2) (PL/I approach) You can support what you want and claim conformance to AS2(1) or AS2(2), but you cannot claim to conform to AS2 without supporting both. (3) (PostScript approach) There's no such thing as conformance to AS2 as a whole, you implement and claim conformance to either part independently. (4) The issue is left to other groups to address. Of these the only one I'd have issues with is (4). The goal of IETF specifications is interoperability. And one of the tools that's been effective in achieving interoperability has been conformance criteria. Therefore the decision to abandon this tool should not be taken lightly. I'm well aware, however, that this is a case where various other groups will likely profile anything the IETF produces. So what the IETF says constitutes conformance may not end up being what matters to vendors. But that's not an excuse for not doing our jobs. In any case, I do think that the two issues should be dealt with independently and the document structure issue needs to be addressed first. If nothing else, it would help to make it clear to everyone what's in each part. Ned P.S. I've used the term "conformance" rather than "compliance" throughout this message. This was an intentional choice: To me, compliance tends to imply measurement or testing will be done to insure things work as intended. But this is not something the IETF does, at least not directly. ******************************************************* This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com ******************************************************* Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. ******************************************************* Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. ******************************************************* This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a ******************************************************* From owner-ietf-ediint@mail.imc.org Tue Jan 21 14:54:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10362 for ; Tue, 21 Jan 2003 14:54:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LJg6109104 for ietf-ediint-bks; Tue, 21 Jan 2003 11:42:06 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0LJg5o09100 for ; Tue, 21 Jan 2003 11:42:05 -0800 (PST) Received: from SEMINOLEVS2.cyclonecommerce.com ([10.1.0.20]) by spyglass.cyclonecommerce.com (NAVGW 2.5.1.13) with SMTP id M2003012112415406198 ; Tue, 21 Jan 2003 12:41:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Tue, 21 Jan 2003 12:41:54 -0700 Message-ID: <9551E76040A2604BBD331F3024BFEA4801598C7D@SEMINOLEVS2.cyclonecommerce.com> Thread-Topic: Split within EDIINT: Multiple versions of AS2 Thread-Index: AcLBLdYCkXrJcJofTGyRj4H8jKWQegAVwKrA From: "Dale Moberg" To: Cc: "Andrew Stickland" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0LJg5o09101 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Wed Jan 22 06:29:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21984 for ; Wed, 22 Jan 2003 06:29:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MBFqK27558 for ietf-ediint-bks; Wed, 22 Jan 2003 03:15:52 -0800 (PST) Received: from FENCE4.perwill.com (firewall-user@[193.130.63.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MBFpo27554 for ; Wed, 22 Jan 2003 03:15:51 -0800 (PST) Received: (from uucp@localhost) by FENCE4.perwill.com (8.10.2+Sun/8.10.2) id h0MBGVg17867 for ; Wed, 22 Jan 2003 11:16:31 GMT Received: from unknown(192.168.101.101) by FENCE4.perwill.com via csmap (V6.0) id srcAAAGGaq5I; Wed, 22 Jan 03 11:16:31 GMT Received: by exchange.perwill.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 11:15:33 -0000 Message-ID: From: Andrew Stickland To: "'Dale Moberg'" , ietf-ediint@imc.org Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Wed, 22 Jan 2003 11:15:30 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dale, Thank-you for your response (and Dick Brooks' as well). Rest assured that I did not intend to cast any dispersions on the authors or editors or the work done to date. My preference for a single document is based on the issue that there are areas of both 'flavours' of AS2 implementation that are the same. If the document is split then these common areas would be duplicated and there is a danger of diversification. I hold my hand up right now and state that I have not dug through the document to see what this would mean - I'm simply raising the point (in any case, see below). As I said, I've not been technically involved in EDIINT for some time and my thanks for the overview/update. You're absolutely correct in that there are fundamental differences in the communications methods. My apologies in that I had intended to phrase my comments more as a question than a proposal. The root of my 'question' is that, in principle, we take a very modular approach to things such as this. For example, the module that sends and receives data through HTTP is the same for AS2 and ebXML. The preparation of data to send and handling of data received occurs in other modules depending on the 'delivery' protocol (AS2, ebXML etc.). Having seen the various responses and revisited the IETF standards process, I'm going to turn around and conclude that the split needs to happen - things are too different. Both camps have stated that there is very little in common between the two variants other that the high-level framework. There was a suggestion that the variants could be called AS2(1) and AS2(2) (or similar) but if the differences are that great then I don't think this is appropriate. At the risk of creating more angst (but with a view to preventing a battle over which variant keeps the name AS2), is it time to put AS2 to sleep and create AS3 & AS4? Regards Andrew Stickland Manager, Technical Services mailto:andrew.stickland@perwill.com -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: 21 January 2003 19:42 To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! ******************************************************* This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com ******************************************************* Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. ******************************************************* Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. ******************************************************* This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a ******************************************************* From owner-ietf-ediint@mail.imc.org Wed Jan 22 17:20:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09620 for ; Wed, 22 Jan 2003 17:20:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MLspF29117 for ietf-ediint-bks; Wed, 22 Jan 2003 13:54:51 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MLsoo29113 for ; Wed, 22 Jan 2003 13:54:50 -0800 (PST) Received: from e2 (12-234-192-139.client.attbi.com[12.234.192.139]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <2003012221544705100pmfn8e>; Wed, 22 Jan 2003 21:54:47 +0000 From: "Carl Hage" To: ietf-ediint@imc.org Date: Wed, 22 Jan 2003 13:54:58 -0800 MIME-Version: 1.0 Subject: RE: Split within EDIINT: Multiple versions of AS2 Message-ID: <3E2EA2B2.25064.2DC7E620@localhost> In-reply-to: X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I agree with the opinion that it would be much nicer to split the RFC3335 MIME-style of message wrapping from the GISB-style since they are fundamentally different ways of signing and packaging the exchange. Having 2 documents would be easier for developers to analyze and reference. It's common for standards (for example MIME) to be split across multiple RFCs. I agree that it would be useful to maintain consistency in common areas, and could be done in a split specification. It is still reasonable to implement a product that could utilize either specification. -------------------------------------------------------------------------- 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 Jan 24 12:40:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26081 for ; Fri, 24 Jan 2003 12:40:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OHMTp18601 for ietf-ediint-bks; Fri, 24 Jan 2003 09:22:29 -0800 (PST) Received: from scidubsmtp01.stercomm.com (scidubsmtp01.stercomm.com [209.95.244.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OHMRo18596 for ; Fri, 24 Jan 2003 09:22:27 -0800 (PST) Received: from cmh0203xcn01.amr.stercomm.com (Not Verified[10.251.99.235]) by scidubsmtp01.stercomm.com with MailMarshal (v5,0,3,85) id ; Fri, 24 Jan 2003 12:23:18 -0500 Received: by cmh0203xcn01.amr.stercomm.com with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 12:22:34 -0500 Message-ID: <7D82A32B200498449E9279D4DFE9E415472B81@scidubmsg02.amr.stercomm.com> From: "Ponko, Vince" To: "'Dale Moberg'" , "'ietf-ediint@imc.org'" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Fri, 24 Jan 2003 12:20:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Fri Jan 24 13:57:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28619 for ; Fri, 24 Jan 2003 13:57:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OIkBl24390 for ietf-ediint-bks; Fri, 24 Jan 2003 10:46:11 -0800 (PST) Received: from ariba-smtp1.ariba.com (ariba-smtp1.ariba.com [216.109.96.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OIkAo24384 for ; Fri, 24 Jan 2003 10:46:10 -0800 (PST) Received: (from root@localhost) by ariba-smtp1.ariba.com (8.11.3/8.11.3) id h0OIkCY11830; Fri, 24 Jan 2003 10:46:12 -0800 (PST) Received: from us-mtvmail3.ariba.com (mail1.ariba.com [205.180.14.142]) by ariba-smtp1.ariba.com (8.11.3/8.11.3) with SMTP id h0OIgwc11179; Fri, 24 Jan 2003 10:42:58 -0800 (PST) Received: by us-mtvmail3.ariba.com with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 10:42:58 -0800 Message-ID: <19A187F26DD4D311949F009027E28ACE13266156@us-mtvmail3.ariba.com> From: Yajun Liu To: "'Ponko, Vince'" , "'Dale Moberg'" , "'ietf-ediint@imc.org'" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Fri, 24 Jan 2003 10:42:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We just implemented AS2 UCC Version. I agree that we should keep GISB and UCC version separate. It is up to companies to implement either or both. For EDIINT service providers or EDIINT software vendors, they might choose to implement both, but for service consumers, it is much easier to implement just one as long as it meets its business needs. --Yajun -----Original Message----- From: Ponko, Vince [mailto:Vince_Ponko@stercomm.com] Sent: Friday, January 24, 2003 9:20 AM To: 'Dale Moberg'; 'ietf-ediint@imc.org' Subject: RE: Split within EDIINT: Multiple versions of AS2 As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Tue Jan 28 11:23:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29747 for ; Tue, 28 Jan 2003 11:23:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SFxaW01183 for ietf-ediint-bks; Tue, 28 Jan 2003 07:59:36 -0800 (PST) Received: from mail0 ([210.83.130.39]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0SFxSo01177 for ; Tue, 28 Jan 2003 07:59:29 -0800 (PST) Received: from above.proper.com([208.184.76.45]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm673e31aeb9; Sat, 25 Jan 2003 02:43:50 +0800 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OHMTp18601 for ietf-ediint-bks; Fri, 24 Jan 2003 09:22:29 -0800 (PST) Received: from scidubsmtp01.stercomm.com (scidubsmtp01.stercomm.com [209.95.244.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OHMRo18596 for ; Fri, 24 Jan 2003 09:22:27 -0800 (PST) Received: from cmh0203xcn01.amr.stercomm.com (Not Verified[10.251.99.235]) by scidubsmtp01.stercomm.com with MailMarshal (v5,0,3,85) id ; Fri, 24 Jan 2003 12:23:18 -0500 Received: by cmh0203xcn01.amr.stercomm.com with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 12:22:34 -0500 Message-ID: <7D82A32B200498449E9279D4DFE9E415472B81@scidubmsg02.amr.stercomm.com> From: "Ponko, Vince" To: "'Dale Moberg'" , "'ietf-ediint@imc.org'" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Fri, 24 Jan 2003 12:20:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Tue Jan 28 12:39:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01979 for ; Tue, 28 Jan 2003 12:39:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SHIdx04053 for ietf-ediint-bks; Tue, 28 Jan 2003 09:18:39 -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 h0SHIco04049 for ; Tue, 28 Jan 2003 09:18:38 -0800 (PST) Received: from LAW2KN008 (host111.systrends.com [65.244.195.111] (may be forged)) by www.tech-comm.com (8.11.6/8.11.6) with SMTP id h0SIuOU11027; Tue, 28 Jan 2003 12:56:26 -0600 From: "Dick Brooks" To: , , "'Dale Moberg'" , "Ponko, Vince" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Tue, 28 Jan 2003 10:18:36 -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.2911.0) In-Reply-To: <7D82A32B200498449E9279D4DFE9E415472B81@scidubmsg02.amr.stercomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Clearly, there are two opposing viewpoints expressed by AS2 implementers. Supporters of the UCC profile favor splitting the specification, supporters of the GISB/AIAG profile favor a single specification. The responses thus far have indicated strong support on both sides. In an earlier posting, Ned Freed stated: "There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049." I believe we should consider taking the same approach as MIME. In an attempt to reach consensus I propose the following course of action: - Create two documents and call them AS2-U and AS2-G - The draft produced by Rik and Dale will be called AS2-U - A new draft will be created for AS2-G, which will be largely based on the text that was removed from AS2 draft 11. - Following the MIME model, the group will create a conformance document along the lines of RFC 2049. This will spell out in detail what is required to be AS2 conformant. I believe this will address the clarity issues which Rik identified, that ultimately led to this situation. Does this bring us closer to agreement? Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Ponko, Vince Sent: Friday, January 24, 2003 10:20 AM To: 'Dale Moberg'; 'ietf-ediint@imc.org' Subject: RE: Split within EDIINT: Multiple versions of AS2 As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Tue Jan 28 13:33:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03241 for ; Tue, 28 Jan 2003 13:33:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SIFXq07671 for ietf-ediint-bks; Tue, 28 Jan 2003 10:15:33 -0800 (PST) Received: from localhost.conedmtce.com (localhost.conedmtce.com [158.57.150.68] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h0SIFWo07667 for ; Tue, 28 Jan 2003 10:15:32 -0800 (PST) Received: from no.name.available by localhost.conedmtce.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Jan 2003 18:15:34 UT Received: from M020EX11.conedison.net ([158.57.159.124]) by m020exg2.conedison.net with Microsoft SMTPSVC(5.0.2195.3779); Tue, 28 Jan 2003 13:15:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Tue, 28 Jan 2003 13:15:32 -0500 Message-ID: <790BF29993CD42498A0015E82F1E3C42033247E2@M020EX11.conedison.net> Thread-Topic: Split within EDIINT: Multiple versions of AS2 Thread-Index: AcLG9atjC9qBNfIJSz6nmJg4LdRELgAA3MEA From: "Costa, Michael J." To: "Dick Brooks" , , , "Dale Moberg" , "Ponko, Vince" X-OriginalArrivalTime: 28 Jan 2003 18:15:33.0015 (UTC) FILETIME=[3F409A70:01C2C6F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0SIFWo07668 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dick: A most reasonable idea. -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: Tuesday, January 28, 2003 12:19 PM To: rvd2@drummondgroup.com; ietf-ediint@imc.org; 'Dale Moberg'; Ponko, Vince Subject: RE: Split within EDIINT: Multiple versions of AS2 Clearly, there are two opposing viewpoints expressed by AS2 implementers. Supporters of the UCC profile favor splitting the specification, supporters of the GISB/AIAG profile favor a single specification. The responses thus far have indicated strong support on both sides. In an earlier posting, Ned Freed stated: "There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049." I believe we should consider taking the same approach as MIME. In an attempt to reach consensus I propose the following course of action: - Create two documents and call them AS2-U and AS2-G - The draft produced by Rik and Dale will be called AS2-U - A new draft will be created for AS2-G, which will be largely based on the text that was removed from AS2 draft 11. - Following the MIME model, the group will create a conformance document along the lines of RFC 2049. This will spell out in detail what is required to be AS2 conformant. I believe this will address the clarity issues which Rik identified, that ultimately led to this situation. Does this bring us closer to agreement? Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Ponko, Vince Sent: Friday, January 24, 2003 10:20 AM To: 'Dale Moberg'; 'ietf-ediint@imc.org' Subject: RE: Split within EDIINT: Multiple versions of AS2 As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Wed Jan 29 11:56:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23477 for ; Wed, 29 Jan 2003 11:56:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TGDom18435 for ietf-ediint-bks; Wed, 29 Jan 2003 08:13:50 -0800 (PST) Received: from drummondgroup.com (drummondgroup.com [161.58.166.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TGDio18424 for ; Wed, 29 Jan 2003 08:13:44 -0800 (PST) Received: from RIKDGI (c66.169.103.180.ftwrth.tx.charter.com [66.169.103.180]) by drummondgroup.com (8.12.6/8.11.6) with ESMTP id h0TGDWFc082669; Wed, 29 Jan 2003 09:13:32 -0700 (MST) From: "Rik Drummond" To: "'Dick Brooks'" , , "'Dale Moberg'" , "'Ponko, Vince'" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Wed, 29 Jan 2003 10:13:33 -0600 Organization: Drummond Group Inc. Message-ID: <000801c2c7b1$654e14f0$7824fea9@RIKDGI> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sounds like an approach. Dick, the version ll draft is really confusing.... You may wish to consider more than basing the next version on it... If people are not going to use the gisb standard to implement but the as2-g ietf draft it may cause serious problems.... I will resubmit the v12 draft with any comment changes to it, with a change record if necessary to the ietf ediint wg as draft-ietf-as2-u-13.txt and resubmit v11 as draft-ietf-as2-g-11.txt.... Is that appropriate? If so we can then work them in parallel.... Best regards, rik -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: Tuesday, January 28, 2003 11:19 AM To: rvd2@drummondgroup.com; ietf-ediint@imc.org; 'Dale Moberg'; Ponko, Vince Subject: RE: Split within EDIINT: Multiple versions of AS2 Clearly, there are two opposing viewpoints expressed by AS2 implementers. Supporters of the UCC profile favor splitting the specification, supporters of the GISB/AIAG profile favor a single specification. The responses thus far have indicated strong support on both sides. In an earlier posting, Ned Freed stated: "There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049." I believe we should consider taking the same approach as MIME. In an attempt to reach consensus I propose the following course of action: - Create two documents and call them AS2-U and AS2-G - The draft produced by Rik and Dale will be called AS2-U - A new draft will be created for AS2-G, which will be largely based on the text that was removed from AS2 draft 11. - Following the MIME model, the group will create a conformance document along the lines of RFC 2049. This will spell out in detail what is required to be AS2 conformant. I believe this will address the clarity issues which Rik identified, that ultimately led to this situation. Does this bring us closer to agreement? Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Ponko, Vince Sent: Friday, January 24, 2003 10:20 AM To: 'Dale Moberg'; 'ietf-ediint@imc.org' Subject: RE: Split within EDIINT: Multiple versions of AS2 As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Wed Jan 29 12:02:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23638 for ; Wed, 29 Jan 2003 12:02:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TGXq019134 for ietf-ediint-bks; Wed, 29 Jan 2003 08:33: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 h0TGXpo19128 for ; Wed, 29 Jan 2003 08:33:51 -0800 (PST) Received: from LAW2KN008 (host119.systrends.com [65.244.195.119] (may be forged)) by www.tech-comm.com (8.11.6/8.11.6) with SMTP id h0TIBZu13408; Wed, 29 Jan 2003 12:11:35 -0600 From: "Dick Brooks" To: "Rik Drummond" , "'Dick Brooks'" , , "'Dale Moberg'" , "'Ponko, Vince'" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Wed, 29 Jan 2003 09:33:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: <000801c2c7b1$654e14f0$7824fea9@RIKDGI> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rik, I like the name changes you propose. However, I would prefer for you to send me the source for draft 11, which will be edited and republished as draft-ietf-as2-g-12.txt. Thanks, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: Rik Drummond [mailto:rvd2@drummondgroup.com] Sent: Wednesday, January 29, 2003 9:14 AM To: 'Dick Brooks'; ietf-ediint@imc.org; 'Dale Moberg'; 'Ponko, Vince' Subject: RE: Split within EDIINT: Multiple versions of AS2 Sounds like an approach. Dick, the version ll draft is really confusing.... You may wish to consider more than basing the next version on it... If people are not going to use the gisb standard to implement but the as2-g ietf draft it may cause serious problems.... I will resubmit the v12 draft with any comment changes to it, with a change record if necessary to the ietf ediint wg as draft-ietf-as2-u-13.txt and resubmit v11 as draft-ietf-as2-g-11.txt.... Is that appropriate? If so we can then work them in parallel.... Best regards, rik -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: Tuesday, January 28, 2003 11:19 AM To: rvd2@drummondgroup.com; ietf-ediint@imc.org; 'Dale Moberg'; Ponko, Vince Subject: RE: Split within EDIINT: Multiple versions of AS2 Clearly, there are two opposing viewpoints expressed by AS2 implementers. Supporters of the UCC profile favor splitting the specification, supporters of the GISB/AIAG profile favor a single specification. The responses thus far have indicated strong support on both sides. In an earlier posting, Ned Freed stated: "There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049." I believe we should consider taking the same approach as MIME. In an attempt to reach consensus I propose the following course of action: - Create two documents and call them AS2-U and AS2-G - The draft produced by Rik and Dale will be called AS2-U - A new draft will be created for AS2-G, which will be largely based on the text that was removed from AS2 draft 11. - Following the MIME model, the group will create a conformance document along the lines of RFC 2049. This will spell out in detail what is required to be AS2 conformant. I believe this will address the clarity issues which Rik identified, that ultimately led to this situation. Does this bring us closer to agreement? Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Ponko, Vince Sent: Friday, January 24, 2003 10:20 AM To: 'Dale Moberg'; 'ietf-ediint@imc.org' Subject: RE: Split within EDIINT: Multiple versions of AS2 As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! From owner-ietf-ediint@mail.imc.org Wed Jan 29 13:29:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25437 for ; Wed, 29 Jan 2003 13:29:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TI5Kh25338 for ietf-ediint-bks; Wed, 29 Jan 2003 10:05:20 -0800 (PST) Received: from gpu1dot38.gpu.com (gpu1dot38.gpu.com [148.108.1.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TI5Io25334 for ; Wed, 29 Jan 2003 10:05:19 -0800 (PST) Received: from mail04.fenetwork.com (gpu4dot25.gpu.com [148.108.4.25]) by gpu1dot38.gpu.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id NAA01221; Wed, 29 Jan 2003 13:12:54 -0500 Subject: Re: EDIINT AS2-U, AS2-G and a separate conformance document? To: Cc: X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: pbyrne@gpu.com Date: Wed, 29 Jan 2003 13:05:12 -0500 X-MIMETrack: Serialize by Router on mail04/Servers/FirstEnergy(Release 5.0.10 |March 22, 2002) at 01/29/2003 01:05:13 PM 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: Dr. Brooks, et al, I agree with Crough (20030115, 20030116, 20030117), Moberg (20030116, 20030117, 20030121), and you (20030128): create two documents, one from the version 12 draft and one based on the version 11 draft but to be edited and republished. However, I am against the notion of AS2-U and AS2-G!! The former version is used by many more than just the UCC and the latter version is named for a group that no longer exists! Let's recognize reality and move straight to draft-ietf-as2-12.txt and to draft-ietf-as3-1.txt and be done with it! That way, people can concentrate on conforming to the one 'standard' predominately used in their industry. With two ASs, is there a need for a conformance document? Pete --------------------------------- Pete Byrne EC/EDI Group, FirstEnergy Services Electronic Communications for the Efficient Delivery of Information Tel: 610-939-4334 Fax: 330-315-8465 pbyrne@gpu.com "Dick Brooks" om> cc: (bcc: Pete Byrne/GPU) Subject: EDIINT AS2-U, AS2-G and a separate conformance document 2003-01-29 11:37 AM Please respond to dick Dr. Byrne, How do you feel about the proposed compromise? - Create two documents and call them AS2-U and AS2-G - The draft produced by Rik and Dale will be called AS2-U - A new draft will be created for AS2-G, which will be largely based on the text that was removed from AS2 draft 11. - Following the MIME model, the group will create a conformance document along the lines of RFC 2049. This will spell out in detail what is required to be AS2 conformant. Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 From owner-ietf-ediint@mail.imc.org Wed Jan 29 14:18:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26893 for ; Wed, 29 Jan 2003 14:18:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TIqvp27190 for ietf-ediint-bks; Wed, 29 Jan 2003 10:52:57 -0800 (PST) Received: from drummondgroup.com (drummondgroup.com [161.58.166.198]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TIqmo27186 for ; Wed, 29 Jan 2003 10:52:49 -0800 (PST) Received: from RIKDGI (c66.169.103.180.ftwrth.tx.charter.com [66.169.103.180]) by drummondgroup.com (8.12.6/8.11.6) with ESMTP id h0TIqfw9054700; Wed, 29 Jan 2003 11:52:41 -0700 (MST) From: "Rik Drummond" To: "'Dick Brooks'" , , "'Dale Moberg'" , "'Ponko, Vince'" Subject: RE: Split within EDIINT: Multiple versions of AS2 Date: Wed, 29 Jan 2003 12:52:40 -0600 Organization: Drummond Group Inc. Message-ID: <000a01c2c7c7$9cdfd7d0$7824fea9@RIKDGI> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C2C795.524567D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: 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_000B_01C2C795.524567D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dick I assume you want to be the editor on this? It would be best if you also found someone else to help... Two is better than one..... Please keep me posted on progress.... Thanks for the good work.. rik -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: Wednesday, January 29, 2003 10:34 AM To: Rik Drummond; 'Dick Brooks'; ietf-ediint@imc.org; 'Dale Moberg'; 'Ponko, Vince' Subject: RE: Split within EDIINT: Multiple versions of AS2 Rik, I like the name changes you propose. However, I would prefer for you to send me the source for draft 11, which will be edited and republished as draft-ietf-as2-g-12.txt. Thanks, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: Rik Drummond [mailto:rvd2@drummondgroup.com] Sent: Wednesday, January 29, 2003 9:14 AM To: 'Dick Brooks'; ietf-ediint@imc.org; 'Dale Moberg'; 'Ponko, Vince' Subject: RE: Split within EDIINT: Multiple versions of AS2 Sounds like an approach. Dick, the version ll draft is really confusing.... You may wish to consider more than basing the next version on it... If people are not going to use the gisb standard to implement but the as2-g ietf draft it may cause serious problems.... I will resubmit the v12 draft with any comment changes to it, with a change record if necessary to the ietf ediint wg as draft-ietf-as2-u-13.txt and resubmit v11 as draft-ietf-as2-g-11.txt.... Is that appropriate? If so we can then work them in parallel.... Best regards, rik -----Original Message----- From: Dick Brooks [mailto:dick@tech-comm.com] Sent: Tuesday, January 28, 2003 11:19 AM To: rvd2@drummondgroup.com; ietf-ediint@imc.org; 'Dale Moberg'; Ponko, Vince Subject: RE: Split within EDIINT: Multiple versions of AS2 Clearly, there are two opposing viewpoints expressed by AS2 implementers. Supporters of the UCC profile favor splitting the specification, supporters of the GISB/AIAG profile favor a single specification. The responses thus far have indicated strong support on both sides. In an earlier posting, Ned Freed stated: "There are plenty of examples of specifications split into multiple documents in the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049." I believe we should consider taking the same approach as MIME. In an attempt to reach consensus I propose the following course of action: - Create two documents and call them AS2-U and AS2-G - The draft produced by Rik and Dale will be called AS2-U - A new draft will be created for AS2-G, which will be largely based on the text that was removed from AS2 draft 11. - Following the MIME model, the group will create a conformance document along the lines of RFC 2049. This will spell out in detail what is required to be AS2 conformant. I believe this will address the clarity issues which Rik identified, that ultimately led to this situation. Does this bring us closer to agreement? Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]On Behalf Of Ponko, Vince Sent: Friday, January 24, 2003 10:20 AM To: 'Dale Moberg'; 'ietf-ediint@imc.org' Subject: RE: Split within EDIINT: Multiple versions of AS2 As an implementor and interested party it is my view that we have two separate standards and they ought to remain that way, in part for the reasons that Dale Moberg cites below. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, January 21, 2003 2:42 PM To: ietf-ediint@imc.org Cc: Andrew Stickland Subject: RE: Split within EDIINT: Multiple versions of AS2 Andrew Strickland wrote: "From my own point of view, I don't see that creating two documents really solve the clarity issue when a single document can be restructured to achieve the same effect. " Dale Moberg>> I hope you had a chance to review some earlier messages in which I explained how the integration framework (also describable as the extension framework) created confusion and was what we wanted to remove. I think your opinion, expressed above, is one with which I do not agree. However, I suspect it will be necessary to go into some technical matters here in greater detail because the restructuring of which you dream is not one we foresee working (unless we have two distinct specs concatenated into one document-that might work except for confusing or annoying current implementers about what it means to implement what is in the document.) GISB introduced the idea of placing metainformation about a business data payload into separate body parts of a MIME entity in a POSTed HTTP PDU. The reason for this is that GISB wanted to be able to make use of a HTTP/HTML browser in sending data. Browsers typically cannot add HTTP headers, so an entirely new implementation technique was introduced to convey metainformation. These interactive browser limitations have never played well with AS2 as it originally was speced by this working group. We introduced the unification framework-the agreed upon source of most of the confusion we hope to eliminate-in order to put both approaches into one document. You now propose some unspecified restructuring that will solve the clarity issue by reintroducing some unification perspective. I am not hopeful and several years of having several authors and editors work on this suggests that a clean break with this approach is much more promising. Let me elaborate some of the problems that having them together creates: Should the multipart/form-data way of formatting metainformation also be useable with the original POST of the core EDIINT security formats or should it be restricted to when you also use the GISB receipt mechanism and/or PGP based formats (open pgp)? Should transport headers be used to convey GISB metainformation instead of bodyparts in a multipart/form-data? How much should we mix and match the mechanisms? Can you supply both? When both are used, and the same metainformation item has different values, which one do you mean? Perhaps "confusion" is the wrong word here. Implementers basically just did not want to have to implement with this degree of generality and complexity and called what they did not want to do, "confusing". We believe they have a point. In point of fact, no one has implemented a fully general unified AS2 as it is now written. They have picked and chosen one or the other of the two "parts" they find in it (actually you should see that the "two parts" phrase already embodies a misunderstanding). Given that this is what we have ended up having in working code, we just want to get rid of the complexity and break the two implemented specs out into separate documents, each of which can be implemented independently of the other, and both of which can be done by a single product. Andrew continues writing: "I've been out of the deep technical loop on this for some time so please don't shoot me if I get some things a little bit wrong... The original split between AS1 and AS2 was purely due to the difference in delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be said that this is still true today and in fact both the 'UCC' and 'Energy' variants could be carried by either mechanism? Actually, if this is not true then maybe it should be." Dale Moberg>> I will not shoot you, but I think you are laboring under serious oversimplifications of the technical issues involving in using SMTP versus using HTTP. There are, I suppose, ways that the variants (and we will here adopt the simplification which we are hoping to make true)-the _two_ AS2 variants "could" be carried by either mechanism. For example, one could ignore the HTTP specification and used content-transfer-encodings and put them in the HTTP MIME entity. [Not a good thing for an IETF working group to do, and not something endorsed here, by the way Ned.) Or, you could make certain that you used ESMTP mechanisms to make certain your MTAs handled binary content-transfer encodings (with arbitrarily long strings of octets without a CRLF), and maybe omit the content-transfer-encoding header (to conform to HTTP recommended practice). These are not prerequisites we are interested in enforcing for business users; we want them to be able to use existing available MTAs and webservers when possible. In other words, Andrew, the MIME of HTTP and of SMTP and its cousins differ in some basic ways that frustrates having byte-for-byte identical PDUs. If you wish to invent a PDU that has this property, please submit your proposal (and we will shoot it, not you, down.) Add to the MIME differences, the differences in header conventions! Or the defaults that govern omitted headers (omit the content-type in mail, and text/plain (with a 7-bit cte) will be assumed but in HTTP the cte is as always binary, with a content-type of text/html. Or the fact that "From" is given different semantic functions as a header. The result is that while we have had the goal of keeping the PDUs similar in AS1 and AS2, the existing standards themselves upon which we are building do not allow identical PDUs to be used. Since we mainly are describing or profiling PDUs in AS1 and AS2, keeping the profiles in separate documents is and will remain a far cleaner way to proceed. While your idea is not silly (it is one we aspired to and which we asymptotically approached until we added the GISB techniques), in practice it cannot be realized. I do not want to spend time revisiting these issues, as they were ironed out over 4 years ago. I would very strongly oppose trying to follow the regroupings you propose later in your message at this point; it would definitely not remove the confusions we wish to remove and would in all likelihood create new ones to boot! ------=_NextPart_000_000B_01C2C795.524567D0 Content-Type: text/plain; name="draft-ietf-ediint-as2-11 KEEP.txt" Content-Disposition: attachment; filename="draft-ietf-ediint-as2-11 KEEP.txt" Content-Transfer-Encoding: 7bit EDIINT Working Group Dale Moberg Internet draft Dick Brooks Expires: November 2002 Rik Drummond David Fischer May 2002 HTTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet draft-ietf-ediint-as2-11.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet- Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the EDIINT working group of the IETF, using the address . Requests to subscribe to the mailing list should be addressed to . Abstract This document describes how to exchange structured business data securely using HTTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport), XML or other data used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the HTTP POST requests. This document extends the procedures and payload packaging options of AS1 in the following ways: HTTPS may be used to obtain data, privacy both synchronous and asynchronous reply procedures are, described multipart/form-data packaging may be used, a generalized Moberg, Brooks, Drummond, Fischer [page 1] HTTP Transport for Secure EDI May 2002 multipart/report format is added to the MDN format of AS1, replies may include a multipart/mixed payload that contains both the acknowledgement and an additional EDI payload. This document is intended to be read in conjunction with AS1 and the referenced RFCs defining the MIME and cryptographic packaging that are used to obtain secure, authenticated, and acknowledged transport. Feedback Instructions: NOTE TO RFC EDITOR: This section should be removed by the RFC editor prior to publication. If you want to provide feedback on this draft, follow these guidelines: - Send feedback via e-mail to the ietf-ediint list for discussion, with "AS#2" in the Subject field. To enter/follow the discussion, you need to subscribe at ietf-ediint@imc.org. - Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. - If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. Table of Contents 1. Introduction 1.1 Purpose and relation to previous work 1.2 Overall operation 2. Stages and Details of HTTP Transmission and Acknowledgment 2.1 Requesting Receipts 2.1.1 Requesting MDN-based receipts 2.1.2 Requesting Generalized receipts 2.1.2.1 Additional Commonly Used Headers 2.1.3 Summary Remarks on Receipt request options 2.2 Sending EDI in HTTP POST Requests 2.3 Using Transport Layer Security 2.4 Response Status Codes in Replies 2.5 Receipt Reply 2.5.1 MDN Receipts and Signed MDN Receipts 2.5.2 Generalized Receipts and Signed Receipts 2.6 Additional Reply Content 2.7 Non-Repudiation of the POST Reply 2.8 Error Recovery 3. Other differences between HTTP and SMTP based transport 3.1 Unused MIME headers and operations 3.1.1 Content-Transfer-Encoding not used Moberg, Brooks, Drummond, Fischer [page 2] HTTP Transport for Secure EDI May 2002 3.1.2 Epilogue must be empty 3.1.3 Lengthy message bodies 3.2 Differences in MIME or other headers or parameters used 3.2.1 Content-Length 3.2.2 Final Recipient and Original Recipient 3.2.3 Message-Id and Original-Message-Id 3.2.4 Host header 4. Additional AS2 specific HTTP headers 4.1 AS2 Version Header 4.2 AS2 System Identifiers 4.2.1 Unrecognized System Identifiers A. AS2 MIME templates. B. Using AS2 Extensions in the GISB Protocol C. Samples of AS2 Protocol Data Units D. Acknowledgments E. References F. Security Considerations G. Authors' Addresses 1. Introduction 1.1 Purpose and relation to previous work Early work on Internet EDI focused on specifying MIME content types for EDI data [MIMEEDI] The functional requirements document , "Requirements for Interoperable Internet EDI," [EDIINT] provides extensive information on EDI security and the business and user processes that can benefit from the use of EDI security. In addition, MIME structures appropriate for SMTP transport of the packaged EDI data are specified in ([AS1] "MIME-based Secure EDI") as well as the details needed to support signed receipts as acknowledgments. The framework of [AS1] shows how to implement the security features--specifically data privacy, data integrity/authenticity, non-repudiation of origin and non-repudiation of receipt --found to be requirements for secure EDI. In this document, it is assumed that the reader is familiar with the SMTP/MIME transport document, the requirements document, and the RFCs applied or referenced in those documents. This draft, like the SMTP/MIME transport document, builds on previous RFCs and is attempting to "re-invent" as little as possible. The goal here is to specify how previously specified MIME messaging structures and operations can be adapted for use with HTTP servers and clients to obtain secure, reliable, and acknowledged transport for EDI and other business data. The applicability statement, [AS1] "MIME-based Secure EDI," Moberg, Brooks, Drummond, Fischer [page 3] HTTP Transport for Secure EDI May 2002 explained the basic EDI transaction using the concept of a "secure transmission loop" for EDI. This loop involves one organization sending a signed and encrypted EDI interchange to another organization, requesting a signed receipt, followed by the receiving organization sending this signed receipt back to the sending organization. The transmission therefore involves the following stages: 1. The organization sending business data encrypts the data and provides a digital signature, using either PGP/MIME or S/MIME. In addition, they request a signed receipt. 2. The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender. 3. The receiving organization then sends a signed receipt using a signature over the hash of a message disposition notification, which contains a hash of the received message. The above stages describe the functionality that would satisfy all security requirements. Applications are expected to be able to provide full functionality, though users may agree to exchange data using only a restricted subset of functionality. For example, businesses may agree to send signed data using TLS, and only request a simple, unsigned receipt. Implementations are expected to be configurable so that they may support business community agreements that use subsets of the full functionality. In this document, the goal is to make use of HTTP instead of SMTP as a transport protocol, and make the changes that are needed to adapt to protocol packaging differences. In either transport case, the body of the message is a MIME structure, using MIME headers ("content-type" and other "content-X" tags) to convey information about the data being transported. Also, one primary use of SMTP RFC 822 headers within SMTP based transport of secure EDI has been to enable requests for acknowledgements and to specify options for signatures over acknowledgements (asymmetric encryption and cryptographic hash algorithm preferences). One way to convey this information within the HTTP transport context is to use either HTTP entity-headers or extension-headers [11, section 7.1] that have the syntax of SMTP headers. Only the "From" header is overloaded by possibly different usages in the SMTP and HTTP contexts. The "From" header normally contains machine-usable email addresses as defined in [SMTPMSG]. The Moberg, Brooks, Drummond, Fischer [page 4] HTTP Transport for Secure EDI May 2002 usage of the "From" header in [HTTP] section 14.22 is to provide the email address of an administrative contact for the HTTP client. The function of the "From" header in the SMTP context of secure EDI transport has been to supply a value used in constructing the MDN style receipt. But the MDN receipt has been found to be too restrictive for some commercial EDI transport scenarios [GISB]. So alternative receipt mechanisms will be provided that, among other things, will remove any conflicts arising from trying to reuse the SMTP-MDN roles of "From" within the context of HTTP reserved usage of "FROM". Also, it is currently difficult to make use of HTML [HTML] and simple scripting to send HTTP entity-headers as part of the HTML FORM tag construct. For HTML-based POST situations [GISB], it is useful to specify ways to convey 'metadata' needed for the secure transmission loop that do not make use of HTTP headers. One way to specify this data is by using the MIME multipart/form-data packaging specified in [FORMDATA]. For SMTP transport, the receipt and signed receipt functions are implemented using Message Disposition Notifications [MDN] and Multipart/signed Message Disposition Notifications [AS1]. For HTTP transport, generalization of the Message Disposition Notification is useful. The MDN is a special kind of multipart/report [REPORT]. For MDNS, specialization is achieved by assigning the "report-type" parameter in the content-type header the special value, "disposition-notification" and by having the second body part (the "machine-readable" body part) have the MIME content-type, "message/disposition-notification". To generalize a MDN, all that is needed is to remove the restrictions that make the underlying multipart/report into a MDN. In other words, the "report-type" parameter [REPORT, section 1] is given a new value and the second body part is changed to a content-type other than "message/disposition- notification". Acknowledgements defined by these changes will be referred to as "generalized receipts. Each receipt of this kind will have its own specific report-type parameter and its own specifications for the syntax and semantics of the automated response body part. Implementations are encouraged to be able to register new report-type handlers using only configuration changes (not recompiling) that specify how to process new report- type values. Nothing else needs to be changed to construct reply acknowledgements that are not restricted by the semantics of MDNs. Specifically, a signed reply will still be constructed by using a multipart/signed package to wrap up generalized receipts with their signatures. Finally, within the HTTP transport context, it is useful to make Moberg, Brooks, Drummond, Fischer [page 5] HTTP Transport for Secure EDI May 2002 use of Transport Layer Security [TLS] to provide privacy. Compression can be provided using HTTP content-codings [HTTP], sections 3.5, 14.3, 14.12]. (Content codings are not to be confused with the MIME concept of content transfer encodings.) A variety of other minor differences (for example, absence of content-transfer-encoding) are noted below and summarized in the concluding section. 1.2 Overall operation A HTTP POST operation [HTTP] is used to send appropriately packaged EDI, XML, or other business data. The Request-URI ([HTTP],section 9.5) identifies a process to unpack and handle the message data and to generate a reply for the client that contains a message disposition acknowledgement or a multipart/ report, signed or unsigned, and possibly other turnaround transactions. This request/reply transactional interchange provides secure, reliable, and authenticated transport for EDI or other business data using HTTP; the security protocols and structures used also support auditable records of these transmissions, acknowledgements, and authentication. 2. Stages and Details of HTTP Transmission and Acknowledgment A data file or stream is first structured into one of the message templates described in [AS1], sections 4.2.1 to 4.2.4 or 4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. In addition to the content-types of [MIMEEDI], applications should be prepared for handling other content-types used in business to business transactions, such as those for XML [MIME-TYPES]. For convenience, these message templates, adapted for the HTTP transport context, are provided in Appendix A. If TLS is to be used, the typical packaging will be that described in sections 4.2.2 or 4.3.2; that is, a multipart/signed message will be created with no encryption in the message. Otherwise, if privacy is desired, message templates 4.2.4 or 4.3.4 are used. Content transfer encoding is not used and a content-length field is to be provided. If HTML-based POST is used (using the METHOD=POST attribute within the "FORM" tag) [HTML, 17 Forms], then the message payload will be packaged in the input-data element of a multipart/form- data. The metadata needed for application layer routing, identification, requesting a reply and other transaction operations can be packaged in message body parts in the multipart/form-data. The labels for the metadata values are found in the "name" parameter of the Content-Disposition header in each form-data part as discussed in [FORMDATA, section 3]. Moberg, Brooks, Drummond, Fischer [page 6] HTTP Transport for Secure EDI May 2002 In general, both HTTP servers and HTTP clients handling the message templates of [AS1] should be prepared to process these basic EDIINT data formats when they are embedded within MIME multiparts. In addition to the enveloping and MIME media type options defined in sections 4.2.x and 4.3.x of "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet" [AS1], this specification enables the transport of payload objects containing other MIME media types. Implementors are to follow the appropriate specifications identified under "References" in [MIME-TYPES], for the type of object being transmitted. For example, to send an XML object, the MIME media type of application/xml is used in the Content-type MIME header and the specifications for enveloping the object are contained in [XMLTYPES]; for example: Content-type: application/xml; charset="utf-8" Many of the specifications referenced by [MIME-TYPES] were designed for SMTP transports. Implementors are advised to make appropriate adjustments for HTTP transport as indicated in section 3 of this document. Finally, several industry groups currently make use of "encapsulated"(or opaque) signatures within encrypted or signed objects. Encapsulated signatures should be supported in order to accommodate these existing practices. Objects containing encapsulated signatures must be prepared according to the specifications contained in section 3.4.2 of [SMIMEV2] or, in the case of PGP, according to the specifications contained in section 6.2 of "MIME Security with Pretty Good Privacy (PGP)" [MIMEPGP] and "OpenPGP Message Format" [RFC2440]. 2.1 Requesting Receipts 2.1.1 Requesting MDN-based receipts For requesting MDN based receipts, the originator supplies metadata using the syntax of extension headers (the [SMTPMSG] header syntax) that precede the message body. The header "tags" are as follows: A Disposition-Notification-To header is added to indicate that a message disposition notification is requested in the reply to the POST request. This header is specified in [MDN]. It may have values other than email addresses, such as a D-U-N-S number, when it is found as a name parameter in a form-data body part When this tag is used in HTTP extension headers, it follows the MDN usage. A Message-ID header is added to support message reconciliation, so that an Original-Message-Id value can be returned in the MDN Moberg, Brooks, Drummond, Fischer [page 7] HTTP Transport for Secure EDI May 2002 body part of the receipt. (The term "Receipts" is here used to refer to the signed or unsigned multipart/report content.) Both "From" and "To" extension headers SHOULD be supplied. The "From" value needs to have an email address as specified in [SMTPMSG] and [HTTP]. If other uses of "From" are needed, the generalized receipts to be next discussed should be used. There the role of "From" is replaced by symbols not having a reserved HTTP or SMTP usage. Other headers, especially "Subject" and "Date", should be supplied; the values of these headers are often mentioned in the human-readable section of a MDN to aid in identifying the original message. A Disposition-Notification-Options header is used to request a signed message disposition notification. The parameters used to select protocols for signed message disposition notification are found in [AS1]. Disposition-Notification-To is a name that, if present, indicates that the MDN style of receipt is to be used. Disposition-notification-options identifies characteristics of message disposition notification in accordance with [AS1] and [MDN]. A Receipt-delivery-option is a header whose value is a URL that indicates how the receipt is to be delivered. This header is only used within AS2. The default mode of operation is synchronous within HTTP transport, which means that the receipt (be it MDN, signed MDN, generalized report receipt, or signed report receipt) is returned in the reply body. By using the "receipt-delivery-option," an asynchronous reply mode can be requested. The values for this option are URLs that indicate the destination for the reply, and may use any appropriate protocol ("mailto", "http", and "https" will be the more common types) for this information. If this header/metadata is absent, then the mode of operation is synchronous, which means that the receipt is returned in the reply to the current HTTP request. 2.1.2 Requesting Generalized Receipts In this section, the ways to request generalized receipts are specified. Generalized receipts are multipart/reports with a report-type other than "disposition-notification," and a second automated response with a content type other than "message/disposition-notification". For requesting generalized receipts using the MIME template for multipart/reports [REPORTS], the following metadata elements will be useful. A specific example of a generalized receipt Moberg, Brooks, Drummond, Fischer [page 8] HTTP Transport for Secure EDI May 2002 with report-type "GISB-Acknowledgement-Receipt" will be presented in appendix B. When the term "metadata" is used in the following, the term indicates the information may be supplied in one of two ways: First, the metadata information may be supplied using the syntax of HTTP headers. That is, the symbol name is followed by a colon and its value follows; the header is subject to processing of structured field bodies [SMTPMSG, section 3.1.4], also including parameters. Second, the metadata information may be supplied by using the syntax of the "name" parameter within the "Content-Disposition" header of the multipart/form-data structure, when that MIME packaging [FORMDATA] is used. For example, --boundaryformdata Content-Disposition: form-data; name="Receipt-Report-Type" GISB-Acknowledgement-Receipt --boundaryformdata Within HTML, the symbols used for these names correspond to the value of the name attribute within the INPUT element, where the "type" attribute has a "text" value. [HTML], section 18; for example,
To indicate the various options for generalized receipts, the basic metadata that the POSTing client needs to convey to the replying server are: "Receipt-Disposition-To", and "Receipt-report-type", "Receipt-Security-Selection", "Receipt-Delivery-Option". The presence of the metadata value "Receipt-Disposition-To", using the extension header syntax, indicates a request for a generalized receipt. Because HTTP already has a role for the "From" header, the "Receipt-Disposition-To" header is used to avoid conflicts with [HTTP], when using the header syntax for metadata. (Within a multipart/form-data package, the "From" value can be used to identify the sending party without any conflict with HTTP headers.) Notice that the value for this identifier need not be an email address or a URL. In this way, other systems of identification (such as a DUNS number) may be Moberg, Brooks, Drummond, Fischer [page 9] HTTP Transport for Secure EDI May 2002 used, if needed. Notice that the information needed for delivery of the receipt is found in the receipt-delivery-option element described below; delivery information is not generally needed if the default mode of operation occurs. In that case, the receipt just goes back in the reply to the current HTTP request. "Receipt-Report-Type" indicates the desired value of the "report-type" parameter in the multipart/report content type of a specific version of the generalized receipt. This parameter must be supplied when "Receipt-Disposition-To" is used to indicate a request for a generalized receipt because this indicates what specific type of receipt is desired. An example for this value (discussed in appendix A) is "GISB-Acknowledgement-Receipt". "Receipt-Security-Selection" is a name that indicates the protocol and algorithm choices for a digital signature over the receipt. Signatures are always in multipart/signed packages. The format for protocol and algorithm choices is that used in [AS1] and [MDN]; for example, Receipt-Security-Selection: signed-receipt-protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,rsa-sha1 "Receipt-Delivery-Option" is used to indicate the URL for asynchronous delivery of the receipt. While the default mode of operation within HTTP transport is to return the receipt(be it MDN, signed MDN, generalized receipt, or signed generalized receipt) in the reply body, asynchronous reply is allowed through use of this symbol. The URLs will typically use the "MAILTO", "HTTP", and "HTTPS" schemes. For the HTTP and HTTPS schemes, the POST method is to be used. 2.1.2.1 Additional Commonly Used Headers The following set of header data elements are also available for use. Organizations wishing to use this specification for the secure and reliable transport of business documents are not required to utilize all of these headers and are free to use whatever subset they deem appropriate for their business needs. TO: The To name contains an identifier identifying the intended recipient of a data exchange and may be D&B D-U-N-S number [DUNS] or other agreed upon identifier system. Applications should allow users to configure these elements in the automated HTTP agents Moberg, Brooks, Drummond, Fischer [page 10] HTTP Transport for Secure EDI May 2002 processing these values. For example, the body part MIME header line looks like the following line: Content-Disposition: form-data; name="To" FROM: The From name contains a textual value identifying the sender of a data exchange, such as the a D&B D-U-N-S number [DUNS] as in [GISB]. Because "From" has a specified use within [HTTP], the From name parameter is not to be considered equivalent to the extension header. If an extension header "From" is to be used within HTTP, it should conform to the usage, syntax, and semantics of [HTTP] section 14.22. The extension header counterpart of the sender of a data exchange is the extension header version of "Receipt-disposition-to" INPUT-FORMAT: The Input-format name identifies the type of data contained in a data file. AGENT: The Agent name parameter indicates the network or agent where the data exchange originated. APPLICATION: The Application name identifies the application used to process the data next (after the URI-request process has finished with the stream). DATETIME: The DateTime name provides the date and time the data was created and uses the format specified in [SMTPMSG] as updated by RFC 1123. REFNUM: The RefNum is an integer value used to uniquely identify the communication exchange and is in a textual format. The RefNum is similar to the Message-ID and Content-Id headers of SMTP that are used in constructing values in receipts based on MDNs. USERPARAM: The UserParam is a user-defined parameter. Version: Version is a protocol version number [GISB]. TRANSACTION-SET: Transaction-set is an optional data element identifying the EDI transaction. INPUT-DATA: Input-data is the sending side's local file system name Moberg, Brooks, Drummond, Fischer [page 11] HTTP Transport for Secure EDI May 2002 for the file being sent. The payload is contained as the body part of this header element. PRIORITY: The "Priority" name is used to indicate the processing priority of each message relative to other messages sent by a given party. The value "1" indicates highest priority and a value of "5" indicates the lowest priority. EXPIRATION: The "Expiration" name is used to indicate the date and time at which a message is no longer transportable. No message delivery should be attempted beyond the date and time specified in this value. The date/time format must follow the specifications contained in section 5 of RFC822. 2.1.3 Summary Remarks on Receipt request options Applications are encouraged to support handling all metadata values whether they make use of the name parameter syntax within a multipart/form-data or whether they use the message header syntax used in SMTP or HTTP headers [SMTPMSG]. If metadata items are repeated in extension headers and in form-data parts, but the values are not the same, the extension header values will be selected for use. Because the value in Receipt-Disposition-To may have no significance for how the receipt is transported, the extension header "Receipt-delivery-option" is to be used to provide that information. The receipt-delivery-option's value should be a URL indicating the delivery transport destination for the receipt. The Receipt-delivery-option field is used when asynchronous delivery is desired. It should not be present if the intention is to deliver the reply synchronously; synchronous delivery of the reply is the default mode of delivery. For signed generalized receipts, an extension header of "Receipt-security-selection" should be added to indicate the desired security protocol for the multipart/signed over the multipart/report. In summary, the receipt request and construction processes now have the following options: 1. Receipt requests are made by conveying metadata values using a syntax of either the name parameter in a multipart/form-data's Content-Disposition headers or by using a syntax of HTTP extension headers. Moberg, Brooks, Drummond, Fischer [page 12] HTTP Transport for Secure EDI May 2002 2. Both MDN and generalized receipts can be requested using either syntax. However, using an extension header syntax and requesting a MDN receipt means restricting the "From" values to email addresses. 3. Either type of receipt comes in signed or unsigned versions. 4. Finally, receipts may be delivered synchronously (delivered in the HTTP reply) or asynchronously by using the "Receipt-delivery-option" header. 2.2 Sending EDI in HTTP Client Requests using POST For sending EDI, the following protocol elements are typically present: a request line ([HTTP], section 5.1), entity headers, a CRLF pair to mark the end of the entity headers, followed by the message-body. The request line will have the form: "POST Request-URI HTTP/1.1", with spaces and followed by a CRLF. The Request-URI is typically exchanged out of band, as part of setting up a bilateral trading partner agreement. Applications should be prepared to deal with an initial reply containing a status indicating a need for authentication of the usual types used for authorizing access to the Request-URI ([HTTP], section 10.4.2 and elsewhere). Automation of this process is not discussed in this document but might involve obtaining a session URL from a page requesting authentication and possibly other information about proposed EDI standard versions and other trading conventions to be used. The request line is followed by entity headers specifying content length ([HTTP] section 14.14) and content type [HTTP], section 14.18. The Host request header ([HTTP] sections 9 and 14.23) is also included. The entity or extension headers used for requesting a MDN (unsigned or signed) have previously been mentioned, as have those ("To" "From" "Message-Id") that are needed as values for MDN fields or for other receipt requests. For generalized receipts based on the multipart/report content type, the metadata can be the values found in extension headers, but can also be placed in body parts of a multipart/form-data using "name" parameters in the content-disposition header. Finally, the payload is found in any of the message patterns of [AS1] sections 4.2.1 to 4.2.4 or 4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. These payloads may arrive as the "input-data" part of the multipart/form-data or may even be enclosed in some other multipart. Moberg, Brooks, Drummond, Fischer [page 13] HTTP Transport for Secure EDI May 2002 2.3 Using Transport Layer Security To use Transport Layer Security [TLS], the request-URI should indicate the appropriate scheme value, HTTPS. Usually only a multipart/signed message body would be sent using TLS, as encrypted message bodies would be redundant. Encrypted message bodies are not prohibited, however. For asynchronous receipt delivery requests, use the "Receipt-delivery-option" header with a URL value making use of the HTTPS scheme to obtain confidentiality. 2.4 Response Status Codes in Replies The status line for response to errors in the POST request line will be provided by a status line with the following protocol elements present ([HTTP], section 6.1): HTTP version (normally, The status codes return status concerning HTTP operations. For example, the status code 401, together with the WWW-Authenticate header, is used to challenge the client to repeat the request with an Authorization header. Other explicit status codes are documented in [HTTP], sections 6.1.1 and throughout section 10. HTTP/1.1), a status code, reason phrase, and CRLF. For errors in the request-URI, 400 ("Bad Request"), 404 ("Not Found") and similar codes are appropriate status codes. These codes and their semantics are specified by [HTTP]. A careful examination of these codes and their semantics should be made before implementing any retry functionality that is described below; specifically, retries should not be made if the error is not transient or if retries are explicitly discouraged (for real authentication failures, for example.) 2.5 Receipt Reply The details of the response to the POST command vary depending upon whether a receipt has been requested and upon what kind of receipt has been requested. With no extended header requesting a receipt, and no errors accessing the request-URI specified processing, the status line in the Response to the POST request should be in the 200 range. Status codes in the 200 range should also be used when an entity is returned (a signed receipt in a multipart/signed content type or an unsigned receipt in a multipart/report). Even when the disposition of the data was an error condition at the authentication, decryption or other higher level, the HTTP status code should indicate success at the HTTP level. The HTTP server-side application may respond with an unsolicited multipart/report as a message body that the HTTP client Moberg, Brooks, Drummond, Fischer [page 14] HTTP Transport for Secure EDI May 2002 might not have solicited, but this may be discarded by the client. Applications should avoid emitting unsolicited receipt replies because bandwidth or processing limitations might have led administrators to suspend asking for acknowledgements. When a Disposition-Notification-To extension header is present in the POST request entity headers, then entity headers for the MDN should be included. The content type for the MDN receipt (multipart/report [REPORT] or multipart/signed [SECURITY]) should be included in the Response entity headers. The basic responsibilities of responding to requests are discussed in [AS1] section 5, and in detail within section 5.2.1. 2.5.1 MDN based Receipts and Signed MDN Receipts Message Disposition Notifications, when used in the HTTP reply context, will closely parallel a SMTP MDN. For example, the disposition field is a required element in the machine readable second part of a multipart/report for a MDN. The final-recipient-field ([MDN] section 3.1) value should be derived from the entity headers of the request. If the "To" field is missing, for signed messages, the value for Original-recipient may be the email address field from the signer's X.509 attribute for email addresses, if that value is available. For a MDN, an application must report the Message-ID of the request. The human readable part (the first part of the multipart/report) should include items such as the subject, date and other information when those fields are present in entity header fields following the POST request. The HTTP reply should normally omit the third optional part of the multipart/report (used to return the original message or its headers in the SMTP context). 2.5.2 Generalized Receipts and Signed Receipts For generalized receipts, the multipart/report [REPORT] or a multipart/signed containing a multipart/report as the signed data is the basic MIME packaging. Each generalized receipt needs a value for the multipart/report parameter, "report-type," a selection of a content-type for its second body part, when signed, a hash value over a defined portion of the original message and, when asynchronously delivered, information allowing the identification of the original POSTed message. The basic structure of the multipart/report is used so that the first part is a "human-readable" message concerning the received message. The second part should be for automated process utilization. It should at least possess some common Internet Moberg, Brooks, Drummond, Fischer [page 15] HTTP Transport for Secure EDI May 2002 syntax for expressing names and values, such as the [SMTPMSG] header syntax, XML, or some MIME content type correlated with automated processing. The MDN requirements, therefore, are removed for this second part, but information used in MDNs may be used here. The third part of the multipart report is usually omitted in the HTTP context, but could include the extension headers, or even the entire payload, to provide diagnostic information. A multipart/signed over a multipart/report is constructed precisely in the same way as a multipart/signed over a MDN [AS1]. One metadata element should be within the automated part. This is the Received-Content-MIC (also allowing X-Received-Content-MIC). This value is constructed and formatted as described in [AS1] and the syntax should be either RFC822: Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==, rsa-md5 or simple XML w7AguNJEmhF/qIjJw6LnnA== Original-Message-ID: <43141asfioufasd@somewhere.com> Otherwise the automated acknowledgement semantics are left open to specific definition by other electronic commerce communities, such as in [GISB]. Each specialization of the generalized receipt should make use of a explicit identifying value to be placed in the parameter "report-type," Any original metadata thought useful to include in the automated part may be reflected back using "Original-X", as in Content-Type: multipart/report; report-type="identifying-value"; boundary="=-Trfds88fd99" Implementations should attempt to be configurable to allow for new report-type values to be added; communities can then agree to the specific extensions they need to support application level routing, transaction identification, timestamps, and other specialized information about the data they have exchanged. Moberg, Brooks, Drummond, Fischer [page 16] HTTP Transport for Secure EDI May 2002 2.6 Additional Reply Content In general, both HTTP servers and HTTP clients should be prepared to process the basic EDIINT data formats when they are embedded within MIME multiparts. This is true for HTTP request payloads as well as HTTP reply payloads. So, as previously mentioned, for HTML-based POSTS, any of the EDIINT templates described in [AS1], sections 4.2.1 to 4.2.4 or 4.3.1 to 4.3.4 for PGP/MIME or S/MIME security, may be found as parts of a multipart/form-data. [Consult Appendix A for the templates adapted for this document.] In addition, the response to the POST operation may include other MIME wrapped content besides an MDN Receipt, Signed MDN, Generalized Receipt or Signed Generalized Receipt. If a receipt was requested within the POST data, and additional content is to be returned, the receipt multipart/report must be combined with the other data using some MIME multipart pattern. Real-time EDI processing systems may use MIME multipart content-types to include a response EDI message, for example, a Quote in response to a Request-For-Quote transaction. Also, if requested, the sender may request an asynchronous mode for return of receipt. This mode is indicated by including the metadata for Receipt-delivery-option as explained above. 2.7 Non-Repudiation of the POST Reply If the reply to a POST operation needs a MDN receipt for non- repudiation (for example, the reply includes content other than a receipt), the top-level headers in the response include the same headers required for POST data described above: Disposition-Notification-To, Message-ID, From, and To. Other headers described above used in a MDN should be included, for example, Date and Subject. The MDN receipt of the response data is returned using a subsequent POST operation. A POST operation used only to transmit an MDN MUST NOT include the Disposition-Notification-To receipt request, and only a 200 ("OK") response would be expected. An MDN in response to a reply may be combined with a subsequent EDI message sent with a POST operation, for example a Purchase-Order transaction in response to a Quote. The MIME multipart/mixed form is used to combine the MDN with the other data, the same as for a POST reply. Moberg, Brooks, Drummond, Fischer [page 17] HTTP Transport for Secure EDI May 2002 2.8 Error Recovery If the HTTP client fails to read the HTTP server response data, the POST operation with identical content (including Message-ID, RefNum, and other header elements) should be repeated, if the error condition is transient. The Message-ID or RefNum on a POST operation can be reused if and only if all of the content (including the original Date) is identical. Details of the retry process -- including time intervals to pause, number of retries to attempt, timeouts for retrying -- are implementation dependent. Servers should be prepared to receive a POST with a repeated Message-ID. The MIME reply body previously sent should be resent, including the MDN and other MIME parts. 3. Other differences to notice in HTTP and SMTP based transport For HTTP version 1.1, TCP persistent connections are the default, ([HTTP] sections 8.1.2, 8.2, and 19.7.1). A number of other differences exist because HTTP does not conform to MIME [MIME] as used in SMTP transport. Relevant differences are summarized below. 3.1 Unused MIME headers and operations 3.1.1 Content-Transfer-Encoding not used in HTTP transport HTTP can handle binary data and so there is no need to use the Content transfer encodings of MIME [MIME]. This difference is discussed in [HTTP] section 19.4.4. 3.1.2 Epilogue must be empty The EBNF for a multipart [MIME] RFC 2046, section 5.1.1 allows a multipart to have trailing octets after the close delimiter. In [HTTP] section 3.7.2, it is explicitly noted that multiparts must have null epilogues. 3.1.3 Lengthy message bodies In [AS1], section 5.4.1, options for large file processing are discussed for SMTP transport. For HTTP, large files should be handled correctly by the TCP layer. However, [HTTP] sections 3.5 and 3.6 discuss some options for compressing or chunking entities to be transferred. Section 8.1.2.2 discusses a pipelining option that is useful for segmenting large amounts of data. Moberg, Brooks, Drummond, Fischer [page 18] HTTP Transport for Secure EDI May 2002 3.2 Differences in MIME or other headers or parameters used 3.2.1 Content-Length Because connections are persistent, closing a connection cannot be used to indicate the end of an entity. Therefore, [HTTP] sections 4.4 and 14.14 indicate the need for a Content-Length entity header in a request. 3.2.2 Final and Original Recipient The final and original recipient distinction should not arise for HTTP transport because SMTP aliases and mailing lists should not be used. 3.2.3 Message-Id and Original-Message-Id The Message-Id and Original-Message-Id distinction should not arise for HTTP transport because SMTP MTA alterations should not occur. Message-Id is formatted as defined in RFC2822: "<" id-left "@" id-right ">" (RFC2822 3.6.4) Message-Id length is a maximum of 998 characters. For maximum backward compatibility, Message-Id length SHOULD be 255 characters or less. Message-Id SHOULD be globally unique, id-right should be something unique to the sending host environment (e.g. a host name). When sending a message, always include the angle brackets. Angle brackets are not part of the Message-Id value. For maximum backward compatibility, when receiving a message, do not check for angle brackets. When creating the Original-Message-Id header in an MDN, always use the exact syntax as received on the original message - don't strip or add angle brackets. 3.2.4 Host header The host request header field must be included in the POST request made when sending business data. This field is to allow one server IP address to service multiple hostnames, and potentially conserve IP addresses. See [HTTP], sections 14.23 and 19.5.1. Moberg, Brooks, Drummond, Fischer [page 19] HTTP Transport for Secure EDI May 2002 4. Additional AS2 specific HTTP headers The following headers are to be included in all AS2 messages and all AS2 MDNs. 4.1 AS2 Version Header To promote backward compatibility AS2 includes a version: AS2-Version: 1.0 This header MUST be present on all AS2 messages and AS2 MDNs, but not in a single line response (see section 2.4). Receiving systems MUST NOT fail due to the absence of the AS2-Version header. This would indicate the message is from an older system. 4.2 AS2 System Identifiers The receiving system needs to obtain the identity of the sending system. This may be company specific, such as DUNS number, or it may be simply an identification string agreed upon between the trading partners. The two AS2 headers are: AS2-From: < AS2-name > AS2-To: < AS2-name > These AS2 headers contain textual values, as described below, identifying the sender/receiver of a data exchange. This information MUST appear either in the AS2-From/AS2-To headers or in the GISB Form-Data; name="from"/"to" (see appendix B). AS2-text = "!" / ; printable ASCII characters %d35-91 / ; except double-quote (%d34) %d93-126 ; or backslash (%d92) AS2-qtext = AS2-text / SP ; allow space only in quoted text AS2-quoted-pair = "\" DQUOTE / ; \" or "\" "\" ; \\ AS2-quoted-name = DQUOTE 1*128( AS2-qtext / AS2-quoted-pair) DQUOTE AS2-atomic-name = 1*128AS2-text AS2-name = AS2-atomic-name / AS2-quoted-name The AS2-From header value and the AS2-To header value MUST each be an AS2-name, MUST each be comprised of Moberg, Brooks, Drummond, Fischer [page 20] HTTP Transport for Secure EDI May 2002 from 1 to 128 characters and MUST NOT be folded. The value in each of these headers is case-sensitive. The AS2-quoted-name SHOULD be used only if the AS2-name does not conform to AS2-atomic-name. The string definitions given above are in ABNF format. 4.2.1 Unrecognized System Identifiers If either the AS2-From or the AS2-To or the combination of both header values is determined to be invalid or unknown by the receiving system, the receiving system MAY respond in one of the following ways, but is not limited to these options: 1. The receiving AS2 system MAY disconnect from the sending AS2 system before completing the reception of the entire entity if it determines the HTTP headers do not represent a valid trading-relationship. 2. The receiving AS2 system MAY disconnect from the sending AS2 system before completing the reception of the entire entity if it determines the entity being sent is too large to process. 3. The receiving AS2 system MAY return an HTTP response with a response code in the 2xx range, with or without any explanation of the error, even if the sending system requested an MDN. 4. The receiving AS2 system MAY return an unsigned MDN with an explanation of the error, if the sending system requested an MDN. Moberg, Brooks, Drummond, Fischer [page 21] HTTP Transport for Secure EDI May 2002 Appendices A. AS2 MIME templates Structure of an AS2 MIME message - PGP/MIME No encryption, no signature (analog of 4.2.1) -RFC2068/2045 -RFC1767/RFC2376 (application/EDIxxxx or /xml) No encryption, signature (analog of 4.2.2) -RFC2068/2045 -RFC1847 (multipart/signed) -RFC1767/RFC2376 (application/EDIxxxx or /xml) -RFC2015 (application/pgp-signature) Encryption, no signature (analog of 4.2.3) -RFC2068/2045 -RFC1847 (multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version: 1" -RFC2015 (application/octet-stream) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) Encryption, signature (analog of 4.2.4) -RFC2068/2045 -RFC1847 (multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version: 1" -RFC2015 (application/octet-stream) -RFC1847 (multipart/signed)(encrypted) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) -RFC2015 (application/pgp-signature)(encrypted) Structure of an AS2 MIME message - S/MIME No encryption, no signature (analog of 4.3.1) -RFC2068/2045 -RFC1767/RFC2376 (application/EDIxxxx or /xml) No encryption, signature (analog of 4.3.2) -RFC2068/2045 -RFC1847 (multipart/signed) -RFC1767/RFC2376 (application/EDIxxxx or /xml) -RFC2633 (application/pkcs7-signature) Moberg, Brooks, Drummond, Fischer [page 22] HTTP Transport for Secure EDI May 2002 Encryption, no signature (analog of 4.3.3) -RFC2068/2045 -RFC2633 (application/pkcs7-mime) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) Encryption, signature (analog of 4.3.4) -RFC2068/2045 -RFC2633 (application/pkcs7-mime) -RFC1847 (multipart/signed)(encrypted) -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) -RFC2633 (application/pkcs7-signature)(encrypted) B. AS2 Extensions for the GISB Protocol and Report-type GISB AS2 Profile The United States based Gas Industry Standards Board (GISB) is a consortium of companies and individuals that operate in the Gas Industry. The membership is divided into 5 sectors, Producers, Pipelines, Services, End Users, Local Distribution Companies, representing the various type of organizations within the industry. In 1996 GISB initiated a program to move from the expensive Value Added Networks they were using, to the Internet. By October of 1996GISB had developed and tested a protocol, called GISB Electronic Delivery Mechanism (EDM), which uses HTTP and is based on RFC1867 (Form-based File Upload in HTML). By May 1997 this protocol was being used by Enron and others to send/receive live, mission critical business transactions over the Internet. Additional companies followed suit and a large percentage of today's business transactions in the Gas Industry are transmitted over the Internet using the GISB EDM protocol. In 1998 the Automobile Industry Action Group (AIAG) adopted the GISB EDM protocol and in 1999 the local electric companies serving the state of Pennsylvania declared the GISB protocol as their standard for transmitting business transactions via the Internet. In May of 1999 the AIAG, GISB and members of the IETF EDIINT workgroup initiated an effort to converge their independent specifications, the result of which is this specification. In order to bring the GISB EDM into compliance with this specification GISB initiated a formal change to the EDM specification. The following information, referred to as the "GISB AS2Profile", reflects the planned utilization of this specification by the GISB membership. The GISB membership will utilize PGP to meet all P.A.I.N. requirements. All data exchanges will utilize the multipart/form- data enveloping method and two generalized receipts, GISB-Acknowledgement-Receipt and GISB-Error-Notification. All Moberg, Brooks, Drummond, Fischer [page 23] HTTP Transport for Secure EDI May 2002 original business transactions must be digitally signed (using encapsulated signatures) and encrypted using RSA algorithms. Upon successful transfer of an original business transaction the receiver is required to send a GISB-Acknowledgement-Receipt indicating that the transfer has completed successfully. If, upon further processing of the business document an error is encountered a GISB-Error-Notification is sent to the original sender using the multipart/form-data enveloping. It is expected that companies following the GISB AS2 profile will protect their web sites from unauthorized access through the use of basic authentication (username/passwords), as defined in the HTTP specification. GISB is not "requiring" the use of signed receipts; however, signed receipts are allowed between consenting trading partners. GISB has decided to use the following core headers: FROM: Contains the DUNS number of the sending party TO: Contains the DUNS number of the intended recipient INPUT-FORMAT: Type of data being sent (only x12 and error currently supported) other options can easily be added to this list. INPUT-DATA: The actual payload containing the business transaction or GISB-Error-Notification. If the payload contains a business transaction it is signed and encrypted using PGP. Version: The GISB version number (currently 1.3) RECEIPT-DISPOSITION-TO: The DUNS number of the party to receive the GISB-Acknowledgement-Receipt (typically the same DUNS number associated with the From header.) Presence of this field also serves as a flag indicating that an acknowledgement receipt is requested by the sender. The receipt is returned synchronously (on the same session used to send the input-data payload). RECEIPT-REPORT-TYPE: Contains the value GISB-Acknowledgement-Receipt. Optional headers also available: TRANSACTION-SET: Identifies the type of transaction contained in the input-data payload. Moberg, Brooks, Drummond, Fischer [page 24] HTTP Transport for Secure EDI May 2002 RECEIPT-SECURITY-SELECTION: This field serves as a flag indicating that a signed receipt is being requested. The contents of this field indicate the algorithm and signature type to use in constructing the signature. Example of a GISB data exchange: The sending party creates an X12 business transaction and concatenates with an RFC 1767 compliant header. The entire package is then encrypted and signed using PGP. The encrypted package is then enveloped with the appropriate headers/values and sent to the trading partner using HTTP POST, the contents of this post appear as follows: POST c:\execute HTTP/1.0 Referer: http://www.get.a.life/upl.htm Connection: Keep-Alive User-Agent: brow v0.1 XYZ Corp. Host: localhost Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Content-type: multipart/form-data; boundary=---------------------------87453838942833 Content-Length: 5379 -----------------------------87453838942833 Content-Disposition: form-data; name="from" 123456789 -----------------------------87453838942833 Content-Disposition: form-data; name="to" 234567890 -----------------------------87453838942833 Content-Disposition: form-data; name="Version" 1.3 -----------------------------87453838942833 Content-Disposition: form-data; name="receipt-disposition-to" 123456789 -----------------------------87453838942833 Content-Disposition: form-data; name="receipt-report-type" GISB-Acknowledgement-Receipt -----------------------------87453838942833 Content-Disposition: form-data; name="input-format" x12 -----------------------------87453838942833 Content-Disposition: form-data; name="input-data"; filename=c:\temp\smallnom.bin Moberg, Brooks, Drummond, Fischer [page 25] HTTP Transport for Secure EDI May 2002 Content-Type: multipart/encrypted; boundary=9876; protocol="application/pgp-encrypted" --9876 Content-Type: application/pgp-encrypted Version: 1 --9876 Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: PGP 6.5 hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9 UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+ 4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4= =Oiuo -----END PGP MESSAGE----- --9876-- -----------------------------87453838942833-- Upon receiving the above stream of data the receiving host parses the headers and returns an unsigned GISB-Acknowledgement-Receipt, appearing as follows: Content-Type: multipart/report; report-type="GISB-Acknowledgement-Receipt"; boundary="GISB7867" --GISB7867 Content-type: text/html Acknowledgement Receipt Success

time-c=19960619082855* request-status=ok* server-id=coolhost* trans-id=234423897*

--GISB7867 Content-type: text/plain Moberg, Brooks, Drummond, Fischer [page 26] HTTP Transport for Secure EDI May 2002 time-c=19960619082855* request-status=ok* server-id=coolhost* trans-id=234423897* --GISB7867-- C. Samples of AS2 Protocol Data Units C.1 The following example illustrates the full HTTP request that sends X12 EDI data from company1 to company2. A signed receipt is requested; the receipt is to be a MDN report-type, with the pkcs7 signature option, using a signature algorithm of rsa-md5. The receipt is to be sent synchronously (that is, in the reply to this HTTP request), because no special delivery options are indicated. POST https://tp2server.company2.com/cgi-bin/tp1drawer.pl HTTP/1.1 Host: tp2server.company2.com AS2-To: zzzcompany2 AS2-From: zzzcompany1 AS2-Version: 1.0 From: ediadmin@company1.com Date: Tue, 06 Nov 2001 12:53:01 UT Subject: Purchase orders for 6 November 2001 Message-Id: <20011106@company1.com> Disposition-Notification-To: tp1@company1.com Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional,rsa-md5 Content-Type: multipart/signed; boundary="20011106RsXgYlvCNW"; protocol=application/pkcs7-signature; micalg=rsa-md5 Content-Length: 3056 --20011106RsXgYlvCNW Content-Type: application/edi-x12 Content-Disposition: Attachment; filename=rfc1767.dat [ISA ...EDI transaction data...IEA...] --20011106RsXgYlvCNW Content-Type: application/pkcs7-signature [omitted binary pkcs7 signature data] --20011106RsXgYlvCNW-- Moberg, Brooks, Drummond, Fischer [page 27] HTTP Transport for Secure EDI May 2002 C.2 This second example illustrates returning a signed MDN that corresponds to the request for a MDN found in C.1. HTTP/1.0 200 OK Server: HTTPEDI/1.1 AS2-To: zzzcompany1 AS2-From: zzzcompany2 AS2-Version: 1.0 Content-type: multipart/signed; boundary="boundary1" Content-Length: 1200 --boundary1 Content-type: multipart/report; boundary="boundary2" --boundary2 Content-type: text/plain Message <20011106@company1.com> was authenticated; EDI processing was initiated. --boundary2 Content-type: message/disposition-notification Reporting-UA: Company2UA Final-Recipient: rfc822; tp2@company2.com Original-Message-Id: <20011106@company1.com> Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==, rsa-md5 Disposition: MDN-sent-automatically/processed --boundary2-- --boundary1 Content-Type: application/pkcs7-signature [Signature data omitted] --boundary1-- D. Acknowledgments Carl Hage, Karen Rosenfeld, Chuck Fenton and many others have provided valuable suggestions improving this applicability statement. E. References [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997 [AS1] T. Harding, R. Drummond, C. Shih, "Peer-to-Peer MIME-based Secure Business Data Interchange", April 2002, Internet draft: draft-ietf-ediint-as1-17.txt. Moberg, Brooks, Drummond, Fischer [page 28] HTTP Transport for Secure EDI May 2002 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. [FORMDATA] L. Masinter, "Returning Values from Forms: multipart/form-data", RFC 2388, August, 1998. [GISB] Gas Industry Standards Board, "Electronic Delivery Mechanism Related Standards", Version 1.3 July 31, 1998 [HTML] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0 Specification", World Wide Web Consortium Technical Report "REC-html40", December, 1997. [HTTP] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol--HTTP/1.1", RFC 2068, March 1997. [MIME] N. Borenstein, N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 02, 1996. [MIMEEDI] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995. [MIMEPGP] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, Sept. 1996. [MDN] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [SECURITY] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995 [SMTP] P. Resnick, Editor "Internet Mail Format", RFC 2822, April 2001. [SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, "S/MIME Version 2 Message Specification", RFC 2311. [SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, March 15, 1996. Moberg, Brooks, Drummond, Fischer [page 29] HTTP Transport for Secure EDI May 2002 [TLS] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246, March 1999. [MIME-TYPES] "Media Types," http:// www.isi.edu/in-notes/iana/assignments/media-types/media-types [XMLTYPES] E. Whitehead, M. Murata, "XML Media Types", RFC 2376, July 1998. F. Security Considerations This entire document is concerned with secure transport of business to business data and considers both privacy and authentication issues. G. Authors' Addresses Dale Moberg dale_moberg@cyclonecommerce.com Cyclone Commerce 8388 E. Hartford Drive Scottsdale, AZ 85255 USA Dick Brooks dick.brooks@systrends.com Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 USA Rik Drummond rik@drummondgroup.com Drummond Group 5008 Bentwood Ct. Fort Worth, TX 76132 USA David Fischer david@drummondgroup.com Drummond Group 4200 S. Hulen St. Suite 600 Fort Worth, TX 76109 USA Moberg, Brooks, Drummond, Fischer [page 30] ------=_NextPart_000_000B_01C2C795.524567D0-- From owner-ietf-ediint@mail.imc.org Wed Jan 29 15:12:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28473 for ; Wed, 29 Jan 2003 15:12:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TJpxo28944 for ietf-ediint-bks; Wed, 29 Jan 2003 11:51:59 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TJpwo28939 for ; Wed, 29 Jan 2003 11:51:58 -0800 (PST) Received: from e2 (12-234-192-139.client.attbi.com[12.234.192.139]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003012919515400300jhs72e>; Wed, 29 Jan 2003 19:51:55 +0000 From: "Carl Hage" To: Date: Wed, 29 Jan 2003 11:52:02 -0800 MIME-Version: 1.0 Subject: Re: EDIINT AS2-U, AS2-G and a separate conformance document? Message-ID: <3E37C062.15004.516425B6@localhost> In-reply-to: X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT From: pbyrne@gpu.com Date sent: Wed, 29 Jan 2003 13:05:12 -0500 > However, I am against the notion of AS2-U and AS2-G!! The former version > is used by many more than just the UCC and the latter version is named for > a group that no longer exists! Instead of U and G, a letter matching the style could be used in lieu the name of an organization, e.g. M and F, for MIME and Form-Data. Or choose some letter that better describes the technical difference. -------------------------------------------------------------------------- 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 Wed Jan 29 15:39:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29179 for ; Wed, 29 Jan 2003 15:39:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TKKBi00586 for ietf-ediint-bks; Wed, 29 Jan 2003 12:20:11 -0800 (PST) Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [12.34.72.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0TKKAo00581 for ; Wed, 29 Jan 2003 12:20:10 -0800 (PST) Received: from SEMINOLEVS2.cyclonecommerce.com ([10.1.0.20]) by spyglass.cyclonecommerce.com (NAVGW 2.5.1.13) with SMTP id M2003012913180408119 ; Wed, 29 Jan 2003 13:18:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: EDIINT AS2-U, AS2-G and a separate conformance document? Date: Wed, 29 Jan 2003 13:18:04 -0700 Message-ID: <9551E76040A2604BBD331F3024BFEA48EF61F0@SEMINOLEVS2.cyclonecommerce.com> Thread-Topic: EDIINT AS2-U, AS2-G and a separate conformance document? Thread-Index: AcLHxbgk+JXiIbDpS26ypb+HIoxFmgAC01xw From: "Dale Moberg" To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0TKKBo00583 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree with Pete Byrne's naming solution. This issue is not primarily a technical one. However, the new AS2 document contains the functionality that is by far the more widely used and identified as "AS2". Also, if there is a conformance document (and I think it is not essential to have one), it should basically say that a product may implement AS1 AS2 and/or AS3. If it does AS2 without AS1, however, it probably will not be able to return MDNs asynchronously over email. That aside, a product that does all is expected to interoperate with products that do a subset, and conversely. In general, products that each do a subset should be able to be configured to interoperate provided that the two subsets have an intersection that isn't empty! Dale Moberg -----Original Message----- From: pbyrne@gpu.com [mailto:pbyrne@gpu.com] Sent: Wednesday, January 29, 2003 11:05 AM To: dick@systrends.com Cc: ietf-ediint@imc.org Subject: Re: EDIINT AS2-U, AS2-G and a separate conformance document? Dr. Brooks, et al, I agree with Crough (20030115, 20030116, 20030117), Moberg (20030116, 20030117, 20030121), and you (20030128): create two documents, one from the version 12 draft and one based on the version 11 draft but to be edited and republished. However, I am against the notion of AS2-U and AS2-G!! The former version is used by many more than just the UCC and the latter version is named for a group that no longer exists! Let's recognize reality and move straight to draft-ietf-as2-12.txt and to draft-ietf-as3-1.txt and be done with it! That way, people can concentrate on conforming to the one 'standard' predominately used in their industry. With two ASs, is there a need for a conformance document? Pete --------------------------------- Pete Byrne EC/EDI Group, FirstEnergy Services Electronic Communications for the Efficient Delivery of Information Tel: 610-939-4334 Fax: 330-315-8465 pbyrne@gpu.com "Dick Brooks" om> cc: (bcc: Pete Byrne/GPU) Subject: EDIINT AS2-U, AS2-G and a separate conformance document 2003-01-29 11:37 AM Please respond to dick Dr. Byrne, How do you feel about the proposed compromise? - Create two documents and call them AS2-U and AS2-G - The draft produced by Rik and Dale will be called AS2-U - A new draft will be created for AS2-G, which will be largely based on the text that was removed from AS2 draft 11. - Following the MIME model, the group will create a conformance document along the lines of RFC 2049. This will spell out in detail what is required to be AS2 conformant. Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714 From owner-ietf-ediint@mail.imc.org Thu Jan 30 08:26:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27215 for ; Thu, 30 Jan 2003 08:25:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UCush00549 for ietf-ediint-bks; Thu, 30 Jan 2003 04:56:54 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UCuqo00544 for ; Thu, 30 Jan 2003 04:56:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25739; Thu, 30 Jan 2003 07:53:20 -0500 (EST) Message-Id: <200301301253.HAA25739@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ediint@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ediint-compression-01.txt Date: Thu, 30 Jan 2003 07:53:19 -0500 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : Compressed Data for EDIINT Author(s) : T. Harding Filename : draft-ietf-ediint-compression-01.txt Pages : 5 Date : 2003-1-29 The intent of this document is to be placed on the RFC track as an Informational RFC. The EDIINT AS1 and AS2 message formats don't currently contain any transport neutral provisions for compressing data when utilizing S/MIME as the secure packaging standard. Compressing data before transmission provides a number of advantages including 1. reducing data redundancy, and so reducing opportunities for attacks exploiting redundancy, and 2. reducing the amount of data and so speeding up cryptographic processing such as signing, encryption, archiving, and 3. reducing the overall transmitted message size, reducing both time and bandwidth needed for transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-compression-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ediint-compression-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-29154640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ediint-compression-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ediint-compression-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-29154640.I-D@ietf.org> --OtherAccess-- --NextPart--