[Bug 25557] Spec should allow returning NotSupportedError for reasons other than failed Algorithm normalization

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25557

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #1 from Mark Watson <watsonm@netflix.com> ---
(In reply to vijaybh from comment #0)
> (see discussion in
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Apr/0085.html)
> 
> Currently the spec only allows NotSupportedError to be returned if Algorithm
> normalization fails to produce a registered algorithm. We should give an
> implementation the flexibility to return this error in other cases as well:
> 
> 1. If we ever add anything to the registry then old implementations will
> automatically be in violation of this rule as they will then be returning
> NotSupportedError for "registered algorithms".

I don't think that's correct. We describe an internal [[supportedAlgorithms]]
object which contains the algorithms supported *by the UA* and you return
NotSupportedError for any others.

> 2. An implementation may choose to not support a particular algorithm or
> operation due to various constraints, and may desire to fail early so
> scripts can handle errors more easily.

I think these cases end up being OperationErrors right now: you pass all the
WebCrypto validation / data manipulation procedures and end up failing at the
operation.

The problem with allowing implementations to optimize for cases they know
aren't supported, whether they return OperationError of NotSupportedError is
that we get inconsistent behavior across implementations as there can always be
implementations that only discover whether something is supported when the
operation is handed off to some crypto library.

So, I would suggest Won't Fix here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 26 September 2014 19:03:32 UTC