OASIS PKCS 11 TC

The error first:

The "Meaning" cell for CKF_DUAL_CRYPTO_OPERATIONS refers to section 5.14, but in v3.1/3.2 that should say 5.17 

The digression:

Reading the spec I do not see how a token that want to implement this can reasonably do so without a C_DualFunctionInit that tell the token what init functions to allow in the session.

The rest of the spec clearly states that if you try to Init a new operation when there is another operation ongoing you get an error.

So the spec is now inconsistent, applications that do not know about dual-function operations may rely on error returned if they try to initialize a new operation while another is active, and even if the door is closed once the first active call (after the Init() is executed) it means there are race conditions (for threaded or highly abstract async programs) where sometimes you get the expected error, and sometime you end up initializing a dual function you were not intending to initialize).

Is there space to add such an Init function and add language on how tokens should behave when the new Init function is not supported ?

For example, should tokens error out if a third Init function is called?

Should tokens close the barn door and deny dual functions if any operation other call than a Init() is called ? Or should operations on be allowed on the initialized one before the second is initialized ?

Does any Init() function call with a NULL pMechanism abort both the functions of a dual function, or does the application need to call both Init()s with a NULL pMechanism?   Does the order matter? (this is another quirk that would be more cleanly handled by a C_DualFunctionInit() call).