On Sat November 6 2004 19:16, Nathaniel Borenstein wrote:
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"?
No, in a case where message/rfc822 inside multipart/signed is
known to be mangled by some particular transport,
application/rfc822 would be used instead. I suspect that
message/rfc822 works fine in the vast majority of cases
provided that the applicable existing canonicalization rules
are applied to valid message/rfc822 content. Use of
application/rfc822 would be for pathological cases.
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?
No. I'd have it leave the media type unchanged.
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
In your example scenario, if you send a signed message/rfc822
and the signature is unverifiable due to a mismatch (as opposed
to something like lack of an available public key), and if having
a valid signature is deemed important, I would report that the
message signature could not be verified, and ask you to resend
it. If you had reason to believe that the mangling was due to
some improper manipulation of the message/rfc822 content, you
could package it as application/rfc822 (or application/octet-stream
w/o having to have a new media type registered for this case).
On receipt, the decoding application (probably an MUA) would
save the result as a file, which could be handled by any application
that can read message/rfc822 (I am presuming that when you
package the content as an application type to work around the
mangling, that you include a brief note indicating that the
content is in fact of type message/rfc822, but relabeled specifically
to work around the signature invalidation issue). I'm not
advocating building anything into signature algorithms; I'm
suggesting a human workaround agreed upon by the parties
involved in the end-to-end communication.