Web Crypto Spec Updates for ArrayBufferView, ArrayBuffer, and Streams

WG,

In the IE team we believe that defining overload methods that use ArrayBuffer for the operations below make it easier for developers to use the APIs without having to be constantly creating new objects or casting. From our perspective there is no internal difference on how ArrayBuffer or ArrayBufferViews are handled internally.

In addition, the table below contains some proposed new methods to process Streams. This would optimized the memory footprint of the operations.  The expectations is that for each of the Stream methods we would have a stream result from which developers could read information.

See Attachment #1 (table1.html)

We expect the following processing to take place as part of the Streams:
1. Open a stream
2. Pass the streams as input
3. Create output stream
4. Read data from input stream when available
-->Input buffer sizes are defined by the UA
5. Process the data from input stream
6. Put processed data into output stream
7. Generate and send progress event
8. If the stream is not done, goto step 4.
9. Continue normal processing of data

We also believe it is better to return an ArrayBuffer type for the operations below because it avoids the implicit type cast we would have to do with an ArrayBufferView.  In other words, when returning an ArrayBufferView, we methods need to cast the ArrayBufferView to a specific type (e.g. Uint8Array, Int8Array, Int16Array, Uint16Array, etc.).  Unfortunately, there is not enough information provided by the API usage to guess correctly at the correct view type. 

In addition, to avoid the potential casting of ArrayBuffer into ArrayBufferView we believe it would be useful to create a new type called AlgorithmInputData:
-->typedef (ArrayBuffer or ArrayBufferView) AlgorithmInputData;

This would allow the various input dictionaries to be able to support input variables with either ArrayBufferView or ArrayBuffer.

Our proposal is to change the following Algorithm result to ArrayBuffers (empty fields are unaffected).

See attachment #2 (table2.html)

Thanks,

Israel