- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 4 Feb 2013 13:42:17 -0800
- To: Richard Barnes <rbarnes@bbn.com>
- Cc: public-webcrypto@w3.org
On Mon, Feb 4, 2013 at 11:53 AM, Richard Barnes <rbarnes@bbn.com> wrote: > On question related to this issue that arose as we were implementing: > > If a 'progress' event is sent to a listener while a progressive operation is in progress, what is the expected content of the 'result' attribute? It seems like the developer might expect partial output to be available, but that might be possible in all cases. By definition, progress should *only* be fired when output is available. Can you provide a more concrete definition of the problem you're imagining? Not all implementations can support progressive output (ex: AES-GCM or other AEAD decryption, which requires the full ciphertext for the tag validation). So in those cases, the progress event is not fired until the CryptoOperation is finish()'d. The same (non-progressive output) also applies to hash operations, for example. > > > > On Jan 31, 2013, at 2:08 PM, Ryan Sleevi <sleevi@google.com> wrote: > >> http://www.w3.org/2012/webcrypto/track/issues/18 >> >> I would like to propose that we CLOSE ISSUE-18. >> >> The current API already incorporates supports for progressive >> operations, such as encryption or hashing. Alternative semantics, such >> as those afforded by the Streams API proposal, have not progressed in >> their relevant working groups. Further, proposals for URI-like schemes >> (such as createObjectURL) have already shown to be significantly >> complex to implement correctly and efficiently. >> >> As such, I do not believe this is an issue for this working group to >> resolve, unless we're willing to hold further activity until the >> alternative specifications are proposed. >> >
Received on Monday, 4 February 2013 21:42:45 UTC