[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 #16 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Ryan Sleevi from comment #15)
> (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.

We are not discussing an IANA registry. We are addressing that concern of
"where developers find out if an algorithm is specified if it's not in the main
spec". For that, a W3C wiki is a lightweight solution that has a longevity that
is not connected to the spec. 

We may have that issue with both NUMS and Curve 25519. We are simply stating
*where* the specifications not in the main spec can be found, what process they
go for maturation (i.e. the WG process if available) and how they are
published, i.e. as Notes. 

That's one concrete proposal. We still need to go through and make sure the
spec clearly lists all extension points where "the object is defined by the
other specification." However, it would seem useful that for algorithm
identifiers in particular that the "other specifications" can be easily found,
lest folks reinvent the wheel. 


> 
> 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 19:50:30 UTC