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 6:35 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/9/14, 4:16 PM, Ryan Sleevi wrote:
>
>> I think we're saying the same thing, just differently, in that algorithm
>> normalization allows an ES NULL value to be propagated through, right?
>>
>
> null value.  Yes, for nullable members.
>
>
>  I didn't think default values were legal for union types
>> (CryptoOperationData).
>>
>
> They are legal as long as it's a valid default value for a type in the
> union.


>
>  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)
>>
>
> Yes, I'm saying we should fix this in Web IDL as needed .  More
> importantly, I'm saying that we should not allow Web IDL to constrain our
> API design in cases when it's obviously leading to a worse API.  If that
> happens, that's a problem with Web IDL.
>

Agreed - it's just a matter of identifying when something is "obviously
worse" :)

FWIW, I don't think Web IDL currently permits it, at least by the grammar.

DefaultValue = ConstValue | string | " [" "]"
ConstValue = BooleanLiteral | FloatLiteral | integer | "null"

So there's no IDL-way to say CryptoOperationData label = ArrayBuffer(0)



> Most simply, we could add some syntax in Web IDL to require a dictionary
> value to be present in a dictionary.  This has come up a few times now.


Yeah, this would have been nice.


>
>
>  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%
>>
>
> I think you want "the initial value of %ArrayBufferPrototype%.slice" here.
>
> -Boris
>