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

["Bonatti, Chris" <BonattiC@xxxxxxxx>]

Peter Gutmann wrote:

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

Peter,

    Of course, since the 'CompressedData' wrapper itself is an option I guess we
needn't bother with the whole draft.   ;-)   Sorry, I couldn't resist.

    I have a bit of a soft spot for "useful options".  If they aren't implemented,
they'll die on their own.  We never innovate if we don't strive, and all that.  A
lot of proprietary compression structures DO store this value, so it seems like
there is some weight on the side of it being practical.  I don't think there are
actually that many streaming scenarios in S/MIME.  The dominant scenario is still
that of e-mail.

    The real problem with this is the timing.  I thought this completed WG Last
Call back in November.  Can we still influence this?

Chris B.