It seems that message/rfc822 is used to encapsulate an entire message. In
this case, we want to repeat a subset of the RFC 822 header lines from the
current message, and we never want to duplicate the body.
The required support for message/rfc822 is attractive, but I am not sure
that is has the correct semantics. Can you explain your idea further?
At 06:39 PM 12/21/2001 -0800, you wrote:
This is getting much more complicated than it needs to be, and is
likely to break interoperability with non-enhanced clients.
The simplest thing to do is to say:
- Senders should put the minimum that they want in the unprotected headers
- Senders include as much as they want protected in a
text/rfc822-header part at the beginning of a multipart/mixed message
- Enhanced clients should display the message with the headers from
the text/rfc822-header part moved to where the user thinks he/she
sees the headers. In the case of headers that are in both in the 822
message and in the text/rfc822-header body part, the latter wins
(because it is protected)
Even simpler than this is to use message/rfc822. It has the advantage that
conformant MUAs are supposed to handle it. There is no such requirement for
- The moved-up headers may cause side-effects that the MUA should act
on. For example, if the Cc: in the 822 headers is
but the Cc: in the protected headers is "amy(_at_)example(_dot_)com", the
to all" action should include amy but not include bill.
The rules for header merging from message/partial can probably be applied
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and
CONFIDENTIAL. Access by any other party is unauthorized without the express
prior written permission of the sender. If
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender.