Re: WebCrypto edits on key material (Option 2)

We have WebCrypto test suites here
<https://netflix.github.io/NfWebCrypto/web/test_promise.html> and here
<https://github.com/Netflix/msl/blob/master/tests/src/test/javascript/msltests.html>
and would be willing to integrate them with the W3C tests if someone can
provide an update on the status / location of those.

...Mark


On Tue, Jan 19, 2016 at 10:52 AM, Mark Watson <watsonm@netflix.com> wrote:

> What is the status of the test suite ?
>
> We had made available some test cases a while ago and these certainly
> cover a subset of the specification which we are successfully using in the
> field across four browsers. So I find it hard to believe the situation is
> really as dire as Ryan seems to suggest.
>
> Perhaps we should proceed by first ensuring we have a good set of tests
> and using those to identify the subset of the current specification which
> has multiple interoperable implementations ? We can likely provide some
> resources to assist with this.
>
> ...Mark
>
> On Mon, Jan 18, 2016 at 10:17 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>> On Jan 18, 2016 9:39 PM, "Harry Halpin" <hhalpin@w3.org> wrote:
>> >
>> > Could you post spec bugs that point to the implementation bugs in
>> relevant parts of the spec *if* they could cause changes to the spec (i.e.
>> there are not more than one UA working on solving it)?
>> >
>>
>> I cannot imagine what you hope to gain if one implementation follows the
>> spec, another doesn't, and neither implementation is communicative about
>> change. That gains nothing, other than to suggest the spec should say
>> nothing about it, which is equally something that says something that we
>> don't want to say. That is, by saying nothing, it is very clearly saying
>> something, and saying nothing in the spec for the simple reason that no one
>> else spoke up, yet sites depend on it, is not acceptable.
>>
>> Perhaps rather than arguing about this, as I believe your logic and
>> position are unsound, unreasonable, unsustainable, and reflect a fixation
>> on process that is damaging to the ecosystem, perhaps a path forward would
>> be for you to attempt to engage with the W3C (which you previously
>> suggested would commit resources to) or WG members to contribute tests to
>> demonstrate to the W3C the ability to progress to spec maturity, by showing
>> two interoperable implementations. In writing such tests, you will realize
>> that at virtually every key point of behaviour, there is something
>> different.
>>
>> If this does not immediately stop you from trying to advance to PR, as it
>> should, then you can also make proposals that demonstrate WG consensus
>> supports your proposed plan of removing significant chunks of the spec
>> (based on what I've seen, likely accounts for 3/4 of the spec if we take a
>> strict approach).
>>
>> I will be the first to say we do not have time to contribute to such
>> tests, but will respond to changes and spec bugs if they advance
>> interoperability and reflect consensus as to the future directions.
>>
>
>