Subject: Re: compressedData

From: [email-masked] (Peter Gutmann)
Date: Thu, 26 Oct 2000 14:53:57 (NZDT)

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).