W3C home > Mailing lists > Public > public-webcrypto@w3.org > November 2012

Re: On optionality

From: Harry Halpin <hhalpin@w3.org>
Date: Thu, 29 Nov 2012 10:11:25 +0100
Message-ID: <50B726BD.7080408@w3.org>
To: Ryan Sleevi <sleevi@google.com>
CC: Mark Watson <watsonm@netflix.com>, Mike Jones <Michael.Jones@microsoft.com>, public-webcrypto@w3.org
On 11/28/2012 05:02 PM, Ryan Sleevi wrote:
>
> Please go read the PubRules and understand the W3C process.
>
> As stated repeatedly, but continually ignored, no features are being 
> removed.
>

Essentially,  the Editors Draft does not necessarily reflect Working 
Group consensus, although it is preferable that it do so, and the editor 
should in good faith attempt to do so. The editor does not need the 
Chair's permission (or the rest of the WG) to start editing the Editors 
Draft.

However, the Working Draft should reflect the consensus of the WG 
(although this is not always possible for every heartbeat), and 
*definitely* has to represent WG consensus by the time we get to Last 
Call. When not possible to get consensus on content, the WG should  get 
consensus to publish without content (which is fine by W3C process until 
we get to Last Call), but areas of active disagreement really should be 
highlighted so the public gives the correct feedback.

In Working Drafts such as our next heartbeat publication, where there 
are still open issues, the standard procedure here would be to highlight 
the issue in the Working Draft heartbeat as an open issue, including 
references to text in either other documents or alternative versions of 
the text in the document (often done in a different color).

The replacement of KeyStorage by structured clone was definitely a 
decision made by the WG in the f2f, however, I do agree that the WG did 
not fully think through the reprecussions on pre-provisioned keys and 
thus members of the WG may call for the issue to be re-opened. 
Technically, I might add I think pre-provisioned keys *are* compatible 
with structured clone, and MarkW's proposals in this space around key 
discovery are  one way forward).

Thus, we can either put KeyStorage and Key Discovery mechanisms in a 
separate document and point to that document (my preference) or change 
the original KeyStorage text (or MarkW's amendments around Key 
Discovery) to a different color in the API and highlight the issue, 
keeping the alternative structured clone text next to it.

Does that sound reasonable?
>
> The inclusion - or absence - of text within the WD is not reflective 
> of consensus of final features or implementation.
>
> Pre-provisioned keys remain as they have since day 1 - under discussion.
>
Received on Thursday, 29 November 2012 09:11:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:14 UTC