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

If it was going to unblock us on extensibility and EC then I could justify
prioritizing work on that and have significant time to spend on it in the
next week. I would expect it's largely a question of cloning the spec five
times and then deleting all-but-the-bit-we-want from each one, adding some
common bollerplate and pruning the references.

...Mark


On Thu, Aug 28, 2014 at 12:03 PM, GALINDO Virginie <
Virginie.Galindo@gemalto.com> wrote:

>  Ryan,  Mark,
> what would be the realistic delay for you as editors to actually execute that split?
> Virginie
>
> ---- Ryan Sleevi a écrit ----
>
>
>
>
>
> 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.
>   ------------------------------
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>