[Top] [All Lists]

Re: Proposed amendment to the Compressed data Content type for S/MIME

2000-12-18 09:13:08
"Bertrand BOUTELOUP" <bboutelo(_at_)capgemini(_dot_)fr> writes:

Can we add as an optional field the "SizeUncomp" field in the The compressed-
data type. SizeUncomp will be the size of non compressed data.

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
somewhere is feasible, but you can't mandate its use because it'll cause
problems for any streaming implementations (for example one of the uses I
mentioned ages ago 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).

The problem which arises in conjunction with that is that if you can't
guarantee there'll be an uncompressed size indicator present, you can't build
an application which requires it because it's then guaranteed to break if it
isn't there.  A corollary to that is that your application must be able to
function without the uncompressed-size-indicator, in which case its presence
becomes unnecessary.