[Bug 25618] Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

--- Comment #49 from Domenic Denicola <domenic@domenicdenicola.com> ---
With my TAG hat on, I would really like to second Ryan's point that this seems
to highlight the issues described by Jeff Jaffe in
http://www.w3.org/community/w3process/track/issues/141, and also those of Boris
about the priority of constituencies.

This kind of thinking about extension specs seems systematic of the historical
'process and practice' issues Jeff talks about. In practice the web crypto spec
needs to 'continuously evolve' (Jeff's phrase) to reflect the requirements for
implementing a web-compatible browser, whereas the advocates of extension specs
seem to argue from the point of view that actually updating the web crypto spec
is too difficult for process reasons.

I'd strongly encourage the web crypto working group to lead the way on this
W3C-wide initiative to improve working practices, by having a spec that
reflects implementation realities and does not become stale. As such,
algorithms required for web compatibility should not be put into other specs,
but kept in the main, continuously-updated spec. The proposed "process hack" of
(normatively?) linking to a wiki that documents the required extension
algorithms that didn't make it in time for last call is just that: a hack. If
there are process consequences for issuing this kind of "errata", that needs to
be fixed instead of hacked around.

With my Google/implementer hat on, a continuously-updated standard with obvious
requirements for what needs to be implemented, and how, is clearly preferable.
This is why we use living standards and editors drafts exclusively when
implementing Chrome.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 10 October 2014 15:32:13 UTC