-
Type: Bug
-
Status: New
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: Digital Signature Service Core Protocols, Elements, and Bindings Version 2.0
-
Fix Version/s: None
-
Component/s: Public reviews
-
Labels:None
-
Environment:
Conformance
The types of implementations that need to conform need be clearly identified, preferably at the beginning of the spect - or else as appropriate in the spec body. For example, section 5 (processing model for signing) does not give any hint of what is supposed to conform to it. (is that a machine? or a process implementation? or yet a document representing this process?) See 4.2 in the conformance guideline http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html . In this case, various implementations seem to be: a DSS Client , a DSS server, a signature object, and more (?)In other words , what kinds of thing can we claim to be conforming to this spec? Then ideally, normative statements can refer to this type ("a DSS client MUST....", a signature object SHOULD...") Then such implementation becomes a "conformance target" in a conformance clause. The conformance clause must refer to the implementation type (see sec 5.2 in conf clause guideline): "a server implementation satisfies "DSS server" conformance profile if...". The 2 first conf clauses (JSON and XML) are lacking conformance targets. The two next are better (yet DSS Client never defined as an implementation type! )