Re: [W3C Web Crypto WG] about extensions to Web Crypto specification

On Thu, Aug 28, 2014 at 11:19 AM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  You wrote “Perhaps this is the solution: pull out *all the algorithms*
> into, say, five extension specifications:
>
> - RSA
>
> - AES
>
> - EC
>
> - Hash algorithms
>
> - Key Derivation
>
> ”
>
>
>
> That would just make things needlessly harder on developers.  As a working
> group, we owe it to developers to make the core spec as easy to use as
> possible, while still enabling extension in a timely manner.  Yes,
> obtaining consensus in the working group may be painful, but that’s not an
> excuse for us to inflict enduring pain on developers using our specs as a
> result.
>
>
>
> I strongly oppose removing any of the existing algorithms from the core
> spec.
>
>
>
>                                                                 -- Mike
>
>
>

Mike,

The above proposal is entirely reasonable, and reflects the approach other
WGs have done, whether it be for treating elements like CSS, treating
features of the Web such as Service Workers, DOM events, gamepads, or File
access, or in handling elements like WebGL.

Despite your concerns, developers have not only succeeded, they've thrived
AND benefitted from clear and digestable specifications, compared to the
'traditional' hundreds-of-pages-of-boilerplate.

I would again encourage you to reconsider your position, and also helpfully
clarify whether this is a personal concern or if you have discussed it
within the broader space of your colleagues at Microsoft (including the IE
team), so that we can be clearer both what the concerns are, and how to
solve it.

You can see that Mark and I are both trying to expend significant energy to
find solutions to deal with real and ongoing problems that this WG is
facing. It would be helpful for dialog if you would further explain your
objections and, when possible, provide alternatives you feel meet these
concerns.

I, again, remind you that these specifications, as with the specifications
for things like HTML or XMLHttpRequest, do not and have not targetted
developers. They target, primarily, implementors, to ensure that
implementors can correctly create interoperable implementations. The W3C
has a venue for Developer-facing documentation and guidance, and it's not
the specification.

Thus, your first and foremost objective when evaluating the specification
is not, should not, and cannot be "Is this hard for developers to
understand", but "Is this easy for implementors to understand and reach
interoperable implementations"

To that end, Mark's proposal, which I've said for some time, absolutely
gives greater ability and flexibility to do just that.