- From: Jeff Jaffe <jeff@w3.org>
- Date: Sun, 02 Nov 2014 09:22:38 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Philippe Le Hegaret <plh@w3.org>, public-w3process <public-w3process@w3.org>
On 11/2/2014 5:20 AM, Anne van Kesteren wrote: > On Sun, Nov 2, 2014 at 8:23 AM, Jeff Jaffe <jeff@w3.org> wrote: >> This is a specific example of something more general. > Any examples of non-security related requirements that we botched? > > We are certainly not perfect! For example, I've received considerable input that our standards get out of date quickly. So much so, that we are looking at introducing a Living Standards-like capability [1]; at least to deal with Errata. [1] http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0004.html More to the point - about things that we botch where early attention would be useful - (while I'm not an expert in accessibility) I'm told that we need more attention on accessibility, and that web accessibility continues to be a challenge for people with disabilities. Perhaps you argue, however, that for security (more than other areas) if we don't start with security retrofitting later is harder. This is certainly a plausible argument - but it still leaves open the question as to what is the best solution. Oftentimes an FPWD is very minimal in completeness. Fundamental changes in design; changes in author; new security exposures can easily creep in during the path from FPWD to REC. So a review before FPWD is not a panacea. Who is best to judge when is the best time for the security review? The current philosophy is to require that a set of things get done before CR - and leave it to the WG to determine the best timing. That is why I suggested requiring to do before CR and suggesting to do it early (and I might add early and often).
Received on Sunday, 2 November 2014 14:22:49 UTC