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?
