[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 #15 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Harry Halpin from comment #14)
> The problem is how does one add an algorithm identifier (with appropriate
> extension spec) without returning to Last Call?
> 
> If you think you have a better way, please provide. I assumed a wiki that
> tracks the reserved names and the status of the extension spec as a WG Note
> was about as basic and sensible as you can get. 

Harry,

How does WebApps introduce/propose/spec-through-CFI a new API without sending
HTML5 to Last Call?

For example, the recently introduced Service Workers? Or the Mixed Content
spec?

I hope, by example and extension, you can see that, by design, there is nothing
that should require the "Web Crypto API" to re-enter last call. If there is,
well, that's the general extensibility bug. This does not require a registry to
solve, nor does it require a Note or a Wiki page, nor does the W3C's version of
"point in time HTML5" require a "forward declaration" towards the work of
WebApps or WebAppsSec.

Again, I remain opposed to registries because this is not a generic, arbitrary
registration surface. This is a key, intrinsic component of the API, and it
should not be treated any different than how the Web Platform and User Agents
have treated every other aspect of API - through specifications, WGs, and
consensus.

The only "risk" to requiring a registry is if a UA decides to forgo
standards-based development, forgo the W3C process, and begin shipping
untested, unspecified, unadopted work directly to the Web. I think the UAs
participating in this WG, and in the W3C, have learned of the deleterious
effects, and thus consensus is pursued in parallel or even prior to anything
being shipped, and only shipping when such a thing is believed to be stable
enough such that changes will not affect web developers (or, in the case of
some UAs, prefixing).

Thus even the remotest probabilities of:
1) Some new hip algorithm being introduced
2) Two UAs deciding to implement some new hip algorithm immediately after it's
announced
3) Coming up with incompatible definitions of some new hip algorithm

Are greatly reduced by the incredible unlikelihood that a UA would actually
ship them before building consensus and a standards-based approach.

Microsoft's approach with the NUMS curves is no different than if Microsoft
were to come to WebApps tomorrow and propose a new depth-sensor API for use
with devices like Kinect. It would be discussed, consensus would be built,
Microsoft (might) ship it behind a prefix if they believe it's stable/mature,
or they (might) wait until the WG has adopted and it's progressed to a point of
maturity.

This is API. This is not a protocol format. API changes, by design, take time,
because we need all UAs to agree to the shape and purpose of such API changes,
since it's the shared API of the web.

Once again, a registry is unnecessary to serve this in any form of prescriptive
role. A registry to document this is no more a WG activity than it is the
WebApps responsibility to document every extension of the Document or Window
interfaces. The W3C has already invested - along with it's member organizations
- significantly in providing a place for such documentation "for developers"
(as a registry is often pointed as serving) - webplatform.org

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

Received on Monday, 4 August 2014 18:45:25 UTC