[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 #14 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Ryan Sleevi from comment #13)
> (In reply to Harry Halpin from comment #12)
> > Here's a concrete proposal that I think would satisfy this without relying
> > on an IANA registry. It needs to be worked out, but the general geist is
> > here, very similar to how HTM5 maintains a registry of link relations:
> 
> This seems to miss the forest for the tree.
> 
> > 
> > The Web Cryptography Working Group will support algorithm extensibility in
> > the Web Cryptography API, allowing new algorithms to be defined and
> > specified as extension specifications.
> > 
> > The extension specification publication process is as follows:
> > 
> > 1) The W3C maintain indefinitely a wiki of reserved algorithm identifiers,
> > with links to specifications. This wiki should be referenced from the W3C
> > Web Cryptography API specification. 
> 
> This seems unnecessary. That is, every W3C spec is inherently part of a
> "registry" - the W3C registry. Every extension to the Window object, to the
> Navigator object, etc plays by this.
> 
> There's no need for any explicit registry.
> 
> > 
> > 2) When a new algorithm is suggested and the name reserved, a timeline (no
> > more than 6 months) should be given for the production of a draft
> > specification. This specification should be formatted as an W3C Editor's
> > Note, the Extension Algorithm Note, and sent to the Web Cryptography Working
> > Group for discussion and consensus. If the Web Cryptography Working Group
> > has been closed, the W3C will determine an appropriate Interest or Working
> > Group for reaching consensus over publication of the Extension Algorithm
> > Note. One requirement for the addition of new algorithms should be that they
> > should be well-specified enough for implementers and are supported by at
> > least one implementation. 
> 
> I see no value in artificial timelines like this, nor does it match how the
> rest of the Web Platform works.
> 
> > 
> > 3) If consensus is reached, the Extension Algorithm should be published as a
> > W3C Working Group Note and the wiki should be updated to reflect the
> > maturity of the Algorithm Extension Note. When known, any further supporting
> > implementations should be listed  
> > 
> > In the case of in which there are any disputes over reserved names or
> > process, the Web Cryptography Working Group will be empowered to make a
> > decision. If the charter of the Web Cryptography Working Group is not in
> > effect, the W3C will find an appropriate Working Group or Interest Group, to
> > be reflected in the wiki, to maintain the list of algorithms or will
> > maintain the list of extension specs directly.
> 
> Harry,
> 
> I appreciate you taking the time for this. However, it sets forth a solution
> for problems that it fails to define. I appreciate you may see there are
> problems with the approach of handling this exactly as every other Web
> Specification, but you owe it to the WG to enumerate these, before proposing
> a solution for how to deal with them.

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. 

> 
> That is, what remains to be identified is how, in any shape, form, or way,
> is this different than how every other Web API works?

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

Received on Monday, 4 August 2014 18:20:32 UTC