> There may be a way around that; simply define a discrete media
> type that otherwise looks like message/rfc822 -- maybe
> application/rfc822 a la message/http vs. application/http. That
> discrete media type could then have protective encoding applied
> for transport without violating the rule regarding identity
> encodings of composite media types. Of course that won't be
> "transparent" in the same sense as message/rfc822
And the only difference would be that if you were signing it, you gave
it the primary type "application" instead of "message"? That makes me
unhappy because now we're saying that the data type depends on the way
the data is being protected/wrapped/used. (It's like saying I'm a girl
if you put in me in a gown, but a boy if you put me in a tux.) Let's
say that I forward you a message that is encapsulated as a
message/rfc822 object. Imagine further that at the outgoing gateway
from my email domain, a PGP signature is being applied. Would you have
the software that is doing the signing also change the content-type of
the embedded object? Would you have decoding software change it back?
If so, what you're really doing is building into the PGP signature
algorithm a small "transfer-encoding" that specifically protects
headers in a message/rfc822 object and nothing else. I'm not saying
that wouldn't work, but there's got to be a prettier way to do
things..... doesn't there? -- Nathaniel
The significant problem with the encapsulation approach is the same as its
significant advantage: It renders the content opaque to MIME readers.
We go around this particular maypole all the time and it is always the same:
You either allow near-ubiquituous access to the content, which invariably leads
to content modification (no matter what the standards do or do not say) or you
encapsulate opaquely, in the process rendering the content hard to access.
This is fundamental and irreconcilable, and is always what trips up proposals
along these lines.
Ned