RE: Comments on the recent EDIINT AS2 v12 draft

MessageGary, 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