W3C home > Mailing lists > Public > public-webcrypto@w3.org > January 2016

Re: WebCrypto edits on key material (Option 2)

From: Mark Watson <watsonm@netflix.com>
Date: Tue, 19 Jan 2016 10:52:19 -0800
Message-ID: <CAEnTvdDuG1iELDfjWXJStqcHLDTSR9cYEhC8eHHD5xWN_UP9Wg@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>
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.
>
Received on Tuesday, 19 January 2016 18:52:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:03 UTC