Rik Drummond | 12 Jan 22:34 2003

test




<<...>>

Rik Drummond | 14 Jan 22:40 2003

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
       





<<...>>

Jaime.Zepeda | 14 Jan 23:04 2003

test


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.

Dick Brooks | 15 Jan 02:10 2003

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 <db> and </db>.
 

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.

<db> 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.
</db>

        - 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.

<db>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:
 
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. 
 </db>

        - the twenty plus vendors interop testing help make the v12 draft clearer
<db>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.
</db>

        - 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

<db>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.
</db>

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

<db>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.
</db>

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…

<db>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.
</db>

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
 
-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of Rik Drummond
Sent: Tuesday, January 14, 2003 2:41 PM
To: ietf-ediint <at> 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
       





<<...>>

Rik Drummond | 15 Jan 23:50 2003

RE: Comments on the recent EDIINT AS2 v12 draft

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 -----
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 <db> and </db>.
 

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.

<db> 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.
</db>

        - 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.

<db>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:
 
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. 
 </db>

        - the twenty plus vendors interop testing help make the v12 draft clearer
<db>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.
</db>

        - 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

<db>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.
</db>

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

<db>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.
</db>

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…

<db>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.
</db>

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
 
-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of Rik Drummond
Sent: Tuesday, January 14, 2003 2:41 PM
To: ietf-ediint <at> 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
       





<<...>>

Gary Crough | 16 Jan 02:28 2003

RE: Comments on the recent EDIINT AS2 v12 draft

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.
 
    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.
 
    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. 
 
    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.
 
    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?
 
-----Original Message-----
From: Rik Drummond [mailto:rvd2 <at> drummondgroup.com]
Sent: Wednesday, January 15, 2003 3:50 PM
To: ietf-ediint <at> 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.
 
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 -----
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 <db> and </db>.
 

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.

<db> 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.
</db>

        - 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.

<db>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:
 
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. 
 </db>

        - the twenty plus vendors interop testing help make the v12 draft clearer
<db>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.
</db>

        - 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

<db>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.
</db>

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

<db>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.
</db>

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…

<db>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.
</db>

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
 
-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of Rik Drummond
Sent: Tuesday, January 14, 2003 2:41 PM
To: ietf-ediint <at> 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
       





<<...>>

Dick Brooks | 16 Jan 05:59 2003

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
 

Andrew Stickland | 16 Jan 12:10 2003

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 <at> tech-comm.com]
Sent: 16 January 2003 05:00
To: Gary Crough; ietf-ediint <at> 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

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



Costa, Michael J. | 16 Jan 14:52 2003
Picon

RE: Comments on the recent EDIINT AS2 v12 draft

 
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 <at> coned.com
Voice Mail: 212.460.2994
Pager: 917.360.3197

 
 
 
 
-----Original Message-----
From: Andrew Stickland [mailto:Andrew.Stickland <at> perwill.com]
Sent: Thursday, January 16, 2003 6:11 AM
To: ietf-ediint <at> 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 <at> tech-comm.com]
Sent: 16 January 2003 05:00
To: Gary Crough; ietf-ediint <at> 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

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



Steve Lowery | 16 Jan 15:51 2003

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." <CostaM <at> coned.com> 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 <at> coned.com 
Voice Mail: 212.460.2994 
Pager: 917.360.3197 

-----Original Message-----
From: Andrew Stickland [mailto:Andrew.Stickland <at> perwill.com] 
Sent: Thursday, January 16, 2003 6:11 AM
To: ietf-ediint <at> 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 <at> tech-comm.com] 
Sent: 16 January 2003 05:00
To: Gary Crough; ietf-ediint <at> 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 <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 

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


Gmane