Re: On optionality

Sent from my iPhone

On Nov 29, 2012, at 1:11 AM, "Harry Halpin" <hhalpin@w3.org> wrote:

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

The proposition at the F2F begins 'For non-token backed keys ...'. Whatever this means, it is not meaningless. There is therefore a class of keys to which the decision does not apply. So, no, it was not agreed to wholesale replace KeyStorage, only that KeyStorage would not be used for a certain class of keys.

I would argue that the class of keys excluded from the decision is exactly those that were not mentioned during the discussion and includes pre-provisioned keys (which in practice are often backed by hardware security modules aka tokens).

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

That's fine as a plan, but we have to go there in baby-steps, unfortunately.

> or change the original KeyStorage text (or MarkW's amendments around Key Discovery) to a different color in the API and highlight the issue

That's fine.

> , keeping the alternative structured clone text next to it.

The structured clone text is not 'alternative'. It is fine for generated, derived and imported keys.

> 
> Does that sound reasonable?

With the qualifications above, yes.

...Mark

>> 
>> 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 16:11:58 UTC