- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 11 Aug 2014 18:38:09 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: Mark Watson <watsonm@netflix.com>, Mike Jones <Michael.Jones@microsoft.com>, public-webcrypto@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2014 06:30 PM, Ryan Sleevi wrote: > On Aug 11, 2014 9:19 AM, "Harry Halpin" <hhalpin@w3.org> wrote: >> > > > On 08/11/2014 05:55 PM, Ryan Sleevi wrote: >>>> On Aug 11, 2014 8:43 AM, "Harry Halpin" <hhalpin@w3.org> >>>> wrote: >>>>> >>>> >>>> >>>> On 08/11/2014 05:39 PM, Ryan Sleevi wrote: >>>>>>> On Aug 11, 2014 8:34 AM, "Harry Halpin" >>>>>>> <hhalpin@w3.org> wrote: >>>>>>>> >>>>>>> >>>>>>> >>>>>>> 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. >>>> >>>> Then a link to the process is useful. Do you have one, or do >>>> you want the readers of the spec to just guess the process? >>>> >>>> At least specifying the process is a good thing. Otherwise, >>>> folks could go off and define prefixes, set up their own >>>> registry, or many of the other fun things W3C has had >>>> happened over the last years. Is that what you intend Ryan? >>>> >>>> I was under impression you wanted extensions to go through >>>> W3C process. >>>> >>>>> Harry, >>>> >>>>> While the extreme doom and gloom is as entertaining as a >>>>> Cormac McCarthy novel, its not needed. >>>> >>>>> Linking to the PubStatus does not make it any more or less >>>>> likely that people will do all of the things you said. We >>>>> know this from simple history. >>>> >>>>> We also know that the only thing that matters is what UAs >>>>> do. It doesn't matter if Jane Doe Off the Street goes and >>>>> writes a spec that says "All these identifiers belong to >>>>> me. Attempt no specifications here" - unless and until UAs >>>>> decide Jane is right. >>>> >>>>> Your hypothetical spec authors are either capable and >>>>> cognizant of how the web works, and realize this is no >>>>> different than any other specification activity in the W3C, >>>>> or they aren't. > > The goal is to send future requests for Curve 25519 (see Matt > Corrallo and Greg Slepak) to proposals such as Trevor Perrin's, to > reduce the pain on Bugzilla and mailing lists. So, not having any default advice here is what you recommend? We've had three options put forward: 1) A wiki 2) Extension specs at W3C 3) IANA registry and 4) No advice given. > >>>> >>>>> Your hypothetical developers are not going to be reading >>>>> the spec, certainly not when >>>>> WebPlatform/StackOverflow/MDN/W3Schools(...ugh) results >>>>> dominate their results. >>>> >>>>> Its equally important not to pretend the W3C _is_ the only >>>>> arbiter here. Do I want stuff to go through the W3C? >>>>> Absolutely. But we know what happens when the W3C ignores >>>>> the real world for the academic, when it embraces >>>>> unrealistic technologies with no interest from UAs, and >>>>> when it prioritizes member happiness over meaningful >>>>> improvements - UAs migrate to WHATWG and continue improving >>>>> the web, and the W3C gets ignored. > > I agree people can use whatever process they want, but it seems > like pointing them to a process could be useful. Mike suggested > IANA and you suggested W3C - both are fine by me (as would be > anything really, including a wiki or a list of options), but > clarity here would help for those who are just looking at the > spec. > > Also, if certain UA don't want certain non-NIST curves for > whatever reason, that's fine - but that doesn't mean that we should > forbid other perfectly competent folks from defining them (in > extension specs if one wants) and then show in a test-suite which > UA's offer which curves and which UA's don't. > > >> Harry, > >> Hasn't there been enough discussion from Henri, Anne, and Boris >> to know why "UA pick and choose" is the least desirable outcome? >> That is the very essence of the discussion about how bad such a >> scenario is. Which is why I imagine folks are more happy with the "normative" profile than the non-normative profile. And folks would probably also want to know the status of any extensions as well for perfectly reasonable interop reasons and IPR reasons. > >>>> >>>>> So, again, the only thing that matters is what UA >>>>> implements. > > I wouldn't go far as saying "only thing." Of course, UAs are > vitally important but a dictatorship of a single implementation is > precisely what we are trying to avoid. The test-suite should again > clarify what UAs implement in detail. > > >> Who said anything singular? If its exposed to the Web, it >> matters. If its not exposed to the web, its no different than a >> spec hosted on someone's blog/GitHub - it has zero effect because >> of zero implementations. > > However, we should also not forget what users and developers want > as well, and try to point their energies in the right direction - > as we've I think we've done successfully wiht Curve25519. While > it's been a long few months with many comments, the point of W3C > process is to try to at least give users and developers a voice. > > >> Lest I be accused otherwise (as it seems to be happening here), >> saying UAs matter doesn't detract from their voice or ability to >> be listened to. Simply that until a UA implements, they can say >> whatever they want. You can talk for years about an API - but >> until someone implements and ships, its all academic. We are in agreement here as of course implementation and shipping count. However, in order to implement and ship the right thing, we also agree that the UAs should actually discuss with users, developers, and other UAs in a respectful manner. Although a bit of good humor helps sometimes, no doubt, particularly with a Last Call with this many comments! > >>>> >>>>> But since we haven't seen the doomed and charred wreckage >>>>> of random APIs violating structured clone or getContext, >>>>> which are in far greater use, I do believe we are fine. >>>> > > Cross fingers! :) > >>>> >>>> >>>> >>>> >>>>>>> >>>>>>> >>>>>>> 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) iQIcBAEBAgAGBQJT6PFxAAoJEPgwUoSfMzqce5wP/A6OuEFf4obHAID9l3FIfeV8 pl5T7/MCVQj5XtOpHeUjZjNaJ6ci/A222pxwSq3t6p/FuavGXw5+cx2izLKBWvbj s67/MSt8N6xz4oTutL/T1NhLo/Y2Eb7WR1xgFZkagdDbZdKgzqzh8jHnqqyBoDhS CuunaLZFEdPvmYdgsPigkP1kcpWCWBcsbxgOkAt0YhUDdEV3hvunHBcg03TB+PbC 6m4RFnuceLFENoChoWNt0gOavv30y3Ye5UeKOVhuDetHqE2dWvrwBaTvtj+2sIHa RqXjRHgrfX8oQiZLVgDmQUwq28uYjjONsfx+AYEaj31HvMbsA23BujZ2fZX9fm9B NItvBYzpU+tACNLVcinCT4WkmmDO4jBPjHPFenA+vZvyvHIG3NKAFhjGacD2R3OO +KOJ5/KDHEWqfAH6aQwRgY7Avz0NWG0wGHOpoAy5H8uawx38XCgC9/ULFmgqdzcc eC/8pgK/12F/GlCArUyDbiftiscvG8TqGQQtPnj5O/LmosqJ3mbgj2Q5+hPa5Xij J/F9e73aJ5gRjFli/t86AM4xGOqmiIYvQsOzh/4VOP4GS0WpvZsLZx/4ulCyPqqy 1Gb+VWLRd40Bnf/O/cVqOcmO2Q/hCH+/r/d4PJ352rBXmQLfbWBdHBwK1WdVezKV cy/ff15meNhaF8EQiHWl =jA7f -----END PGP SIGNATURE-----
Received on Monday, 11 August 2014 16:38:19 UTC