Hi
All,
(Ive
reviewed the current Interoperability Suite and I found 2 minor
inconsistencies in the text
that
I have detailed directly below.)
For
"Simple" or "Default" CPA, I think what we at DGI are thinking is that some
sort of
default CPA can be built that will be helpful to assist vendors
targeting SMEs (Small
to
Medium Sized Enterprises), we would like to drive the market adoption of
ebXML Message
Service by SMEs, we believe that this is a worthwhile goal
of the whole ebXML effort, and
that
it could help overall market adoption of ebXML.
I'm
not sure that what we are thinking fits well with what IIC is trying to
accomplish immediately
in
the current IIC Interoperability document... the
CPA stuff from Steve Yung looks like an informative/descriptive
simple CPA but the CPA stuff that Michael Kass put out looks
like a full blown CPA that is trying to capture
all
the canSend/CanReceive kind of details for the Test Framework.... hopefully
the attached is useful input.
For
DGI, we define in our test suite the parameters for each test,
and
we think weve got a pretty good handle on what paramaters are absolutely
required for
Interoprability. Of course, we have to keep in mind that many
implementations do not yet
physically use CPP/CPA. Attached is a list of the parameters that
we use for each of
our
current ebXML Message Service tests, the table shows where the parameters
map to specific
version 2 CPA fields. Let me know if this doesnt make sense, or
you cant read it...
Earlier today, I forwarded a mail, from Matt Mackenzie, who has
made an initial proposal to
the
ebXML Messaging Committee related to "default
CPAs".
------------------------------------------------------------------------------------------------------------------------------
Specific comments on inconsistencies in IIC Interoperability Suite
version 1.01
1)
Section 4.1.2 CPA Data. The description of which test the CPAs relate to,
needs to be renumbered.
For example,
"Urn:config:cpa_basic_reliablesync
(for test cases 1.10)."
Test
case 1.10 has been renamed to 1.9.
2) Section 3.29
Test Case 1.9. The description under Test Material says "at both MSH set
signature to yes" but
the
description directly below this text, and in the related CPA, say that none of
request nor ack nor response
should be
signed.