Forwarded from an external source for discussion in case anyone has any
thoughts...
At 08:33 AM 10/14/2000 +0000, Peter Gutmann wrote:
This seems like an interesting suggestion. What do you think?
As a heads up, the French and Norwegian delegates are interested in a
change to the SMIME RFC. They have said they will propose separately an
extension of the ID for a compressedData S/MIME content type. Extension
consists of an additional field to indicate the uncompressed size of the
encapsulated content. I don't know how soon this will happen.
Hmm, I can see some problems with this, it assumes you know in advance how long
the data stream will be which isn't always the case. Adding an INTEGER
OPTIONAL is pretty easy, but I wouldn't want to mandate its use because it'll
cause problems for any streaming implementations (for example one of the uses I
mentioned a while back was for securing EDI messages which can be ~100MB long,
there's no way to tell in advance just how long they'll be because the systems
processing the data can't afford to spool 100MB of data to disk while they wait
for the end to appear). I don't have a problem with adding something like
this, I just wouldn't want to mandate it.
(Having said that, an indication of what the decompressed size info would be
useful for would also be interesting, I can't think of much offhand where it'd
be necessary but I haven't really given it too much thought).