Re: [dss-x] Test case generation from the core spec

[Stefan Drees <stefan@drees.name>]

Hi Andreas,

Am 11.04.10 18:48, Andreas (kuehne@trustable.de) wrote:
> ...
> Looking at section 3.1 SignRequest I stuck at the RequestID :
> Even though the section is about the the SigningRequest, 
> what's build by the client, the condition says something about the server ! 

In RequestResponseSystems there is sometimes the optional only reserved
for the construction of the Request and the construction of the Response
is ruled by the former decisions. This makes it intermixed but
deterministic in handling the usual semantic expectations.

In short here:
If and only if the request is ammended by an attribute RequestID the
client will receive a Response that MUST also contain this attribute and
its value.

> Moreover this condition is a copy of the corresponding paragraph in 3.2 SignResponse.

I would tend not to call this a copy. The former was a forward ref, a
hint, that the client can build a response mapping IF sending a
RequestID, since that ID will be contained in the Response.

We just tried to bracket the semantics in putting the linking MUST in
both places of the Request-Response-Pair.


> Next problem in SignRequest is the section about InputDocuments. 
> The heading denotes this element as 'Optional' but the text says 
> that it is required in a SignRequest.

We have a lot of this, I remember, because of the design decision to
put a lot in Types and later deriving from them. This eases some parts
of function/description and makes others more complex/vague.

I do not remember if we tended to enforce this presence of the element,
in instances of SignRequest (i.e. extensions of RequestBaseType.


> Generally the term 'REQUIRED' is a bit vague what system is responsible 
> for checking and what should happen in error cases.

I might be tempted to replace REQUIRED by MUST be present/contained in.


> Another general point is the definition of a condition for the client. 
> But there is no definition what should happen when the client sends 
> a non-conformant request. 

Don't we have the Result-Element:
with:
urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError
meaning:
The request could not be satisfied due to an error on the part of the
requester.

> In my ideal version there should a set of conditions for 
> a conformant client and a conformant server.
> 
> So generally there is much more work to be done than just extracting 
> the conditions semi-automatically.  

+1 from my side.

A historic note:
We took every effort in not-exclusion of possible use-cases somehow
bloating the core and softening a few parts in version 1. Many
discussions - when finalizing the standard - tried to resolve possible
exclusions of future usage, if I remember correctly.


> In some cases this may even affect the core. 
> A workaround to preserve the core could am additional version of the 
> where the original text remains unchanged and the conformance statements 
> are mixed into it marked as conformance requirements.

In the next version of the core, this might be considered.


> So many work to, opinions welcome.

Thanks a lot for the analysis and feedback,
until later this evening,
Stefan.