Paul Hoffman / IMC wrote:
This seems like the easiest solution to this issue. I'll add a sentence
that says "messages using application/mime are subject to the same encoding
rules as message/* and multipart/* types" to the next version of the draft.
Adding a sentence to the spec is not sufficient--many existing
transports and such will happily transfer-encode subtypes of application
that they don't know anything about. To apply encoding rules, the type
has to be moved underneath the message top-level type.
With the encoding restrictions, the type then becomes useless for
protecting the contents against transport encoding restrictions. I'm
left wondering what value it really has. Stuff encapsulated in this
type won't be readable by existing MIME implementations. If the
generator is willing to take the unreadability hit, why wouldn't they
use something which can really protect it against the transport, such as
signedData?