Re: WebCrypto edits on key material (Option 2)

On Mon, Jan 18, 2016 at 1:22 PM, Harry Halpin <hhalpin@w3.org> wrote:

>
> We're asking that the editors remove everything that doesn't have two
> interoperable implementations. That's the definition of exiting Candidate
> Recommendation.
>

Yes, I'm aware of what the definition is.

What seems unclear, still, is how unreasonable that request is given the
current situation for the WG.

How are we to determine two interoperable implementations? The tests that
magically appear? Is it the editors who need to install and test every
permutation, presumably writing the tests?

And what happens when something lacks interoperability, but is strongly
desired (or worse, required) by certain large sites? Remove it from the
spec? Or try to work out what the interoperable solution and make changes
are - e.g. what most WGs try to do, but you seem to be actively opposed to.

Harry, I think you are grossly underestimating the work that's required or,
if you think it's simply a matter of going with a metaphorical red pen and
striking out everything, grossly overestimating the value of a spec that
neither reflects users nor implementors desires.

In either event, it's clear that without other UAs being involved, what
you're requesting is unrealistic.

You're putting process above users, above developers, above
implementations. This is how the W3C got into obsolence in the first place.
It would be great if you could channel your energies towards exiting CR not
in attempting to singularly remove by fiat large portions of the spec (and,
to be clear, we're talking about removing all asymmetric encryption if we
adopt your standard, among other things), and instead work to get other
user agents involved.

In either event, it's becoming increasingly clear that I don't think I have
the time or energy to accomplish what you're asking, let alone the
agreement that it is in the interests of users, sites, or browsers - or the
W3C.


> As stated earlier, we can re-charter in maintenance mode to allow a
> 'living spec', but its unreasonable to have the spec sit in CR for more
> than a year if parts of the spec do not reflect underlying implementations.
> Given there has been *no* movement on the spec for more nearly a year, I
> don't think waiting for other UAs to get throw resources at this spec makes
> sense, although we'd be happy to hear more news.
>

Harry, the spec is sitting because there's no clear direction where to take
it precisely because the underlying implementations disagree on things, and
no one is talking about what they think is the right thing, nor indicating
that if the spec said do X that they would do it.