- From: Mike Jones <Michael.Jones@microsoft.com>
- Date: Tue, 10 Jul 2012 18:38:38 +0000
- To: Ryan Sleevi <sleevi@google.com>, Seetharama Rao Durbha <S.Durbha@cablelabs.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, David Dahl <ddahl@mozilla.com>
- Message-ID: <4E1F6AAD24975D4BA5B16804296739436657EEE5@TK5EX14MBXC283.redmond.corp.microsoft.>
I agree that error handling needs to be fully specified. From: Ryan Sleevi [mailto:sleevi@google.com] Sent: Tuesday, July 10, 2012 10:43 AM To: Seetharama Rao Durbha Cc: public-webcrypto@w3.org; David Dahl; Mike Jones Subject: ISSUE-1: Mandatory algorithms (was Re: ISSUE-3: Algorithm discovery) On Tue, Jul 10, 2012 at 10:22 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote: On 7/9/12 7:26 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote: >>Note that none of the above semantics would necessarily be altered by a MUST-IMPLEMENT registry (ISSUE-1), since there would still >>need to be some form of error handling for invalid constants/strings and for unsupported key+algorithm+operation tuples. The difference is whether the developer needs to 'explicitly' catch UnsupportedAlgorithmException and 'do something about it', or 'just not bother', as the algorithm they picked is guaranteed to be available. Errors caused by invalid constants/strings must be caught at development time. I do not believe this is a reasonable approach, nor does it seem to be encouraged by the recommendations for W3C standard web APIs. [1] [2] [3]. My comment was reflecting a the need to have the error handling state machine fully defined in the spec. Failing to specify what happens when an invalid constant/string is provided means the API is incomplete, and developers have no way of knowing what will happen. Will the U-A just crash? Will the API ever call the onerror callback? If not, what happens if the user keeps calling processData() and supplying more data? Will it cause a syntax error that causes all JavaScript to fail executing on the page? When there (and there eventually will) exist two different sets of MUST-IMPLEMENT, how will the web application behave then? When SHA-1 is broken, or SHA-3 is the new MUST-IMPLEMENT, how will that be addressed? If we update the specification, and say "SHA-1 is no longer MUST-IMPLEMENT because it was broken", what does that mean for web applications that were using SHA-1? What will their execution environments be like? Will it break all script on that page? For interop testing and for reference implementations, I do not believe we will be able to escape the need to specify error handling. Which is why I believe that these concerns remain wholly independent of the discussion of MUST-IMPLEMENT question. Because we MUST have error handling, we implicitly have discovery. The only question is whether we want to use error handling as the /only/ form of discovery. [1] http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0058.html [2] http://scriptlib-cg.github.com/api-design-cookbook/#don-t-use-numerical-constants [3] http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis#privacy-enhancing-api-patterns
Received on Tuesday, 10 July 2012 18:39:19 UTC