- From: Harry Halpin <hhalpin@w3.org>
- Date: Thu, 29 Nov 2012 10:11:25 +0100
- 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