Re: On optionality

Sent from my iPhone

On Nov 27, 2012, at 11:07 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:


On Nov 27, 2012 9:12 PM, "Mike Jones" <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
>
> Reading this thread, I feel that it's important to reinforce a factual point that Mark made below.  Removal of pre-provisioned keys from the main specification was *not* discussed at the meeting.  There is no demonstrated consensus to do so.

As recorded consensus during the face to face, and as proposed on the list, removing key storage and using existing web storage mechanisms is what was proposed to and agreed upon, and has been done.

The WG decision on structured clone - which explicitly states 'for non token-backed keys' - *can* be implemented without removing support for pre-provisioned keys. Simply constrain KeyStorage to pre-provisioned keys.

This is what the editor should do. Not attempt to remove an important feature he does not like as an undiscussed side-effect of a different decision.

KeyStorage would then be ripe for renaming, redesigning, moving the keys attribute to navigator or a separate document, all of which could be fine for me. The editor could even raise an issue to the effect that some or all of the above should be considered.


I am aware that pre-provisioned keys are still a matter of discussion. This is not disputed. We discussed them until the end of our last call, as we continue to do so for our next call. It is an orthogonal issue as to where **and how** pre-provisioned keys are to be handled. I am not claiming consensus has been reached on that. It is still an open issue in the spec and a point of discussion.

> I believe that it would be a breach of the working group process to do so without working group consensus.  Changes of that nature are beyond the discretion afforded an editor, at least as I understand the role.
>
> As an editor (of IETF specs), I'm well aware that the editor's job is to implement the working group consensus - not to implement my own viewpoint.  I assume that it must be the same in the W3C.  For the process to work, that's the way that it must be.
>
>                                 Best wishes,
>                                 -- Mike
>

As Harry is frequently fond of reminding me, the W3C process is markedly not the same as the IETF. This is spelled out in
http://www.w3.org/2005/10/Process-20051014/

In the same way that consensus is permitted during face to face and telecons, there is significantly greater flexibility afforded to authors and editors of specs. You find this very specially documented within the Editing guidelines in the W3C, and you can see this further described in the webapps WG for a practical application. For example, both documents clearly establish and affirm that editors are not required to bring everything to the list first, which is very different than IETF. In fact, several groups (including the quite successful WebApps WG) state their process as "Edit first, review later".

In the light of how you are choosing to use this discretion, I propose we move to a more IETF-like process in this group.


Further, consensus is not required for every change, but rather for every PubRules progress change. Our next step is LC in Feb 2013, and the process is described at http://www.w3.org/2005/10/Process-20051014/tr.html#last-call - or on the next *formal* publication of a WD (not the weekly editors updates)

Until such a time as LC/PR/CR, specs remain highly malleable and subject to constant change as discussion - and proposals - change. Such changes do not require consensus or voting - and indeed, Editors, as Authors, are expected to be proposing and expanding text throughout to serve as discussion points. This remains true even as we publish WDs for the heartbeat requirements. This is, as you can plainly see, **very** different than the IETF model. Consensus is measured when advancing the document - CR, PR, REC - not line by line, edit by edit, feature by feature - and until advancement, not even issue by issue. The reason it has been as such has been due to lack of good diffs - solved by Mercurial now.

Regardless of these important facts about editorship, it is clearly evident these things: there was recorded clear consensus for removing **KeyStorage** (and any other form of custom **storage**, as affirmed and voted in the F2F) and there is not clear consensus on where and how pre-provisioned keys work. For these reasons, it is left as an open ISSUE to be resolved - with the previous strawman removed - as we review proposals. Per W3C rules, we **do not** need to reach consensus until advancing a stage in the process, and that ongoing Editor's drafts are just that - Editor's drafts.

Because this is such a hot topic, it has been removed until we reach agreement if, where, and how pre-provisioned keys are addressed. This is not a unilateral declaration of LC - this is just reflecting "Work in Progress. TBD."

We will not agree to the heartbeat publication if this feature - which was in FPWD - is removed.

...Mark