RE: WebCrypto Spec Error Types feedback from MS

Regarding UNKNOWN_ERR and DATA_ERR we should be able to define equivalent error types that live in our spec, thus breaking the IDB dependency.  Perhaps we can rename them to something like:

·        UNKNOWN_ERR – FAILURE_ERR or PROCESSING_ERR

·        DATA_ERR – OPERATION_DATA_ERR
What do you think?

Israel

On Tuesday, March 4, 2014 6:32 PM, Ryan Sleevi [mailto:sleevi@google.com] wrote:
On Tue, Mar 4, 2014 at 6:23 PM, Israel Hilerio <israelh@microsoft.com<mailto:israelh@microsoft.com>> wrote:
As promised, below is MS feedback on the types of error we believe are useful to expose to web developers.  We correlated this information with what was done on IndexedDB.  In addition, we when through Section 14.3 and mapped our proposed error types to steps on each section:

Error Type

Description

Spec Mapping

NOT_SUPPORTED_ERR

The Algorithm is not supported

14.3.1 through 8, 11:
* Step 6
14.3.7:
* Step 7
14.3.9:
* Step 5
14.3.12:
* Step 6
* Step 7

SYNTAX_ERR

Missing parameter errors.  For example, you fail to provide an IV for CBC Mode or not providing a key length when one is needed.

14.3.1 through 12:
* Steps 1 and 5


INVALID_STATE_ERR

An invalid operation was performed on an object instance. For example, you have exceeded the number of operations allowed with a key.

14.3.1 through 4, 8, 11:
* Step 8
14.3.7:
* Step 12
14.3.10:
* Step 6


DATA_ERR

Data provided to an operation does not meet requirements. For example, your plain text is not padded to the correct size.

14.3.1 through 5:
* Step 8
14.3.6:
* Step 7
14.3.7:
* Step 9
14.3.9:
* Step 6
* Step 7
* Step 8
14.3.10:
* Step 5
14.3.11:
* Step 7
14.3.12:
* Step 9
* Step 10
* Step 11
* Step 13

UNKNOWN_ERR

This is a system level transient failure that don’t necessarily indicate a failure in the program logic. For example, out of memory conditions.

This could happen in any step

INVALID_ACCESS_ERR

An invalid operation was perform in an object type.  For example, you try to encrypt with a signing key.

14.3.1 through 4, 8, 9:
* Step 7
14.3.7:
* Step 8
14.3.11:
* Step 8
* Step 12
14.3.12:
* Step 8


Remember you’ll need to update step 4 on each 14.3.x to return DOMError and remove editorial note.

We were also wondering if the following steps should be in the spec (they seemed redundant):

•        Section 14.3.11 Step 13

•        Section 14.3.12 Step 12

•        Section 14.3.12 Step 14

Let us know if you have any questions.
Thanks,

Israel

Regarding UNKNOWN_ERR and DATA_ERR, doesn't that require taking a normative dependency on IndexedDB, which defines UnknownError and DataError? I do agree it's useful, I'm just not sure how to handle this. Do we equally define an UnknownError? Is such a thing even possible?

Regarding the redundant sections, I agree, they seem redundant, because it seems to be covered by Section 14.3.11 Step 4 ("If an error occurs, run these substeps and then terminate the algorithm")

That said, we probably need to smith the language, since really it seems like Step 4 will never be hit (except perhaps in Step 5?) For example, Steps 6, 7, 8, 9, 11, and 12 all separately say "Terminate this algorithm with an error" - which presumably means _don't_ run Step 4.

Spec bug!