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