Peter:
If you look at the structure, there are no hash indicators before-hand. In
fact the document explicitly says don't put in a messageDigest attribute.
I am making the analogy with signedData and authenticatedData in order to
give one example where a creator wants to stream and can only create an
attribute after having processed all the data.
How would you then insert such the attribute on the fly?
You don't. What I said was that it is more important to make sure that
things are good for the validator and not for the encoder. The encoder
knows what is going to be happening and can live with not streaming. The
validator MUST know in advance what is going to happen in order to be able
to set things up correctly.
I do not agree with this argument:
If a creator should/must/could live without streaming, then I would
think that SignedData and
AuthenticatedData also should have their signedattributes before in order to
have maximum information about what to do with the data.
When faced with streaming trade-offs in the past, we have usually
considered the recipient as the one that needs to be able handle the
stream efficiently. This is because there are many situations where
there is one originator and many recipients.
Russ