[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 #11 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Mike Jones from comment #10)
> First, I support Mark's comment that we must define a procedure for
> implementations to support new algorithm parameters, such as curve
> identifiers - not just new algorithms.  His list of "Possible places where
> defined extension points are needed" is valuable, and should be address by
> any proposed resolution to this issue.

Considering that these issues are the entire point of the bug, it seems
unnecessary to express support, since that's the whole point of filing the bug
to begin with.

> 
> Next, without a registry, as an implementer of the specs, how do I know
> where to look for the definitions of the different algorithms and algorithm
> parameters that I might want to use in my implementation?  

As I mentioned in my previous reply, the exact same place for all other aspects
of your user agent - the W3C (and WHATWG)

> Also, without a
> registry, who administers the namespace of algorithm identifiers and other
> extensible sets of identifiers? 

The exact same august body of collaborators that determines that the Window IDL
object shall have an "open" method, that the PerformanceTiming interface should
have a "navigationStart" member, and that the Document object shall fire load
events - the W3C.

>  If I'm writing a spec defining a new
> algorithm, how do I reserve the identifiers that my spec uses?

The exact same process you reserve the identifier "PerformanceTiming" if you're
attempting to reserve an identifier for providing performance details, or
reserving the identifier "serviceWorker" on the navigator object.

Mike, these are API decisions, and the W3C process - and the WebApps work mode
- have identified that these questions you're raising as hypothetical issues to
be solved by a registry are not needed to be solved by a registry. They're part
of the standards-driven W3C process. I realize, coming from the IETF, that
there may be a perchant for IANA registries. This is especially true with
protocols, which are agnostic as to the implementation and how they're exposed
to developers.

This is, still and always, fundamentally a matter of API decisions. That there
are string identifiers may make this slightly confusing, but it's important to
realize that window.crypto.subtle.encrypt({"name": "AES-GCM", ...}, ...) is,
from the point of view of interoperability, web developers, and very purpose,
not one lick of functional difference than
window.crypto.subtle.aesgcm.encrypt(...)

It's an API surface. As such, any changes are treated like all other changes to
the Web Platform - by bringing to the WHATWG / W3C, agreeing, and implementing.

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

Received on Wednesday, 30 July 2014 21:26:44 UTC