Andrew Farrell <afarrell(_at_)baltimore(_dot_)ie> writes:
Also, you're not putting it in CMS, you're writing a supplmentary draft to a
RFC that going towards the light, so it'll be six months before you can even
get a draft of "CMS for S/MIME 4", which might make support of CompressedData
mandatory.
Given that it seems to take 1-2 years to get things from draft -> <anything
beyond a draft>, I don't think starting now will cause any major problems in
switching over - implementors will have at least twelve months before they
even have to think about whether they'll dedicate an hour before lunch or an
hour after lunch towards plugging zlib into their existing code (it took me
longer to write the draft than to implement it, it really is that simple). As
far as I'm concerned a non-MUST requirement is fine (either make it an explicit
SHOULD or an informational RFC), all I'm really after is a standard, non-
propietary (ie other than "define your own content type") way to integrate
compression into CMS.
[My motivation for bringing up compression at this time was a request from
someone who's transmitting batched EDI messages of up to 100MB secured with
CMS. This is used for medical and financial EDI, these guys *really* need
compression. So far the end users I know of have been using hacked-in zlib
compression but I'd prefer to provide something standard rather than a
proprietary add-on which nothing else supports. For this particular use a
SHOULD/informational RFC is fine, since the interoperability spec for
whatever it is they're doing can require "CMS with compression as per RFC
xyz". If any of the EDI/HL7 crowd are reading this, maybe they'd care to
comment]
What would be the best way to handle this? I can see several possibilities:
1. Supplementary draft with something like "MUST after 2000/2001/whatever"
(or just an implied "MUST once this reaches RFC stage", which is probably
the same thing)
2. Supplementary draft with SHOULD.
3. Informational draft.
4. <anything else?>
A solution I came up with the last time someone walked up to me and asked me
this (which works inside the current solidifying structure) is to define new
oids for "this compression followed by this encryption" and "this compression
followed by this hashing", but that run the obvious problem that you end up
with (# of hash algs + # of symmetric algs) * # of compression algs new oids.
Ick. That rapidly becomes unmanageable because of the explosion of OIDs.
Peter.