ietf-smime
[Top] [All Lists]

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

2000-12-18 13:21:02
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.