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

Re: WebCrypto edits on key material (Option 2)

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 18 Jan 2016 22:17:02 -0800
Message-ID: <CACvaWvaXGABg_Vuqy+6sPtooWfAevdd0e-EiXg8AHf1gz8sFiw@mail.gmail.com>
To: Harry Halpin <hhalpin@w3.org>
Cc: public-webcrypto@w3.org, GALINDO Virginie <Virginie.Galindo@gemalto.com>
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

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 06:17:30 UTC

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