ietf-822
[Top] [All Lists]

Re: 2 MIME questions re: message/rfc822

2004-11-06 12:24:11

On Fri November 5 2004 08:32, Nathaniel Borenstein wrote:

Let me be 
the first to say that at least part of the problem here may be in the 
MIME standard itself.

This situation could in theory be avoided by simply applying a suitable 
content-transfer-encoding to the embedded message/rfc822 object 
*before* PGP-signing it, thus protecting against line wrapping.  
However, this is explicitly *prohibited* by the MIME standard, as per 
RFC 2046:

 >   No encoding other than "7bit", "8bit", or "binary" is 
permitted for
 >   the body of a "message/rfc822" entity.

That may still have been the right design decision -- forbidding 
protective C-T-E's for multipart and message makes message structure 
much more transparent -- but as far as I can tell, there is NO 
legitimate way to encode and sign a message/rfc822 object to protect 
against line wrapping in the header fields of the embedded 
message/rfc822 object.

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.