Re: WebCrypto edits on key material (Option 2)

I would add that I believe a standardization process represents more than
simply documentation after-the-fact of what a subset of stakeholders (in
this case browser implementors) choose to implement, but rather there is a
reasonable expectation that implementors attach some weight to the outcome
of discussions involving the full set of stakeholders - otherwise, why is
anyone else here ? In this case, I think we can expect implementors to
invest a reasonable amount of effort in fixing any outstanding bugs that
are preventing us from moving forwards. It sounds from this discussion that
we have not really identified those gaps properly yet and that progress on
the test suite is what is needed to achieve that.

...Mark

On Wed, Jan 20, 2016 at 9:59 AM, Mark Watson <watsonm@netflix.com> wrote:

> 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.
>>>
>>
>>
>