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