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

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Mike:

Hope these answers are useful...

-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Wednesday, January 15, 2003 1:05 PM
To: Jacques Durand
Cc: 'matt@mac-kenzie.net'; 'mmartin@certivo.net'; 'ebxml-iic-interop@lists.oasis-open.org'
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.

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.

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? )

Attachment: BIP_scripts_JD4.zip
Description: Binary data