It seems I'm going to be trying to tackle the problem of implementing
a converter from 8BITMIME to 7bit. I have some comments on
draft-ietf-822ext-ime-imb-01.txt from that perspective.
6.2.2 states:
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the encapsulated headers embedded in the bodies
of messages of type "message."
This wording would seem to imply that if an agent had a message
containing an message/rfc822 with 8-bit data in it, it could not
convert it for transport over a 7-bit channel. The prohibition above
would prevent the agent from modifying the Content-Transfer-Encoding:
header imbedded in the message/rfc822, and it certainly can't apply a
transfer encoding to the entire message/rfc822 itself.
I don't think this is intended.
The "clarification" about the transfer-encoding restrictions on
subtypes of "message" is more confusing than the original outright
prohibition.
The paragraph:
Certain Content-Transfer-Encoding values may only be used on
certain Content-Types. In particular, it is EXPRESSLY
FORBIDDEN to use any encodings other than "7bit", "8bit", or
"binary" with any composite Content-Type, i.e. one that
recursively includes other Content-Type fields. Currently the
only composite Content-Types are "multipart" and "message".
All encodings that are desired for bodies of type multipart or
message must be done at the innermost level, by encoding the
actual body that needs to be encoded.
Implies that all subtypes of "message" are composite, and thus
prohibit transfer-encodings.
The description of message/partial states:
Because data of type "message" may never be encoded in base64
or quoted-printable, a problem might arise if message/partial
entities are constructed in an environment that supports
binary or 8-bit transport.
This also implies that all subtypes of "message" prohibit
transfer-encodings.
6.2.2.4 seems to leave it up in the air whether any future subtype of
message can or cannot be transfer encoded. This is of no help to 8bit
to 7bit converters, which need to know whether or not they can
transfer-encode an arbitrary unrecognized subtype of "message".
I would be happier if we kept the outright prohibition on
transfer-encodings on subtypes of "message". All the existing
subtypes of message prohibit transfer encodings. Any new subtypes
which need to be able to be transfer-encoded can instead just go under
the "application" top-level type.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up