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