Re: WebCrypto Spec Error Types feedback from MS

On Tue, Mar 4, 2014 at 6:32 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Tue, Mar 4, 2014 at 6:23 PM, Israel Hilerio <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!
>

How about, in Step 4, we say 'If the steps below say "return an error",
execute the following substeps and terminate the algorithm'.

and then in the remaining steps we say "return an xxx error" instead of
"terminate this algorithm with an error".

...Mark