Re: WebCrypto edits on key material (Option 2)

On 01/18/2016 09:14 PM, Ryan Sleevi wrote:
>
>
> On Jan 18, 2016 5:24 PM, "Harry Halpin" <hhalpin@w3.org
> <mailto:hhalpin@w3.org>> wrote:
> >
> > It's not my goals, it's the W3C charter that we all explicitly
> agreed to.
> >
> > The obvious way forward is to open, for each interop problem you
> mention and any others that are discovered, a bug.
>
> These aren't spec bugs, Harry. They are implementation bugs.
>

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)?

> If you feel otherwise, feel free to open issues. But absent that, it
> is neither reasonable nor rational to argue that I should trawl
> through other UAs bug lists (nor can I), looking for their bugs of
> non-complaince and suggesting them as spec bugs.
>
> I do hope you take a critical look at what you're asking, because I am
> at a loss, having exhausted every means I have to explain to you how
> unreasonable and inconsistent your suggestions are.
>
> >  If they can't be tackled, then they features have to be removed.
> Hopefully that will motivate UA vendors to fix issues.
>
> And you still hold on to hope despite repeated attempts to engage
> other UAs on core features. This is so disconnected from reality that
> I can no longer reply effectively.
>

Which is why I'm not sure why you are suggesting that we wait for UAs to
fix implementation bugs.
>
> > So, you seem to be stating that you want the Working Group to close
> with no further progress being made. I hope that is not the case.
>
> Yes, that is exactly what I am saying, because that is exactly the
> feedback we are seeing from other UAs. Arguing process and hoping for
> something different than the past few months is naive, at best.
>

I have seen no other UA argue that the Working Group should close and
not finish the work. Does any other implementer agree we should close WG
without finishing a version spec that matches implementations and being
able to maintain it?

Generally, lack of response simply means that there are not enough
available resources to fix implementation bugs or add new features.
Which would back up my point that WebCrypto is simply low priority.
Hopefully energy will come back, but again, we should probably assume it
isn't until we know otherwise.
>
> > I also doubt you are arguing that a spec that is effectively
> unmaintained and that doesn't reflect existing implementations is the
> best for developers. 
>
> Harry, again you've tried to pose this as an issue of the spec being
> unmaintained. I hope you realize how frustrating that is, given that
> the implementations and WG are unmaintained. You continue to push
> arbitrary, technically unsound positions simply for process, rather
> than accept that what matters more is figuring out if the spec even
> matters to UAs, and if it does, to have a clearer direction from those
> UAs. If you mean it is unmaintained because I am unwilling to
> implement your preferred solution without feedback and commitments
> from other UAs, then yes, it's happily unmaintained and will continue
> to do so, as to "maintain" the spec is to do a further disservice to
> users and developers alike.
>

I don't have any preferred technical solution, but we do need to
demonstrate that there is progress and we have a charter deadline coming
up.

I still see no argument that an effectively unmaintained spec that
doesn't match implementations is a service to users or developers. In
fact, I've never seen that argument made before anywhere, much less be
popularly accepted.

> > lets UA vendors keep working on resolving bugs,
>
> Again, UA vendors aren't working on resolving bugs.
>

As noted above.
>
> Unless and until you solve this issue, everything else is lipservice.
>

I'm arguing that we simply have to make changes to the spec to reflect
the current state of implementation and I've noted that no other UAs are
updating their implementations. For the most part, neither UAs or the
code have made updates recently, although I'd be happy to hear otherwise.
>
> >  What do you think?
>
> I think your proposed fork illustrates exactly how bad the idea is for
> holding "process" on a higher pedestal than progress.
>
> But what does it matter, if no other UAs contribute?
>

Simply put, the spec will then match the current state of affairs. If
UAs begin contributing, we can then start updating again and have that
work chartered.

Now, if you don't have the time or energy to update the spec, you should
say so we can plan accordingly. If you can find some time, that would be
great and we can then make a schedule for going forward.  However, doing
nothing is not an acceptable way forward obviously.

            cheers,
                  harry