From: Chris Davenport [mailto:chris@xxxxxxxxxxxxxxxxxx]
In message <GJEAKDBCGBOFGCFOCMLMGEKADNAA.dick@xxxxxxxxxxxxx>, Dick
Brooks <dick@xxxxxxxxxxxxx> 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.
|
