Re: Spec for RSA-OAEP doesn't say what to do for null or missing or array buffer view labels

On Wed, Jul 9, 2014 at 1:09 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/9/14, 3:45 PM, Ryan Sleevi wrote:
>
>>     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.
>>
>> Can you clarify? Step 12.1.1 handles the "not present" case.
>>
>
> 12.1.1 only applies to non-nullable members.


I think we're saying the same thing, just differently, in that algorithm
normalization allows an ES NULL value to be propagated through, right?


>
>
>  To make sure I follow:
>>
>> All dictionary members can be "not present", but for the specs purpose,
>> any dictionary member listed in an algorithm dictionary, that isn't
>> optional/nullable (aka ?) MUST be present.
>>
>
> I think this conflation of "nullable" and "optional" is not a good idea,
> though it's a common mistake people coming from C/C++ make with Web API
> design.  If you just want a non-optional dictionary member, you should
> throw if it's "not present".  Things should be nullable only when you
> explicitly want to allow JS null as a valid value that doesn't trigger an
> exception, not because you want to indicate that they're allowed to be
> missing.
>
> One option, by the way, is to make sure we have default values available
> for all the things you want to allow to be missing, using those default
> values in dictionaries as needed, and then "not present" will just cause
> exceptions, since it will mean there was no default value.


I didn't think default values were legal for union types
(CryptoOperationData).
I also didn't think it was legal for ArrayBuffer/ArrayBufferView, since Web
IDL currently (AIUI) treats them as object types, and there's no way to
represent constant object types (which would be needed for default value,
AIUI)


>
>
>  12.1.2 handles the case where it's optional/nullable. If a field is
>> optional/nullable, and not present, it doesn't get set on
>> normalizedAlgorithm. If it is present, and null, then
>> normalizedAlgorithm is set to the null value (rather than 'not present')
>>
>
> Yes, agreed.
>
>
>  The concern is that the prose for label doesn't handle things the same
>> as AES-GCM's prose for additioanlData (present and not null), right?
>>
>
> Yes, exactly.
>
>
>  Can you recommend language that would satisfy this? ES6 does not
>> (AFAICT) refer to these built-ins as "Canonical", hence the desire to
>> find appropriate language.
>>
>
> ES6 calls these "initial values", I believe.  See e.g. the table at
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-
> well-known-intrinsic-objects (which is also how the rest of the spec
> refers to these things; by the names defined in that table).
>
>
>  The choice of ArrayBuffer.prototype.slice was to reflect the ES6
>> language,
>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-
>> arraybuffer.prototype.slice
>> , which is what it defines the canonical type as (e.g. it doesn't use a
>> %Foo%.prototype.slice notation like TypedArray)
>>
>
> I'm not sure I follow the distinction.  The spec section you're pointing
> to defines the initial value of ArrayBuffer.prototype.slice....
>
> -Boris
>

Just to make sure linguistically we're on the same page. You're proposing I
refer to the value of %ArrayBufferPrototype%.slice, right? Using the
aforementioned table as the definition for %ArrayBufferPrototype%