Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> writes:
I think it is something that would be good to address if we are honest
about how long it will take to get into products. It doesn't need any MUST
or SHOULD. Wording to the effect of "future revisions to CMS SHOULD include
this extension" is appropriate.
OK... hmm, shouldn't it be "Future implementations of CMS SHOULD include this
extension"? The intent is to specify the behaviour of implementations, not
standards authors (if the latter is actually the case then gimme a minute to
crank out draft-ietf-smime-buy-peter-dinner-00.txt: "Pizzas compliant with
this document shall include one or more of the following: ...").
I think that your initial draft should also describe an option in
sMIMECapabilities that says "receiver can handle compression types a, b,
and c" so that S/MIME implementations can add this in in an orderly fashion.
Fairly easy, just include the compression AlgorithmIdentifier as a capability.
I strongly suspect that there'll never be anything other than zlib defined (at
least in the foreseeable future) so having to handle a single new OID
shouldn't be much of a problem:
-- Snip --
Implementations SHOULD use the SMIMECapabilities attribute to indicate their
ability to process compressed content types. A compression SMIMECapability
consists of the AlgorithmIdentifier for the supported compression algorithm, in
the case of the algorithm specified in this document this is is-alg-zlib with
parameters NULL. Alternatively, the use of compression may be handled by prior
arrangement (for example as part of an interoperability profile).
-- Snip --
Peter.