Re: On Registries

On Aug 11, 2014 8:34 AM, "Harry Halpin" <hhalpin@w3.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 08/11/2014 03:55 AM, Ryan Sleevi wrote:
> > On Aug 10, 2014 6:43 PM, "Harry Halpin" <hhalpin@w3.org> wrote:
> >>
> >
> >
> > On 08/11/2014 03:26 AM, Ryan Sleevi wrote:
> >>>> Considering no other WG has needed such a pointer, especially
> >>>> all of the work in WebApps, I think such a pointer would be
> >>>> counterproductive to the spirit of the spec process and
> >>>> ill-advised in terms of spec maturity.
> >
> > What would you expect say, a developer who goes through the spec
> > and notices that Curve25519 is not in the spec to do?
> >
> > Seems like a link back to where he could find a list of specs that
> > the WG is working on in terms of algorithms could be useful to
> > guide the developer to the right spec (ideally with test-suite that
> > shows where it is or isn't implemented). Do you think there's an
> > alternative?
> >
> >> Why ideally with a test suite? How is that any different from the
> >> main spec linking to a test suite? Or having one in-built? Why
> >> would algorithm extensions be expected to provide something the
> >> main spec doesn't?
> >
> >
> > As much as I know we all enjoy new bugs asking for new curves when
> > people read the spec and notice their favorite curve missing :)
> >
> >
> >> I would rather solve real problems than deal with hypothetical
> >> strawmen.
>
> We've had a few of these happen, ala
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
>
> but earlier as regards SEED. I know you find it irritating, but it
> keeps happening.
>
> >
> >> Its the same situation as when a 'developer' reads the HTML5 spec
> >> and notices there's nothing about filesystem access. Or notes
> >> that there is no way to manipulate sound.
> >
> >> I have no objection to a wiki stating the PubStatus - WebApps
> >> has successfully done that for some time. What I object to is
> >> trying to shoehorn it into the spec somehow.
> >
> >> The maximal language that should be sufficient is "Additional
> >> specifications may define other algorithms."
>
> Maybe minimize a bit more with a link?
>
>   "Additional <a href="@@Publication_Status_Page">specifications</a>
> may define other algorithm" suitable?

You don't minimize risk with a link. You minimize it with process.

The omission was intentional.

>
> Otherwise we could mean specs defined outside W3C process. If that's
> what you mean, then we can state that explicitly as well.
>
> Also, do you feel the spec is suitably generic in text yet, in terms
> of the original bug [1]?
>
> We could try to recruit a few proof-readers to check it out - for
> example, BAL and Trevor Perrin I likely would be interested.
>
> Crossing fingers for getting out of Last Call...
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618
>
>
> >
> >> Or split up the algorithms from the main spec, so that its
> >> obvious the relationship between the two.
>
> That would be a lot of cut-and-paste editorial work but is also possible.
>
> >
> >>>>
> >>>> I appreciate your attempt to try to balance things, but
> >>>> again, HTML5 has succeeded without a 'pointer to things that
> >>>> define structured clone', or to 'specs which define
> >>>> canvas.getContext', or to 'supplemental interfaces to the
> >>>> Window interface', all of which are functionally equivalent
> >>>> to any such extensibility discussion.
> >
> > Perhaps more analogous,
> >
> >> No. Its not really analogous to that at all, in that their
> >> processing mechanisms - and effects on web developers - are
> >> nothing like the aforementioned extension points of HTML5.
> >
> > HTML5 also has a wiki for link relationships [1] - see "Types
> > defined as extensions in the microformats wiki existing-rel-values
> > page with the status "proposed" or "ratified" may be used with the
> > rel attribute on link, a, and area elements in accordance to the
> > "Effect on..." field. [MFREL]" [1]. I suspect this is something
> > less formal is what Mike was aiming at with a "registry" but I
> > agree a formal registry will be difficult to maintain.
> >
> > Historically, XML-DSIG used URIs for algorithms to avoid the
> > "registry" problem.
> >
> >> Great for XML-DSIG. Except its relevance to the Web and how the
> >> Web works is virtually nonexistent.
> >
> >> Among other things, its not an API, nor exposed as such. Nor does
> >> it affect things in the same way. The applicability of the
> >> decisions made there are equally nonexistent (and more akin to
> >> JOSE than HTML)
> >
> >
> > [1] http://microformats.org/wiki/existing
> > rel-values#HTML5_link_type_extensions [2]
> > http://www.w3.org/TR/html5/links.html#linkTypes
> >
> >
> >>>> On Aug 10, 2014 5:58 PM, "Harry Halpin" <hhalpin@w3.org>
> >>>> wrote:
> >>>>
> >>>> Would the best way forward here simply be a pointer from the
> >>>> spec to the web-page of the WG near the "Algorithm" so that
> >>>> authors can check to see the status of algorithms that may
> >>>> not be not included the main spec, such as Curve25519?
> >>>>
> >>>> Then the WG homepage's list of "extension specs" (with a
> >>>> clear sign of maturity in terms of Rec process) serves as a
> >>>> "registry" (for lack of a better term).
> >>>>
> >>>> While a bit more heavyweight than the wiki I suggested
> >>>> earlier, it would satisfy I think Ryan's concerns about
> >>>> algorithms going through process without thorough discussion
> >>>> and consensus from the UAs and WG, and also Mike's concerns
> >>>> about where developers would go to find algorithms they don't
> >>>> see in the spec and where UAs could ask for them.
> >>>>
> >>>> Sound reasonable? A quick sentence or two added to "18.1.
> >>>> Registered algorithms" pointing back to the WG homepage would
> >>>> then be enough.
> >>>>
> >>>> cheers, harry
> >>>>
> >>>> On 08/08/2014 07:26 AM, Ryan Sleevi wrote:
> >>>>>>> WebCrypto is a Web API.
> >>>>>>>
> >>>>>>> There is no need for a registry for non-Web users. By
> >>>>>>> definition, charter, and constituency, they do not
> >>>>>>> exist.
> >>>>>>>
> >>>>>>> All that matters, for standardization, is what UAs do.
> >>>>>>>
> >>>>>>> If no UA is involved, then having a name registry only
> >>>>>>> serves to put the Web as second class. On Aug 7, 2014
> >>>>>>> 10:24 PM, "Mike Jones" <Michael.Jones@microsoft.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> You’re missing that user agents don’t have to
> >>>>>>>> implement registered algorithms.  They’re free to
> >>>>>>>> exercise their own best judgment.  If they weren’t,
> >>>>>>>> then you’d be on the side of having required
> >>>>>>>> algorithms, which I know you’re not.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> In the same way that registering new JWA algorithms
> >>>>>>>> doesn’t hurt anything, registering new WebCrypto
> >>>>>>>> algorithms doesn’t hurt anything.  But it can help.
> >>>>>>>> There’s nothing to fear there.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> >>>>>>>> *Sent:* Thursday, August 07, 2014 10:18 PM *To:* Mike
> >>>>>>>> Jones *Cc:* Mark Watson; public-webcrypto@w3.org
> >>>>>>>> *Subject:* RE: On Registries
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Mike,
> >>>>>>>>
> >>>>>>>> If we want to talk hyperbole, suggesting the W3C is
> >>>>>>>> akin to fearing openness is right up there.
> >>>>>>>>
> >>>>>>>> Every algorithm in WebCrypto represents a distinct
> >>>>>>>> capability for the Web. Thus is, by definition, an
> >>>>>>>> API, no different than Canvas.getContext is an API (
> >>>>>>>>
> >>>>>>>>
> >>>>
> >>
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting.html#the-canvas-element
> >>>>>>>>
> >>>>>>>>
> >>>>
> >>>>
> >
> >>
> )
> >>>>>>>>
> >>>>>>>> What scares me is individual UAs arbitrarily and
> >>>>>>>> unilaterally adding new capabilities to the web,
> >>>>>>>> without discussion and consensus of other UAs, which
> >>>>>>>> you have been so gung-ho on for so long and so
> >>>>>>>> clearly, and which I can only hope is an individual
> >>>>>>>> view and not current corporate thinking.
> >>>>>>>>
> >>>>>>>> That is the ONLY technical purpose a registry of
> >>>>>>>> allowing arbitrary organizations to register new
> >>>>>>>> algorithms serves. And expert review does NOT cut
> >>>>>>>> it.
> >>>>>>>>
> >>>>>>>> The registration of JWA/JWK affects no other
> >>>>>>>> implementations, except for those that developers try
> >>>>>>>> to exchange messages with. It is, by definition,
> >>>>>>>> safe.
> >>>>>>>>
> >>>>>>>> Exposing a new capability affects every User Agent
> >>>>>>>> that ever hopes to visit that site, and thus should
> >>>>>>>> absolutely be treated with fear and trembling,
> >>>>>>>> because the Web does not remove capabilities lightly.
> >>>>>>>> Suggesting such a site would "only affect/support IE"
> >>>>>>>> or "Only affect/support Chrome", which is what such
> >>>>>>>> arbitrary capability extensions mean, is the very
> >>>>>>>> essence of a return to browser wars and extinction
> >>>>>>>> through interoperability failure.
> >>>>>>>>
> >>>>>>>> On Aug 7, 2014 9:55 PM, "Mike Jones"
> >>>>>>>> <Michael.Jones@microsoft.com> wrote:
> >>>>>>>>
> >>>>>>>> So why, exactly, was it OK for you to add algorithms
> >>>>>>>> to JWA and JWK with a registry, when you would deny
> >>>>>>>> the same ability to others for WebCrypto? Why does
> >>>>>>>> openness and cooperation scare you so?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> >>>>>>>> *Sent:* Thursday, August 07, 2014 9:48 PM *To:* Mike
> >>>>>>>> Jones *Cc:* Mark Watson; public-webcrypto@w3.org
> >>>>>>>> *Subject:* RE: On Registries
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Aug 7, 2014 9:38 PM, "Mike Jones"
> >>>>>>>> <Michael.Jones@microsoft.com> wrote:
> >>>>>>>>>
> >>>>>>>>> We’re not talking about adding APIs.
> >>>>>>>>
> >>>>>>>> Right, I thought we had agreement that this was an
> >>>>>>>> API.
> >>>>>>>>
> >>>>>>>> Without that agreement, I suspect there is nothing
> >>>>>>>> further of fruit to come of this discussion. The
> >>>>>>>> points for why it is, unquestionably, an API have
> >>>>>>>> been laid out.
> >>>>>>>>
> >>>>>>>>> We’re talking about algorithms.  That’s a much
> >>>>>>>>> more restricted extension
> >>>>>>>> space than the hypothetical one that you’re
> >>>>>>>> pontificating about.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cryptographers are more qualified to extend that
> >>>>>>>>> space than the W3C, the
> >>>>>>>> WHATWG, ECMA, or you or me.  Let’s enable them do
> >>>>>>>> it, irrespective of the organization in which they
> >>>>>>>> write their spec.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Cryptographers, as an abstract group/concept, are
> >>>>>>>> the LEAST qualified of the groups you mentioned to
> >>>>>>>> write browser APIs, to understand both the
> >>>>>>>> limitations and the idioms of the platform, of the
> >>>>>>>> risks and the guarantees, and of how the Web and
> >>>>>>>> Standards work.
> >>>>>>>>
> >>>>>>>> With all due respect to all parties, it's like
> >>>>>>>> suggesting someone who specializes in Computer Aided
> >>>>>>>> Design to design a C API. Very different roles and
> >>>>>>>> functions.
> >>>>>>>>
> >>>>>>>> If they do so, its no different than me writing a
> >>>>>>>> spec for cold fusion and hiding it under my pillow,
> >>>>>>>> because its just a piece of paper.
> >>>>>>>>
> >>>>>>>> It means nothing without the involvement of UAs, to
> >>>>>>>> implement, to agree on things like IPR, etc. Any UA
> >>>>>>>> that went and implemented such extensions ad-hoc
> >>>>>>>> would rightly be called out as breaking the web,
> >>>>>>>> embracing, extending, and extinguishing.
> >>>>>>>>
> >>>>>>>> I can only encourage you to reach out to your
> >>>>>>>> counterparts on the IE team and in WebApps to
> >>>>>>>> understand that none of our organizations (and yeah,
> >>>>>>>> Moz, you too ;D) have their hands clean in these
> >>>>>>>> matters, and that's precisely why we are trying so
> >>>>>>>> hard to work together to ensure it does not happen.
> >>>>>>>>
> >>>>>>>> A spec that blesses or condones such API extensions,
> >>>>>>>> rather than condemning, is a step in the wrong
> >>>>>>>> direction for standards.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> From: Ryan Sleevi [mailto:sleevi@google.com] Sent:
> >>>>>>>>> Thursday, August 07, 2014 9:33 PM
> >>>>>>>>>
> >>>>>>>>> To: Mike Jones Cc: Mark Watson;
> >>>>>>>>> public-webcrypto@w3.org Subject: RE: On Registries
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Mike,
> >>>>>>>>>
> >>>>>>>>> Can you name any organization or individual,
> >>>>>>>>> outside the W3C, WHATWG,
> >>>>>>>> and ECMA qualified to extend the web by adding new
> >>>>>>>> APIs for UAs to implement?
> >>>>>>>>>
> >>>>>>>>> You can easily reach out to Travis L. and co on
> >>>>>>>>> your side, or to your
> >>>>>>>> legal team, to better understand Microsoft's view
> >>>>>>>> against exactly that, with respect to participation
> >>>>>>>> and standardization that occurs in the WHATWG. Or you
> >>>>>>>> can look towards the involvement in TC39 to better
> >>>>>>>> understand that there is very much a split, in both
> >>>>>>>> organizations, as to which party is responsible for
> >>>>>>>> developing and standardizing which aspects.
> >>>>>>>>>
> >>>>>>>>> That the IETF, or any similar organization, would
> >>>>>>>>> and can responsibly
> >>>>>>>> develop JavaScript APIs used by millions of
> >>>>>>>> developers, without the involvement of UAs, is not a
> >>>>>>>> reality. The core constituency is and has always been
> >>>>>>>> wherever the UAs are, since ultimately no standard,
> >>>>>>>> draft, or spec is ever meaningful until UAs sit down
> >>>>>>>> and implement it.
> >>>>>>>>>
> >>>>>>>>> So the only registry that matters is what UAs do.
> >>>>>>>>> Everything else is a
> >>>>>>>> figment of a standards dream that doesn't exist, much
> >>>>>>>> like the debacle of XHTML that lead to the formation
> >>>>>>>> of the WHATWG to begin with.
> >>>>>>>>>
> >>>>>>>>> Put differently, interop is the only registry that
> >>>>>>>>> matters. And the W3C
> >>>>>>>> (and WHATWG) is where interop happens. A registry
> >>>>>>>> doesn't make interop happen - it just documents the
> >>>>>>>> interop that already happened. So does a Wiki. Or a
> >>>>>>>> PubStatus. Or WebPlatform.org, MDN, MSDN, etc.
> >>>>>>>>>
> >>>>>>>>> On Aug 7, 2014 9:20 PM, "Mike Jones"
> >>>>>>>>> <Michael.Jones@microsoft.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Ryan, it seems that your primary motivation here
> >>>>>>>>> is preventing things
> >>>>>>>> that could go wrong.  Mine is enabling things that
> >>>>>>>> can go right.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I find it hypocritical that you’ll happily use the
> >>>>>>>>> IANA Registry to
> >>>>>>>> extend JWK for use by WebCrypto in
> >>>>>>>> http://www.w3.org/TR/WebCryptoAPI/#iana-section but
> >>>>>>>> you’re unwilling to admit that enabling the IETF or
> >>>>>>>> others to similarly extend WebCrypto would likewise
> >>>>>>>> be a good thing.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The IETF is happy to have others extend the
> >>>>>>>>> Internet in a principled
> >>>>>>>> fashion.  Why are you so afraid to let the IETF or
> >>>>>>>> others extend the Web in a similarly principled
> >>>>>>>> fashion?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> JWK is stronger because WebCrypto can extend it.
> >>>>>>>>> It’s better for
> >>>>>>>> WebCrypto, better for JOSE, and better for the
> >>>>>>>> Internet. WebCrypto and the Web would be similarly
> >>>>>>>> stronger if others outside the W3C could extend it.
> >>>>>>>> So let’s make it happen!
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I’ll be happy continue to advocate that it’s more
> >>>>>>>>> important to WebCrypto
> >>>>>>>> and the W3C to enable responsible extensions by all,
> >>>>>>>> even though it may scare you, than to maintain a
> >>>>>>>> closed spec and closed process that only one
> >>>>>>>> organization can extend.  I believe that openness in
> >>>>>>>> this respect is “on the right side of history”.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- Mike
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> From: Ryan Sleevi [mailto:sleevi@google.com] Sent:
> >>>>>>>>> Thursday, August 07, 2014 8:12 PM To: Mike Jones
> >>>>>>>>> Cc: Mark Watson; public-webcrypto@w3.org Subject:
> >>>>>>>>> RE: On Registries
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Aug 7, 2014 7:56 PM, "Mike Jones"
> >>>>>>>>> <Michael.Jones@microsoft.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Replies about the W3C’s positive role in
> >>>>>>>>>> ensuring quality of algorithm
> >>>>>>>> registry entries inline at the end of this message…
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> From: Ryan Sleevi [mailto:sleevi@google.com]
> >>>>>>>>>> Sent: Thursday, August 07, 2014 7:44 PM To: Mike
> >>>>>>>>>> Jones Cc: Mark Watson; public-webcrypto@w3.org
> >>>>>>>>>> Subject: RE: On Registries
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Aug 7, 2014 7:31 PM, "Mike Jones"
> >>>>>>>>>> <Michael.Jones@microsoft.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for your insightful reply, Mark.  A few
> >>>>>>>>>>> comments inline below…
> >>>>>>>>>>>
> >>>>>>>>>>> From: Mark Watson [mailto:watsonm@netflix.com]
> >>>>>>>>>>> Sent: Thursday, August 07, 2014 6:02 PM To:
> >>>>>>>>>>> Mike Jones Cc: Ryan Sleevi;
> >>>>>>>>>>> public-webcrypto@w3.org Subject: Re: On
> >>>>>>>>>>> Registries
> >>>>>>>>>>>
> >>>>>>>>>>> On Thursday, August 7, 2014, Mike Jones
> >>>>>>>>>>> <Michael.Jones@microsoft.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Simple.  In the first case, the algorithm is a
> >>>>>>>>>>> data value. In the
> >>>>>>>> second case, it’s encoded in an API.  Data values
> >>>>>>>> are easily extensible. APIs are not.  That’s why
> >>>>>>>> extending the space of algorithms by registering new
> >>>>>>>> data values makes a world of sense. Expending the
> >>>>>>>> algorithms by adding new APIs for each would be
> >>>>>>>> clunky, procedurally slow, and mostly unworkable.
> >>>>>>>>>>>
> >>>>>>>>>>> I think what Ryan is saying is that it should
> >>>>>>>>>>> be no easier to add an
> >>>>>>>> algorithm than it is to add a new API (or, more
> >>>>>>>> strongly, that a new algorithm *is* a new API and
> >>>>>>>> _therefore_ should be no easier to add).
> >>>>>>>>>>>
> >>>>>>>>>>> I believe you’ve accurately identified the
> >>>>>>>>>>> heart of the disagreement
> >>>>>>>> here, Mark.
> >>>>>>>>>>>
> >>>>>>>>>>> IF we decided that it should be easier than
> >>>>>>>>>>> this to add new
> >>>>>>>> algorithms and especially if we decided that groups
> >>>>>>>> other than W3C Working Groups should be able to do
> >>>>>>>> so, then a registry makes sense as a mechanism to
> >>>>>>>> coordinate that.
> >>>>>>>>>>>
> >>>>>>>>>>> Agreed.
> >>>>>>>>>>>
> >>>>>>>>>>> Otherwise (which is where we are now), then
> >>>>>>>>>>> the definitive list of
> >>>>>>>> algorithms is to be found in the sum total of the
> >>>>>>>> output of the W3C WebCrypto Working Group and nowhere
> >>>>>>>> else.
> >>>>>>>>>>>
> >>>>>>>>>>> If we decide that he definitive list of
> >>>>>>>>>>> algorithms is only to be
> >>>>>>>> produced by the W3C WebCrypto Working Group, I
> >>>>>>>> believe that would be a significant missed
> >>>>>>>> opportunity.  The WebCrypto API is an exercise in
> >>>>>>>> packaging algorithms developed by cryptographers for
> >>>>>>>> use by Web developers, just like JOSE is.  Neither
> >>>>>>>> working group’s primary expertise is cryptography.
> >>>>>>>> Cryptographers should be the ones to write the
> >>>>>>>> extensions specs defining new algorithms – not us.
> >>>>>>>> Some of those may occur in the W3C but some may occur
> >>>>>>>> in the IETF and some may be individual drafts by
> >>>>>>>> people such as Dan Bernstein, David McGrew, and Brian
> >>>>>>>> LaMacchia.
> >>>>>>>>>>>
> >>>>>>>>>>> We would be doing the WebCrypto API and the Web
> >>>>>>>>>>> a significant
> >>>>>>>> disservice if we don’t enable people other than us
> >>>>>>>> to define and register new algorithms for use with
> >>>>>>>> WebCrypto. We should be humble enough to recognize
> >>>>>>>> that defining new crypto algorithms is not our
> >>>>>>>> expertise and let those who are experts define them
> >>>>>>>> for use with our spec, no matter where they choose to
> >>>>>>>> do the work.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I agree with the sentiment that anyone should be
> >>>>>>>>>> able to write
> >>>>>>>> definitions for algorithms, and am excited to see
> >>>>>>>> Trevor's Curve25519 draft.
> >>>>>>>>>>
> >>>>>>>>>> I disagree with the sentiment that it should
> >>>>>>>>>> happen outside the W3C.
> >>>>>>>> To do so is to return to the browser wars, where
> >>>>>>>> both Microsoft and Mozilla, though well motivated,
> >>>>>>>> wrecked great harm through "embrace, extend,
> >>>>>>>> extinguish" and the introduction at large of new
> >>>>>>>> vendor-specific APIs, often without specs (or without
> >>>>>>>> free licensing, or with great patent encumbrance, or
> >>>>>>>> through active hostility towards other UAs efforts to
> >>>>>>>> interop)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The W3C (and the WHATWG) exist to help prevent
> >>>>>>>>>> that terrible harm from
> >>>>>>>> ever happening again. The way to do that is by
> >>>>>>>> having multiple UAs coordinate and ship features
> >>>>>>>> responsibly, to agree on specifications, and to avoid
> >>>>>>>> vendor lock-in.
> >>>>>>>>>>
> >>>>>>>>>> Regardless of this group's cryptographic
> >>>>>>>>>> expertise, which i agree is
> >>>>>>>> unfortunately lacking, we are filled with UA
> >>>>>>>> implementors, the sole entities with the power to
> >>>>>>>> make - or break - the web; For developers, for other
> >>>>>>>> UA implementors, and most importantly, for users, for
> >>>>>>>> this generation of the web and those to come. For
> >>>>>>>> that, there can and should be no alternative - we
> >>>>>>>> must agree, as UAs, and the W3C exists precisely to
> >>>>>>>> support and guide that agreement.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Suggesting that using a responsibly managed
> >>>>>>>>>> registry would be a return
> >>>>>>>> to the “browser wars” or that features would be
> >>>>>>>> shipped without specifications is hyperbole.  I’m
> >>>>>>>> only advocating a specification-required registry
> >>>>>>>> with expert review.  The W3C would appoint the
> >>>>>>>> appropriate experts to ensure that the specifications
> >>>>>>>> registering algorithms are clear and well-written and
> >>>>>>>> meet any other criteria decided by the W3C.  The W3C
> >>>>>>>> can ensure the quality of registered algorithms
> >>>>>>>> without having to write all the drafts itself. It’s
> >>>>>>>> unnecessary and detrimental hubris to think that
> >>>>>>>> we’re the only ones qualified to do so.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -- Mike
> >>>>>>>>>
> >>>>>>>>> Expert Review is exactly the detrimental sort of
> >>>>>>>>> stuff that got us into
> >>>>>>>> this.
> >>>>>>>>>
> >>>>>>>>> The W3C REC track is exactly that. A path for
> >>>>>>>>> _anyone_ to write specs,
> >>>>>>>> submit them to the WG, for UAs and users to agree in
> >>>>>>>> interest, and to develop and publish such
> >>>>>>>> specifications with clear views on patents,
> >>>>>>>> interoperability, and applicability to the web.
> >>>>>>>>>
> >>>>>>>>> No single expert is qualified to reflect consensus
> >>>>>>>>> of a
> >>>>>>>> multi-stakeholder UA community, which is a
> >>>>>>>> fundamental and nonnegotiable portion of any Web
> >>>>>>>> API.
> >>>>>>>>>
> >>>>>>>>> So if we talk a panel of experts, who are they?
> >>>>>>>>> Well, we probably want
> >>>>>>>> some UAs, those are essential. We probably need some
> >>>>>>>> cryptographers, since security is key. We should hear
> >>>>>>>> from developers, since this matters to them. And we
> >>>>>>>> should probably have a few representatives from the
> >>>>>>>> public.
> >>>>>>>>>
> >>>>>>>>> And suddenly, you have an Expert Panel that is
> >>>>>>>>> indistinguishable in form
> >>>>>>>> or function from a WG. And without having to reinvent
> >>>>>>>> a process for that review.
> >>>>>>>>>
> >>>>>>>>> Any solution that fails to go through the
> >>>>>>>>> W3C/WHATWG process is, in
> >>>>>>>> spirit and effect, a return to the browser wars -
> >>>>>>>> including the designation of sole experts (which the
> >>>>>>>> W3C also has readily available if this WG should ever
> >>>>>>>> need - the TAG and AB)
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJT6OKFAAoJEPgwUoSfMzqcENAP/jm+Z1cIF/r2lQCh2FJDR5x2
> nXJ5ND+ATY7UdVm/dBk5920YsjvbB4nHE/SVZbTZLsWSt8+s8SjF8UyN84PkurGJ
> 7/a8x+29mlqTbndeg1Fh0DGqknH3Qp2nRoSTehtGHNgqpIAalWlxMDIA1V89PD/a
> Eqd7WhrUU9uUY0IqSkyl76Gtl7xl90y89gx+a4RTg04pi/xck1JHWArZ1Pj+tNZU
> PUEgPgtt2sjSVSANtUFPmjE+PSg9iYyIH6BrPx8V6cjPZj6rKpJxrnZ4xkz8BaD4
> 9v8tUIct+AlImMj8UJSVkYIFBflMr3GBgtV6TuMm94KRSh/yDICnHUCvvCELIC0X
> 2fYk4wEwWjkkg/NWjOs5TnRvNPPydMm9IQNd8pGL50+dewItXPkE0580Lvj845s0
> 2da376NPPZdicEhcuoxd6RpEFIbWwuhL9mf5h/fhXgi7BmqiSn0KKH5QIQGwDDZ/
> v+Fx7dESiXJ6VC8Wm1lrEFYwX5GLmVBsJgiuOc42m/Vm8AO0lK2l57QRtBjHT8Sb
> d4SnqTtX0TBMZwOdBd8oEq83ibilEEjnVjvem9bUVdCsmfwqer3U0bIgWG7ziSM9
> Hfx9jtm4OKBPMHjSKaDLm+tQil7r+vVZejiWTNQ+hQeOZLdx8vHFHkhahGs2KUth
> s0ZyNBlFgQydWePLIlCk
> =qn1O
> -----END PGP SIGNATURE-----