Re: Revised Test Cases

Hi Tommy,

You have convinced me that the XKISS messages do not belong to the XKRSS
tests. Attached is a revised version based on your comments - note that I
have removed the shared secret from the test cases. Please let me know if
you have other concerns.

Thanks !

Yunhao

----- Original Message ----- 
From: "Tommy Lindberg" <tommy.lindberg@gmail.com>
To: "Yunhao Zhang" <yzhang@sqldata.com>
Cc: <www-xkms@w3.org>
Sent: Wednesday, October 13, 2004 1:17 PM
Subject: Re: Revised Test Cases


> Hi Yunhao -
>
> > I don't see how the tests could exclude implementors from inplementing
only
> > XKRSS. ...
>
> My understanding from the additional tests was the new XKISS messages
> would be used to verify that key bindings were affected in the desired
> way after an XKRSS operation.  Whether they were individual XKISS
> testcases or part of an XKRSS testcase, this approach creates a
> dependency on XKISS.
>
> So, it doesn't prevent the implemention of XKRSS - but it does seem to
> get in the way of testing XKRSS as the implementor wouldn't have the
> XKISS functionality required to execute the test.
>
> I wagely recall someone indicating only implementing a subset of XKRSS
> - I was only sensitive to this.  Personally, I couldn't give a toss :)
>
> > The question is, do we allow people to test only registration without
> > verifying state change?
>
> Yes I think so. Register, like Reissue and Recover, returns some
> artifact that can form the basis for determining whether the operation
> succeeded or failed; provided of course that all service implementers
> agreed upon returning that artifact.
>
> Revoke may require a bit more; if we agreed, a service could produce a
> CRL in the result on which the revoked key resided. This is X509'ish
> but so are the current XKISS tests.
>
> Regards
> Tommy
>
> On Wed, 13 Oct 2004 09:19:18 -0400, Yunhao Zhang <yzhang@sqldata.com>
wrote:
> >
> > Hi Tommy
> >
> > > 1)
> > > While I am personally OK with the approach, using XKISS messages to
> > > verify that XKRSS operations have produced the expected results may
> > > exclude implementors that only intend implementing XKRSS, or portions
> > > thereof, from executing some tests.
> > >
> >
> > I don't see how the tests could exclude implementors from inplementing
only
> > XKRSS. We already have a long list of KRISS tests and it doesn't
preclude
> > people from implementing only part of XKISS or even part of a client to
> > participate in the test. Remember that the test cases can be exercised
> > individually, and untested cases can be marked as 4 in the report.
> >
> > > 2)
> > > Assuming that XKISS messages are used to verify expected results of
XKRSS
> > > requests, it may be more meaningful to incorporate the XKISS messages
in
> > the
> > > actual XKRSS test case as opposed to having them separately, using
T101 as
> > > an example:
> > >
> > >   - verify that binding-to-be-registered does not exist
(Validate/Locate)
> > >   - attempt registration
> > >   - verify that binding-to-be-registered does exist (Validate/Locate)
> > >
> >
> > Then the case can only be used by ones who implement both XKISS and
XKRSS.
> > The question is, do we allow people to test only registration without
> > verifying state change?
> >
> > > 4)
> > > I am not in favor of using the same shared secret for everyone.  Not
only
> > is
> > > it not realistic, but it also allows for accidental inteference
> > > between individual
> > > testers.
> > >
> > Using the same shared secret is to facilitate automated testing where
all
> > the test cases are conducted in sequential order. We can certainly make
it a
> > parameter so that it can be entered before testing.
> >
> > As for more test cases, we can definitely add when needed.
> >
> > Regards,
> >
> > Yunhao
> >
> >
>