1-pass streaming follow-up

On our last call we discussed 1-pass versus 2-pass streaming with respect to the XPath Streaming Profile [1]. Meiko provided a use case, summarized in email [2] regarding the benefits of 1-pass verification.

The suggestion during the call was that the group focus on 1-pass streaming in the XPath profile.

Note that the current XPath profile draft states in section 2 that the profile is 1-pass, and summarizes what this means in the following list. We might want to add to that some text about the implied constraints on applications -  for example:

"This one-pass profile implies certain constraints, in particular,  Applications should not have ds:References pointing to earlier portions of the document in which they occur."

What other constrains should we list? 

Some issues may require deeper understanding of application requirements and for application information to be passed across the API.

In particular, if an application only requires a portion of content (e.g. the medication information in Meiko's example) then only that portion would need to be buffered awaiting signature verification before passing to the application. Thus the buffer size could be greatly reduced but to do this the signature verification processor (if separate from the application) needs to know what is to be returned.

I'm not sure this is in scope for the WG but we probably should make a note of this in the document.

For those who had questions about streaming on the call, are you able to please post to the list a more detailed question?

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/2010/08/17-xmlsec-minutes.html#item05

[2] http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0038.html


This should complete ACTION-629

Received on Monday, 23 August 2010 20:05:20 UTC