[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 #45 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Boris Zbarsky from comment #38)
> > By this logic, I might add, we can't ship Version 5 until we are done with
> > Version 6. 
> 
> By this logic, when you start work on version 6 you need to add a link in
> version 5 pointing out that it's no longer the most recent specification and
> that version 6 exists.  Assuming you were talking about versions of
> specifications.

Extension spec S2 would normatively reference S1. Why would it make sense to
have S1 reference S2? 

> 
> If you were talking about versions of implementations, I have no idea what
> you were trying to say.
> 
> > No one is "pretending" S2 doesn't exist.
> 
> Please put yourselves in the shoes of an implementor who is told to
> "implement S1".  They find the S1 spec and implement.  How do they find out
> about S2?

Like I said, the W3C has offered to host either a web-page or wiki, which can
be pointed at from S1, for these. That's pretty simple and solves your problem. 

> 
> > It seems like extension specs are needed in this case. 
> 
> I'm not extension specs at all.  I'm not even against extension specs that
> are clearly labeled as "optional unless you want your UA to be usable in
> Russia"; in fact I'm quite for it.

Exactly.

> 
> I _am_ against non-discoverable extension specs.
> 
> Obviously I can't speak for Anne and Ryan here, but I suspect that they
> agree with me.

Agreed. We wanted extension specs to be discoverable. Ryan pushed against it
for reasons which he has not clarified. 

> 
> > The argument is "People might think extension spec is implemented, realize it
> > isn't, and file a bug report."
> 
> No, the argument is "A browser implementor will think this S1 is implemented
> and ship it and sites will break in the browser because they assume that if
> S1 is implemented so is S2, otherwise they polyfill S1".

Why would sites assume S2 is implemented if it's clearly an extension?

> 
> As in, if S2 is in fact a required consequence of having S1, then by not
> making that clear you set up people implementing S1 to fail.

However, using Curve25519 and NUMs curves as examples, we are *not* saying they
are required.

> 
> > If developers want to know what browsers definitely support an extension S2
> 
> Based on historical evidence, developers will just test their favorite
> browser or maybe two and then if they support S2 will assume everyone who
> implements S1 does.  They are likely to not even realize that the things
> they're using are in S2 and not in S1, since developer-facing blogs,
> documentation, etc, is not likely to make that clear.

Given there is a vastly decreasing amount of browsers, I don't think this is a
huge problem. Indeed, the problem is that some jurisdictions and applicaitons
*require* crypto that for, some reason or another, some browser vendor won't
implement but another will. To discpline this, an extension spec mechanism
makes sense. 

Also, note the point made by Mark that at least his company is interested in
using this API in JS programs that aren't browsers. 

> 
> > Thus, the pain of not having the ability to easily extend 
> 
> Adding a single forward-reference line to a spec does not seem like a high
> bar for "easily".

Yes, because the patent commits go to the spec and adding algorithms to the
base spec would cause us to go back to Last Call.

That being said, a reference to *a wiki* or *another website* that *forward
references all the other specs and their status/testing from the main spec
solves this problem rather easily.

> 
> On the other hand, I think you underestimate the pain of "ship a browser
> that causes pages to break because a spec was incomplete"; a pain we have
> ended up dealing with on a fairly regular basis with W3C specs and are
> somewhat familiar with.
> 
> Basically, you are prioritizing the comfort of the working group over
> implementors.  This is a direct reversal of
> <http://www.w3.org/TR/html-design-principles/#priority-of-constituencies>. 
> You're not bound by that design principle of course, being a different
> working group and all that, but I'll posit that design principle is still a
> good idea in general.  You might disagree, of course, in which case we
> really do have a fundamental disagreement.

No, we are not prioritizing the comfort of the working group. Certain groups,
like *entire countries*, need crypto that is not included in the base spec for
some reason or another. 

As a global standards body we can't ignore whole countries. I rank ordinary
people above both the comfort of standards bodies and implementers to be
honest. 

We will clearly define a browser profile that every developer can depend on. 

However, we do understand some browsers don't have the resources or desire to
implement certain crypto (like Curve25519 or NUMS or SEED or GOST) that certain
people (and again, whole countries) need. As long as specs for these are
written and code works in at least one browser, I think extension specs are a
good idea for tackling this issue without putting any additional weight on
browser vendors. If the browser vendors decide later to implement extension
specs, then we can update accordingly but no reason to hold up other browser
vendors and the rest of W3C now.

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

Received on Friday, 10 October 2014 14:29:07 UTC