Re: Interop requirements for extensions

On 2018-03-16 05:15 PM, Samuel Weiler wrote:
> 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.

To be clear, the only change for the CR would be to say that *if 
implementation experience has not been demonstrated for those "At Risk" 
features when the WG asks to advance this specification to Proposed 
Recommendation* then rather than removing those features from the 
specification (the common approach in W3C), the features would be 
changed from normative to informative.*

That is, the CR can continue to propose these features as normative.

> 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.

I interpret the proposed text as matching the clarification above.

-Ralph

> -- 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 Saturday, 17 March 2018 13:59:29 UTC