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

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

Peter Gutmann wrote:

> A number of users of my code are doing streaming S/MIME (email gateways and the
> like) where they really have no idea how large a message is, and where they
> can't afford to buffer more than a few hundred kB (I'm not trying to say here
> that everyone should do X just because I see a need for it, just pointing out
> that there is real use of streaming going on out there, in fact I've made
> several changes to my code in the last year or so specifically to handle one-
> pass streaming operations).  Perhaps the dominant scenario for end-user-based
> S/MIME is all-at-once send/receive, but for things like S/MIME gateways I'd say
> there's a fair amount of streaming with one-pass processing constraints because
> the average gateway can't handle the 1000 20MB Powerpoint files the salesdroids
> just sent out in main memory.
>

Peter,

    I take all this at face value.  I like the term "salesdroids".


>
> Having said that I don't want to discount the option, but it'd need some
> thought as to how you're going to manage interoperability - the receiver would
> need to publish some sort of S/MIME capability info to say "I need to be sent
> uncompressed size info".
>

    The way I imagined this, it would not necessarily be an "I need", but an "I can
use".  The receiving agent can always reconstruct this information.  It just takes
time.

Bertrand,

    Can you elaborate the scenario for how this would be used?  Is this something
that your receiving agent would NEED, or just an advisory field?  Have you done any
implementation or testing with this field?


>
> >The real problem with this is the timing.  I thought this completed WG Last
> >Call back in November.  Can we still influence this?
>
> Not at the current state AFAIK and it doesn't seem like a terribly critical
> change, however it shouldn't be too hard to do a short RFC which defines an
> additional OID for foo-with-size-info if there's a real demand for it and if
> the potential interop issues can be resolved (note that the current draft is
> just a framework for doing compression with one standardised algorithm defined
> to provide interoperability, there's nothing to stop anyone else from defining
> their own algorithms and dropping those in alongside the existing one just like
> you can do for the other content types).
>

    This seems like an awful lot of bother for a piece of advisory information to
me.  However, this is an interesting thought.  If I understand you correctly, this
means packing the uncompressed size value into the 'eContent' field after the
compression.  It strikes me that you could also pack such data into the algorithm
ID parameters.  Either way, I think these complicate interoperability.  Instead of
an option field that can be easily ignored by receiving implementations that don't
choose to support it, identifying these mechanisms through the algorithm OID
creates a separate algorithm space that has to be supported to achieve the same
level of interoperability even if the parameter is ignored.

Chris