[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 #30 from Brian LaMacchia <bal@microsoft.com> ---
(In reply to Mark Watson from comment #29)
> (In reply to Brian LaMacchia from comment #28)
> > [Copying my e-mail message to the list here so it's also directly in
> > Bugzilla...]
> > 
> > Folks,
> >  
> > As you are all well aware, we have had extensive discussions in this WG (on
> > both the list and during our conference calls) on the need for defined
> > extensibility points in the WebCrypto specification. The result of those
> > discussions was an agreement that those defined extension points would be
> > added to the specification as part of resolving Bug #25618
> > (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618), which was the
> > placeholder for this work.  Co-editor Mark Watson has already made those
> > changes to the draft and asked for them to be reviewed.  
> >  
> > Speaking on behalf of Microsoft and our two independent implementations of
> > WebCrypto (Internet Explorer 11+ and the MSR JavaScript Cryptography
> > Library), we believe that the spec should not exit Last Call without having
> > a well-defined extensibility mechanism that allows the definition and
> > integration of new cryptographic algorithms.  Our expectation is that
> > whatever the mechanism, an extension will not impact the base specification
> > nor compromise implementations that comply with the base spec.
> 
> Brain,
> 
> The decision to require extensibility points was based on the assumption
> that the objective was to allow extension of the specification without
> modification of the base specification, as described in Comment#0 above.
> 
> Things have now changed, with two browser vendors arguing that this should
> not be possible: the base specification should always be updated, at the
> least with references to the new specification. With this basic assumption
> now contested, the earlier decision is meaningless.
> 
> Given this, can you address my point above that we might as well add the
> extension points when / if we make such updates to the base specification ?
> Indeed, we might as well just add the new stuff into the spec if we have to
> update it anyway.
> 
> Or, are you objecting to the position from Google and Mozilla that
> extensions require an update to the base specification ?
> 
> It would be really great if, instead of simply taking contrary positions
> which leave us at an impasse, people could throw out ideas for resolution. I
> have suggested several things above and it would be nice to have feedback on
> those.
> 
> 
> >  
> > --bal

Yes, I am specifically objecting to the position that extensions require an
update to the base specification.  I don't believe this is the case and that's
why I wrote "Our expectation is that whatever the mechanism, an extension will
not impact the base specification nor compromise implementations that comply
with the base spec." We can make a specification that allows extensions in
defined places and the act of making those extensions changes nothing in the
base spec.  Having a defined extension point in the base spec is not in any way
equivalent to a forward reference to an undefined normative or informative
reference.  

--bal

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

Received on Thursday, 9 October 2014 14:47:33 UTC