RE: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Check the OASIS rules for specification consistency and conflicts between document text and external files (schemas, programming-language codes for some purpose, etc.).  An OASIS PKCS#11 specification needs to align with that.

With regard to in-text inclusion of code snippets, it is important to identify their standing and also deal with any conflicts between any "normative" snippets and normative statements in the text.

 - Dennis

PS: I am not a believer, generally, that code is the specification.  However, if that is intended there is a new task: It is necessary to normatively rely on the programming language chosen and deal with profiling of the language elements used where its specification is silent or dependent on agreements beyond that specification.

PPS: The objective for a specification that is intended to support interoperable implementations is that such a specification-conformant, interoperable implementation can be achieved without having to consult an implementation.  There are the usual caveats about what skills and level of art are required for accomplishing that with the specification. 

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of John Leiseboer
Sent: Tuesday, April 09, 2013 22:32
To: pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

[ ... ]
 
I interpret this to mean that the (normative) specification is given in the snippets of C that appear in the specification, and hopefully are reproduced without error in the header files. So even if there is a typo in the C code, precedence of interpretation is given to the C code definitions. (And by the way this is consistent with other standards that are specified using both text and code; e.g. IEEE 802.1d, and various XML-based specifications. 802.1d explicitly states the precedence rules for interpretation of the standard. PKCS#11 doesn’t.)
 
I haven’t offered an opinion on what we should do about it, but I think that it is important to recognise that the C code is the specification. So we are not talking about simply correcting a typo. We are talking about potentially changing the specification versus modifying, or adding to, the text to be consistent with the C code specification.
 
John
 
[ ... ]