In the interest of testing whether there is a simple solution to a complex
problem, let me ask whether making app/mime subject to the same encoding
rules as message/* and multipart/* types will fix any/all the concerns
It certainly fixes them for me, and leaves the most desireable characteristic
of application/[s]mime intact: That most extant products will treat it as
I continue to be ambivalent about whether or not this characteristic is worth
the effort. On the good side, it is a mostly harmless addition, and may in fact
prove to be useful in other contexts. But it does add unnecessary complexity in
some cases, which is bad. However, it will definitely keep converters out of
multipart/signed in the short to intermediate term, which is good. But if
vendors simply add application/smime to their tables as a synomym for
message/rfc822 (which is wrong in several ways, incidentally) and fail to also
add proper support for multipart/signed, we've actually regressed rather than
progressed. But if vendors take the opportunity to fix multipart/signed
handling when they add support for application/[s]mime, we win big.
Fortunately he missed the pitchfork.
Unfortunately he missed the haystack.