Interop requirements for extensions

TL;DR: what is the problem, if any, in marking extensions as 
"informative" (v. normative) when moving to CR, in the absence of prover 
interoperable implementations?


During the WG call on Wednesday, Ralph, acting as director, pushed back 
on publishing not-yet-implemented and not-yet-proven-to-be-interoperable 
extensions as normative.  He offered the WG the option to still publish 
them but flagged as informative, marking the extensions as "at risk" 
during the present transition to CR.

I heard some objections from the WG, but I don't understand those yet. 
Now's your chance to make the case in writing.  If you think we need 
something different make the case for it, knowing that doing so might 
delay publication.

I have proposed text below (as has John, in private mail) that takes the 
director up on the offer that would still allow the WG to publish 
unimplemented or untested extensions.

-- Sam




-------- Forwarded Message --------
Subject: Re: Transition Request: Web Authentication: An API for 
accessing Public Key Credentials Level 1 to Candidate Recommendation
Date: Fri, 16 Mar 2018 17:06:30 -0400 (EDT)
From: Samuel Weiler <weiler@w3.org>
To: Ralph Swick <swick@w3.org>
CC: John Fontana <w3c@yubico.com>, chairs@w3.org, Philippe Le Hegaret 
<plh@w3.org>, Team Archive <w3t-archive@w3.org>, Mike Jones 
<Michael.Jones@microsoft.com>, Anthony Nadalin <tonynad@microsoft.com>, 
Angelo Liao <huliao@microsoft.com>

On Fri, 16 Mar 2018, Ralph Swick wrote:

> I don't yet see (a version of) this in the Editor's Draft.

It is not in the Editor's Draft (contrary to what you were told 
earlier).  It is in the (unpublished) CR.

The current (as of 15 March) text reads:

For the Web Authentication specification to move to Proposed 
Recommendation we must show two independent, interoperable 
implementations of the Web Authentication API in browsers. We have 
already completed a portion of this work at two informal interops with 
implementations from three browsers (Chrome, Firefox, and Edge). These 
initial compliance tests have yielded relevant datasets that have been 
used to improve the specification. We will have multiple interoperable 
implementations of at least one extension – AppID, validating the 
extensions framework. Some other extensions may not have multiple 
implementations at the time of the PR transition, and are therefore at 
risk. We have a suite of initial compliance tests that have been 
committed to the W3C Web Platform Test repo and additional improvements 
to the tests will be required for the move to Proposed Recommendation

> Please explicitly enumerate in the SoTD those extensions that are at risk; 
> i.e. are all of 10.2 through 10.9 At Risk?

Yes.

> If you only label features as "at risk" then the usual expectation is that 
> those may be removed from the specification at Proposed Recommendation 
> transition if you are not able to demonstrate implementation experience.  As 
> an alternative, you might move those features from normative to informative. 
> If the WG wishes to have this alternative available please state in the SoTD 
> that the "at risk" features will either be removed or made informative.

I propose:

For the Web Authentication specification to move to Proposed 
Recommendation we must show two independent, interoperable 
implementations of the Web Authentication API in browsers.  We will also 
have multiple interoperable implementations of the AppID extension, 
validating the extensions framework.  All other extensions are "at 
risk".  If there are not multiple interoperable implementations, each 
may independently be removed or made informative at Proposed Standard.

We have had two informal interoperability tests with implementations in 
three browsers.

[This proposed text also removes many details re: the testing to date, 
that, IMHO, doesn't need to be in the spec.]

-- Sam

Received on Friday, 16 March 2018 21:16:00 UTC