- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 09 Jul 2014 15:33:49 -0400
- To: Ryan Sleevi <sleevi@google.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On 7/9/14, 3:16 PM, Ryan Sleevi wrote: > This is covered in > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-normalizing > ("if alg is an IDL object -> if member is nullable") I don't believe it is. Specifically, 1) Per step 12.1.2 if member is nullable and is not present then it's left as "not present". The fact that this is based on nullability, seems like a bug to me, by the way. 2) Per these steps, if member is nullable and present and the value is null, the value is left as-is. but the prose assumes the value will be an ArrayBuffer. Does this spec I do agree the ArrayBufferView case is covered by <https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#concept-clone-CryptoOperationData>, though that section should make it clear that it's the canonical (I presume) ArrayBuffer.prototype.slice that's used to do the copying. Now that I've read this normalizing section, I have a few other comments on it too: * "If alg is an IDL object:" is a bit confusing; people might think it means "object defined in IDL", which is not the intent. It should either link to http://heycam.github.io/webidl/#es-object or just drop the "IDL" part. * I'm not sure why we're returning Error instances from the "normalize an algorithm" steps instead of just throwing them as exceptions. The latter will do the right thing because WebIDL will convert them to rejected promises, and seems a lot less confusing. -Boris
Received on Wednesday, 9 July 2014 19:34:18 UTC