Re: Fwd: Interop Tests

Hi Tommy and all,

> > - If we want to test the validation of revoked or expired certs (T[4-5])
> > we should have those defined. Shouldn't we?
> I added keys for Eric and Ralph that are expired and revoked
> respectively.  You will have to edit the document (T4 and T5) to
> reflect these key holders.  For the future I propose additional
> Validate test cases that include X509 CRL's with and without revoked
> X509 certs (for which I will provide CRL's).

I have already edited the document (T4-T5) and successfully tried to
validate the revoked key (with the expected invalid status code:) Could
you Jose change the Report site to include this change there too?

> > - In the Test Collection site we defined tests with keys bound to the
> > domain example.com. However, the existing keys right now are related to
> > domains such as alicecorp.ie or bobcorp.ie. Is it OK to state in the
> > Report site that we located a key bounded to other domain different to
> > the one stated in the test definition?
> I created keys for Alice and Bob with bindings to example.com.

That's great. I made the tests again with the keys bound to the correct
domain.

> > - Only last two tests use Soap Bindings. Jose and myself were discussing
> > about the convenience of testing most of the cases over Soap1.2 and then
> > just one for plain-http and Soap1.1. Should that approach be used for
> > next test collection or would a change need to be done now...?
> I (claim to) support all three bindings so I am neutral to this.
> However, as SOAP 1.2 is the only required transport binding it would
> make sense to give it more attention.  I also note that my SOAP 1.2
> endpoint has seen the least traffic ...

Even though I have been using less the Soap1.x endpoints for
convenience, my client is working fine against both of them and the
plain http one. It wouldn't be very difficult to include a sentence
before the tests stating that the generic binding to be used is soap1.2
and then make the special plain http and Soap1.1 cases.

> Comment about T7:  The text around the "two status requests" makes
> assumptions about the delay in processing and notifiying the
> completion of an asynchronous request.  In the case of my server, the
> asynchronous processing is currently automated as is the notification.
>  This makes highly unlikely that the first StatusRequest will return
> status Pending.   There possibilities to solve this; 1) I configure
> the service for manual notification or 2) change the text for T7 so
> that it does not require a Pending StatusResult.

Both options seem OK for me. For the moment I wrote a comment in the
report site [1] stating that the first Status request/response pair was
not performed, but I would be happy with either solution.

> Comment about T9 - T12: I do not currently support Compound requests.
> As I stated in the original response to Jose's call for interop
> participation, it is likely that I will do this; more so than before.
> My service endpoint has been updated with the revised keyset which I attach.
> Regards,
> Tommy

Regards,
 - -Guillermo

[1] http://www.w3.org/2002/09/wbs/1/XKMS-WG-CR-TEST-SUITE/

Received on Monday, 20 September 2004 16:20:55 UTC