Re: PROPOSAL: Close ISSUE-18: Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics?

Yes, Richard's comments were not related to the ISSUE that was
originally opened, so I don't think they represent a concern to CLOSE
the issue.

On Thu, Feb 7, 2013 at 6:25 AM, GALINDO Virginie
<Virginie.GALINDO@gemalto.com> wrote:
> Richard, Ryan, and all,
>
> Provided that the text is clarified about the onprogress, we will have a proposal for delivering progressive result - when applicable.
>
> Is it ok to close that issue and do not implement the streaming operation with URI semantic ?
>
> Regards,
> Virginie
>
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: mardi 5 février 2013 15:39
> To: Ryan Sleevi
> Cc: public-webcrypto@w3.org
> Subject: Re: PROPOSAL: Close ISSUE-18: Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics?
>
> Ok, thanks, that does clarify things.  That could be clearer in the current text.  What we have now is:
>
> """
> When the process(ArrayBufferView data) method is called, the user agent must run the following steps:
> ...
> 4. If the underlying cryptographic implementation for the specified algorithm supports multi-part cryptographic operations, asynchrously process data, ...
> ...
> When a CryptoOperation is said to process data, the user agent must execute the following steps:
> ...
> 4. Queue a task to fire a simple event named onprogress at the CryptoOperation.
> """
>
> That reads to me as if every call to process() results in an onprogress() call.  Would it make sense to add an "if" clause before the instruction to queue the simple event?
>
> --Richard
>
>
>
> On Feb 4, 2013, at 4:42 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> 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 Thursday, 7 February 2013 17:59:59 UTC