On Sun November 7 2004 16:06, Bruce Lilly wrote:
On Sat November 6 2004 19:16, Nathaniel Borenstein wrote:
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.
[...]
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).
Just to clarify two points:
1. The primary reason to have application/rfc822 would be to
obviate a manual note (with application/octet-stream) that
the content is to be treated as a message; it's shorthand.
2. In addition to using the application type to work around
message handlers that don't respect multipart/signed,
transport encoding could be used as additional protection
with an application type (explicitly forbidden with composite
types).