[Top] [All Lists]

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

2000-12-20 12:48:37
Peter Gutmann wrote:

A number of users of my code are doing streaming S/MIME (email gateways and 
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 
there's a fair amount of streaming with one-pass processing constraints 
the average gateway can't handle the 1000 20MB Powerpoint files the 
just sent out in main memory.


    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 
use".  The receiving agent can always reconstruct this information.  It just 


    Can you elaborate the scenario for how this would be used?  Is this 
that your receiving agent would NEED, or just an advisory field?  Have you done 
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 
you can do for the other content types).

    This seems like an awful lot of bother for a piece of advisory information 
me.  However, this is an interesting thought.  If I understand you correctly, 
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 
ID parameters.  Either way, I think these complicate interoperability.  Instead 
an option field that can be easily ignored by receiving implementations that 
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.


<Prev in Thread] Current Thread [Next in Thread>