RE: FW: [ebxml-iic-interop] comments on Interop suite

At 12:15 AM 1/20/2003 -0800, Jacques Durand wrote:

Mike:
inline

-----Original Message-----
From: Michael Kass
[mailto:]
Sent: Wednesday, January 15, 2003 9:12 PM
To: Jacques Durand; Jacques Durand
Cc: ''; '';
''
Subject: RE: FW: [ebxml-iic-interop] comments on Interop
suite

At 07:19 PM 1/15/2003 -0800, Jacques Durand
wrote:
Mike:
Hope these answers are useful... 
-----Original Message----- 
From: Michael Kass
[mailto:] 
Sent: Wednesday, January 15, 2003 1:05 PM 
To: Jacques Durand 
Cc: ''; '';
'' 
Subject: RE: FW: [ebxml-iic-interop] comments on Interop
suite

Jacques,

   More comments.  Key questions:

1) Need to assign <Manifest><Reference xlink:href
=""abc">" at the application level in order to do any 
meaningful payload testing for interop, otherwise we have no way of
fetching or evaluating a particular 
payload ( no CID to refer to
). 
[Jacques Durand] because we are at application level, we know that
the MSH provides us with an interface 
(API, queuing, callback...) for: 
(a) when building a message to be sent, specifying the payloads we
want to send, and their names, 
(b)  when receiving a message, getting a list of payload names,
and content, in some way. 
The way to do (a) and (b) may differ across MSH implementations, but
given the right adapter, 
our test driver can expect to always get/set this data, and in the
current interop set-up, will get/set it like if 
it were an application. 
So I think this allows for using your GetPaylod() op, just by using
the app-level "name" (not sure if we need 
to specify the "cid:" prefix) of the payload. 
We may assume that GetMessage() will provide the Test Driver with the
list of received payload names. 
But we don't even need this assumption as we know what payloads to
expect when we write test cases. 
(does anyone see cases where that would not work?) 

2) Fold <SetPayload> operation into <Manifest>
declaration, and eliminate <SetPayload> as an operation.. 
not needed, and it is
cleaner. 
[Jacques Durand] I think the SetPayload op is still useful: It tells
which payload file to  pick (e.g. a URI), 
and will associate with it the payload "name" we want to
see in the message. The Manifest alone can't do that. 
In putMessage(), When using Test Driver directly  at transport
level, we need to define Manifest. 
When using it at application level, Manifest content will be actually
determined by the sequence of 
SetPayload ops we do, by sender MSH. So its not important if we don't
mention it, but we can for consistency.

[MIKE] - We could  add a <Manifest
xlink:href=""payload-1"" filename="abc.xml"/> 
That would solve the problem of needing to 

have both a <SetPayload> operation and a <Manifest/>
declaration.  <Manifest/> could be used to set payload both
at

either application level, or at transport level, depending on mode. 
We would only have to reference the payload one time, in the
<Manifest/> declaration,

and could eliminate SetPayload entirely, for both conformance and interop
testing.

[Jacques Durand] 
 

[Jacques Durand] I am a
little uncomfortable with this kind of shortcut : this extension to
Manifest elt is no longer compatible with the ebXML envelope schema,
which we were trying to respect, see [TestFramework 7.1.4.11]
"...The XML syntax used by the Test Driver to construct the ebXML
Manifest extension content consists of the declaration of an Manifest
element. All required content, as defined in the schema in the ebXML MS
v2.0 Specification, is provided through either default parameters defined
in the ebXMLTestSuite.xsd schema in Appendix C, or by explicit
declaration ...". That might be confusing to people: they may want
to use same esxpression later on when crafting test cases "on the
transport", and that won't be consistent with the message envelope
expected by the schema. I see that not negative at all to have a separate
operation to attach payloads... different from envelope building in
putMessage() main message expression. Is the shortening of test case
script the only advantage you see in removing
setPayload? 

 Frankly, your idea
of adding a setPayload op was not bad
initially!

[MIKE2] - OK.  I was doing that to avoid the "MIME" issue,
but since it is clear that we will be able to manipulate CIDs  ( or
Manifest "href" values ) at the application level, then we can
leave this in. 

3) Define a standard message payload format for including the
digest(s) of payloads used in the PayloadVerify 
operation, consisting of a list of CIDs and their corresponding
Digest values. 
[Jacques Durand] We could do that. Note that in Test Service
definitions, we were assuming that payloadVerify 
would compare received payload(s) with local copies of the
payload(s), and just send back a status message. 
Drawback is, a copy of the payload(s) has to be pre-installed on each
party host before testing.

[MIKE] - Plus the drawback of additional computation time for determining
signature of pre-installed file... each time we

execute PayloadVerify  

We may assume that, in case there is no local copy to compare with,
the status message is replaced by a 
"digest" message that lists the digest values (or
signature) for each received payload. 
When getting back this digest message, we would compare these 
in VerifyContent op with digest values created by putMessage() before
sending to payloadVerify() . 
Is that what you suggest? (any XML format in mind for this? 
)

[MIKE] - Yes. Send a simple payload stating what the digest values for
1-N payloads, with 1-N CIDs and matching digest values 

to the Test Service PayloadVerify action.  The PayloadVerify action
could then verify those signatures against what it computes, and send
back a payload

with a report, as shown above.  This would be nice, because anyone
can submit any number of payloads, without the Test Driver or Test
Service already having to 

know about it, or have files pre-installed. 

[Jacques Durand] Mike: agree
except for one thing: the pre-computed signature (I prefer to call it
digest, as this is actually the part of the signature we need) should be
pre-installed in the Test Service of the remote party. (or send in a
separate "administration" message (to "configurator"
action?) - but I'd reserve that to a future version) Because again we
can't piggyback it on a "normal" message - which again would
assume that we add a special payload - that would twist the test case:
technically, when we say "3 payloads", we should send 3 and not
4. Same if we say 1 payload. So I think it is not really a big deal to
require preinstalling these digests (big improvement from pre-installing
the entire payloads). Opinion?

 

 

[MIKE2] - We can do this.  I still have a question about the
Configurator action.  If CPAId is provided in a message to MSH, why
is CPAId also provided to Configurator action?  Doesn't the

MSH "self-configure" based upon CPAId in message?  If not,
do we need to make a call to the Configurator action at the start of
every message conversation? Or at the start of a test suite?

 The XML would be:

(Send 3 payloads, an XML, gif and Word file.. Test Driver would recognize
the "PayloadVerify" Action declaration, and create an
additional payload that

contains signature values for all 3 payloads along with their CIDs, and
send it to the "PayloadVerify" Action on the Test Service
side.

<MIME:Message> 

<MIME:MessageContainer> 

<SOAP:Envelope> 

<SOAP:Header> 

<eb:MessageHeader eb:Action="PayloadVerify"> 

<eb:CPAId></eb:CPAId></eb:MessageHeader></SOAP:Header>

<SOAP:Body> 

<eb:Manifest> 

<eb:Reference xlink:href=""cid:payload_1""
fileName="payload_1.xml" /> 

<eb:Reference xlink:href=""cid:payload_2""
fileName="payload_2.gif"/> 

<eb:Reference xlink:href=""cid:payload_3""
fileName="payload_3.doc" />

</eb:Manifest></SOAP:Body>

</SOAP:Envelope>

</MIME:MessageContainer>

</MIME:Message>

(Test Service "PayloadVerify" Action receives this message,
along with 4 payloads ( 3 files plus special payload containing their
signatures ), and

computes signatures for 3 files itself, compares their signature values
with those sent in message payload, and sends message back to Test
Driver

with pass/fail result for each payload.)